Will the Civ 6 modding community be the quickest ever to establish itself?

[Gorbles]

Modders, more than gamers, are more attracted to things that are familiar, simply because making a mod is an investment of time and effort that endears you to the product you end up making. It's very hard to separate out that personal investment to anything relating to an analytical view of your mod, or even the game that houses it.

That said, the CFC community seems to have a much healthier attitude to it than modding communities I've been involved with in the past. Nobody's perfect of course, but there are reasons for modders expecting X, Y or Z. I can only hope that if it isn't delivered precisely as they ask, that they don't burn the place down over it

I got a bit into the modding scene with Beyond Earth, and I'm looking forward to carrying it on with Civ VI, time allowing. Will be nice to have a game with actual community support.

 

[TPangolin]

What i'm getting from all this chat is that modders hate change and are very stubborn people.

Not really. I think the Civ V community is absolutely open to change, it's just that we hope that unlike in our own iteration - we don't want to have to scratch needlessly away at the surface of the game for months on end, wearing down our proverbial fingernails to even get a semblance of moddability that isn't hardcoded or superfluously restricted.

I think it's more apprehension than anything else. The community worked so hard to get where it is today after years of isolationism. If Civ VI shows any inkling of the same challenges that were presented to vanilla Civ V modders then don't consider it out of order that we start flipping tables.

 

[albie_123]

I have a distinct feeling that the pattern will be similar to that of Civ V.

We'll get a slew of badly made rushed out mods at first (including many, many 'Unofficial Patches / Balance Updates / Game Fixes / etc.', at least one of which I'll have made because hey, why not), a handful of solid but basic mods created by Civ V veterans that will lay the groundwork for others and inevitably be incorporated into shudder "modpacks", and then after this initial boom, there'll be a period where not much gets done as we all:

a. decide whether Civ VI is worth it,
b. work out how to go about modding,
c. figure out what is 'missing' and what is 'broken' from the game,
d. wait for our new whoward to become apparent and tell us what to do when things go wrong.

We'll then get some first total overhauls before any expansion comes out, one of which will last. There'll be a few well made scenarios, most of which will take a long time before releasing. There'll be the usual gang of modders who stick to making polished civilizations, and the other gang who master the artstyle of icons, units, etc. and do the graphics for everyone else who can't.

Then, as the expansions get released and everyone gets better at modding, there'll be a steady rise in both the quality and number of mods available.

If I recall correctly, Civ IV followed the same "Boom - Bust - Gradual Rise" path that Civ V did, although I wasn't around to know if Civ III did. I don't expect Civ VI to be an exception, provided that the game doesn't suck hard (like Beyond Earth ended up doing). Luckily, all evidence points to it being pretty damn decent.

Additionally, it's inevitable that the old guard either undergoes a big shake up in the transition, or doesn't make the transition at all. It doesn't just happen from game to game, it happens within the lifecycle of the individual games as well. The modders who were most active during the Vanilla / G&K days aren't the same as the ones who are most active now.

 

[poom3619]

If Civ VI shows any inkling of the same challenges that were presented to vanilla Civ V modders then don't consider it out of order that we start flipping tables.

