I started prototyping something very similar to this but was going for a singleplayer thing to start where you control one ship at a time. The hard parts I bumped into were: 1) the scale of space doesn't play nice with Unity C# floats 2) the scale of space doesn't play nice with the player's time 3) Switching to a language I'm comfortable with that solves both 1 & 2 means I would have to go back to school to learn how to write a physics & collision resolution engine or learn a new engine & language.
In any case good luck on your project because the idea you have is basically the same as mine and has been a dream game of mine for many years.
Yeah, I've started with idea where you controlled one ship at a time too, but I think multiship gives more possibilities for gameplay. In my game, most of the time you would be controlling your ships on a map as small markers anyway (no need to render your nice 100m wide ships when they are 100km apart).
1. The scale of space: I was comitted to custom engine for this (first techdemo based on love2d). When centimeter resolution is enough, you can go with int64, it's good for one solar system and you can represent deep space as grid of empty solar systems (hierarchical coordinate system). At such scales, even standard doubles have problems and bigger doubles or are too slow.
2. Scale of player's time: hyperspace jumps for "small" distances of up to half a solar year (so many jumps required between solar systems) and big jump gates (so you have to pool resources with other players) for fast jumps between systems (allows for factions to have their own jump gates, war can destroy gates, you need to pool resources to make gates and can extract rent for jumping trading ships). Having to wait single minutes to dock or do any sensible navigation is a slightly shady but efficient way to hook up player for more gameplay time.
3. Yeah, choosing a good language and engine is hard, I can't help you with this, you just have to commit some time and try them all. Fortunately for me, I'm good at learning programming languages and can write in anything (client engine in c/c++/lua, server in c/erlang, some tools in python).
The way that article suggests adding more ELBs to the diagram would take a lot of work with a drag and drop tool is hilariously bad, maybe the author should learn how to use drag and drop tools or maybe they are using terrible ones that don't let you also drag to select?
Perhaps the language/stack they were using wasn't condusive to this but honestly I can't think of one where this would be a problem they couldn't solve with a module/package the performs the essential business logic piece.
the less digits you give, the less precise your input looks, the bigger the geohash tile you're in and the bigger the difference between your input and the tile's center.
