[TillE]

Thanks so much for all of this. It's extremely well put together.

I'm still trying to figure out the optimal way to organize every part of a Dwarf Fortress-style simulation (but multi-threaded of course), and I feel like I'm reinventing the wheel somewhat poorly. Component-based design is an important part of that, but there are still so many hairy problems to solve.

These are problems which most games don't encounter because they're not complex simulations. And the agent-based simulation literature isn't much of a help either.

[Ogre]

Something you can do with components if you set some strict restrictions is do static or runtime analysis to determine which sets of components are disjoint in terms of systems that access them. For example, if the combat system only needs access to combat components, and the builder system needs pathing and inventory components, then those two systems can run completely in parallel.

One place this is likely to break down is the transform (position) component, but one strategy for that is to differentiate between read-only and write access. Lots of systems need to know where things are (const access) but few need to change where things are (write access). All the systems that can deal with const access can still run in parallel.

The trick here is you have to strictly enforce all this. You CAN'T have a method for getting an arbitrary component from an entity, and this may drive you nuts. Instead you have to have each system specify ahead of time exactly what components it needs and how it uses them, and then hand them those components, and only those components. As soon as you let someone write "entity->GetComponent(Physics)" in leaf code, you've lost your ability to analyse the dependency tree.

For a lot of games, the other problem you're going to run into is that one or two systems are going to take up most of your time and every other system is just going to sit around waiting for those anyway. Usually those are physics and rendering. Which you might be happily avoiding by making a dwarf fortress style game!

I have a coworker who's got a "toy" engine at home that does all this and some other fairly amazing tricks. He says he's going to open source it, still waiting on that. Sorry for this pointless tease, just wishing he'd hurry up out loud.

[RobotCaleb]

That's an ambitious project you're undertaking. Can you share more?

[TillE]

As I said, on a technical level think Dwarf Fortress - but with a bit less detail and a much larger world (potentially distributed across multiple servers). I'd like to be able to truly simulate a medieval/fantasy RPG world, so a player can see logical consequences from their actions.

The same underlying simulation could conceivably be used for a peaceful economic sim, or a highly strategic military game, or just an RPG with a ton of depth.

[Noelkd]

This is something I have been thinking would be great, Mount and Blade has been the only game that has come close in my opinion.

Don't really understand how you would stop players just slaying all your NPC's? Which I think isn't a problem in the whole if it was offline single player but after playing many online games I just can't see it actually working online.

Also recreating DF with a lot less detail in real time across multiple servers seems like a insane technical challenge good luck!