(ノಠ益&#3232ノ彡┻━┻

That would be my prediction. I do hope Firaxis made an active support to modding instead of "more moddability" buzzword, but it's optimistic IMHO.

I have an impression that to find out how to do something new in Civ 5 mod is like figure out how to build a canal to fit in a world that have plenty of river made by the dev.

What i'm getting from all this chat is that modders hate change and are very stubborn people.

More like a logical reaction, if you ask me. Imagine Civ 5 release a new expansion at this moment and every XML have to be rewritten into Python to work.

 

[Acken]

I wouldnt mind having to learn a new language as long as the modability is really there. Kinda doubt they really make a change anyway. The xml is not exactly the hard part either

 

[AlbDreamweaver]

More like a logical reaction, if you ask me. Imagine Civ 5 release a new expansion at this moment and every XML have to be rewritten into Python to work.

As someone who's already making the large time investment to try to learn LUA so I can push some Civ 5 mods before Civ 6 comes out to establish myself, this is exactly what I fear.

Unless they want to just have us write mods in Javascript. That would be nice. Python, though? Nah.

 

[JosEPh_II]

IV probably didn't transition to V as much because of the IV die-hards who thought V was the work of the devil.

1UPT is your 1st answer. Then it becomes a laundry list.

JosEPh

 

[Delnar_Ersike]

1UPT is your 1st answer. Then it becomes a laundry list.

JosEPh

Actually, Python+XML+DLL to Lua+SQL without DLL is your 1st answer. When you spend years learning getting to know a system to the point where you can write overhaul mods in your sleep, you kind of get pissed off when the next game forces you to throw everything you've learned out the window and start from scratch on a system that is both less documented and less powerful (remember, no DLL) than what you're used to working with.

Lua modding is great for adding in new features, but when you want to change or remove a feature, things can get messy. At that point, you're very much at the mercy of how much Firaxis allows a user to override code in the DLL with Lua code. Since Lua code runs at least 1000x slower than DLL code (and also allows for easier desyncs unless Firaxis really cleaned up their netcode), it is not feasible for Firaxis to allow everything to be overwritten.

An often underestimated benefit of DLL modding is that opens up a precise reference to the game's internal workings. Instead of having to spend hours experimenting with utilities to figure out how a certain part of the game works, a modder can just spend a few minutes to look up the appropriate code in the DLL's source and be set. Even if we cannot change the DLL, simply having access to its source code would be a huge boon.

 

[EmperorFool]

I really liked the change to 1UPT, more specifically away from the SoD. I would have made CivV mods if it didn't take so much time to launch the game, load the mod, and load a saved game. It went from 5 seconds with CivIV to 2 minutes with CivV, and you couldn't just walk away and get a coffee while it loaded.

For other modders, I'm sure having to learn a new language was a concern. I had to learn Python to mod CivIV, but I've already taught myself more than ten other programming languages, and most of my experience transferred directly. But most modders aren't software engineers by trade and won't use what they learn modding in their jobs. I can understand why people would be hesitant to move to the new environment.

However, I would be that they'll stick with Lua and XML for CivVI. Lua is also used by a lot of other games for modding. You can't really go wrong making the switch if the new tools are good.

 

[JosEPh_II]

Actually, Python+XML+DLL to Lua+SQL without DLL is your 1st answer. When you spend years learning getting to know a system to the point where you can write overhaul mods in your sleep, you kind of get pissed off when the next game forces you to throw everything you've learned out the window and start from scratch on a system that is both less documented and less powerful (remember, no DLL) than what you're used to working with.

Lua modding is great for adding in new features, but when you want to change or remove a feature, things can get messy. At that point, you're very much at the mercy of how much Firaxis allows a user to override code in the DLL with Lua code. Since Lua code runs at least 1000x slower than DLL code (and also allows for easier desyncs unless Firaxis really cleaned up their netcode), it is not feasible for Firaxis to allow everything to be overwritten.

An often underestimated benefit of DLL modding is that opens up a precise reference to the game's internal workings. Instead of having to spend hours experimenting with utilities to figure out how a certain part of the game works, a modder can just spend a few minutes to look up the appropriate code in the DLL's source and be set. Even if we cannot change the DLL, simply having access to its source code would be a huge boon.

Good point especially for a modder. From the player side 1UPT.

EmperorFool wrote: I really liked the change to 1UPT, more specifically away from the SoD.

While I have to tip my hat to your Modding prowess EmporerFool, I must disagree with your assessment of SoD being worse than IUPT.

SoD can have limits set on them. 1UPT is Limits taken to the extreme. And sucks the life out of composing a SoD that functions for your designed purpose. The dislike for SoD in IV is that most players get caught by the AI with their "pants down" and get thumped instead of the player thumping the AI. (Disclaimer: this holds true for the average normal players, and not the Uber Deity players) And the base CiV IV btS AI needs more AI programming for utilizing it's SoDs better still. But how much AI programming is needed for a 1UPT AI. Not much.

JosEPh

 

[Gorbles]

Actually, Python+XML+DLL to Lua+SQL without DLL is your 1st answer. When you spend years learning getting to know a system to the point where you can write overhaul mods in your sleep, you kind of get pissed off when the next game forces you to throw everything you've learned out the window and start from scratch on a system that is both less documented and less powerful (remember, no DLL) than what you're used to working with.

Lua modding is great for adding in new features, but when you want to change or remove a feature, things can get messy. At that point, you're very much at the mercy of how much Firaxis allows a user to override code in the DLL with Lua code. Since Lua code runs at least 1000x slower than DLL code (and also allows for easier desyncs unless Firaxis really cleaned up their netcode), it is not feasible for Firaxis to allow everything to be overwritten.

An often underestimated benefit of DLL modding is that opens up a precise reference to the game's internal workings. Instead of having to spend hours experimenting with utilities to figure out how a certain part of the game works, a modder can just spend a few minutes to look up the appropriate code in the DLL's source and be set. Even if we cannot change the DLL, simply having access to its source code would be a huge boon.

I don't really understand opposition to developers improving their codebase. They do this to ship the game; modding is a secondary concern that in a lot of cases requires significant engine work to support. If you're on a tight deadline, one of the first things to go is modding support (or at the very least, extensive / dedicated modding support).

DLL access isn't something that's a right; it's a privilege. It's the core functionality of the game which understandably companies get a bit tetchy about passing around left right and centre. Ideally the game would support extensive modding without need for the DLL - the DLL itself is a bandage and not a complete solution to a lack of modding support - but we don't live in an ideal world. DLL access comes with sign-off from legal, has to account for marketing to sign off on DLC strategies (if that's a concern), and then also has to come with an element of technical guidance that might have already been re-allocated to a new project.

