Author Archives: EatThePath

ATOMIC SPACE NEWS #23: Odds and ends

The math efforts mentioned last time are still ticking along, but keeping my own passion for the project fired doesn’t fit well with letting it languish completely until I crack that nut. Consequently I’ve gotten a number of important but sometimes low-visibility things done since last post.

Possibly the oldest part of the racing UI at this stage was this element that showed some properties about the relationship between the player’s ship and a given object. Relative speed, distance, heading information and the lot. It’s been of little use and partially broken for quite  a while now, and I’ve finally replaced it with something more useful.

The old panel

The old panel originally required you to type in the name of the object you wanted information on, and for a while has simply been fixed to the largest object in the system. The new data panel makes use of the recently implemented improved system tree querying to detect what object currently dominates your motion(in other words, whatever you are orbiting or flying by) and use that as its default, with buttons in the system summary to override. The panel also shows directions you’ll probably need to know if you are hand-editing common orders, and shows some basic orbital information.

The new panel

Working on this has also led to tightening up some of the panel layout and text rendering settings generally, visible in a full screenshot. There’s still plenty of room for improvement here, especially for higher resolution displays, but every step is useful.

the UI as it stands

Under the hood a number of edge cases with objective evaluation have been cleaned up. Due to the nature of the objectives the timeline as a whole needs to be examined to validate the objective state, which can take up some runtime. This process is given a lower priority than simulating motion, so when there’s a course change the objectives aren’t rechecked until the ship’s path is fully simulated again. This has meant that if you meet the objectives and them make a course change the level could now be failed, but the objectives won’t notice for potentially several seconds. This is undesirable for several reasons, so now the objectives are given a single evaluation cycle at the end of every simulation frame, so they can always notice and react to course changes. A single check is low enough impact that it’s not a significant cost.

At the same time objective evaluation has now been made aware of how much of the timeline has been checked, and will report a preliminary state immediately but the level will not be considered passed until that coverage is complete. 

With that done, and a few other legacy bad decisions cleaned up along the way, victory detection is now in a much better place than it was. I next turned my attention to level selection, score saving and save loading. The level select screen isn’t pretty yet, but shows most of the information I want it to now.

Behold the most efficient use of screen space ever devised.

When you complete a level’s objectives it scores your solution on three categories, speed, simplicity, and efficiency. If it beats your existing score in that category the solution is saved, and you can load it later at any time. There’s currently a single save slot that you can use to keep one other solution. The level select screen now shows a basic summary of the level’s contents, and of your score or any saved solutions. In the future this should also show you information about the general playerbase’s solutions so you can compare.

Finally, all the tunable values of the bloom settings are now exposed to the user as profile options, as well as an option to scale line width. This should let people who find my preferred bloom settings either overdone or insufficient to find their own comfort zone. 

Top and bottom: Crazy settings
Center: Default settings


This month the time I’ve been able to put to the project has gone towards beefing up my math skills. My own higher math education is somewhat lacking, and up till now I’ve been able to muddle through, but there are limits. I’ve been running up against problems where I lack the ability to even ask the right questions, let alone understand the answers. Luckily there are helpful people to point me in the right direction and some amazing education resources out there, so this is a speed bump, not a roadblock. So far this seems to be going well, but is not yielding much to talk about or show in the blog. Regardless, the project yet lives.

ATOMIC SPACE NEWS #21 Tidying up

Several aspects of the full game, such as level baking or score verification, require the ability to run a command-line no-graphics version of it, and ideally be able to do it on a Linux system to boot. Doing so requires a careful separation of Unity-specific code from the simulation-specific code, and in part because of my lack of knowledge when starting out.

Over time I’ve been working to make the barriers between the two parts of the program more solid, but the lines still blur in places. When redoing the objectives logic the last time some unity references dripped down into the level file format that shouldn’t have, and repairing that misstep has been the primary work this month.

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.