Author Archives: EatThePath

ATOMIC SPACE NEWS #20: Relative points in space and time

Tricky February almost snuck past me!


The work this month was focused on expanding the capabilities of the trajectory plot mouseover, as well as straightening out some kinks in the backing code. Now when you mouse over it not only shows you the time frame of the object you are mousing over, but also displays marks for the positions of all the other objects at that moment in time. This should help in planning intercepts as it makes it much easier to scan back and forth over a time period to see when objects line up right.


Shown here with the UI and thus context menu turned off, because I love that neon glow.


The display can now also be frozen by clicking, making way for an interactable context menu. The context menu doesn’t currently do anything, but options I intend to explore include creating orders at the selected time, copying the time to a currently selected order, and selecting the nearest order forward or backward in time. I’m a big fan of context menus as a GUI feature in general, so getting this working is pretty exciting for me.


That’s all, see you next month.

ATOMIC SPACE NEWS #19: Relighting the fire


It has been too long since the last update. It was my goal originally to not have a month go past without an update, and now that’s solidly failed. Reasonably speaking News#18 doesn’t really count, and news #17 was over three months ago. I can only apologize for that, both to you and myself, and continue to move forward.

It’s often tough to pick a project back up after an interruption, and that’s effectively what’s been going on here. While never having been a full time dev project, for a few months there it got shoved further back burner than before and went a little cold. At the same time there were some things in the code that needed doing that were giving me conceptual problems. Now as I’m getting some momentum and breaking those mental blocks, progress is happening again. So, let’s talk about that.


The Atomic Space Project exists at all because I stopped trying to figure out the perfect ideal way to write the simulation my dream game needed. Instead I implemented it the most obvious way and got something that worked. A few relatively straightforward math improvements later I had the foundation that everything now rests upon. That taught me a lesson about development that’s been very important to me, but that I occasionally forget.

Many improvements in the systems of the game have been waiting on a standardized way to view the system in terms of keplerian orbital elements rather than raw state. While a pure-kepler based simulation leads to many nuances of orbital motion being lost the information it provides is still highly useful. While the math for this is not especially hard, in fact parts of the sim were already doing most of it, I was stuck in the trap of premature optimization. Out of concern that some of the parts of the game that will depend on it might end up bogging down I spent far too much time agonizing over how to build the most efficient data structure and cleverly cache the results of kepler queries, and so forth.

Generally it’s best to optimize what you know for certain is slow, rather than spend huge amounts of effort optimizing something that may turn out to be nowhere near as big a problem as it seems. The irony in this case is that I’ve identified places in need of optimization, and they’ve been waiting on the kepler querying to be implemented before I can properly attack them. Real identified as necessary optimizations held up by premature optimization.

After talking over the state of the project with a friend who is better at development than myself I finally recognized this fact. Once I had I set out to clear the slate of all my overly complex stumbles and simply add dead-simple kepler querying to the sim with little to no optimization. That didn’t take very long at all. After moving the existing ad-hoc kepler conversions in other parts of the sim over to the new centralized method I did some profiling and found that currently it has no noticeable performance footprint. Since it’s all on a unified infrastructure now, if expanded use in the future does start to have an impact I can implement caching for it without any changes to the rest of the game’s code.

Once I’d gotten that mental stumbling block out of the way I realized I was similarly over-complicating what I’d need to do to make mouse-based interactivity work, and got a start on that. The under-the-hood simulation improvements are always good for the future of the game, but things that immediately alter the experience of playing the game are great for stoking the fires of development.

Right now the only thing you can do with a mouse is to hover over a trajectory line and see what time that point in the plot represents, but the under the hood bits that make that possible should also enable the implementation of a number of other UI bells and whistles that other orbital mechanics games have, to significant player benefit.



Last blog I was planning on gathering requests for cool fictional or extra-solar planet systems that I’d put in game and show pictures of. Unfortunately, while I did get some requests, the information needed to implement those requests was quite thin on the ground. Even pretty hard-SF properties pin down the elements of their locations quite rarely,and this was meant to be an exercise in implementation, not invention.

Instead, I’ll give you a pictured of my current, updated development to-do graph.

ATOMIC SPACE NEWS #18: What’s your favorite star?

