Plans for DoC 1.17

[rmontaruli]

Hi everyone! I'm new at this forum. First of all I'd like to congratulate Loreth for this great mod. I can't stop playing it and I'm so excited since I've heard that a new version's coming. I can't wait to see the update!. Last march you wrote that you were in the step 3. What can you tell us now? Shall we have it before the new year or you still have a lot of work to do?

It is curious: I'm playing Leoreth's mod since its first version and i say: "Keep calm, i want to complete all UHV before a new version." and you say you are a new player of this mod and you can't wait for the update.

Did you play a game with each civ on 1.16? Did you get any UHV?
There is still a lot of fun in the current version... be patient.

 

[Leoreth]

Just to be clear, I sympathise with both ways to play the mod. It's good to know that people find a lot to play with even without updates, but it's also motivating to have people who are interested in new content. Right now I don't feel too much pressure and asking for the current state from time to time is alright.

 

[Leoreth]

Updated roadmap:

0. Fixing bugs (unrelated and related to the rewrite)
As I mentioned earlier, I will fix all bugs in develop based on the new code. Unlike usually, I will try to address issues in reverse order, starting with recent ones. This way I can hopefully address problems that come from the recent changes immediately.

1. Clean up and improve autoplay
The current code for autoplay is more complicated than it needs to be, and I would also like some additional functionality, like:

1.1. Minimal autoplay code
1.2. Easy functionality to enable autoplay for n turns even after spawn (for testing AI only games)
1.3. Maybe even an observer mode that does not require to pick a specific civ to run AI only games​

2. Clean up and improve Rise And Fall code
I've talked about this a lot before, essentially throwing out all the old rules and implement them as needed from scratch, including:

2.1. Remove unit defections, replace with other mechanics to protect new civs from easy conquest
2.2. Additional mechanics to help some civs on spawn, e.g. when you want them to expand quickly
2.3. Greater differentiation around spawn situations based on historical circumstances
2.4. Consolidated and more generalist code for conditional spawns
2.5. Consolidated and more generalist code for civ specific pre-spawn preparations and advantages on spawn​

3. Transition from scenarios to custom games and improve tooling for multiple start dates

3.1. Game starts from Play Now / Custom Game instead of Scenarios
3.2. Start date becomes a game setting instead of a consequence of the scenario you pick
3.3. Only one file describing the initial state of the map
3.4. Differences between the initial map and later start dates implemented in separate files with scenario infos or via Resources.py etc.​

4. (Optional) Rewrite of Victory.py where victory goals are decoupled from civs but instead goals themselves are a proper unit, e.g.:

4.1. The goal check itself, hook for the event handler, texts, progress display etc. are grouped in goal classes/objects
4.2. Mechanism to group multiple subgoals into one goal
4.3. State of the goal is self contained and does not need to be tracked separately​

As usual, the goals here are long term: code easier to maintain, more consistency, easier to add or change civs, goals, start dates, and so on. The Rise and Fall changes are the exception in that they would actually change how the game behaves.

So, I don't think I have said this outright but I am now back to working on this. The plans have changed slightly since then:

• Point 0 is now done for the most part, of course there are probably still bugs somewhere but it seems we are past the growing pains phase of the transition.
• Instead of moving on to what is point 1 above, instead I decided to do point 4 marked as "optional" first. I realised this is actually necessary to untie civs from slots completely and will also solve some other problems, and I will learn things that are needed later on.
• Then, there's another additional thing I will be doing. When fixing some issues, I noticed that the game at this point has many different "scripted spawns" of various types, for example: time based conqueror events (Greeks, Romans, Seljuks...), contact based conqueror events (New World conquistadors, Mongol conquerors), building/tech based conquerors (Trading Company event), tech based settlers/conquerors (Russian far east and American west coast), maybe more that I am forgetting right now. While they are different to some extent (e.g. what triggers them and if the player can benefit from them), they have a lot in common, such as figuring out where to place units in a way that makes sense. However, they all use completely different code which makes fixing issues hard. Also almost every one of them does one thing better than others, for instance the Mongol conquerors had a neat algorithm to make units spawn at the borders coming from the right "direction". Unifying these events should simplify the code and improve at least some of those events by bringing them up to par with the rest.

So, taking the list from above, the new priority list is:

