Hi, Citybound author here! Thanks for posting this here as well. Since this is still at the top, feel free to ask me anything about the project. Make sure to check out aeplay.org/citybound for a more concrete and up-to-date impression of what the game does than the README. Also join /r/Citybound where I'm quite active!
Physics and graphics aren't the main issue with Eve, the problem is that ultimately the game logic - how much shields a ship has, who is targeting who, who is shooting at whom, has to be synchronized among all players in a system, unless you sacrifice consistency and somehow partition this logic to separate independent units. This kind of synchronous game logic cannot be easily improved by stacking more processor units, as Amdahl's law shows.
This is significantly harder than the challenges of a server which mostly serves static content (like Netflix or Google search), which are indeed bottlenecked by IO and not CPU.
I know one game which is trying to tackle this issue from the start - Citybound, and time will tell if their approach will work. But the architectural change needed(e.g moving from shared mutable state to message passing/actor based concurrency) is massive, tantamount to rewriting the entire game. It's hard to blame CCP for their architectural decisions, considering this is a 17 year old game.
Wow, this looks great. Reminds me of https://aeplay.org/citybound , it would be super cool to design a city in Citybound and then solve the traffic problems with A/B Street.
The subversion city generator you linked to is pretty much the gold standard - unfortunately it was abandoned and no one knows HOW they pulled that off.
Most city generators out there either use a straight grid (think Manhattan) or some sort of an L-systems derivative (google "Parish and Muller").
The only generator out there that has curved roads is Citybound (click on github logo at the top to see the repo).
I have my own Godot implementation that has curved roads, but is definitely less flexible than Citybound's (no hand-editing) and it has other limitations (only one lane wide in each direction, only 3 and 4 way intersections so far).
IMHO the main thing you need to ask yourself is "what do I need the city for"? If you want it for a FPS/TPP/RPG game, you'll need interiors, but you don't really need curved roads as the player will most likely spend majority of time indoors. If you want just some scenery, you will probably be fine with a grid AND buildings that are just premade models, no extruding shapes. If you want a racing game, premade models probably will be fine, too, but you really want curved roads at the minimum, and most likely other things too (banked roads, elevation differences).
Yes, I imagine Anselm has plans in this direction. It's just difficult of course because he's taken on a hugely ambitious project, is doing it more or less alone, and isn't currently receiving enough in sponsorship to work on it full time.
You can read more about where it's going here btw: https://aeplay.org/citybound
Thanks for the fix! I noticed a small mistake on your blog post for the live builds (old I know) where the live builds are linked at <strong>aeplay.co</strong> instead of aeplay.org. While this won't impact anyone here, correcting the link should reduce confusion for any newcomers visiting the site.
The projects have some major differences -- Citybound simulates economy and zoning, not just transportation, and it allows creating everything from scratch. A/B Street has the much narrower purpose of exploring the effects of simple road/intersection changes in an existing city. I'm excited to watch Citybound evolve into something very moddable.
As for sharing libraries, /u/theanzelm certainly may have a use for fast_paths!