This past month has seen the least development time on the project of any month since I started this blog. Still not zero, but the progress I have made is not very flashy. December will be more fruitful, and the project is still alive.

So, instead of information, this time I have a request. If you have a favorite star system, real or fictional, make a comment telling me what it is. If I can find enough information about it online I’ll recreate it in the game and post pictures in the next update.



Last time I talked about tighter coupling of gameplay logic to the core simulation. A deeply connected and equally important effort has been uncoupling the game display and that simulation. Over time some simple, easy first-effort implementations of features have given the user interface direct access to the core simulation data. The interface obviously needs some way to get that data to display anything, but full unfettered access can lead to trouble and rigid code that is hard to update later. A lot of my work since the last post has been me finally pulling off that band-aid, cutting off access that the user interface has completely and fixing everything that breaks. I believe that’s pretty well finished, and everything works now.


Runtime barycenters

In addition to clearing away that technical debt I’ve been able to get some important simulation features in place, the first fruit of which is engine recognition of barycenters. As previously discussed when talking about adding binary stars to the level editor, a barycenter is the point around which a pair of objects orbit. Strictly speaking all cases where we would say one object orbits another are actually two objects orbiting a shared barycenter, but if one of those two is significantly more massive than the other the barycenter and the center of the more massive object are so close together that it the difference can be ignored.

When two objects are similar in size however, and assuming that no outside forces affect their motion, then both move noticeably around a single empty point in space. You see this in binary stars, or more rarely in binary planets. Pluto and its moon Charon form such a binary system, and some have argued the earth and moon ought to qualify too.

While it’s been possible to set up that structure in the level editor for months now, there’s been no ability to see them while actually playing the level. Now there is! Below is a snapshot of a binary star system under this function.



The trajectory-line drawing code doesn’t know how far forward to draw the lines in this case yet, and is still figuring it as if the heavier star were stationary, but that’ll clear up in time. You can still see that the secondary star(Naanlil) is orbiting around the barycenter, instead of the primary star(Anlil). The other limitation at present is that it doesn’t have a good way to detect appropriate places to put barycenters or a means to have level objectives refer to them. That is in the cards, though. The systems that allow this will also provide a framework for working with Lagrange points more richly.


About Objectives Again

Last time was talking a lot about the partially finished work with objectives. Now I do have a functional level with those systems, testing objective chaining, duration, and alternate conditions. Take a look!



This also shows the greatly expanded information in the objective display section. That’s subject to plenty of revision, but should remove a lot of guesswork at what you’re supposed to do. In time more visual signposting will be worked into the main rendering itself, but having the written version of the objectives should make it a lot easier to learn what those visuals mean.



Now seems like a decent time to share one of the tools I use to keep track of my plans for ASR. So, below is my high-level to-do list, made with the wonderful Graphviz tool.


Unfilled are things that aren’t implemented at all yet, blue are things I think are probably complete, and light blue are things that are functional but I expect to have to do more work on. Of course this list shouldn’t be seen as set in stone, things may be dropped from it or added to it, but that’s the plan at present.

A final note, I’ve seen a big uptick in spambot activity here getting past my existing filtering. AApologiesin advance if I miss approving a comment in the sea of noise.

ATOMIC SPACE NEWS #16: Puzzling Goals


At its heart Atomic Space Race is a puzzle game. Puzzle games live and die on the puzzles they present, and there must be room for some complexity if the game is to have any staying power. One form of complexity is in giving the players additional tools. While I do have some ideas for that, it’s not a long list. Another major form is in what you’re tasked to do. To date the objectives in a level, or track, in ASR have been relatively simple, always taking the form of getting within a set distance from an object at some point in the level’s set duration. This has been a good start, but I’ve wanted to open up more options there. To that end I’ve rewritten objective logic and handling to that end, with a number of aspects.

The new system allows the designer a choice between the objective being to have your distance above a set value instead of below. This could be used for disallowing approaches too close to an object, or directives to escape an object.

The old system only allowed objectives of the form ‘meet this requirement at least once’, the new one also supports ‘meet this requirement once and then continue to meet it’, which can be used to impose additional requirements on the shape of a course after meeting the objective.

The new system allows objectives to be chained, so you can require they be completed in a certain order. An example use of this is a mission where you need to flyby the moon, then return to the earth. Approximating long multi-stop cargo trips also presents itself as an option. An objective can be valid before or after the objective it is dependent on.

