The day job has been burning me at both ends for most of this past month, but I’ve still got some stuff to talk about. Working under a less comfortable time budget than the last time I touched the project has prompted me to turn my attention away from the more toy-like facets of it and refocus on making it something to play. The third arm of the project, ASTools, will thus languish until I really need some part of it. That said, the most recent release of AST is now available from the links up top of the page if you want to fiddle with it.
In the mean time, let’s look at Atomic Space Race’s current form, and some thoughts along the way about where it should be going. It’s worth saying upfront that the interface is currently at a stage where I know it’s quite rough and ugly, I’m throwing tool ideas at the screen to see how they need to be implemented and how useful/necessary they are, then once I know what needs to be there I can find a more pleasing way to organize and skin them.
Centrally, there’s the display of motion, with the purple line being the player’s ship, the ring at the end representing the present location and direction. I usually refer to these as the motion plots. You can also see markers for each planned maneuver. The icons for this are a bit shaky and could do with a revisiting soon, especially since the direction indicator is a bit too easily lost in the lines. Currently ta plot is shown for approximately one orbital period in the future, relative to the object’s current orders in case of a ship. I’m experimenting with ways to improve the utility of this as the player probably wants to see the entire future course of a maneuvering ship, and in more complex systems than the one shown here one orbital period might not be sufficient. For instance the shown system has only Jupiter and it’s moons, no sun. If you added the sun you could want to see where the moons would be for an entire Jovian year.
Another objective for the plots is to show some sort of marker or gradation for passage of time along the plot, so it’s easier to identify what’s moving fast and slow, and perhaps easier to line up encounters as a result. The exact means of doing so is still up in the air, my past attempts to do so weren’t very pretty or fruitful, but I mean to try again.
Further you might want to be able to switch between seeing their motion relative to Jupiter, the nice circles you see here, and their motion relative to the sun, which would be an exciting corkscrewing motion, and do the same thing for your ships. Recent experience with other space combat games, particularly Children of a Dead Earth, shows that a relative display is a pretty useful thing, so that’ll be a near term priority once more immediate tasks are cleared out. It’ll probably be a vital tool for more complex scenarios, and later actual combat in ASN.
Down at the bottom are the time slider and scale. The scale is the smaller box in the center, where the white line is the length stated in the label there under it, in scientific notation. what that means is that that little 100 pixel bar represents about 556 thousand kilometers, or 345 thousand miles. That makes the screen itself about 10.6 billion km, or 6.6 billion miles, wide. A trip all the way around the earth is at most 40 thousand kilometers, for scale’s sake.
Above that is the time slider, which you can grab and move anywhere along. Right now in ASR motion through time is entirely manual, you have all the time in the world to solve the mission’s challenges. Challenge modes where you only have a certain amount of time to figure things out and your start time is always moving forward, or replay modes where it auto-advances from start to victory, both seem like they’re worth looking into later.
The labels here on the time bar are all in seconds, as are any other times you see in the UI at present. Deciding what the most useful unit to show a time in is not an easy question so far. Doing it all in seconds is the most practical to me, as everything is easy to compare, but the numbers do get large enough to be hard to manage quickly. The window for this particular test level is 60 days, just over 5 million seconds. If eventually multi-year missions are in play, that’s a lot of big numbers to juggle, though once you can pick manuver times with clicks instead of manual entry it’ll be a bit less of a problem.
Since finding points in time more presicely can be important to manuver planning, on the right side of the screen are some ways to move in time in discrete steps. I wanted to avoid outright number entry but give as much power as possible to move around. In the captured moment here you can move forward or backwards 100 or 500 seconds, or add or remove a zero to those numbers. Also visible is a stab at presenting a more relate-able time display string. It’s a bit rough in it’s own way.
Up top center you can see the victory condition display. Right now it doesn’t really give you much info on exactly what’s being demanded of you, but it does tell you when or if you’ve finished it. This will have to improve. In the scenario shown here the player satisfies the requirement to get to Io, but not the rest, so they never meet all their objectives.
Top right is the info panel. You can get a lot of information about your current position and motion, as well as that information relative to a given target. Right now targeting the relative display requires typing in the name, eventually a dropdown and some clicking should be able to do it. Also here is the ‘burn’ button, which gives you a manuver node at the current time to attempt to put you into a circular orbit. Right now this assumes you have essentially infinite acceleration capacity. Also it requires you be close enough to an object to orbit it, naturally. Trying to orbit Io from your starting location will give you a burn, possibly an exciting one, but it won’t put you in orbit of Io.
This kind of operation is something I’d like to make more buttons for. I don’t want to make the player do orbital math all on their own, I want to give them tools and let them figure out how to combine them for the most part. Of course if they want to do the math themselves, that’s fine too. Which brings us to…
Top left and far right respectively, we have the listing of maneuvering burns, where you can select existing maneuvers or add new ones, and the edit panel for setting up the details of a burn. You do this by entering a direction, an acceleration, a duration, and a time for this all to happen. As you can tell, a lot of manual figuring currently. Ways to more visually edit things is on the to-do list, but I want to always leave the option of precision, and a little trial and error have gotten me solutions to my test objectives far more easily than I ever expected. Not seen here is a relatively recently added button that auto-fills the start time of the burn with the current position of the time slider. A near term goal is similar buttons to set the heading to standard useful directions, like with or against the current motion, or at right angles to it.
One thing to note is the heading values currently are a bit dumb. This is a consequence of reusing the code that sets up the rotation of the burn marker sprites on the screens to come up with the heading values. This results in values that look like this:
rather than a more standard compass like…
I recently noticed that this is not helpful and following a more broadly understood convention might be helpful and am in the process of fixing it, but got detoured into a bit of code cleanup that should have happened a long time ago that should prevent weird inconsistencies from cropping up as a result of the change.
And there you go. Now the pressure is on to get some meaningful progress to show off in the next month! See you then.