[YesBox]

That would be quite an impressive game. Each simulation would need to be automateable in case the player does not want to manage that particular aspect of the game. Otherwise the game will fall into the trap of "trying to please everyone pleases no one".

Anyways, I'm working on Archapolis, a city builder game. The game will feature more hands on management than existing games in the genre, such as being able to design/build your own buildings. The player will see the interior of the buildings so making the exterior pretty wont need to be worried about. I'm also aiming to have a city board that will automate parts of the game for you if you choose (like having a fire marshall to handle fires)

I've got a tech demo of the path finding code up on youtube here, in case you're interested in path finding hundreds of thousands of units efficiently

https://www.youtube.com/watch?v=7q0l87hwmkI

[CMay]

Also been slowly brainstorming a city sim technical design on and off for maybe 7 years as a side project that has a few similar goals in regards to large unit counts and custom buildings so it seems we have similar interests there. It feels like it has a high risk of becoming an endless feature creep project, though, so it's been hard to prioritize as a focus until I can settle on what the soul of it should be which informs all other decisions.

Just guessing From what I see, it looks like you may have chosen a technical path that doesn't scale well even if the resource usage is reasonable at this scale (constant time != constant resource). There are certain features I want to have that I think your approach doesn't make viable, so depending on how your game evolves the algorithm may get in the way. You've probably already thought through some of that and figure with some optimizations maybe it will be enough for your needs. Might even have a little extra versatility in other ways.

Hope you find success! I'll keep an eye out on your project. One bit of feedback though, I would personally change the name. It's not fun to read and doesn't roll off the tongue very well.

[YesBox]

I've figured out how to make the path finding scale well-enough. Before I was using a hash table but that ate up 12.5 GB of space for 10,000 nodes. I looked around for better hash libraries and managed to lowered the RAM needed to 10 GB.

Then I figured out a way to store the results in a vector while still maintaining constant time access, which lowered the space needed to 2.5 GB. (This discovery came after the linked video, hence not being mentioned)

For reference, 10,000 nodes would be about 50 x 50 blocks (~4 nodes per intersection). Using Manhattan sized blocks, that's about 13 square miles of city, which is the same area as 3 x 3 Cities: Skylines tiles. Should be way more than enough!

Regarding the name, my first choice Metropoly was taken by existing companies (plural), and there's a domain squatter holding metropoly.com. Im not attached on the name yet so there's room to change it.

[CMay]

That's good to hear. Off-street areas do have their own cost as well which doesn't sound included in that, but there are other ways to optimize those which can depend to some extent on the designer feature set.

Gah, it's so tempting to share my notes, because you'd appreciate a lot of the ideas in there. It's probably a bad idea though, because part of the motivation to actually develop it would be to share those ideas and the vision some day. :)

[YesBox]

It's a solved problem. Off road travel off screen will use timed-teleporting, on screen I will use A*. I dont need to worry about real time path finding inside homes (no traffic, no combat, etc) if the unit isnt visible.

If this is something you are serious about then I'd recommend unlocking your enthusiasm and ideas. I'm not able to connect with you if you're secretive and indirect. If that makes sense then you're welcome to send me an email (see profile). My door is open to working with up to a small group of people, provided they can support themselves now and its a good fit.

[CMay]

We have very different lists of constraints that forced us to reason towards different optimizations. Unless your aims change drastically before launch, I don't think there's much risk that our projects would be highly redundant. It seems like you might have a larger focus on individual unit identities ala Dwarf Fortress than I do, but I still prioritize the value of identity highly with a different design approach.

Enthusiasm isn't a huge problem, it's partially that I have a great many interests of varying levels of importance where appealing ideas just pour out of my mind and that whole process enriches all other interests. The difficulty is that it keeps adding more and more considerations, so there's more complexity to comb through in order to prioritize.

Being vague is intentional, but not out of any disrespect. I'm doing strange things and part of their future appeal might be that they are strange, which wouldn't be the case if they become common in the market before I ever even get around to finishing it. :) That strangeness is also part of the problem, because there are a lot of harder to predict things that may go wrong.

[mpettitt]

Yes, I imagined that a component could provide some inputs (e.g. Grain) and outputs (e.g. Bread) with some default link between the two, and that would apply to all instances of that component within the world, unless a player took control of an instance and modified the behaviour. The nice thing there is that backing out of the instance allows for a different link between input and output to be created, without needing to simulate the full process.