If you want that level of control to basically be able to start over from scratch, you either want to be actually working at Firaxis, or working on a game of your own. It's not on Firaxis to necessarily provide that for you, especially in an age where games are getting more complex, and more demanding. By extension this makes them harder to modify (to allow for modding) and in the event of modding makes the process of making mods more complex. Games aren't like SMAC where most of the data was exposed in plaintext or held in spritemaps. People often seem to think there's an intentional downgrading of "moddability" in game engines.

They're mostly-wrong. It's just complexity. The tools we use to edit games like SMAC, the developers will have mostly done at the time (barring the advanced reverse-engineering of the source code, which I know is also a big thing in the SMAC community). I know several developers that use the same tools in-house, as the modders use out of house, for most of the development pipeline.

I'd side with JosEPh_II, personally. Design decisions that influence whether people actually like the base game at all (or not) will matter more than supported languages or levels of access. While you can mod a game if you're unhappy with aspects of it, if the core fundamentals are that disagreeable you're very unlikely to even get started on changing it. Individuals may differ, of course.

 

[Delnar_Ersike]

I don't really understand opposition to developers improving their codebase. They do this to ship the game; modding is a secondary concern that in a lot of cases requires significant engine work to support. If you're on a tight deadline, one of the first things to go is modding support (or at the very least, extensive / dedicated modding support).

[snip]

If you want that level of control to basically be able to start over from scratch, you either want to be actually working at Firaxis, or working on a game of your own. It's not on Firaxis to necessarily provide that for you, especially in an age where games are getting more complex, and more demanding. By extension this makes them harder to modify (to allow for modding) and in the event of modding makes the process of making mods more complex. Games aren't like SMAC where most of the data was exposed in plaintext or held in spritemaps. People often seem to think there's an intentional downgrading of "moddability" in game engines.

They're mostly-wrong. It's just complexity. The tools we use to edit games like SMAC, the developers will have mostly done at the time (barring the advanced reverse-engineering of the source code, which I know is also a big thing in the SMAC community). I know several developers that use the same tools in-house, as the modders use out of house, for most of the development pipeline.

Improving the game's codebase isn't opposed at all, the problems come when codebase improvements are not followed up with proper documentation and/or aren't actually improvements. The best example I can think of for the latter in Civ5 is actually the SQL database used to store data. SQL commands definitely allow for much cleaner and more elegant alteration commands and make a mod's file structure much less of a jumbled mess. However, SQL assigns IDs to table entries when the table entries are added, so if a mod removes an entry from the middle of the table (e.g. removing an Industrial era unit or removing a policy), it also then has to reassign the ID of every single table entry following the removed one or face game-breaking bugs. If you want to remove several entries from all over the place in a table, it's often easier to just wipe a table clean and reconstruct it from scratch with those entries missing than to remove the individual entries... however, reconstructing the table makes it so that all changes to that table made by mods that were loaded before yours are thrown out as well, so that's a problem.

