itch.io

I think there's some misconception here. SotE 's funding run out but the game is still under development by the community. We open sourced it under the GPL license ( https://github.com/Calandiel/SongsOfGPL )

It takes 1-3 minutes to generate a planet with your high performance computer precisely because the planet generation system isn't bad (in the sense of accuracy). SotE runs a tectonic simulation, calculates fluxes of magma heat, runs multiple climate simulations at different timescales, runs erosion simulations, figures out watersheds and lake placements by running a physical simulation of water movement and drainage, generates soils using a physically based bedrock erosion model while also coupling it to the water movement simulation, generates glaciers along with their movements, runs a plant growth simulation and so on.

And that's just a short summary, each of these steps is much more detailed than just doing the simplest thing possible (to give an example, if you pay close attention to oceanic plates youll see that as they get older they get denser, leading to deeper oceans on average at one edge of the plate)

Calculating all of that is a *ton* of work and that's why world gen takes a long time. 1-3 minutes sounds about right. On my laptop it used to take 5-7 minutes to run full world generation.

As for the game, assuming you're talking about the version from itchio, there isn't any. At that point in development it was only a world generator.

Source for all of the above: I coded around half of SotE if measured by lines of code. 

Well, I don't check on itch io often but I am here now. If you're still around, we can chat ^^

It's a Goldberg polyhedra

What do you find "bad" about SotE? To my information it's the most accurate planet simulation you can run on a consumer device, provided you have 8 GB of RAM (which is more than normal, it was benchmarked against median computers as per Steams hardware survey: https://store.steampowered.com/hwsurvey )

Splendid! I send you an email, let's discuss everything there ^^

Hello! ^^

I'm not sure what would be the best way to reach out as I don't use Twitter so I'll try my luck here.

I want to ask, do you take commissions? I've noticed you have a Patreon account but I'd be interested in having a bunch of old school textures made. I've been using your texture packs for prototyping and I've come to like them so much I'd actually prefer using them for the final product. Only problem being, they don't cover everything I'd need.

If you do take commissions, do you perhaps have an email address for business related queries? I'd like to know the rate and discuss some other details. For example, I would prefer if any textures I'd potentially ask for were made publicly available like your other texture packs. Not sure if that'd work with you.

Best regards,

Calandiel

OwO

Ah. I haven't had a chance to test the game on any kind of multi monitor setup (I work on it on a laptop). If you're on our Discord server, could you send me a DM? I'd send you a recent version of an in-development build, I'm curious if the issue persists in the latest iterations of the game.

Interesting. It's the first time this was reported. I wonder if it's perhaps the Unity version 0.2 was using slowly getting outdated. Thanks for the report, I'll look into fixing it for 0.3

I'm not sure if it's referring to some of the latest videos by Solitarian showcasing our 3d world renderer, but if it is, Demian told me to remove it for the foreseeable future.

While cultural "evolution" is more or less necessary to accomplish our goals, biological evolution isn't planned. At best there will be a sort of tech tree for various plant cultivars or breeds of domesticated animals but I doubt that's what you meant.

It's a video game so I highly doubt that will ever be a thing. Simulating all imaginable planets isn't a goal for us.

Sorr, it likely will never be supported. Changing the world size would make the climate model hopelessly inaccurate.

It's a false positive. You'd need to add the launcher to a list of exceptions.

The launcher is open source if you'd like to read what it's doing before adding it as an exception: https://github.com/Calandiel/sote_launcher/blob/main/loader.c

in 0.2, w/s/a/d + mouse wheel

Could you provide more information? What version of the game is it exactly? When does the error happen? Right after double clicking the exe? Does it render the launcher or the main menu at all? What's your operating system? Have you tried running it again to see if it's a persistent issue? Most versions of SotE (including the latest 0.2) have two executables in their zip file. You have to use the one with Launcher in name. Additionally, on some systems, it may ask for administrative privileges, on others it may require them but fail to ask.

I'm not sure how that'd work.

I looked at geojson on wikipedia:

https://en.wikipedia.org/wiki/GeoJSON

and it seems to be a data format for storing lines, polygons and points on a globe.

What exactly are you expecting from such feature?

They'll be re-enabled in the next update -- the way they worked wouldn't fit 0.3 because it'll only contain the stone age

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

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

No. I mentioned it at the end of the post:

"(with exception of treemapping, it's a bit too slow to use all over the place)"

I used my admin powers to fix it

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)?

To give an update, we went with static territories/provinces.

They'll be on average the size of irl Luxemburg (the country, not the city).

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:

https://sote.miraheze.org/wiki/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.

World gen is close to being finished (tho it still needs bugfixing and parameter tuning) and it's a hobby/passion project so I think we'll be fine ^^'

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.

65 km^2

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! If I may ask, what's your CPU?

Yay

Yeah, in that case there shouldnt be any other issues, but you'd need to open the game through SongsOfTheEons.exe (which is the launcher).

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?

Nope, sorry, the game uses more RAM than is allowed on 32 bit systems. It's a technical impossibility.

You could check Songs of the Eons on itchio if you want detailed plate tectonics. Tho, SotE doesn't let you draw on the map.

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).