I can share a bit or two about strategy of modding some large projects based on my experiences.
The most important things related to successful execution of large project for Civ5 are:
(1) KNOWLEDGE of game's data and its processing workflow
(2) STANDARDIZATION of your project
(3) AUTOMATION
The rest are just details. Without these things there are very slim chances that such large project will be ever successful, and modding will be only a "time-killer" for people that are involved in the process of making such a mod.
Now what these actually mean:
1) Knowledge of game's data and loading work flow
You need to know structure of game's sqlite database inside out. And be proficient with SQL data manipulation language. Period.
For large project, to know this is critical, otherwise you blindly wander in the mist, which can generate a lot of frustration why things don't work as you expect.
"Traditional" modding advice to newcomers such as "inspect mods of others to learn things" is as bad as it can be for large projects. Well, majority of released mods are xml based, and many (and I mean really many) just have errors or inconsitencies. Whether it can be a typo, some missing letter here and there in game's variable name, not existing value, missing file, etc.
The point here is: XML modding for database manipulation, in case of large project, makes far more harm than good. In fact, it should be banned! ;]
Casual modding scenario for small mods usually works like this:
1) check other mod
2) copy other mod's xml code to your mod
3) change values
4) build, run the game, and hope for the best ;D
This is no go, for large projects, until we don't mind the overall quality of the mod, or wasted time spent on debugging errors.
Here's how the game's actually processes data:
1) it creates a database in sqlite format (Civ5DebugDatabase.db - this is the file where all game's data from vanilla, expansions, and user mods are merged)
2) it executes SQL files from mods to insert data into database - errors go to logs (database.log)
3) it parses/validates data in XML files from mods, and if data are correct, then creates SQL query with that data, and inserts values in database - errors go to logs (xml.log if xml incorrect, database.log if data incorrect)
4) validates and checks data in and between databases (debug, and localization-merged) - errors go to logs (database.log)
5) retrieves the data from databases, handling it to the game's engine to make use of it during the game.
As you can see, XML based mods that manipulate data in database require additional (unnecessary) step in processing data, and add one more place to check while debugging if something is wrong - complete waste of time during development for large projects.
Large project development work flow could be:
1) create SQL that inserts/updates/deletes data in database, then build your mod
2) start the game, select your mod only, and load it (but not start the actual game!)
3) switch alt+tab out of the game, and run sqlite database app (SQLiteSpy, SQLiteStudio, etc.), and open file Civ5CoreDatabase.db, then search for your data in certain tables (if data is not there, there's no point starting the actual game :] and we all know that Civ5 is not the demon of speed here ;P - this technique saves tremendous amount of time while debugging for large projects *)
4) only after your data are correct in database, then start the actual game, and inspect other things related to your mod (graphic, missing text, audio, etc.)
* you can even make things faster if you don't run the game at all. Let's say that you've just written a SQL code that inserts 20 buildings. Then just run SQLiteSpy, open a copy of Civ5DebugDatabase.db, and execute code directly there. If it won't work, don't bother with starting the game, as it won't work there as well. And SQLite usually informs right away what's wrong with queries. Search for typos, fix it, check again without running the game. Conclusion: huge amounts of precious time saved.
2) Standardization
It means that no matter what content you create for your mod, or whether you import ideas or resources from other mods, the data (audio, graphics, code, etc) need to be in certain and proper format, and have its own place into your mod structure of folders.
Couple of examples:
- splashes for wonders saved as .dds files with DXT1 compression, no mip maps, and with 972x448 dimensions in their own folder
- icons saved as DXT5 compression, no mip maps, possible joined together in icon atlases in their own folder
- all audio files normalized, with proper fade in and out, no extensive gaps, saved as .mp3 128kbps in their own folder
- all lua scripts in their own folder
- code which inserts data into game's db, all in SQL
- XML code only for UI layouts, or other stuff (no database manipulation here! we leave that to SQL!)
Conclusion:
Why Standardization is such important?
Because if you standardize, you are always at control what happens in your mod. You'll introduce far less errors, and make far less mistakes, and at the end, you save a great amount of time, literally.
Without standardization, especially in the case while you will be in need of importing other mods' assets, you may end up not only importing the proper content, but introduce into your project some additional unnecessary things and errors/bugs/issues of those mods as well, and definitely a lots of inconsistency that may lead to next, sometimes even obscured, and hard to debug future issues.
3) Automation
With applied standards to your mod (prefixes, naming convention etc.) , and SQL you can AUTOMATE things.
Believe me, you don't even want to manually set those flavors for zilion-th building, or unit in your mod. You want to save your future sanity, to not bother yourself with seeing those BuildingClasses, or Civilization_BuildingOverrides values ever again. And if you value your fingers, you don't want to type those TXT_KEY strings like forever. And so on, and on...
TL;DR ;D
If you want to make a decent large project (no errors, and eventually finished thing) - focus on:
- inspecting game's SQL database files: Civ5DebugDatabase.db, Localization-Merged.db (with programs SQLiteSpy, SQLiteStudio, etc.)
- trying to write your mod's code in all SQL in case of DB manipulation
- inspecting graphic .dds files (with Windows Texture Viewer from Nvidia)
- the rest, like lua, will come later ;]
If you don't want to make a large project:
- focus on XML mods ;D