.

[member66170]

.

 

[MatzeHH]

SDK
...
Bad
...
Harder to debug

I don't agree in this point. The DLL ist much easier to debug than python code. In python you just have the error log and everything else you want to see you have to display ingame.
In the DLL you can simply set breakpoints where the game stops and you can watch variables and step through the code. Exeptions are catched, the debugger stops if an exception occurs and you see what happened.

Matze

 

[Impaler[WrG]]

I dont think anyone will be suprised to hear me say I'm 100% an SDK man.

I'll adressess each of your pro/con points in turn

Python
Good
Easy to develop - My compile time is quite fast actualy, compiling the whole code base only takes about 4-5 minutes and a single file is around 5-10 seconds which is what I'm doing when in a bug chasing cycle.

Can be merged with other mods with minimum work - Screens yes but event triggered effects are more complex, this aspect has improved substantialy from the earliest days of moding

Can add another 'layer' of game code easily - true and I agree python is a nice place to experiment with ideas and to get experience and familiarity with Civ4 moding

Small files to send and recieve - yes they are definatly smaller but an entire zipped SDK (minus the Bost and release folders which are unessary and can be easily replaced by the reciving party) is only 5MB and easy to put on the FC easy upload server, its how I distribute most of my source.

Required for modifying screens - Python is definantly the better language when it comes to screens, Firaxis did good their

Bad
Cannot modify existing (SDK) code - generaly this is only an issue if you want to prevent something from happening in the SDK, 95% of mods are about additional effects added to the game. Still its a brickwall when your in one of thouse 5% situations

Cannot change mouse overs to make things easier to understand for the player - actualy I think you could append things to the mouse over data and theoreticaly you could disect and splice stuff into the strings the DLL returns it would constiture one of the messy hacks mentioned below

Limited scope for changing AI - As far as I know their esentialy no meaningfull way to modify the AI in python or atleast no one has yet done it yet

Sometimes requires messy hacking - I'm realy anal about my programing and hate kludge

SDK
Good
Almost no limit to what can be done - the .exe and the Graphics engine seem to be the only barriers, every truely complex or ambitious mod will have to use the SDK

Everything can be done in 'neat' code by following firaxis - I love neatness, but Firaxis code is not always correct or optimal

Required for new XML attributes and for modifying existing classes - most of my work has been throuh new XML atributes to give maximum flexibility

AI can be fully modified - Havent done much their, first AI moding I did was for Spy Missions, I plan to do more. This is probably one of the most compelling reasons to do it in the SDK. Also note TGA's efforts to make the AI inherently better in the vanilla game quite a major undertaking and possible only with the SDK, AI by its nature needs fast compiled code.

Mouse overs can be added to make things clear to the player - As I said theoreticaly can be done in Python but way easier here

Bad
Have to send source as well as DLL if working as a team - Definantly the biggest downside of the DLL, from what I can tell most mod teams which incorporate DLL's have a single "SDK man" who compiles and manages a custom DLL for their mod, an XML/Lead Designer grinds out most of the modified XML files and steares the mod creativly, Python might be done by either of them or both or a third person.

Lengthy developing time - have to compile, no on the go changes - not a big issue for me, I ponst here on CF durring any big compiles, the greater volume of code that needs to be writen isn't that big of a deal either as the initial write time is only a small portion of the whole development

Harder to debug - I find that the compilers ability to catch all my syntax errors is better then the interpreted style of Pythons "suddenly blow up at each syntax error". I've mastered not making low level logic errors like fence post or Null access in C++ so the only major hurdles will the the highest level logic of the mod which would be essentialy the same in either language.




I'd also have to add "easy to learn" under Pythons Good colum and "Smaller developer base" under SDK's Bads. But theirs also "Extreamly ambitous high productivity developers" for the SDK which balances the smaller number.

I've been modding Civ4 from practicaly day 1 and I've seen a lot mods and modders and gotten the pulse of the community here. Overall I'd say that the quantity, quality and sophistication of moding has been incressing exponentialy. At the very beging the modding comunity was dispersed over a few other Civ sites such as Aplyton but gradualy almost all moding has gravitated to CivFanatics which is today the undisputed epicenter of all Civ4 modding.

At first you had mostly XML file moding but because Firaxis did such a nice job on balance their wasn't much that needed doing their (atleast nothing which could be universaly agreed on), so most of these revolved around new units and buildings that just mixed the existing XML tags in new IMHO rather un-interesting ways. After about the first month the Python mods started to hit the scene, these were event triggered and crudly implemented. Mylon mod came out about that time and was the first realy BIG mega-mod built out of many smaller Python and XML mods. Python mods continued to become more sophisticated, XML mods became less common but I suspect this is incressingly because people make their own private XML mods to tweak unit balance and generaly theirs so little agreement on this kind of minutia that people rarly both to post it publicly.

