Dev diaries
Without getting too recursive, I want to start by talking about dev diaries themselves for a bit. Basically I have noticed that individual versions of DoC often lack focus. This is bad because it leads to feature creep and year long release cycles. I think it's better to avoid this and I will aim for smaller feature sets and quicker releases in the feature. Not only will this help me be more productive and hopefully stay motivated for longer. It should also help you, the players, to better understand the current direction of development. Too often have I seen feature requests or suggestions that are planned somewhere along the road, but cannot happen because development concentrates on other aspects instead, which might often be prerequisites for the requested feature.
Dev diaries are also a tool to that end. Some of you may still remember how I listed planned features in a to do list; I dropped that along the way because it was hard to maintain in a helpful and up to date state. For a while I was deliberately vague for that reason, but that didn't work for the opposite reason. Now instead I will write this sort of thread to expand a bit on what my current plans are, or give some detailed thoughts on a subject that is currently being discussed even when I can't work on them immediately. Besides allowing me to write huge paragraphs, it also has the advantage that they are explicitly only current for the time they are written and may be superseded by things that happen later. I have decided to presumptuously name them dev diaries in the tradition of Paradox games. Hopefully it'll work.
Transition to Git
This was one of my goals for the mod in the long run, I only had to delay it to make the transition when we are around release. I have expanded on this in the other thread already. It will definitely make development easier for me, and from early experiences also encourage community contributions. That's really great.
I hope this didn't make things too complicated for those who just want their dev updates regardless of the technology. I will write a more detailed guide on this soon to help with the common use cases.
Release of 1.13
I will use that heading to quickly announce that my to do list is finally empty and without anything getting in the way you will see the release of 1.13 around Monday evening CET.
Release up the updated submodules will follow soon after, including Git repos.
Plans for 1.14
In keeping with the goal to have smaller versions with more focused feature sets, 1.14 will have two major features:
Religion:
Utility improvements:
Plans for 1.15 and beyond
I don't want to go into too much detail here. But I have already mentioned previously that one of my long term goals is to untangle the current strong coupling between player slots and civilizations. Doing so will have multiple benefits, including often requested features like autoplay for all civs or taking control of random respawns, but it will also enable me to add new civs without negative performance consequences or other stuff such as real civil wars (multiple instances of the same civilization around!).
1.15 will likely not be about that though. But like 1.14 with its various utility changes it can be pave the way to there. In specific, I will probably rewrite the entire Rise and Fall code and all the utility methods around it. As of now, I don't have full overview over how that code works, which is what I need to make the necessary changes later. Also the code is old and inelegant in many ways, so I can rewrite it so that the later slot-uncoupling will be easier. In the process, I will remove some of the awkwardness of the spawn mechanics and make them a bit more civ specific. This includes some differentiation between peaceful and aggressive (and independence) spawns and the way they play out both when controlling the new civ as well as the one controlling their spawn area. This includes the ability to stop spawns, and a replacement of the annoying defecting unit mechanic. More details when 1.15 comes closer.
That's it for now. I hope I can stick to this new tradition and it gives everyone some additional perspective.
Without getting too recursive, I want to start by talking about dev diaries themselves for a bit. Basically I have noticed that individual versions of DoC often lack focus. This is bad because it leads to feature creep and year long release cycles. I think it's better to avoid this and I will aim for smaller feature sets and quicker releases in the feature. Not only will this help me be more productive and hopefully stay motivated for longer. It should also help you, the players, to better understand the current direction of development. Too often have I seen feature requests or suggestions that are planned somewhere along the road, but cannot happen because development concentrates on other aspects instead, which might often be prerequisites for the requested feature.
Dev diaries are also a tool to that end. Some of you may still remember how I listed planned features in a to do list; I dropped that along the way because it was hard to maintain in a helpful and up to date state. For a while I was deliberately vague for that reason, but that didn't work for the opposite reason. Now instead I will write this sort of thread to expand a bit on what my current plans are, or give some detailed thoughts on a subject that is currently being discussed even when I can't work on them immediately. Besides allowing me to write huge paragraphs, it also has the advantage that they are explicitly only current for the time they are written and may be superseded by things that happen later. I have decided to presumptuously name them dev diaries in the tradition of Paradox games. Hopefully it'll work.
Transition to Git
This was one of my goals for the mod in the long run, I only had to delay it to make the transition when we are around release. I have expanded on this in the other thread already. It will definitely make development easier for me, and from early experiences also encourage community contributions. That's really great.
I hope this didn't make things too complicated for those who just want their dev updates regardless of the technology. I will write a more detailed guide on this soon to help with the common use cases.
Release of 1.13
I will use that heading to quickly announce that my to do list is finally empty and without anything getting in the way you will see the release of 1.13 around Monday evening CET.
Release up the updated submodules will follow soon after, including Git repos.
Plans for 1.14
In keeping with the goal to have smaller versions with more focused feature sets, 1.14 will have two major features:
Religion:
- new mechanism for religion spread: stronger historical and geographical impact (no Hinduism in Europe), disappearing religions
- New Christian schism: for a more logical and rewarding relationship between Catholicism, Orthodoxy and the Apostolic Palace
- Minor religions (may require new mechanics for spawning or branching off religions)
- Rewards for religious unity over religious diversity
Utility improvements:
- better city name manager with less maintenance: auto-discovery of reverse name translations, auto-discovery of native tile names from other languages
- more dynamic names with less maintenance overhead: e.g. separate conditions for title (like "Empire of %s" or "Protectorate of %s") and used short name (e.g. "England" or "Britain"), increasing available combinations while reducing maintenance on game text
- better world builder: I'm currently looking at adapting the one from History Rewritten
- better civilopedia: I like the one HR uses here as well
- Xyth also did a great espionage advisor recently (he's just very good with interface stuff)
- RFC specific world builder features: display and edit tile stability, output stability maps. Hopefully this will allow us to edit stability/settler maps in world builder
- New solution for dynamic Great People names: keep the code in the DLL but remove the need for duplicate GP unit types. If possible, even make the names era specific to avoid inappropriate names for respawns or later scenarios
Plans for 1.15 and beyond
I don't want to go into too much detail here. But I have already mentioned previously that one of my long term goals is to untangle the current strong coupling between player slots and civilizations. Doing so will have multiple benefits, including often requested features like autoplay for all civs or taking control of random respawns, but it will also enable me to add new civs without negative performance consequences or other stuff such as real civil wars (multiple instances of the same civilization around!).
1.15 will likely not be about that though. But like 1.14 with its various utility changes it can be pave the way to there. In specific, I will probably rewrite the entire Rise and Fall code and all the utility methods around it. As of now, I don't have full overview over how that code works, which is what I need to make the necessary changes later. Also the code is old and inelegant in many ways, so I can rewrite it so that the later slot-uncoupling will be easier. In the process, I will remove some of the awkwardness of the spawn mechanics and make them a bit more civ specific. This includes some differentiation between peaceful and aggressive (and independence) spawns and the way they play out both when controlling the new civ as well as the one controlling their spawn area. This includes the ability to stop spawns, and a replacement of the annoying defecting unit mechanic. More details when 1.15 comes closer.
That's it for now. I hope I can stick to this new tradition and it gives everyone some additional perspective.
