SDK Community enhancement project

The Great Apple

Big Cheese
Joined
Mar 24, 2002
Messages
3,361
Location
Oxford, England
Right... now we have the SDK it's time to get to work making Civ 4 into something very similar, only better. Firaxis have given us an excellent start, but there's only so much improvement they can justify for a commercial company.

The way I see it, what Civ 4 really needs is one large community project to enhance the default game, without actually changing the game. What I am proposing is a universal mod to improve the game - a sort of 'must-have' patch. This patch would improve the AI, the UI, as well as attempting to improve the performance of the game. The rules, however, should not be changed. Of course, mods which change the rules could be applied on top, but one big mod is going to be alot better than many small ones.

Tackling the points one at a time:

1) The AI - While it is good, there is always room for improvement. This part will probably take the longest, as each AI change will require extensive testing to make sure that it is actually an improvement over the already pretty damn clever AI. Probably the first step will have to be ask the community as a whole (especially the good players ;)) what they think is wrong with the AI, and then taking steps to improve it.

2) The UI - Work has already started on this, as most of the UI is implemented in python. Pretty much the same as it is at the moment - more info while avoiding too much clutter.

3) Performance - I think I read somewhere that the CTP 2 team managed to get the game to run perfectly on a system which was at half the minimum requirements when given access to the source code. We don't quite have all the source code, nor do we have access to the graphics engine, so I doubt we'll be able to manage this, but I'm sure there are improvements out there to be found.

4) Moddability - making the game more moddable for the community.

5) Bug Fixes - fixing silly little glitches.

6) Gameplay tweaks - it's quite easy to put enable/disable switches on these, and hide them away in a little menu. The will be off by default, but if the user wants to have them, he can enable them.

Now it seems to be that 1) & 2) should have disable switches put in for the puritans amongst us, but I can't see anybody objecting to 3), 4), or 5)

What I'm really looking for in this post are suggestions as to what people think I've got wrong/right here, as well as to sign up as many people who are willing to contribute to this project as I can.


As for myself, I've been looking with greedy eyes at the city AI for a few hours now, and I'd love to have a crack at fiddling with the rest of the AI scripts to tweak litte improvements here and there, although I'll say from the start that I probably can't really lead this project, as I don't have access to a compiler for 25 weeks a year.

If you are interested in joining we now have a private mod forum on CFC. To be able to access it you will have to go to "Group Management" in the UserCP (http://forums.civfanatics.com/profile.php?do=editusergroups),
and apply to join the "Civ4 Community Enchancement Project" group. I'll then have to approve you, and you will be able to see the forum right at the bottom of the main forum list (below Site Feedback). NOTE: This forum is more for implementation discussion rather than suggestions. Suggestions can be made here.

If I don't seem to be accepting you, but I do seem to be online then drop me a PM - it doesn't notify me automatically, so I have to remember to check whenever I log on.
 
I would like ta add a note :
the SDK is chance, but it is also a danger. As far as we talked about Python. Nearly everybody who is able to deal with notepad and with some very little experiences in any programming language was able to modify the game or at least to merge mods.
As soon as we talking about the SDK and c++ modifications, this will be not longer possible, because programming in c++ is not that easy than to program in python. Also it is not that easy two merge c++ code as it is in python. I'm quite sure, that this will change this wonderful community and mod scene in any kind.
Therefore one of the targets of such a project should be to keep things modular and simple for anybody else. In other words : as less as c++ modifications as possible, as much as needed. As modular as possible, as integrated as needed. How ever this could be realized.
 
12monkeys said:
I would like ta add a note :
the SDK is chance, but it is also a danger. As far as we talked about Python. Nearly everybody who is able to deal with notepad and with some very little experiences in any programming language was able to modify the game or at least to merge mods.
Partly true. I've taken a look at the files, and, from what I can tell without much testing, a few simple edits can change quite a bit. While I agree that more advanced changes would take quite a bit of skill, some things, for example, the weighting the AI puts on the food output of plots when founding a city, can be changed without much hassle.

As for combining mods, my idea here was to have a team who would work together on all aspects of the SDK, and produced a combined final product which anything can be overlayed onto. For example, while it would be possible to make one-man AI mods, it seems to me more people contributing to a joint AI mod has to be better - you'd not only get it done quicker, but you'd also have a much larger pool of testers.
12monkeys said:
As soon as we talking about the SDK and c++ modifications, this will be not longer possible, because programming in c++ is not that easy than to program in python. Also it is not that easy two merge c++ code as it is in python. I'm quite sure, that this will change this wonderful community and mod scene in any kind.
True, merging will be hard if there are many small mods, which is why I'm suggesting a large generic mod.
12monkeys said:
Therefore one of the targets of such a project should be to keep things modular and simple for anybody else. In other words : as less as c++ modifications as possible, as much as needed. As modular as possible, as integrated as needed. How ever this could be realized.
Personally, I can't see anybody wanting to take something out of their game with the result of improving performance at no loss of gamplay. I was thinking the AI and UI could be turned on/off with config switches.
 
12monkeys said:
Also it is not that easy two merge c++ code as it is in python. I'm quite sure, that this will change this wonderful community and mod scene in any kind.
Therefore one of the targets of such a project should be to keep things modular and simple for anybody else. In other words : as less as c++ modifications as possible, as much as needed. As modular as possible, as integrated as needed. How ever this could be realized.

I don't think it is that hard to merge c++ code with one qualification - as long as the changes have been clearly commented. But I agree completely with you 12monkeys, only make changes to the C++ where it is critical to do so, or to enhance the game where it is lacking i.e. not allowing health to be a yield type for specialists in cities.

I will make this pledge to the community (I hope you - 12monkeys, TGA, etc. will follow my lead):
I, TheLopez, will release the source code to any and all C++ changes I make in the SDK to facilitate the merging of my code into any other Civ4 related C++ code. I further pledge to clearly indicate changes made to the released SDK files in my releases.[/CODE]
 
As for combining mods, my idea here was to have a team who would work together on all aspects of the SDK, and produced a combined final product which anything can be overlayed onto. For example, while it would be possible to make one-man AI mods, it seems to me more people contributing to a joint AI mod has to be better - you'd not only get it done quicker, but you'd also have a much larger pool of testers.

This is definitly a pro for this project. As far as we can gather some qualified people. Anyway, I'm willing to contribute. You have your first volunteer! I would like to enrole as UI programmer (or anything else, doesn't matter;))!
 
TheLopez said:
I don't think it is that hard to merge c++ code with one qualification - as long as the changes have been clearly commented.

I saw a lot of code of different programming languages in my life (I have a secret past as professional programmer ;)) and you as well, as far as I know. So you surely know, that there are a lot of coders out there which can mix up a code very very easliy. And this includes me, when I look at my first steps in python! :).

I, TheLopez, will release the source code to any and all C++ changes I make in the SDK to facilitate the merging of my code into any other Civ4 related C++ code. I further pledge to clearly indicate changes made to the released SDK files in my releases.

Hehe :D! Yes, I join!
 