Finaly the SDK arrived about 5 months after Civ4 itself and everyone jumped on it, Kael's SDK guide got lots of people compiling the source and layed the foundation for much of what was to follow. About a month later the SDK mods started rolling out. But Python remained dominant for some time, the SDK was generaly used only as a last resort if the desired goal was impossible in Python. SevoMod dominated this era between the SDK and WL. Theirs been a gradual shift towards more and more SDK modding which whent hand in hand with more ambitious mods. Python also seems to have lost out because the elite moders who previously used Python transitioned to the SDK, often learning C++ specificaly to do so. Hybrid mods popularized by folks like Lopez are also incressingly common because the mods are complex enough to entail new screens to support. I predict they will continue to incresse in popularity.

Warlords arival threw a monkey wrench in practicaly all mods that had been made up to that point XML, Python or SDK. Again it took the community about a month to recover from the blow, inwhich time the most popular mods were transitioned and the WL code changes asimilated. Now it seems about half of the new mods are made with duel WL/vanilla versions with the other half just avalible in WL. Its aparent that a substantial percentage of the use base desided not to upgrade to WL, their arn't any figures to go on but I'd guess 10-20% and decressing all the time. The next WL patch now hangs ominously over our heads, it will probaly cause a shorter lull in moding then previous patches as people become more experienced with the updating process, also WL is quite stable so theirs not much likley to change in the code. After that future expantion packs seem likley but so far nothing has been anounced.

I forsee much more mod making with mods as of yet undreamed up and moders who have yet to even register on CF who will surpass us all. The Civ franchise has already been so enriched by Civ4 modability that I cant imagine it wont continue with the next intalment Civ5

 

[Kael]

Having once written an post proclaming that python mods would die out after the SDK released Im not so sure that I still hold that opinion.

At the time I figured that significantly complex mods would need to make SDK modification. And since anything that can be done in python can be done in SDK the real choice was, do I want to make changes in to languages or just one? It seemed obvious that the answer would be one and most modders would gradually switch to straight SDK mods and python would only be used by more casual modders.

But Ive actually reversed my opinion on this. Once python is viewed as a scripting language, and the SDK as a game engine the purposes of each became clearer. So now when I consider either I ask myself if the function Im defining is global or specific just to the task Im using it for. If its global (isHiddenNaitonality() function on a unit which defines if it is hidden nationality or not and called from multiple places) it goes in the SDK and becomes a permanent piece of the game engine. If it is specific to one task (units that are crazed have a 50% chance of being enraged each turn which is only checked at the begining of a turn) then I use python for it.

As in all things the specific circumstances sometimes override the general rule, but thats the guideline I follow.

 

[Déja]

I feel that the SDK and Python serve two different purposes, although they share some common ground. Obviously it's necessary to use the SDK for AI and Python for the interface, but as far as determining which to use for the common ground, there are two factors I keep in mind:

#1 Depth of modification: If it's going to be a mod comp, I'll go with python, since it's easier to combine with other comps. However, if it's a much more in-depth mod-specific block of code, I'm more likely to go with SDK because of....

#2 Speed: It takes processing power and time to pass information from python to C++ (have any of you ever looked at the Cy*.h/cpp files?). So if you want to do something speed-critical, such as change the terrain on an entire map, it is a lot faster to go directly through the SDK than to use Python, because of the number of layers from the actual map engine in the .exe (the SDK goes through the CvPlot class to change the terrain, and then calls the .exe to redraw the terrain, iirc, while Python goes through the python CyPlot class to the C++ CyPlot class to the CvPlot class to the .exe).

As far as sharing the C++ code among multiple developers, I find Subversion (SVN) to be a simple, excellent, free, open-source versioning/repository system. Plus, using TortoiseSVN, it's very simple to use.

 

[Kael]

#2 Speed: It takes processing power and time to pass information from python to C++ (have any of you ever looked at the Cy*.h/cpp files?). So if you want to do something speed-critical, such as change the terrain on an entire map, it is a lot faster to go directly through the SDK than to use Python, because of the number of layers from the actual map engine in the .exe (the SDK goes through the CvPlot class to change the terrain, and then calls the .exe to redraw the terrain, iirc, while Python goes through the python CyPlot class to the C++ CyPlot class to the CvPlot class to the .exe).

Ive played a lot with performance and from what I can tell the difference between python and C++ in most things we are using it for is negligeble. Im sure C++ is faster, but not enough that the player notices a difference, or even an additive difference as they all stack up.

The performance killer in Civ4 isn't C++ or python, its the graphics engine. So in your example above it wouldnt matter if you changed it in python or C++, handing that request off to the graphics engine to change the tiles is where the slowdown will occur.

 

[Déja]

That's a good point. There are a number of other factors that affect speed.