The colored land outside the polity are the regions the polity considers part of their core regions. In theory, a polity would try expanding into those lands until it covers them fully. But it doesn't always work. Especially if the area is too big or it is already occupied by other polities. I will try to improve on that behavior on future versions.
So, the values that I need to calculate can be calculated on demand when the player performs the action. The game is currently designed to stop simulating until all decisions are resolved. So I could use a naïve algorithm to calculate those values. What the player would experience is one second pause (approximately) while the game calculates the values before presenting the player with a choice. This doesn't seem like big deal, but this precludes me from ever using that same algorithm in situations that do not involve pausing the game.
What I want (and I already have a solution in mind. I just haven't written the code yet) is an algorithm that updates those values on-the-fly while minimizing the recalculations. This way, the values will be already calculated before the player performs the action and there will be no delays in presenting the player with a choice. If this works, then I will be able to use that same algorithm in situations that do not require the simulation to pause.
Like I said, I already have a solution in mind. It's not perfect and will require a bit of work. But it's a decent solution that solves the bigger problem: What I need is something that gives me the bounds of a polity (in map squares) without going through every cell. That is, without doing 'n' checks (where n is the number of cells in the polity). If my solution works, I will be able to do it by performing roughly sq(n) checks (where 'sq' is the square root). Also, this is an operation that I will only need to do very occasionally. 90% of the time, I will only need to perform one check when I need to update the bounds of the polity.
The decision to change allegiance will depend solely on the relationship strength to keep things simple and easy to balance for the next version. Later I'll start adding more parameters that take into account relative strength, etc. Though right now I don't have a metric to measure a clan or tribe's strength.
I understand the complain. One of the reasons I made the game open source is to give others the opportunity to improve the code in places where I can't. But assembling a team is not straightforward. The few people that have helped me eventually drop out as interest fades out over time. Though I don't blame them. The codebase is badly organized and very hard to work with (which is totally my fault). On top of that, the project earns very little money, most of which I have used to pay for hosting services (which I will discontinue eventually), to buy licenses for a few dev tools, and to buy a macbook to work on the macOS version. So anybody willing to work on the project has to work on the expectation that no money will be ever earned. If this game ever explodes in popularity, which is unlikely, then I'll consider hiring people to work full time on other aspects of the game. But for now it will continue to be a personal hobby project.
So, as long as I'm the sole developer, my main focus will continue to be on the simulation since its really what drives my interests and it is the core of the game. But I'll try to add more player interaction elements whenever I can.
I have to clarify. What you are seeing in the gif is not a battle. It's just weird migratory behavior (which as of this writing I have already made less janky). People from different tribes are migrating into each other territories and claiming them as their own. This is a decades-long process that only seems to happen very fast in the gif because the simulation is running at top speed.
So in this instance there's no need to involve any of the complex economic and societal effects of war. "Aggression" is only involved in the sense that more aggressive tribes are less reticent to move into another tribe's territory and push people away. But I have yet to add any sort of mechanics that would actually involve violence. I'm still not sure how to implement it since the most obvious effect, population culling, could have severe consequences and I want to be very careful about it (I don't want my game to turn into just another genocide simulator). Not all tribal interactions, even violent ones, ended with the extermination of one group. I would argue that in most instances, the most common result was cultural and societal intermixing.
Remember that right now I'm just simulating very very primitive cultures. Once I start implementing more complex cultures then I will (very slowly) add the concept of warfare with all its political and economic intricacies.
You can modify the events to tolerate higher administrative limits based on the knowledge levels of a tribe. Though administrative loads are still experimental and you might not be able to control the effects very well. You will be able disable/enable tribe splitting events through discoveries hopefully by the next alpha.
It's unlikely I will ever go into that much detail for every population member since that would be too CPU taxing. But I might add procedurally generated descriptions for certain individuals (like leaders) which might include details on their physical appearance but will focus mostly on their exploits and/or their character.
I plan to add general cultural descriptions for entire tribes or clans. Like what typical members wear or what customs they practice (festivities, ceremonies, etc)
I still haven't done it. But for 0.3.4. The way discoveries are modded is going to change. You will no longer define the discovery and the event that triggers the discovery on the same file. So it will be possible to trigger discoveries in different ways, which will include modded decisions and actions.
I like the idea of naming eras, but I think there's no need to set an arbitrary start or end of an era. My hope is that certain cultures will be able to set eras on their own. For example, different civilizations might have their own classical eras at different stages. And they might end calling those eras by different names. And once I have proper timeline exploration tool, you'll be able to browse the timeline of different civilizations, with markers for major events and discoveries added in.
I do hope to be able to build a time-lapse mechanism. There will be an autosaving function on the next release that will let you save the game every 1000 years for example. So you'll be able to go back to a previous stage of the simulation. Though the save/load process is slow. So it might not be very enjoyable to use. I'll tyr to improve on it though.
The speed at which tribes expand is variable and can be easily be improved on. You saw on the gif I posted on the last devlog how a tribe grew to occupy the entire continent in less than a hundred years. Though in this case it was completely unintentional. Tribal growth will be mediated by technology and better social organization. Once I get to add more advanced civs, you'll see them grow much more quickly than the initial tribes.
You are right that primitive polities shouldn't be able to grow that big (even the small ones I generated in previous versions were unrealistically large). That's the reason I added events that split tribes and clans when they grow too big. In this case though, the tribe is growing so quickly, none fo the splitting events had yet a chance to occur. I ran another example where I left the simulation run long enough for the megatribe to eventually split into dozens of smaller tribes, but it took a long time for that to happen because the simulation was running very slowly (about 300 sim days per sec).
Your first paragraph I think get's very close to the crux of the issue: Environmental factors are not limiting population growth as much as they should. And that's something I will have to fix. Nevertheless there's a missing piece in the puzzle. This problem seems to happen only with tribal populations and not with unorganized bands, which doesn't make much sense since I basically use the same algorithm for both. There's something in the code that I'm not taking into account with effects tribal migrations in unexpected ways...
The expansion behavior of tribes is guided by which regions they consider as core to their territory. And regions are defined mostly by the biome which is more common. So, in theory. I could make it so that tribes choose regions more appropriate for their survival, which will make them enter into conflict with other tribes occupying those regions. I say in theory because right now, region selection is totally random. I plan to change that eventually. But it might have to wait for a future release. My current priority is still to get tribes to expand properly and push each other around. It doesn't matter yet if the region is worth it or not.
Thanks for this little essay. It does help me think about what aggression should mean in terms of the simulation. Unfortunately, there are many details that for a variety of reasons I can't add into the game (lack of time being the most important factor). But I wish I could add at least climate change, which, as you mention, was the most important factor driving people to migrate from one place to another, and enter into conflict with others during pre-classical and classical times (and way into the late middle ages, up to a point).
I might end up revising my plans for 0.3.5 or 0.3.6 to add climate change to simulation at least in a very abstract manner.
For the moment I have no plans of adding fantasy races. It's complicated enough just to add mere humans. But I might add modding tools to add fantasy races in the future.
I think they are going for more fantasy like worlds? I couldn't tell you more since I don't follow that closely. Though I must say, what they have done so far looks pretty cool.
I must add, I would keep an eye on Worldbox. They are following a very different approach more focused on fun than realism, but with every update they are adding more and more complexity. I wouldn't be surprised if they end up with a very advanced simulation game eventually.
At this point, territories are not 'politically' defined. Instead, each cell on the map is assigned to the territory of the tribe who has more 'prominence' on it (where prominence is just a percentage of population that has allegiance to the same tribe). Prominence is gained or lost through demographic changes and acculturation.
That said, my intention is that, as tribes become more politically complex and new forms of government appear, then territories will start to become less fluid and they will no longer change hands simply due to demographic changes. In this sense, tribes might need to start laying claims in order to acquire new lands, and these claims might overlap with competing claims. Though there will always be a polity or tribe who has de-facto control over a piece of land regardless of how many claims exist over it. But, like I said, I will need to work on more advanced forms of governance before I can add territorial claims.
1. There's other projects with very similar ideas. Of the top of my head I can think of WorldBox and Song of the Eons. 2. For 3.6. I plan to add at least chiefdoms. But the intention is to make government types moddable. So modders will be able to add new government types.
At some point, high res maps will be added. I also plan to add a height-map exporter. By the way, the game already includes a function to convert maps into image files which include any active overlay. It's not the best thing but it might be useful if you want to get only the maps to use elsewhere.
The new version is very likely to be buggy. That's why I want modders to help me test the alpha version. I'd would like to receive suggestions and comments so that I can fix them before I put out the public version.
Some things are going to remain pretty much the same, like biomes and layers. So it's likely you won't find any issues there.
Lastly, The next release, for the most part, is still going to support mods made for 0.3.3.1. So you can continue working on this version of your mod and then port it later.
Hey mod creators! If you like to get early access to 0.3.4 and test the new mod system (which is very incomplete, but still), please contact me through my email (drtardigrage2020 at gmail) or by DM via twitter @DrTardigrade
n3xpo, sorry for the very late response. Hilliness is a value that is calculated internally based in a couple of factors like neighboring cell altitude. Accessibility is affected negatively by hilliness (cell base accessibility multiplied by 1 minus the hilliness value of the cell). Though, there's no way to modify this interaction through mods. Survivability is currently unaffected by hilliness.
I need to modify the game to use localized texts which would take time, even if I don't do the translations myself... I will do it. But probably for versions 0.3.5 or 0.3.6. If I don't have it already on my to do list, I'll add it right now.
No, it would be a very terrible idea for this kind of open ended project. It would force me to define a very strict scope and schedule and which would have a very very low chance of success. Besides the fact that I would have to spend 100% of my time just advertising it.