Objectives can have a time limit that they must be completed within, and if they are a link in a chain objective that time limit can be relative to the completion time of the parent objective. Objectives can also have a duration, where their conditions must be met for at least that long before being considered complete. This could for example complexify a round trip objective by requiring you to spend at least one orbit’s worth of time around each destination. Then you need more burns than just a simple flyby.

A related change is that levels will now be run for a stretch of time after their ‘finish line’, definable by the level editor, to allow levels where part of the challenge is to get your course in a state that remains stable without active correction for a ‘cooldown’ period.

The kinks are still getting ironed out on all the possibilities here, but most of the pieces are in place. This has led to some restructuring both in my level editor code, which happens every time I touch it. It’s also seen me move the entirety of the objective handling code from the unity layer, where it was uncomfortably intertwined with the UI code, and into the underlying engine layer with some carefully chosen parts exposed to that UI.

I’d previously wanted to keep the engine layer as gameplay-agnostic as possible, but I’ve come to the conclusion that most gameplay needs tighter coupling with the simulation than is healthy for other parts of the program to have. As I intend to have a unity-free, ‘headless’ version of the simulation that can do various gameplay supporting operations(level baking, solution verifying) and some of those need a concept of level logic to properly function. The rewrite and tighter connection to the simulation has also fixed some issues with the old system not always detecting objective passage if the player ship was moving sufficiently fast, while still performing plenty acceptably.

With luck next time I’ll have some levels that take advantage of this new system to show off! I’ll likely implement delta-V caps(aka fuel limits) for levels as well to put a bit more pressure on level solutions, at least on a trial basis.

Ludum Dare

A quick followup on the game jam mentioned in last month’s post. Despite some difficulties with my own energy level throughout, I felt I did quite well at stretching my boundaries with the game I made, doing some sprite work for the first time and approaching the structure of the code in a different way than I typically would. The game I made in many ways mimicked the economic model of Supreme Commander, and I was very satisfied with how much of that model I was able to put together in the time available. The game fell down somewhat on presentation, not adapting well to varied resolutions nor explaining it’s mechanics well. I’ve found that people who are already familiar with Supreme Commander have a better chance of getting hooked to some degree. As always with Ludum Dare, an imperfect game, but a great learning experience.

The game, made from start to finish in a 48 hour period, is available for anyone to play at this link.

Tester signups

Lastly, I want to thank everyone who has filled out the tester sign-up lately. I’m holding off on the next wave of testers until I get the next major UI change in place so that I’ll have some fresh eyes and hands as well as people who’ve learned how the game plays already. However if you want to hang out and chat with myself or other interested people on the public portion of the discord server, this invite link will take you there.

ATOMIC SPACE NEWS #15: Dots ‘n Disks

Previously all objects were drawn as simple dots no matter the zoom level. For the largest parts of most courses this is quite sufficient, but when you get to the interesting bits near planets it can become important to see where the space ends and the ground or sky begins. At present there is still no collision with the ground, but object size is now stored and, if viewed closely enough to visible, displayed. I’ve found it provides a nice reference point for scale when you get close to things and the curve of large orbits falls away.

Here’s some looks at familiar locations in the solar system.

Beyond that, I’ve been able to refine some aspects of UI responsiveness and resilience based on tester feedback, as well as iron out kinks in my build preparing scripts. Nothing very exciting, but the game plays a little better as a result now. Reminder, if you’re interested in testing you can still fill out the form.

Finally, this weekend I’ll be participating in the 42nd Ludum Dare, a 48 hour game jam. It starts at 5pm central time(GMT-5), about 4 hours from time of writing. In the past I’ve found it to be a very valuable exercise. I will be attempting to stream my efforts with it via my twitch channel, and if that for whatever reason proves impractical I will be updating through my twitter, if you are interested in following my progress. When it’s done I’ll edit this section as is appropriate.

ATOMIC SPACE NEWS #14: Testers Welcome

It is common advice to test your game as early as possible and keep testing it constantly throughout development, with as many fresh eyes as possible. I’m sure it’s very good advice, but it’s hard to follow when starting from zero in terms of following and budget, especially the fresh eyes part. I’ve gotten a few friends to test earlier versions of Atomic Space Race some time ago, but it’s time to cast that net again. If you want to be involved I’ve set up a signup form here. I’d prefer to coordinate tests by means of a Discord server, but if that doesn’t work for some interested potential testers I’m open to other ideas, and the form has a place to suggest. The comments section here works for suggestions and discussion too.

Currently I’m building versions for Mac OSX and Linux as well as windows, but don’t have enviroments to test them myself.

One of the challenges with testing is drawing the line on when enough has been implemented to push it out the door. There’s always one more thing you want to do before it’s ready, especially when there are large parts unfinished.

Many things have been advanced a little, but only a few item have come to fruition since the last posting. One is a basic options menu, presently just a color option and some volume controls. The other is sound and music for those options to control. Sound design and music production are areas I have no expertise in, but there’s some good resources out there. In particular I’d like to highlight Gravity Sound who has produced several tracks I’m using in the current build, and has plenty of other good work I’m not using.

Another challenge is minimizing the amount of repeated work every time you need to release a version. I’ve got a build-and-package script from when I made the Atomic Space Tools builds, but that was at least one computer and several adjustments of the file structure ago. My ideas about proper package structuring and naming conventions have also evolved, so I’m revising all that before getting myself locked into anything.

Lastly I’ve moved the project from Unity 5.x to Unity 2017. Constantly moving up versions isn’t a great idea for an ongoing project, but there’s a few behind the scenes features of newer versions that I’d like to have on hand, and 2017 is the basis for Unity’s current Long-Term Support version that promises to get stability and compatability updates for a while without the major feature changes of the ongoing verison, so I made the decision to make the jump to that rather than Unity 2017. This time at least it was a rather painless update.

Again, if you are interested in participating in testing, check out the signup form. First testers will probably get given links within the next week.

The link to the signup form above might escape a skim due to less visible link colors so I’ve made this entire paragraph another link to it.

ATOMIC SPACE NEWS #13: Like a Record

Back in News #3 and the subsequent video I talked about reference frames. As this update builds on that idea, I’ll recap. It is often useful for course planning to draw the universe as if something that is in motion isn’t. If you draw the solar system from the reference frame of the sun, the course of the moon makes a wobbly spiral around the course of the earth, which isn’t very useful for flying from the earth to the moon. If you draw the solar system from the perspective of the earth, then the moon makes an orderly circle that’s much easier to deal with. The sun also makes a circle around the earth then! And the other planets make weird curly paths.

Incidentally, these kinds of weird shapes are related to the various complicated systems people came up with to explain the motion of the planets in the sky when they thought the earth was motionless. In any case this relatively simple form of reframing the view can be quite useful for many kinds of courses, but there’s another step further beyond that’s useful, the rotating reference frame.

Consider the Lagrange points. To recap them as well: For every sufficiently massive object in a circular orbit around a star or planet these five points of relative stability exist, three along the line between the two bodies, two along the orbit of the smaller body at a 60 degree angle to that line. These locations have been used for space missions both completed and proposed and have influenced the locations of large populations of asteroids, so they’re worth consideration.

If you draw the motion of the earth-moon L-points from the perspective of earth you get circles. If you draw them relative to the moon, you get circles. Neither of these are great for helping you see how your course relates to these points.The solution is to draw the universe as if neither is moving. You create a rotating reference frame where the universe rotates around your primary object once for every orbit the secondary makes. (The implementation for ASR actually just rotates the universe so the secondary is always to the direct right of the primary, but the difference is probably only significant for notably elliptical orbits) This has the following effects:

  • The secondary appears to stay motionless, if it’s orbit is perfectly circular. Otherwise it’ll wobble around a bit.
  • The Lagrange points appear stationary too, plus a little wobble as above.
  • Objects orbiting the primary or secondary will generally have recognizable orbits rather than arcane curls
  • Objects interacting with the Lagrange points will have quite interesting curls!

If you look at diagrams of the Apollo missions where you get a figure-8 like structure with the ship circling around a static earth and moon, this is an example of a rotating reference frame. I have found that planning similar courses in Atomic Space Race is a lot easier with this tool available. Without it need to either rapidly switch between reference frames or do a lot of scrubbing along the timeline to determine you approach your target after tweaking a transfer burn.

The same advantages manifest when dealing with courses that interact with Lagrange points. A great example from outside of the project is this animation of the motion of asteroids influenced by Jupiter’s Lagrange points, produced by Petr Scheirich. If you drew those all those courses in a normal, sol-centric non-rotating frame you’d just have a huge mess of orbits overlapping Jupiter’s, but in the rotating frame you can clearly see the structure emerge.

If you want to see this in motion in-game, particularly with examples of Lagrange-interacting orbits, here’s a video I made of that.

ATOMIC SPACE NEWS #12: Time, mass, and names.

This post goes up close to two weeks behind when it should. Sorry about that. I will try to get the next one out in a little under a month to wind that back. That said, the development since last update has been largely invisible. I’ve mostly been doing more under the hood improvements that pave the way for other features, as well as code cleanup and planning. No pictures this time, but I did bring some words.

Investigating Level Baking

For context, I will give a quick refresher on the architecture of the game; when you start a level the motion of everything in the system is simulated forward as fast as possible and stored in memory. Thus, when the player changes their planned course, the motion of the other objects doesn’t need to be resimulated, only the motion of the ship does. It stands to reason then that the next step is to simulate the system once when the level is created and save the positions to disk rather than memory. This would ease the load on lower end machines and make practical more complex levels than would otherwise be viable.

That opens another can of worms, though. If freed from the need to simulate them at runtime, highly demanding systems such as ones including the sun, Jupiter, and Io for multiple Jupiter years start sounding like things you might want to do. But in the present state, that’s not possible. Holding that much state for Io in memory at once isn’t possible at the resolution needed to keep Io stable.

It would make sense then to simulate it at a high enough resolution to ensure stability, then save out a lower resolution set of points that can be interpolated between. The conceptually hard problem then becomes, for me at least, finding a general way to measure error in this process to ensure the right number of points can be saved. For instance, from a far enough view Io’s motion around the sun looks just like Jupiter’s, but if that’s all that’s saved then we’ve got a big problem. The primary way that I’ve come up with to best deal with this need for context would probably slow the simulation down, but if we’re pre-baking the levels anyway that’s acceptable up to a point.

Picking the right way to do the math on the interpolation should be less difficult, but I want a way to measure any error it introduces to ensure that I’ve done it right, and that leads us right back to the same question again.

These problems are ones I ground my brain against for a while, then put back on the shelf for the time being since it wasn’t getting anywhere and there are some other ones that yield more immediate returns in game-ness.

Tutorials and more abstract levels

Which brings us to the next point, tutorial levels. I’ve some design on how to introduce concepts in their smallest possible steps, which is important for something like this, and I want them at least partially realized before I hand this off to any testers(which hopefully will happen soon.) Getting those from idea to level has needed some expansions to the types of objects and data the level editor can handle.

I thought that would be the hard part, and while it was tedious it turned out that I’d left myself a surprise in the code. Quite a few parts of the simulation, and the game on top of it, had been built with the unexamined assumption that there’d be at least one object present with mass. It’s a fair assumption for any full blown levels that emulate a physical location, but some of the tutorial levels break that rule. I had to go on a small safari through the code base to whack all the moles that one surfaced. Now that works, but I’ve got a good chunk more work to do on replacing the rather bare-bones objective definition and evaluation code to do before the tutorials are really done.

Parts of the capabilities I’m building here will likely also go towards making levels with non-physically-founded features similar to those in some science fiction universes. Because seeing how that would work out is fun.

Ship names

Finally, a somewhat fluffier matter! Back when objects were identified by name, the player’s ship had to be named ship always. Now it’s set up so that in the level editor it can be named anything, and a very low hanging fruit is to rename it from a list of options(later on I mean to let the player pick a name of their own if they’d like, too). I’ve made a short list to pull from of my own, some with personal meaning, some of historical spacecraft, and some with sci-fi meaning.

If you have anything you think would be at home in such a list, feel free to suggest it in the comments! Though keep in mind that in the case of sci-fi sourced names I’d be more inclined to include names that make sense when separated from their source. For instance, Enterprise may make most people think of a particular property first, but it’s been used for real ships many times(and it’s in the list of space shuttle names, so it’s in anyway). ‘Galactica’ on the other hand is pretty married to its property, so it’s not in. But if you think it really belongs, feel free to suggest it anyway!