Proper documentation, on the other hand, is not something that should be ever disregarded. Even if a game is made without any official mod support at all, it is an extremely good idea for the developers to properly document their game's code, otherwise the developers themselves could get lost and pull things like they did in Civ5 where you'd have 2-3 different functions that are all supposed to do the same thing, but are in different sections of the code written by different people at different times (specific case I'm thinking of is research cost modifiers). If a developer already has proper documentation, then sharing it with the modding community requires no effort.

DLL access isn't something that's a right; it's a privilege. It's the core functionality of the game which understandably companies get a bit tetchy about passing around left right and centre. Ideally the game would support extensive modding without need for the DLL - the DLL itself is a bandage and not a complete solution to a lack of modding support - but we don't live in an ideal world. DLL access comes with sign-off from legal, has to account for marketing to sign off on DLC strategies (if that's a concern), and then also has to come with an element of technical guidance that might have already been re-allocated to a new project.

It doesn't matter whether access to the DLL source code is a right or a privilege, if it was offered in Civ4 from the very start but held back in Civ5, you can easily see why Civ4 modders would not want to move to Civ5. If this happens again in Civ6, you will again find that a lot of Civ5 modders will not want to move onto Civ6, though I guess that pool is much smaller because there are a lot fewer active DLL modders for Civ5 than there were for Civ4. Soren Johnsen talked about how much he had to talk with Firaxis' legal team just to get DLL source code released for Civ4, and it ended up not only not impacting the game's sales, but also allowed Firaxis to release official mods in the game's second expansion, BtS. All this considered means that legal should not have an issue with a DLL source code release. Technical guidance is unnecessary because if the source code is already well-documented, and it should be even if it's for internal use only (for reasons outlined above), modders don't necessarily need anything else to fiddle with the DLL.

The main reason therefore to not release DLL source code immediately is due to marketing and DLC strategies... and that's when things get finicky. If Firaxis releases DLL source code immediately, they help the modding community build better mods faster, which sells more copies of Civ6 (because mods sell games). In addition, by the time it comes to make Civ6's second expansion, they could also then pull a Beyond the Sword and invite some of the now-experienced modding community to make a couple of official, significant overhaul mods that they'd release with the expansion (like a Final Frontier or Ryse and Fall equivalent), and this would only be possible if the modding community has access to the DLL source code long enough to get experienced enough with overhaul modding the game within 3 years of its release. If Firaxis does not release DLL source code immediately, then they maintain a monopoly over a significant amount of mod effects, allowing them to sell DLC and expansions that use those effects without worrying about people potentially not buying those bits of DLC because a free mod would do it better. I obviously think that immediate release's upsides are much better, especially since people will still buy paid DLC for the art/assets alone even if a free mod exists with the same effect, but Firaxis might not agree, and that worries me.

 

[Chinese American]

DLL should be only for interface to hardware only (graphics, sound, files, network, input controls). All the game logic should be done in the scripting language. This way, there's no need for them to release the source code to the DLL, modders don't have to wait to fix bugs or make total conversion mods, and the modding community will thrive. This will also allow Firaxis to more easily and quickly make new DLC content and expansions.

The core yields system is example of how hard-coded stuff in the DLL led to mess of code in the expansions. New yields like culture and faith had to be added in all different ways in the XML and Lua. When it should be simple to extend the list of yields to accommodate new yield types without affecting or creating new XML tags for every new yield type.

 

[Xyth]

DLL should be only for interface to hardware only (graphics, sound, files, network, input controls). All the game logic should be done in the scripting language. This way, there's no need for them to release the source code to the DLL, modders don't have to wait to fix bugs or make total conversion mods, and the modding community will thrive. This will also allow Firaxis to more easily and quickly make new DLC content and expansions.

This would be very unlikely, but amazing. Would also allow full mod compatibility with OS X and Linux. Downside is speed, as compiled code is usually much faster. Multi-threading may be enough to overcome that though.

 

[sukritact]

DLL should be only for interface to hardware only (graphics, sound, files, network, input controls). All the game logic should be done in the scripting language. This way, there's no need for them to release the source code to the DLL, modders don't have to wait to fix bugs or make total conversion mods, and the modding community will thrive. This will also allow Firaxis to more easily and quickly make new DLC content and expansion

This isn't a good idea as you might think it is. There's a reason games and game engines are mainly written in C/C++. C languages are simply faster and much better optimised. Computers have improved greatly and there is an impressive amount we can do in scripting languages without greatly affecting performance. But ALL the video game logic? All the AI logic and all the pathfinding? All the video game logic? That's too much.

 

