As is tradition, I'm going to give a quick overview about what my current plans for 1.17 are, this is of course subject to change as I am developing. On a very high level, most of this version will be about preparing things to come in future versions. This can have the unfortunate side effect of not offering as much straight up content as usual, in particular compared to 1.16 which added so much in terms of units, wonders etc.
I have spent a lot of time thinking through how to enable some of the big milestones further down the line, such as additional civilisations, the new map, more scenarios (or different ways of creating maps) etc. (all of which will not be in 1.17) and how to keep the codebase manageable with such an expansion of features. DoC 1.17 will be primarily about laying the groundwork for these things and cleaning the existing codebase to make it easier to maintain and get rid of some annoying holdovers from initial implementations in RFC and DoC.
1. Ongoing preparations for the new map
Status: city name suggestions being collected
This is technically not really part of 1.17, because development of the new map will continue in an isolated branch and I have no plans of merging it before 1.17 releases. However, this is likely where I will focus my efforts first.
Firstly, I will go through the feedback and the suggestions that have accumulated over time to bring the branch up to date with them.
Then, I plan to lay some groundwork to enable the community to make further contributions. As far as I can see now, this is a) a new city name manager that will operate from one global city name map instead of many individual language based maps, and b) a new implementation of stability and settler maps. In each case this will let people work on the new CNM and settler maps so I want to enable that as soon as possible.
2. Rise and Fall reimplementation
The idea here is to implement the entire content of the Rise and Fall module again from scratch, which handles everything around how civilisations spawn and respawn, and all the rules around that. From a code perspective, this is one of the major elements of the mod that is still using code largely written by Rhye, and I am pretty sure there is a lot of opportunity to streamline it. In the process of rewriting it I will also gain a better understanding of how everything works exactly, which is important for features I have in mind further down the line.
From a gameplay perspective, it gives me the opportunity to change how spawns and flips work to be less luck dependent and less frustrating, specifically by removing unit defections and replacing them with different mechanics to ensure that recently spawned civilisations can establish and defend themselves.
In addition to that, I have some further ideas on how different civilisations could spawn according to different rules depending on how they emerged historically (e.g. through conquest or through independence from an existing civilisation). This can include aspects discussed previously such as starting as a vassal (e.g. Canada) and can represent existing special cases like the Ottoman spawn more organically within the system.
3. Use civilisations instead of players in implementation
Status: complete
Right now, most game rules rely on the player ID (also referred to as its "slot") instead of the civilisation they actually are. This needs to be changed in the future to enable reusing slots for multiple civilisations so we can add additional civs later on in development (so the abilities, modifiers etc. of a given player depends on the civilisation they actually are). This is nothing special in itself, but requires a thorough change of the code throughout the mod and may take some time, but if complete we are a major step closer to adding more civs to the mod.
4. Change how scenario files work
Right now, the different start dates in the mod are implemented as scenarios, which are essentially equivalent to saved games in a certain situation. I would like to transition from scenarios to a map script (i.e. the "Play Now" button). This is a necessity to uncouple civilisations from slots, as for scenarios the civilisation for each slot needs to be set at the beginning, and no more civilisations than slots are possible. Instead the player will be able to choose their civilisation just like at the beginning of a custom game.
In addition, this will also enable additional game options for various things. In particular, I want to explore this possibility to turn the start date into a game option, instead of having different scenarios for each start date. This would have the significant advantage that there is only one file to maintain for all scenarios. Right now, even having only three scenarios makes it hard to make changes to the map etc. because these changes have to be kept consistent between all scenarios. If shared elements (e.g. the basic terrain) were kept in the same file, it would reduce the workload significantly, and make additional scenarios much more likely.
DoC has some unique requirements for this approach because custom maps are usually randomly created, while DoC has a predetermined map. I need to figure out how to solve this, but I am fairly certain it is possible. The advantage of this approach is that it brings us much closer to adding different maps (including randomly generated ones like in RAND) to the mod.
5. Overall code cleanup and refactoring
Status: mostly complete
Besides all of this, there are other aspects of the codebase that I want to clean up and improve. For example, I have noticed that the RFCUtils module has grown quite large, and when tracking down some bugs in 1.16 I also discovered that specific functionalities have been implemented multiple times with slightly different use cases but completely different code (I think there are at least three functions to push out units somewhere else). On the other hand there are some common tasks (e.g. collecting and interacting with lists of players, cities, units ...) that barely have helper methods or are somewhat clunky, so I hope to improve on that front as well to make existing code easier to read and easier to develop new code in the future.
There is other stuff that needs cleanup in my opinion, for example Python event handlers. This has barely any implication on the gameplay itself besides maybe eliminating some yet undiscovered bugs.
Unlike the development of 1.16, most of this cannot be separated into neat features that can be worked on and then rolled out one by one. For example, when entirely rewriting the rise and fall code I will already make sure to keep the new code up to the improved standards and use civilisation IDs instead of player IDs. It's also entirely possible that like remodeling a house, the mod will not really be playable or at the very least kind of buggy while I am rewriting everything. So that could mean that a lot will happen in separate branches that won't be merged back into develop for quite some time. But on the other hand I want playtesting and feedback on these changes, so let's see what I can figure out.
I hope that gives some insight into what I am trying to do right now. Due to the nature of the goals I have, everything is a bit more technical than usual. Please let me know if you have questions or ideas. Of course as before I will open up threads to go into more detail once I actually start working on one of these items.
I have spent a lot of time thinking through how to enable some of the big milestones further down the line, such as additional civilisations, the new map, more scenarios (or different ways of creating maps) etc. (all of which will not be in 1.17) and how to keep the codebase manageable with such an expansion of features. DoC 1.17 will be primarily about laying the groundwork for these things and cleaning the existing codebase to make it easier to maintain and get rid of some annoying holdovers from initial implementations in RFC and DoC.
1. Ongoing preparations for the new map
Status: city name suggestions being collected
This is technically not really part of 1.17, because development of the new map will continue in an isolated branch and I have no plans of merging it before 1.17 releases. However, this is likely where I will focus my efforts first.
Firstly, I will go through the feedback and the suggestions that have accumulated over time to bring the branch up to date with them.
Then, I plan to lay some groundwork to enable the community to make further contributions. As far as I can see now, this is a) a new city name manager that will operate from one global city name map instead of many individual language based maps, and b) a new implementation of stability and settler maps. In each case this will let people work on the new CNM and settler maps so I want to enable that as soon as possible.
2. Rise and Fall reimplementation
The idea here is to implement the entire content of the Rise and Fall module again from scratch, which handles everything around how civilisations spawn and respawn, and all the rules around that. From a code perspective, this is one of the major elements of the mod that is still using code largely written by Rhye, and I am pretty sure there is a lot of opportunity to streamline it. In the process of rewriting it I will also gain a better understanding of how everything works exactly, which is important for features I have in mind further down the line.
From a gameplay perspective, it gives me the opportunity to change how spawns and flips work to be less luck dependent and less frustrating, specifically by removing unit defections and replacing them with different mechanics to ensure that recently spawned civilisations can establish and defend themselves.
In addition to that, I have some further ideas on how different civilisations could spawn according to different rules depending on how they emerged historically (e.g. through conquest or through independence from an existing civilisation). This can include aspects discussed previously such as starting as a vassal (e.g. Canada) and can represent existing special cases like the Ottoman spawn more organically within the system.
3. Use civilisations instead of players in implementation
Status: complete
Right now, most game rules rely on the player ID (also referred to as its "slot") instead of the civilisation they actually are. This needs to be changed in the future to enable reusing slots for multiple civilisations so we can add additional civs later on in development (so the abilities, modifiers etc. of a given player depends on the civilisation they actually are). This is nothing special in itself, but requires a thorough change of the code throughout the mod and may take some time, but if complete we are a major step closer to adding more civs to the mod.
4. Change how scenario files work
Right now, the different start dates in the mod are implemented as scenarios, which are essentially equivalent to saved games in a certain situation. I would like to transition from scenarios to a map script (i.e. the "Play Now" button). This is a necessity to uncouple civilisations from slots, as for scenarios the civilisation for each slot needs to be set at the beginning, and no more civilisations than slots are possible. Instead the player will be able to choose their civilisation just like at the beginning of a custom game.
In addition, this will also enable additional game options for various things. In particular, I want to explore this possibility to turn the start date into a game option, instead of having different scenarios for each start date. This would have the significant advantage that there is only one file to maintain for all scenarios. Right now, even having only three scenarios makes it hard to make changes to the map etc. because these changes have to be kept consistent between all scenarios. If shared elements (e.g. the basic terrain) were kept in the same file, it would reduce the workload significantly, and make additional scenarios much more likely.
DoC has some unique requirements for this approach because custom maps are usually randomly created, while DoC has a predetermined map. I need to figure out how to solve this, but I am fairly certain it is possible. The advantage of this approach is that it brings us much closer to adding different maps (including randomly generated ones like in RAND) to the mod.
5. Overall code cleanup and refactoring
Status: mostly complete
Besides all of this, there are other aspects of the codebase that I want to clean up and improve. For example, I have noticed that the RFCUtils module has grown quite large, and when tracking down some bugs in 1.16 I also discovered that specific functionalities have been implemented multiple times with slightly different use cases but completely different code (I think there are at least three functions to push out units somewhere else). On the other hand there are some common tasks (e.g. collecting and interacting with lists of players, cities, units ...) that barely have helper methods or are somewhat clunky, so I hope to improve on that front as well to make existing code easier to read and easier to develop new code in the future.
There is other stuff that needs cleanup in my opinion, for example Python event handlers. This has barely any implication on the gameplay itself besides maybe eliminating some yet undiscovered bugs.
Unlike the development of 1.16, most of this cannot be separated into neat features that can be worked on and then rolled out one by one. For example, when entirely rewriting the rise and fall code I will already make sure to keep the new code up to the improved standards and use civilisation IDs instead of player IDs. It's also entirely possible that like remodeling a house, the mod will not really be playable or at the very least kind of buggy while I am rewriting everything. So that could mean that a lot will happen in separate branches that won't be merged back into develop for quite some time. But on the other hand I want playtesting and feedback on these changes, so let's see what I can figure out.
I hope that gives some insight into what I am trying to do right now. Due to the nature of the goals I have, everything is a bit more technical than usual. Please let me know if you have questions or ideas. Of course as before I will open up threads to go into more detail once I actually start working on one of these items.
Last edited:
