Solar System: why the launch window matters more than speed
Most "space" games solve the transfer problem with a single line: press a button, arrive in N days. It does not work here, and that is the whole point. A transfer is not paid for in time, it is paid for in Δv — the velocity change the ship must produce to connect two points at two different moments. That is not eyeballed either: it is Lambert's problem, and the planner chart shows all 78×58 combinations of departure date and flight time at once.
A chart instead of a calendar
The classic "porkchop plot" of orbital mechanics is a heat map of cost. Dark is cheap, light is expensive, and the darkest point is the optimum — but it almost never sits where you intuitively expect: not "leave now", not "leave in a month", but on a specific date when the right geometry lines up. The practical rule: find the window first, then build a ship for it. If you assemble a hull by eye and only then go looking for a window, you will find your Δv budget cannot reach the cheap one — and the launch button simply will not enable.
The Δv budget is the real constraint
A ship is not described by a "level" but by the rocket equation: propellant, specific impulse of the drive, dry structural mass. Swapping a chemical drive for a nuclear-thermal or ion drive changes everything — the specific impulse, the mass, and therefore how much propellant you have to carry. Hence the uncomfortable but honest conclusion: a bigger ship does not go further simply by being bigger. The real choice is always "lighter and shorter" against "heavier, but slower and cheaper in fuel".
Three sensors, three bargains
A sensor here is not decoration, it is a source of trouble. Passive RF hears only those who are transmitting themselves, and never gives you away. Optical sees a cold hull, but goes blind wherever the Sun lights it, and depends on engine heat. Radar sees dark hulls, but its own illumination announces you to everyone listening. The practical conclusion: scouting and safety are incompatible, and "turn everything on at once" is the worst possible mode.
The rule: time, rate, EMCON
Simulation time runs from real time to millennia per second, and that changes the task completely. At high rate a multi-year transfer is a few frames; at low rate you watch the ship leave orbit, accelerate near the planet and only then settle onto the transfer trajectory. Add EMCON on top: transmitting an order is itself noise in the band, so orders to your fleet arrive after a light-speed delay, and a command given "now" is executed much later. That is a whole layer of the game sitting on top of the orbits — and probably the most underrated one.