[Gorbles]

Improving the game's codebase isn't opposed at all, the problems come when codebase improvements are not followed up with proper documentation and/or aren't actually improvements. The best example I can think of for the latter in Civ5 is actually the SQL database used to store data. SQL commands definitely allow for much cleaner and more elegant alteration commands and make a mod's file structure much less of a jumbled mess. However, SQL assigns IDs to table entries when the table entries are added, so if a mod removes an entry from the middle of the table (e.g. removing an Industrial era unit or removing a policy), it also then has to reassign the ID of every single table entry following the removed one or face game-breaking bugs. If you want to remove several entries from all over the place in a table, it's often easier to just wipe a table clean and reconstruct it from scratch with those entries missing than to remove the individual entries... however, reconstructing the table makes it so that all changes to that table made by mods that were loaded before yours are thrown out as well, so that's a problem.

Proper documentation, on the other hand, is not something that should be ever disregarded. Even if a game is made without any official mod support at all, it is an extremely good idea for the developers to properly document their game's code, otherwise the developers themselves could get lost and pull things like they did in Civ5 where you'd have 2-3 different functions that are all supposed to do the same thing, but are in different sections of the code written by different people at different times (specific case I'm thinking of is research cost modifiers). If a developer already has proper documentation, then sharing it with the modding community requires no effort.

It doesn't matter whether access to the DLL source code is a right or a privilege, if it was offered in Civ4 from the very start but held back in Civ5, you can easily see why Civ4 modders would not want to move to Civ5. If this happens again in Civ6, you will again find that a lot of Civ5 modders will not want to move onto Civ6, though I guess that pool is much smaller because there are a lot fewer active DLL modders for Civ5 than there were for Civ4. Soren Johnsen talked about how much he had to talk with Firaxis' legal team just to get DLL source code released for Civ4, and it ended up not only not impacting the game's sales, but also allowed Firaxis to release official mods in the game's second expansion, BtS. All this considered means that legal should not have an issue with a DLL source code release. Technical guidance is unnecessary because if the source code is already well-documented, and it should be even if it's for internal use only (for reasons outlined above), modders don't necessarily need anything else to fiddle with the DLL.

The main reason therefore to not release DLL source code immediately is due to marketing and DLC strategies... and that's when things get finicky. If Firaxis releases DLL source code immediately, they help the modding community build better mods faster, which sells more copies of Civ6 (because mods sell games). In addition, by the time it comes to make Civ6's second expansion, they could also then pull a Beyond the Sword and invite some of the now-experienced modding community to make a couple of official, significant overhaul mods that they'd release with the expansion (like a Final Frontier or Ryse and Fall equivalent), and this would only be possible if the modding community has access to the DLL source code long enough to get experienced enough with overhaul modding the game within 3 years of its release. If Firaxis does not release DLL source code immediately, then they maintain a monopoly over a significant amount of mod effects, allowing them to sell DLC and expansions that use those effects without worrying about people potentially not buying those bits of DLC because a free mod would do it better. I obviously think that immediate release's upsides are much better, especially since people will still buy paid DLC for the art/assets alone even if a free mod exists with the same effect, but Firaxis might not agree, and that worries me.

Your example in the first paragraph is a key example of the lack of translation between modders and developers. You complain that the improvement (from Civ 4 to the situation) in CiV, right? Or was the SQL change implemented post-release for CiV? I'm assuming the first, anyhow.

Your issue is that the change wasn't an improvement because it made it more difficult for modders. This is not a rationale when it comes to software development because making it easier (or even maintaining the difficulty of implementation) for modders isn't a primary concern. Making it easier or more manageable for the developers is the primary concern.

Documentation is another Good Thing that developers Should Have. But it doesn't always work out that way. Implementation comes first; implementation always comes first. You won't see me disagreeing with the need for it, but sometimes it just doesn't exist and you have to understand that it isn't down to laziness on the dev's part. This is a common problem through video games and indeed software development; unless you outsource it (and there are problems with how that could / would work), your core dev team are likely to be too busy to sit down and take a break (effectively) to write it. It's that wonderful revenue-driven model where you can't hire staff unless they're contributing value, and documentation isn't seen as a priority that delivers value. The product itself does. Add to that the disconnect between management and actual production ("oh you can just fix it, right") that's increasingly-present the larger a company gets and you have a business that doesn't hire staff to let the existing staff work on secondary concerns because that costs Money, and Money eats into Profit Margins. It's all tied up into the business model in general, and how our world revolves around capitalism (i.e. it's not enough to generate money, you have to generate more money every year. Like how Apple got slammed by the finance sector for not selling "enough" iPhones despite making enough sales to build a space elevator to the moon. Out of gold). But that's a bit of a tangent. To wrap this up a bit faster:

1. DLL modding should not be a requirement to make mods. Legal is always a concern because as you said it was a huge issue around Civ 4. That doesn't mean all future products automatically allow legal to authorise their corresponding DLL sources. It has to be argued, repeatedly, for each product.

Probably why it turned up late in CiV's lifecycle, and why it didn't turn up for BE at all (as of yet, at least, heh. But unlikely anyhow).

2. I understand your worry - balancing DLC strategies (which funds post-release support) against supporting a modding scene is frustrating for developers who want to support their fans as well. However, fans also demand endless post-release support for titles these days (regardless of how polished they are or not) which needs to be financed someone.

You have a reasonable concern, and you understand where Firaxis are coming from on their end. Nothing to disagree with there.

 

[EmperorFool]

While I have to tip my hat to your Modding prowess EmporerFool, I must disagree with your assessment of SoD being worse than IUPT.

I said I liked the change; I didn't say SoD was absolutely worse. 1UPT has plenty of issues itself, the most obvious being what a PITA it is moving your "army" around to get to the battlefield. What I like most about 1UPT is that it feels like I'm playing with little plastic toy soldiers and that I can use the terrain tactically. It brings me back to the days of playing with physical model trains and LEGOs. Of course, the AI is horrible at this so it's not as fun as it could be.

Improving the game's codebase isn't opposed at all, the problems come when codebase improvements are not followed up with proper documentation and/or aren't actually improvements.

That's especially hard in the game industry. The things that make a good developer tend to make for a bad writer, and no one's getting directly paid for good documentation. This will probably be an area where the modding community will always have to step in for the developers. I learned everything about CivIV modding from this site and other mods.

However, SQL assigns IDs to table entries when the table entries are added, so if a mod removes an entry from the middle of the table (e.g. removing an Industrial era unit or removing a policy), it also then has to reassign the ID of every single table entry following the removed one or face game-breaking bugs.

Surrogate keys (typically integers automatically assigned by the database) are great when you're building a data-neutral transactional system, but it's a shame they went that way here. In CivIV all the keys were strings like UNIT_ARCHER that didn't have to appear in any particular order in the file. I don't know why they didn't follow the same pattern with CivV. Using SQL was supposed to open up possibilities and make it easier to mod.

 

[Delnar_Ersike]

Your example in the first paragraph is a key example of the lack of translation between modders and developers. You complain that the improvement (from Civ 4 to the situation) in CiV, right? Or was the SQL change implemented post-release for CiV? I'm assuming the first, anyhow.

Your issue is that the change wasn't an improvement because it made it more difficult for modders. This is not a rationale when it comes to software development because making it easier (or even maintaining the difficulty of implementation) for modders isn't a primary concern. Making it easier or more manageable for the developers is the primary concern.

[snip]

You assumed correctly, SQL data management was a part of Civ5 from the very start. It's not like the removal thing is only an issue for modders: if you look at the XML files for Civ5's expansions, you'll see Firaxis also having to deal with this issue. For G&K, Firaxis completely deleted all of their old (vanilla) data entries and rebuilt them with new stuff added. Then, with BNW, Firaxis had to very carefully delete all of their old data in a way that wouldn't delete the data that they wanted to only be available for people with G&K, then they rebuilt the data tables with both the new G&K and the new BNW data. This sort of careful construction of SQL commands wastes Firaxis' time and forces them to pay interest on their technical debt whenever it comes up, instead of just constructing their system with less technical debt from the start.

Besides providing modding-specific tools that cannot be used by the internal development team, everything that helps modders also helps developers, and anything that hurts modders also hurts developers. When this help and/or hurt is in the form of technical debt, it becomes a lot more difficult for non-technical staff to understand and work with, and as you've said, Firaxis is currently primarily composed of non-technical staff. Tying things back to the main topic at hand, Civ6's modding community will only establish itself quickly if Firaxis' non-technical staff fully come to terms with the concept of technical debt; if they do not, I would expect a similar outcome to Civ6's modding scene as what happened with Civ5, i.e. Civ6's modding community will not be the quickest to establish itself, and all the downsides that come with it (e.g. no major overhaul mods, no community patches until very late into the game's lifecycle, side-projects that are more like CivBE and less like Civ4:Col).

That's especially hard in the game industry. The things that make a good developer tend to make for a bad writer, and no one's getting directly paid for good documentation. This will probably be an area where the modding community will always have to step in for the developers. I learned everything about CivIV modding from this site and other mods.

You don't need to be a good writer to have good code documentation. A lot of it comes down to being a great programmer: a good programmer writes code that they can understand, a great programmer writes code that everyone can understand. For example, before John Carmack left id software, he had a programming dogma enforced where nobody was allowed to write comments anywhere in any of their games' code. This meant that in order to document your code properly, you had to write it in such a way that it did not need any extra comments to explain what it did: variables and functions were named in such a manner that a reader would immediately know what the functions did or what the variables' roles were. Fancy programming tricks were discarded in favor of readable code, and id made sure to hire and train programmers for the latter instead of the former. As a result, even if people who worked at id did not either know how to or have the time to write good documentation, their code was well documented simply by virtue of its readability.

Surrogate keys (typically integers automatically assigned by the database) are great when you're building a data-neutral transactional system, but it's a shame they went that way here. In CivIV all the keys were strings like UNIT_ARCHER that didn't have to appear in any particular order in the file. I don't know why they didn't follow the same pattern with CivV. Using SQL was supposed to open up possibilities and make it easier to mod.

Well, SQL does open up possibilities for easier modding, the problem is that Civ5 both relies on primary keys to be continuous (i.e. if an integer without an entry associated with it is discovered, there must be no more entries in that table) and immediately assigns final, primary keys the instant an entry is read by the system. There are solutions that would allow for SQL to still be used with all of its upsides: the system that loops through data entries could be designed in a way that it does not immediately think a null entry means the end of the table, or the data loading system could first store all data in a temporary database and perform all table modifications there before transferring all non-empty entries in non-empty tables to the final SQL database. I'd see the latter as the ideal solution: developers and modders wouldn't need to care about what IDs are associated with their data entries when they are loaded because primary keys in the temporary database would not transfer to the permanent one, and the transfer process itself would take care of "shifting" IDs up whenever an deleted entry would be encountered. Firaxis opted for neither throughout the entire development cycle of Civ5 and CivBE, and if they go without a solution for Civ6 as well, expect to see them similarly suffer with DLCs and expansions that overwrite some but not all data from previous DLCs and expansions (oh yeah, and a similar difficulty when making overhaul mods).

 

[Acken]

DLL should be only for interface to hardware only (graphics, sound, files, network, input controls). All the game logic should be done in the scripting language. This way, there's no need for them to release the source code to the DLL, modders don't have to wait to fix bugs or make total conversion mods, and the modding community will thrive. This will also allow Firaxis to more easily and quickly make new DLC content and expansions.

The game would run like pure crap.

Having access to the game logic with the DLL is fine. The complaints about yields not being all treated the same wouldn't be magically solved either if the whole logic was in scripts. It's a coding issue, not a language issue.

 

[EmperorFool]

You don't need to be a good writer to have good code documentation. A lot of it comes down to being a great programmer: a good programmer writes code that they can understand, a great programmer writes code that everyone can understand.

Certainly, the best code documentation is good naming instead of commenting, but the Civ4 code had neither! It took a modder to generate API documentation and fill in some of the descriptions. This could have easily been provided by Firaxis with minimal effort.

As for needing a good writer, I was speaking more about architecture and introductory documentation to show modders where to start. Community-written tutorials are indispensable when starting out because Firaxis doesn't make any attempt whatsoever. My point is that with a deadline and too much work to do, this is not even a low priority for them.

I discovered mods after Warlords came out and used Ruff's modpack. When BTS was released, I knew I couldn't live without it and created BUG as a result. It was a great excuse to finally learn Python, and once the DLL source was released I was able to scratch my C++ itch again. But as other modders began building on top of BUG, I quickly found I was getting swamped answering the same questions. I wrote up some high-level documentation with walk-throughs for integrating a simple mod within the system. All the code was documented, but it helps to have a map showing you where to even start looking.