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.

Leave a Reply