1. Victory.py refactoring
2. Conqueror events refactoring
3. Clean up and improve autoplay
4. Clean up and improve Rise and Fall code
5. Transition from scenarios to custom games

Still is still an accurate summary of what the status and plans are. Those posts are from here, and I think it's better to follow that thread for updates.

Let me give some additional detail for what is going on with victory goals. As you may know, a lot of goals have things in common, and there are repeated types of goals that function in similar ways. For example, a whole class of goals is "Have X instances/amount of Y thing" where Y can be different things like buildings, cities in an area, units, gold in your treasury, culture in a city etc. There's a variant of this that is "Have X% of some total of Y thing" (e.g. control x% population or land).

A lot of logic associated with those goals was repeated over and over again, but it's always the same. For example, if you have <current amount> and <required amount> you can both check if the goal is succeeded and create the display text for the goal (the dynamic part, at least). Sometimes the required amount X scales with game speed (such as gold or culture), which I turned into a simple flag that you can set for a goal and that will be taken into account, instead of me having to remember that everytime I implement the same goal or its display.

Often, checks for goals are repeated as well. For example, every "in year X" goal basically just needs to be checked once in that turn, and every "by year X" goal needs to expire in the year unless it is already fulfilled (plus needing some additional event triggers to check before that time). Also, there is a class of goals that I call tracked goals, which are based on event handlers. For example, the game does not keep track of how many ships you have sunk, so you cannot ask the game for that number for that kind of goal. Instead, the goal needs to react to game events that occur every time units engage in combat, and count up if we defeated and enemy naval unit. I have added some very useful code to make adding that kind of goal tracker very simple.

Another thing that I have enabled is assigning goals to players as a discrete object. Previously, goals were hardcoded for a specific player. The rewrite changed that to civilisations, which is better, but it's still a tight coupling. I'm not quite there yet, but once I am done you will be able to just "give" any goal to any player. Even more/less than the magic number of three goals, theoretically (I do not think I will make use of this though). Why is that important? Once we unbind civilisations from slots, you need to give the appropriate goals for a civ to the player a civilisation is assigned to. This will be much easier with the current system. Likewise, URVs can be implemented much more easily: you will always be assigned the corresponding goals when you switch your state religion. We could also think of other options: for example, different/additional goals for different LHs could become a possibility.

It took me a while to get here because to achieve the desired level of generality with code that wasn't complete garbage itself (which would have defeated the purpose) I needed to learn a lot about Python I wasn't familiar before, in particular dynamic class generation and metaprogramming. I have barely used Python for work, so it's not like I was bringing extensive background knowledge in those fields. So it was a lot of learning by doing, and in the process I made some wrong decisions that I had to walk back later on, resulting in quite a bit of lost time, with the benefit of having an implementation I am now actually happy with.

At this point, I have laid the fundamentals to use what I already have to reimplement all victory goals in the new way. As I said, I already have half of them transitioned, including tests. Most others will probably be simple and quick from here, besides a small number of very unique goals that don't fit into what already exists. I still have to do some work, for example I also want to generate most of the description texts for each goal dynamically (e.g. filling in the building names that make the difference between "build 3 barracks" and "build 3 granaries"). But for the moment, I have put that off for later, and will take some time to address the bug reports that have come in during the last couple of months.

After that, it is probably time for another release (by which I mean a minor 1.16.x release with a patch). I have been waiting so long because I wanted to fix as many bugs from the rewrite as possible, but the reports suggest nothing serious. At this point, it's much better if as many people as possible play on the code after the rewrite, because they will get the benefit of all the bugfixes and improvements I've made since then, and it will be easier for me to help them and address issues.

 

[Mr-Goriyaki]

Maybe 1946 is a better start year for cold war, East and West Germany, North and South Korea, most important, an epic civil war between CCP and KMT.

Then, we should split China into North and South China civ. Kinda similar to the Realism Invictus idea.

 

[Leoreth]

No.

Why do people keep talking about this.

 

[Mr-Goriyaki]

No.

Why do people keep talking about this.

Becuase Northern Chinese is diffrent from Southern Chinese. Especially with today government of People's republic of China and Republic of China.

 

[Leoreth]

I would have put a question mark if I actually wanted to hear why people are talking about this.

 

[Leoreth]

Moderator Action: Deleted off topic comments. Please remember that PDMA is a violation of the forum rules.

 

[HighFunctioningAlcoholic]

I would have put a question mark if I actually wanted to hear why people are talking about this.

*Cracks the whip

 

[Imperator Knoedel]

Moderator Action: Post content removed. Enjoy your warning points. -- Leoreth

 

[ariel552]

I'd love to see a new DAWN OF CIVILIZATION v1.17.
With new starting dates like 1900 and 1400 AD.
New technologies and future technologies. A wormhole to discover and ancient civ like in call to power 2.
Different ideologies: communism and fascism
New units, like slavers, abolitionists and fascists.
Different leaders to pick from for a civ.
Thank you all!! it's amazing this game

 

[freethink]

I'd love to see a new DAWN OF CIVILIZATION v1.17.
With new starting dates like 1900 and 1400 AD.
New technologies and future technologies. A wormhole to discover and ancient civ like in call to power 2.
Different ideologies: communism and fascism
New units, like slavers, abolitionists and fascists.
Different leaders to pick from for a civ.
Thank you all!! it's amazing this game

Ill go point, by point.

-1400 AD will not happen in the base game, but 1900 might. I still don't quite understand world builder so I am not sure how to make this myself.
-I think the late game has already been changed, but I am not sure how much Leoreth would want to add in the sci/fi direction. I think someone years ago suggested that content from the Next War mod be brought into the game
- I suspect you played Civ V or CIV VI, Civ IV uses civics instead. Now there have been suggestions to make civics feel more like religions or for certain civics to have diplomatic penalties but those were not implemented here. Dark Civ, however has some of these things.
-In this game leaders change automatically or on certain conditions for the AI. I think Rhyes and Fall is more concerned with unique attributes to civilizations than leaders.

And yes, I think this is the most amazing of games of all time ( to me). I think Dawn of Civ has succeeded in creating a historical feel for the game.

 

[Orbii]

...
-In this game leaders change automatically or on certain conditions for the AI. I think Rhyes and Fall is more concerned with unique attributes to civilizations than leaders.
...

On this point, I know that the different leaders have different favoured civics. But do they have other gameplay differences? I have some vague memories that there's some different variables that can be attached to the leaderheads; at the very least, there's something that lets some leaders be less likely to agree to Open Borders and what not (for example, Japan starts with Kammu as its LH, and he opens borders much easier than Nobunaga/Tokugawa does). Depending on the ability to implement differences between the leaders, I think there is some opportunity for some more gameplay changes on the AI's part (e.g. having the Elizabeth/Victoria LHs be much more aggressive than the Alfred one to promote England's empire-building during the time periods those two are leaders, or for America, having Washington and Lincoln be more protectionist / less interested in interacting with other civs while making FDR much more to simulate America's growing international role from the 1900s onwards).

 

[Hickman888]

Different ideologies: communism and fascism

- I suspect you played Civ V or CIV VI, Civ IV uses civics instead. Now there have been suggestions to make civics feel more like religions or for certain civics to have diplomatic penalties but those were not implemented here. Dark Civ, however has some of these things.

I believe that Leoreth mentioned at some point that he would like to implement ideologies like that into the game. I think he said it would be baed off of the civics you pick for yourself, and would automatically put you in a certain ideological camp, and presumably you would be buddies with other civilizations that share your ideology, and antagonistic towards opposing ideologies.

 

[troubleshooting]

This would make the Russia game a good bit less complicated

 

[Peter84]

I'd love to see a new DAWN OF CIVILIZATION v1.17.
With new starting dates like 1900 and 1400 AD.

I don't know why the 1400 A.D. From 600 to 1400, not much happens. The game is usually the same, and in 1400 the maps are very similar. As soon as you start, there is more time to prepare for colonialism.

However, Scenario 1900 is a good idea. A lot has changed in the 19th century. States in Africa arose. The United States took all its territory. Australia has emerged. All the land was colonized. The world has changed like from 600 to 1700. The last 100 turns of the game are very interesting but not historical. It would be nice to write a new probably 20th century story.

 

[LukeAtmey]

I have a couple of questions that I'm not sure if they've been answered already so pardon me if that is the case!