Well I'm willing to bring my C++ skills to the table, as well as any ideas I have. Although I do have to admit that in general I enjoy fiddling with models more than with code. I haven't had a chance to look at the SDK yet because I was in the middle of another unit when it came out (see what I'm saying), but from the bits and pieces I've seen so far it seems like a well written code which should make this undertaking easier.

I think you're on the right track with the idea of limiting this project on the AI, UI and performance. However, I would like to also suggest the addition of some features/properties that won't even need to have a toggle (as you suggested for AI and UI) because they will be accessed through XML. For example new domain types (like LAND+COAST), new mission types (I'm thinking here of better implementation of siege weapons), new improvement type (one that would allow combining improvements on a tile) and other things of that nature. So, obviously if people don't won't to use them they simply don't creat any objects that use any of these new properties.
 
Rabbit said:
Well I'm willing to bring my C++ skills to the table, as well as any ideas I have. Although I do have to admit that in general I enjoy fiddling with models more than with code. I haven't had a chance to look at the SDK yet because I was in the middle of another unit when it came out (see what I'm saying), but from the bits and pieces I've seen so far it seems like a well written code which should make this undertaking easier.
Heh - I got hit with that bug with Civ 3, though I can't affort Max, so I'm holding off until the blender scripts come up to the point where they are as good.
Rabbit said:
I think you're on the right track with the idea of limiting this project on the AI, UI and performance. However, I would like to also suggest the addition of some features/properties that won't even need to have a toggle (as you suggested for AI and UI) because they will be accessed through XML. For example new domain types (like LAND+COAST), new mission types (I'm thinking here of better implementation of siege weapons), new improvement type (one that would allow combining improvements on a tile) and other things of that nature. So, obviously if people don't won't to use them they simply don't creat any objects that use any of these new properties.
I hadn't thought of that, though it's a very good idea. Got to make sure it doesn't get out of hand with too many changes however.
 
I think this would be really great. Its always struck me as weird that Civ has never really inspired any true "community" type project like I've seen with some other games. I don't know any programming though, so I don't think I'd be able to help too much. Just voicing my approval :)
 
I reiterate my statements from the earlier SDK thread

I will be fiddling around with the SDK as well. As for what can/should be done in C++ I say keep it in Python/XML if possible (aka its not ugly/slow when done thier). Because its going to be a BIG hurdle for the average user to use modified DLL files (their going to be harder to combine, run, trouble shoot ect ect). I predict we will see much fewer combo SDK based mod packs unless developers realy make an effort to integrate their code to the greatest extent possible.

A lot of work should focus on just expanding the number of API calls we can make with Python, I myself have been infuriated by the fact theirs no call to remove the HolyCity tag, you can only move it another city. Clearly this is an example of Firaxis puting desisions about game play into the games core code rather then Python ware it belongs. Breaking down such barriers by simply creating new calls wont break any existing mod. Non C programers can then start playing with these new tools to enhance and diversify their mods.

I would see these type of enhancements as the top priority. With respect the TGA 3 priorites I rank them as follows. AI - 2nd, as mentioned the AI is already darn good and it will be mostly a matter of tweaking it rather then overhauling it. Performance - 3rd, Morres law means we would simply be subtracting a year off the age of the computer nessary to run the game, will people realy care about that in a few years time or will they care about gameplay. UI - 4th, its all in Python so shouldn't be included in a SDK based mod, python programers are doing a fine job at it already, I'm all for creating TOOLS for them but that falls under my Primary imperitive of more flexible calls.
 
Impaler[WrG] said:
I reiterate my statements from the earlier SDK thread

I will be fiddling around with the SDK as well. As for what can/should be done in C++ I say keep it in Python/XML if possible (aka its not ugly/slow when done thier). Because its going to be a BIG hurdle for the average user to use modified DLL files (their going to be harder to combine, run, trouble shoot ect ect). I predict we will see much fewer combo SDK based mod packs unless developers realy make an effort to integrate their code to the greatest extent possible.
I agree, which is why I'm suggesting combining them from the start, and trying to make something universal which nobody can say isn't an improvement. The average user won't need to worry about what we've done behind the scenes.
Impaler[WrG] said:
A lot of work should focus on just expanding the number of API calls we can make with Python, I myself have been infuriated by the fact theirs no call to remove the HolyCity tag, you can only move it another city. Clearly this is an example of Firaxis puting desisions about game play into the games core code rather then Python ware it belongs. Breaking down such barriers by simply creating new calls wont break any existing mod. Non C programers can then start playing with these new tools to enhance and diversify their mods.
I agree with this - enhancing the power of python and xml will be a great boost to modders who don't want to take the step to the SDK. Kael has already shown how to easily add XML variables, as well as eidt domains, and as I see it the next big thing will be event - somebody is already working on it. While I agree that there is a place in this project for such a thing we must be careful not to overdo it. If we add to many things we may just make it easier for modders to go straight into the SDK rather than fiddling about with hundreds of different XML valies (extreme case).
Impaler[WrG] said:
I would see these type of enhancements as the top priority. With respect the TGA 3 priorites I rank them as follows. AI - 2nd, as mentioned the AI is already darn good and it will be mostly a matter of tweaking it rather then overhauling it. Performance - 3rd, Morres law means we would simply be subtracting a year off the age of the computer nessary to run the game, will people realy care about that in a few years time or will they care about gameplay. UI - 4th, its all in Python so shouldn't be included in a SDK based mod, python programers are doing a fine job at it already, I'm all for creating TOOLS for them but that falls under my Primary imperitive of more flexible calls.
One of the main troubles I found with modding the UI was the limitations of the python functions, although you could hack most of it it was by no means pretty. My motivation for including a optional UI section into this mod goes back to the idea that the mod should aim to improve all aspects of gameplay. While most people wouldn't mind a better UI, there will always be people who do.

I think I might see about getting a forum set up so that anybody interested can contribute, and maybe set up a project on SourceForge.

Oh yeah... and I, TGA, will release the source code to any and all C++ changes I make in the SDK to facilitate the merging of my code into any other Civ4 related C++ code. I further pledge to clearly indicate changes made to the released SDK files in my releases.
 
Imo the changes to the C++ code should be mostly to provide hooks for the job to be done in Python. When one thinks a variable should be tweaked or modified, one should make the variable readable from xml files and accessible in python so it can be tuned without having to recompile the mess every time.
Also, if anyone can get rid of the forced specialists in cities, I think that would be good. I looked at the code and think it's a bit too cryptic for me.
 
LDiCesare said:
Imo the changes to the C++ code should be mostly to provide hooks for the job to be done in Python. When one thinks a variable should be tweaked or modified, one should make the variable readable from xml files and accessible in python so it can be tuned without having to recompile the mess every time.
Also, if anyone can get rid of the forced specialists in cities, I think that would be good. I looked at the code and think it's a bit too cryptic for me.

I think that is already fixed in this patch. There is not need to have them forced any longer.
 
The Great Apple said:
I think I might see about getting a forum set up so that anybody interested can contribute, and maybe set up a project on SourceForge.
But for this I'll need a name...

How about civ4patch?

LDiCesare said:
Also, if anyone can get rid of the forced specialists in cities, I think that would be good. I looked at the code and think it's a bit too cryptic for me.
I'm not entirely sure what you are talking about.
 
How about Civ4Tweak?

And I'd be interested to join, but my internet acces isnt the most reliable since I have non at home. :D (btw, cant wait to get home without inet access so I can get some work done on my mod lol - already prepared by downloading like every tutorial on this site, all tools I need and TONS of information to use).
 
12monkeys said:
I think what we are heading for is a kind of common framework. So why not calling it "Common Framework"?
Too many letters. We will get a URL at http://sourceforge.net/projects/<insertournamehere>, and there is a 15 letter limit. Obviously we'll need to mention Civ 4 in there as well.
 
Well I was thinking Civ4 Community Pack (or Project), but then you said there's a 15 letter limit, but then I thought we can use a short form for the url, something like Civ4CP.
 
Hmmm.... How about Civ4CC - Civ4 Community Core?

EDIT: Also, the CC part will help to identify it as being C++ based...
 
This sounds great. Although there is a lot of excitement around the SDK right now the truth is that most modders won't be able to make practical use of it because of the difficulty in troubleshooting and the learning curve.

Being a "dont tear down a fence unless you understand why it was built" kind of guy I don't know how possible it will be to improve performance without effecting functionality. I would worry about the unforseen consequences of changing functions that are being used by modders in "creative" ways.

But, as you guys have discussed I can see a HUGE advantage of a community project that adds new python functions, and xml aattributes to the game to make life easy for modders.

For example. I could go through the multi-domain unit stuff and instead of doing it in the kinda cheesy piggyback method that I used add a new attribute to promotions that allows land units to travel on water tiles. That change gets checked into the community project and anyone who uses the community project as a foundation has access to all the new features it offers.

The rule should be that all of the new features dont change anything unless the modmaker chooses to utilize it, default config should be to play exactly as normal.
 
Top Bottom