OK, good points, all good points. I have a newfound respect for the difficulty of adding fire, (even although I suspect, as @hieronymous says, that lots of problems will automatically be resolved later on.)
But because I can’t help myself, I’ll try to take a whack at it anyway. (Some of it might be useful for other systems.) But because I am a noob, and not a radiant engineer, this might be stupid stuff, or stuff that’s already talked about. Don’t feel obliged to respond to everything.
My whack at fire mechanics
- To get computational load away, I thought it would be good to make fire spreading a “turn-based-inspired model”. That is, the computations only happen every stonehearth hour. Then, if you are insistent on the fire not spreading in a single instant, you can make the fire play out it’s moves over the next 10 stonehearth minutes.
- This might aid your hearthlings in fighting the fire, as fighting fire will now come in battles, not wars. It’s about getting out more fire every hour than the fire creates every hour.
- Also, if other systems can use this model, (maybe sickness), then you have a tool to keep load off your cpu, by plannning the computation time to be at a different spot. For instance, the fire is computed at every whole hour, while the sickness is computed every half hour. This is why this idea can be usefull even before you actually start working on the fire
- buildings can burn by parts, just like the way they are build by parts.
to balance the world not burning off at every lightning strike, you rip off the dynamics of the real world. (Video for reference) Bottom line: Forests which have recently burned are less likely to burn, due to the fact that there is less shrubbery on the ground. i.e. by introducing differnt levels of forest shrubbery that burns and grows, you can balance it so that forest fires sort of balance themselves, with an occasional big fire, which you need to protect the town from.
this also partly answers how far the hearthlings have to prioritize fire fighting. Since forest fires generally balance themselves, the hearthlings mostly needs to protect the town from fires, and only go into the forsts actively to protect wood farms, allies and to fight unusually big fires.
- As far as 2D and 3D are concerned, maybe a hybrid system can work. It has a few parts, which can be useful for other systems as well:
- First, the game keeps a heat map, a picture next to the save game .json, which specifies for each 2D voxel how many layers there are in the world in the column of that voxel. This lets the game know how 3D the world is. That building analogy you had malley, that applies to this too, where every ‘building floor’ counts like a +1, which affects the colour of the pixel in the heatmap.
- changes to this map can be scheduled at every nn:15 hour in the stonehearth world, to keep computational stress low, similar to how I described above.
- This 3D-ness map also sounds like something other systems will gladly benefit from. For instance: any other heatmap, which will have to come in different parts because of the 3D-ness of the world, can use the 3D-ness map to decode which of those parts corresponds to an item in the game world, counting from the bottom up. (The item on voxel (x,y) on the second floor of building Z is on the 4 layer in the world, thus there are three things directly below it, and you need to find the items heatmap values on the 4’th picture/layer of the picture(if you use photoshop or paint…net to create the heatmap, which have layers)).
- Then you make a 2D system, which cycles through all the layers of a column when it handles that columns voxel. The game determining for each layer whether or not the thing in that layer can burn, and will burn.
Maybe we should begin a new thread to continue the talk on fire, if necessary. This as to not derail the thread. @moderators, what do you think.
On the topic at hand, this is from a satisfied fan’s perspective:
As for the feelling of The Sims, what I think you are frustrated with is ‘skewed development’. The fact that hearthlings (and related systems) are the current focus of the dev’s means that the feel of the game changes. This is because these hearthling-related gameplay systems are in the game, but also because systems focussed on other areas of gameplay, like siege mechanics, the crafting overhaul, building repair, are not in the game yet.
Add to this the fact that the speech bubbles above hearthlings heads are a shallow feature in The Sims, and your association is complete. This is not to say that the association is wrong, and that the feel of the as-is game being too focussed on hearthlings is misplaced, but it is not a problem.
Ok, this comes from a longer post I was wanting to write on this, so I will have to explain what I mean by shallow features.
By a shallow feature, I mean a feature close to the surface, i.e. a feature you’ll likeley see as a player, and one which you will prominently see. Think any particular class, a certain race of enemies, main gameplay systems like building and combat, and that kind of superficial stuff. What I do not mean is one of the many interlocking systems which work on the background until the time is ripe for them to play a big role in some unfolding story, like the fire mechanic in boatmurered Hieronymous talked about.
I believe the dev’s have made the right choice in starting with the hearthlings. After all, to quote @Brackhar: “If the game is about hearthlings, start with the hearthlings.” That said:
When the hearthlings are done, and the team moves on to building, economy, environment, combat, or something else, this skew will become less noticable. (Not sure, just sounds like it would be true). At some point, the modd system will just be another system among many. It’s just that they decided to start with the hearthlings.
And isn’t this what you can expect in an alpha stage of development: That the feel of the game is off from what the released game is promised to be due to skewed development.
It’s like a puzzle: We currently have the border (engine) firmly in place, and we start in a corner with fitting pieces in the final puzzle (gameplay systems), meanwhile we have some pieces stitched together next to the puzzle board, which we don’t yet know how they fit in (engineer without siege mechanics, maybe a model of a titan somewhere, etc.). In that way, it’s not like a blurry picture that gets a higher resolution every pass you have at it.