1. Do you reckon the code rewrite will have any impact on loading times? Once the bigger map is finished and playable I would assume the turn/load times are going to be even longer in the latter eras. Will the rewrite help this matter in any regard or is there some other plan to address that?

2. The changes to how scenarios work as well as the change from players to civilizations present an exciting prospect. Do they also mean that Permanent Alliances could become a thing for DOC in the future as right now I understand the current setup sort of makes it impossible?

 

[Leoreth]

1) Maybe. There is not much opportunity to get at the major problems with performance, which are unrelated to anything that the RFC mechanics are doing, and only depend on the overall size of the map and the number of players. You are right that the new map will probably come with a performance tax of some kind, and we cannot do anything about that directly, but we can try to save elsewhere. Number of players is something where the rewrite can help to some extent. Once the transition from scenarios to custom games is completed, the mod is finally completely independent of tying civilizations to player slots. Note that in part, the number of player slots is the issue with performance, not the number of currently active players. DoC currently has what, 48 player slots? I don't think all of these are ever actually used even when many civilizations have spawned and are alive. So I could scale down the number of slots to a more reasonable number that is shared by whoever is alive at the time.

Still, that may not address the cost we get by switching to the new map. The best candidate for improving beyond that is to merge the mod with Advanced Civ, which optimised the game in a number of ways. Don't pin me down on it, but the number I remember is a 16% improvement compared to plain BtS. That would be extremely helpful in this situation.

I even considered merging Advanced Civ before going to the new map (and the additional civilizations that may come along with it) for this exact reason. But I figured everyone (including myself, if I'm being honest) would be a little tired at this point of under the hood changes, and it's nice to see some actual content changes for the mod instead. In particular for something so highly anticipated as the new map. So I'll do it that way. Which is also not too bad, we can observe how bad the larger map actually turns out to be and then compare what the eventual merge of Advanced Civ will ultimately give us. If everything goes to plan.

2) You are right that they are impossible (or rather, technically possible but probably bug ridden to the point of impracticality) under the current setup, but the reason is unrelated to the tight civ/player coupling. Civ4 has a concept called teams, which is used to implement both permanent alliances and actual teams in team games (they follow identical rules). Basically, the team is responsible for everything that is shared between players in a team, for example research and diplomacy. In RFC, every player is their own team, making the distinction meaningless. However, unfortunately, a lot of code is written with the knowledge in mind that the distinction doesn't matter, in particular that a player ID is always identical to the ID of the team of that player. I did my best to not rely on this assumption when rewriting the code anywhere I touched it, but I did not nearly touch all of these instances. So essentially: player/civ almost decoupled, player/team far from decoupled but some progress made.

That said, I don't consider this to be too much of a priority, because what are actually examples from history for which permanent alliances would be necessary? Having a European Union maybe, but even there shared research and foreign policy don't really apply. I considered modeling something like the British Empire, where many constituent parts are or might be playable civs, as a shared team, but I think a vassal/master relationship with some rules for playable vassals are a better fit for it. So I think this is mostly a theoretical problem.

 

[Publicola]

Hey Leoreth, is the 'transition from scenarios to custom games' still part of your plans for the 1.17 release? I didn't see it mentioned in your latest post on the rise-and-fall mechanics, and wanted to check. Thanks again for your work on all of this!

So, taking the list from above, the new priority list is:

1. Victory.py refactoring
2. Conqueror events refactoring
3. Clean up and improve autoplay
4. Clean up and improve Rise and Fall code
5. Transition from scenarios to custom games

3. Transition from scenarios to custom games and improve tooling for multiple start dates
3.1. Game starts from Play Now / Custom Game instead of Scenarios
3.2. Start date becomes a game setting instead of a consequence of the scenario you pick
3.3. Only one file describing the initial state of the map
3.4. Differences between the initial map and later start dates implemented in separate files with scenario infos or via Resources.py etc.

4. Change how scenario files work

 

[Leoreth]

Yes! That's going to be the last big feature before some sort of release. I was planning on updating this thread when the rise and fall changes are actually merged to develop, because until then they are not complete yet.

I have already been thinking and researching for that part a bit and I don't think it should take as long as the previous one. But it's still a bit until I can start working on it: fixing current bugs and then merging the rise and fall changes comes first.