I think you may be confused. This method is more or less already what SotE is doing. We stopped using a GCM after the Patreon-only release of version 0.1
Recent community posts
Yeah, well. Placing whole biomes by hand and placing them by providing monthly figures for temperature and rainfall with code are not exactly the same task.
We still need to retune climate tho.
I skimmed over it and I think this is actually roughly how climate in sote works currently, but the constants are not tuned.
+ I think we exposed climate defines in the latest release
I'll give a more throughout reply in the coming days, it's 2 am in my timezone at the moment
I'll keep this short because the subject isn't that complex either.
At the moment, we're using pie charts for data visualization, like so:
However, we could instead use waffles, like this chart:
or this one:
They have less dead space but they may be more difficult to read and only show percentages rounded to the nearest integer. They also have a bit different aesthetic.
Which one would you prefer? Or perhaps there is some yet different graph you'd suggest for the main data visualization tool (with exception of treemapping, it's a bit too slow to use all over the place)?
Sorry for a late reply. Corona got in the way of development and we haven't been paying enough attention to our media.
To answer your question, here is the list of currently planned (playable) races:
In general, we won't be limiting you to "civilized" peoples only. You will be able to play as (organized) tribes of hunter gatherers or nomads.
As a word of clarification.
The article you linked is actually also the one on which our currently preferred economic model is based (in a modified form to allow good quality to be taken into account).
However, keeping a market on each tile is impossible due to RAM constraints. I mentioned cities/settlements in my post above for a reason. We can have about 20k entities storing pops per million tiles. These cities then have territories from which they can extract resources (through farming, mining, fishing, woodcutting, foraging, hunting and other means). Rural population is stored on a separate list on those entities.
I'm under impression some people see tiles as our equivalent of provinces from Paradox' games. They're not. Settlements are. Tiles act as dynamic pixels to define environment for settlements so that things like available resources and farming rates can be determined.
It's not just pathfinding but also any other type of cache we may come up with (as well as them being the same as regions used to store animal data). If they could be redrawn, we'd lose out on these optimizations.
Demian and I were rediscussing the best approach to territories. As some of you may know, we want borders to be more fluid than those in most strategy games (especially at the beginning of the game). As such, we talked about dynamic provinces that can grow and shrink. There are, however, multiple ways to implement them that we are considering. We'd like to hear your thoughts on the subject (and possibly your own ideas as to how the system should be approached).
To introduce both models, we'll need some shared assumptions. The map is divided into tiles (hexes). Those hexes are then aggregated into territories. Each territory contains at most a single settlement (you can think of settlements as cities in Civilization. They're the main hub of population in any given territory). Settlements can then exert control over other territories forming more complex structures. Here, we'll call these structures "provinces". These aggregations will be dynamic in either model.
Our two models are what I'll call a "dynamic" and a "static" model. In the latter, territories are predefined, like they are in, say, Endless Legends or Humankind. Whereas in the "dynamic" model territories would gain and drop tiles depending on the hold they have on them.
Now, before you immediately say "Well, that's easy, I want more dynamic stuff!", the choice isn't as simple as that. Static regions have a lot more going for them than may meet the eye.
In no particular order, they simplify pathfinding a lot, allowing for much more efficient path caching and direct usage of algorithms superior to A* (such as HPA*). They would also allow us to store animal pops directly on them, removing the need to recalculate accessible animal populations for each territory with each monthly tick.
They also prevent issues with possibly excessive border gore in situations where a decaying coastal settlement could get squished into a thin line by two neighboring coastal settlements. There are some countermeasures we could take against that but they generally increase code complexity (which is *not* a good thing in an already complex simulation).
And, lastly, they're much easier to implement and maintain. Though, that's a bit less of a consideration (but it may open using them to bootstrap the simulation with the goal of replacing them by a dynamic model later on).
I think their issues are much easier to spot(rigidity, lack of adaptation to evolving terrain so they'd need to be based on terrain profile more than biomes, etc). If you can think of other issues or advantages (for either model), or a different model entirely, let us know. Otherwise, share your thoughts on the subject below.
I don't like such patch systems and there were already other patches on the way that we didn't inform people around so public and private versions were out of sync. As such, I think it's better to simply update the game repeatedly until we are ready to increment the minor version number.
Hey, thanks for the heads up. Ill investigate it further. I think its because the game does some very low level memory manipulation that is normally not done by user-space programs (they make the game performant enough to run on personal PCs). Antiviruses tend to dislike non standard behaviour.
Just to confirm, could you try running the other exe included in the main game directory?
Hey guys. We are working hard on 0.2 but 0.3 is getting closer and closer so I think it may be time to consider in more depth what exact technologies we should include in that update.
We'd like to hear your ideas and suggestions regarding technologies. What kind of techs would you like to see? ("writing" may be 'obvious' but what about 'Yam processing'?) What should be their dependencies (if any)? What special requirements should they have? (you can't research metalworking with no metal to work) Would you prefer an extremely in-depth tree with hundreds (thousands?) of "techs" describing different (possibly specialized) areas of knowledge or a more general framework with fewer technologies?
Keep in mind that SotE wont use a simple civ-like tech tree and that there could be multiple ways of reaching new knowledge and that a great deal of scientific progress will happen without your direct contributions so having a lot of techs wont necessarily mean a lot of needless micro.
I'll stick this post in this channel category for ease of access and future reference.
We want to spend a lot of time on this project. The ideal is to keep developing this game for over 20 years (kinda like Dwarf Fortress and Kenshi devs did). Along the way we will release playable versions of the game that won't have all the features implemented (but will still have more depth than all the competition on the market - see our tectonics demo).