User interface/user experience is important to any game, even though some games manage to limp along with pretty bad interfaces. The Atomic Space Projects in particular will most likely live or die on interface, presenting as many aides and visualization tools as possible to make the alien and complex problem of orbital mechanics more approachable.

The interface of Atomic Space Race has been a slowly growing pile of elements shoved into random corners of the screen as they’re implemented, to just get things on the screen. That’s been productive but makes for a mess that’s hard for people who aren’t me to navigate. And even if you know where everything is, you need to cross the entire screen constantly when doing common things. That’s entirely no good.

old interface
How it was
new interface
How it is

So here you can see the reorganized user interface. For the most part the functionality is the same as the old, but things are a lot saner. I got tired of the grey look, so while I was at it I splashed some color on the interface.

This is by no means the final form of the user interface, either in function or look, but getting it to testers has shown a big step up in usability.

To cap this off I’ve put together an updated narrated video, since the old one didn’t have the bloom and newer UI.

4 Responses

  1. Hi!
    I think the new UI looks much cleaner and attractive.
    Do you have plans for adding KSP/COADE-like click-and-slide controls for creating maneuver nodes? If not, what are the challenges or difficulties involved?

    1. Those sorts of features are definitely on the to do list! They’re not trivial to implement, but they’re also very high value UI features in my book. I can break the issue down into a few sub-issues.

      First is just being able to click on things in the world. This shouldn’t be too hard, and I’m running out of things I need to do first. Still, the out of the box solutions to making things clickable in unity don’t seem suitable to my situation, so it’ll be a little work, and anything to do with GUI can be sticky.

      Second is instant feedback. My simulation runs gratifyingly fast, usually simulating the whole course of a ship takes a few seconds at most so long as all the planets have been simmed out already. Unfortunately, that’s still an order of magnitude or two slower than needed for smooth maneuver-parameter sliding. If you’re dragging or sliding orders you want at least 30 updates a second to feel good. To achieve this I expect to need an approximation like the patched conics that KSP uses to display the portion of the course the simulation hasn’t gotten to yet. My plan is to display this as visibly different than the simulated plot, for instance with a fuzzier, wider, or dotted line. I see no reason why this should be impossible or impractical, but neither does it appear particularly easy from where I am now.

      Third is the orders themselves. Right now maneuvers are in absolute terms, you have an exact world-space vector you’re burning on and that’s that. If you want to be able to slide an order around KSP style, that’s no good. A ‘forward’ burn at one part of the orbit has a different vector than a forward burn elsewhere. Orders need to be stored and processed differently from how they currently are for that to work. This shares some infrastructural needs with the patched conics to do well, but is definitely on the list of things I feel would be a big help to players. Similar work is needed to enable useful very low thrust maneuvers also, and that’s something I want to enable.

  2. I have an idea. I am not sure how it will work out in practice :

    ‘Running line orbits’:
    -Instead of calculating the entire trajectory out to a predetermined period of time, you slowly trace a trajectory after each update to the trajectory.

    The effect is that if I pull on a slider continuously, with 30 updates a second, the trajectory is only drawn ahead for 1/30th of a second. In that time, it will not trace a very long line, but a short line very close to the maneuver node.

    Single-click updates restart the trajectory trace once per click.

    Instead of being able to click anywhere on the trajectory to create a maneuver node, add an alternate UI box at the bottom of the screen that you can use to slide XYZ inputs into. The box is fixed in the UI and not part of the ‘game screen’.

    1. Your first suggestion is more or less how it works currently, the simulation is run as far forward as can be afforded within a single frame. The question is if that’s far enough to show a useful amount of course when you have to start over every frame because the user is dragging a value. The answer to that question is going to probably vary depending on the level, because simulation speed depends to a degree on the content of the simulation.

Leave a Reply