ATOMIC SPACE NEWS #8: Goodbye prototype, hello Alpha

As of Monday I now feel comfortable dropping the ‘prototype’ label from Atomic Space Race and moving it into ‘alpha’ status. Since the various development stages have fairly fuzzy meanings in the gaming world these days, I think I should outline what exactly I mean by them. 
  • Prototype: A program that tests or demonstrates an isolated example case of the game concept. A complex game might have prototypes for different sections of it, and these prototypes may not run outside a development environment or otherwise be highly inaccessible, but they serve to determine if the idea has any chance of working or not before building all the more complex trappings of a game around them
  • Alpha: At this stage the project is playable as a game and gives a good indication of how the final game will play. There may be large gaps, and indeed every individual system may need significant work, but you should be able to test the entire flow of the game at this stage and have a viable experience despite the gaps.
  • Beta: All the gaps are filled in now. Improvements are still possible or needed throughout the game, and some chunks of content may still need finishing, but all the systems should be present and approaching complete. Testing at this stage can hopefully focus on finding out what parts of the game need more improvements than you thought.
The movement to alpha for ASR is marked by the advent of a main menu that stitches all the modes together so that you can move from level to level smoothly. It also comes with score saving and a handful of working levels. The editor, accessible through the same menu, can create fully working levels from scratch, though it’s a bit fragile. I’m starting to get copies of this version out to a select few testers already. 
Of course it’s still alpha, so there’s a long way to go. The GUI is as rough and subject to redesign as ever, there are several known bugs, there are still missing systems. Most glaringly thrust and fuel aren’t capped inside levels, which is going to be a fundamental part of levels. That should be my focus in the near term, in additional to general bugfixing and strengthening of the code’s weakest points. Beyond that, a tutorial message system is on my mind, though building a specific tutorial might better wait for the interface to be more final.
For now, enjoy this playback of a solution for one of the new levels.

ATOMIC SPACE NEWS #7: Smooth testing


At the end of last month’s update I talked about being very close to being able to go from editor to gameplay smoothly. That’s working now, which has led to some fun iteration. Before I’d done months of testing and development on a single level, and now I can whip a new one up in minutes. There’s a lot of bumps and bugs in it that I still have to work out, though. Working so long with a hard-coded level in a fixed unity scene led to code that is not structured well for loading and especially reloading.


One change a long time coming that happened this month is line drawing. Previously, an object’s trajectory was drawn by simply getting a start and end time(ideally equal to one orbit in the simplest cases), then picking N points of time evenly spaced through it and getting the object’s position at those times. The problem is that an object only spends equal times at different parts of an orbit if it’s orbit is perfectly circular, if it’s highly elliptical you could run into cases where one end becomes visibly jagged even with high numbers of overall points.


An example of the old system breaking down.

The new system starts out making a set of points the same way as before, then refines the line further. At each initial point it takes the object’s velocity at that moment and extrapolates out an amount of time matching the time of the next point in the set. If the extrapolated and actual points are far enough apart it asks the simulation for another point at the time-midpoint halfway between the existing ones. I tried a few other smoothing methods, but right now this seems like the most reliable way to handle the particularly curly paths that can arise if you’re looking at the system relative to a moon.


This month I did get to put the game in front of a couple friends and watched them come to grips with it. The state it’s in is rough enough that I wouldn’t want to throw it out to anyone that I can’t be there to guide, and that plus the fact that it was being tested by very good friends does mean that the opinions I got are far from perfectly objective, but I still learned a lot! I’ll list a few of the things I learned.

  • More parts of the racing interface are currently broken than I realized
  • People want the information those parts would provide without much prompting, so I really need to fix them!
  • The better line smoothing is still imperfect and needs more refinement.
  • If you don’t stop them, people will break the speed of light.
  • People really want to orbit the moon even if you don’t ask them to.
  • Orbiting the moon requires you to be a LOT closer than people expect.

It definitely gave me some useful information and ideas on what I should focus on next.


Something I’ve finally gotten around to testing this month is Lagrange points. If you’re unfamiliar, I’ll provide a quick overview of the idea. If you have one object of notable mass, like a planet, orbiting a larger object, like the sun, then in most cases a third object added to the system will not be able to keep a constant distance to both of them. It’s distance to either one or the other, if not both, will be constantly changing. However, at least if the orbit of the planet is relatively close to circular, there are five points where the forces can balance out such that an object can be placed there and keep a constant distance to both bodies. These are the Lagrange points. The first three are on a line with the two main objects, L1 between the two, L2 just outside the lesser object, and L3 on the far side of the larger object from the lesser. L4 and 5 sit on the same orbit as the lesser object, 60 degrees ahead and behind it.

Lagrange points are of some note because they’re commonly thought to be useful to a space-faring civilization, and they’re a feature that does not arise in some popular approximations such as the patched conics used by Kerbal Space Program. They should be something that naturally comes up in the simulation, and it hasn’t been urgent that I verify their presence, but with the editor working it’s become pretty trivial to check L3, 4, and 5, so I did.


In this example I made a Jupiter mass object at 1 AU in a circular orbit of a 1 solar mass object and then threw down a bunch of zero mass objects in the same orbit but offset a number of degrees, and named them according to the amount of offset. The A60 point thus corresponds with the L4 point and can be expected to be stable. The other objects don’t match any Lagrange points, so they shouldn’t be stable.


Then I wound the simulation forward 9 years. It might be a bit hard to see in the jumble, but relative to J the A60 is still in its place, while all the other ones have wandered around significantly. That’s what they’re supposed to do, so huge success!

Those are the high points for the last month. For the coming month, I need to focus on polish, and on organizing my internal documentation. The next post consequently might be a bit thin, but we’ll see! There tends to be more to talk about in these than I expect, so maybe I’ll be surprised.

ATOMIC SPACE NEWS #6: Binaries and other fun things

I was feeling down on my most recent progress until I pulled back up News#5 realized just how much I’ve really done in the last month. Last time, I’d just got saving and loading working. A few things have happened since then.


I’ve gotten most of the way to making objects sharing a mutual center of mass, like binary stars or binary planets, work in the editor. There are a few hiccups in saving out final state vectors for simulation, but the path to solving them seems a clear one to me. I’m not going to go down it until some other things are cleared out, because binary systems aren’t a requirement to hit the next milestone I’m aiming for, but it’s definitely on the to do list later.

Here’s a snapshot of a binary system in the editor. It may not be immediately evident at a glance, but the central ‘Nirgal System’ marker does not represent a physical object, but rather the shared center of mass of the stars Anlil and Naanlil. A different icon for this kind of object might be a good idea. The outline of a dot perhaps, rather than a filled one? The main object dot is probably going to get replaced at some point too, so that can wait till then.

An interesting wrinkle that I didn’t realize would crop up before really getting into the math here is that if you’re designing a binary system, the mass and separation are interconnected such that you can only set one of them independently. What I mean by that is that you can have each star be of a specific mass, then set their total separation from each other, or you can set their individual orbital radii and set the total mass of the system. Then the editor will have to distribute appropriate portions of the set total value based on the independent values. At the moment I’ve only implemented one of these two options, the one with setting the masses of the objects independently.


Getting system loading by the simulation working led surprisingly easily into a very rewarding other feature, one button testing. The editor now has a button that will immediately fire off a simulation of the currently loaded system. Seen below, a quick snippet of simulation of the famous[link]Trappist-1 star system

link to full size video

I’ve not yet got it to where I can immediately jump into a test of race gameplay from the editor, but I’m closing in on that, and it’s my next major target.


The current thing on my plate is getting mission goals from the editor into the simulation. While working on that I decided it’d likely help people if the objectives were drawn visibly. Even with all my playing with my test scene I’ve never been entirely certain how close I need to get, I picked the distance for the objectives relatively at random and simply know from experience that it’s not that hard to hit, but neither is it that easy.

So I did that. Here’s an Io intercept, both from normal reference and from Io reference. No other objectives are completed, so you can see the difference in how they’re drawn.

In the future there may be a few different kinds of objectives. So far four major ones have come to mind.

  • Get within distance X at least once
  • Get beyond distance X at least once
  • Never get within distance X
  • Never get beyond distance X

Maybe there are more, but those are the obvious ones so far. None of them should be that hard to represent in code, either.

That’s most of the month’s progress. Maybe next time I’ll have hit that milestone of going from editor to full playable level. Getting very close!

Atomic Space News #5: Building a better builder

Last month I said I’d be working towards having multiple levels. That’s led me down a bit of a rabbit hole. To have multiple levels I need a better level file format. That format is going to need to contain various kinds of objects, whereas the existing format only knows how to handle one type of thing. That leads to the fact that the level editor itself needs to be more flexible, and while I’m at it there’s real star system arrangements that the editor can’t support that I want it to. Also it’d make setting up systems based on real data much easier if I could enter in values like distance or mass in various units instead of a single option, so if I’m hacking on the editor I might as well try to do that at the same time.

Some might call this scope creep, and they might be right, but this is all stuff I need to do eventually and they go well together.

Working back up from the bottom of the rabbit hole to the top, the new editor has option selections for each appropriate line to let you choose what unit you want to view/edit them in.

The option list is flexible, I could add or remove some without much effort(though it’d cause some layout headaches, those are solvable). A few familiar units like miles or tonnes might be useful to put in.

I streamlined text entry while I was at it. In the old system you’d put in values, then have to hit a button before they were pushed into the actual data and you could see the results. Now they update as you type. There are surprisingly many moving parts involved in that! The old system does have some small benefits in being able to back out of bad ideas without commiting them, but I’ve some ideas on how I could potentially implement undo, and I think the faster feedback will be a worthwhile trade-off.

The other big change from the existing system editor interface is less visible, which is that the values to edit are not hard coded into the GUI, instead the object being edited tells the GUI manager what values it has to be edited and what kind of values they are, meaning that as I add new object types they can slot in there with minimal extra work and hopefully no special cases. This is a big win for me that’ll hopefully save some time going forward, and bits of it my be re-usable elsewhere.

Back up the rabbit hole another step is saving. Up until now all my saving and loading has been through creating or parsing comma separated value files, essentially a spreadsheet of values with a line for each object and an expected format. Strictly speaking I could extend this to plenty of new objects, but doing so is labor intensive and failure prone, and the resulting files are somewhat opaque when I’d like them to be at least theoretically hand editable. That brings me to serialization, which is pretty much the automated process for doing just that. C#, which is the language all this is being done in, has some standard serialization features. This is a thing I’d tried to make use of long ago, but I was too novice at certain aspects of programming to make it work. This time around it went relatively smoothly, I did have to more or less turn a portion of my data structure inside out to make it work, but that only took about an hour and seems like it’ll have some good side effects down the road. I can now save and load the editor files to an XML format with minimal amounts of special work to prepare for saving or cleanup after loading. Similar to the GUI stuff this happens without me needing to specifically write (much) code to handle new objects types, which will save time in the future. XML is less than ideal for my goals of human readability/editing, so I may look into alternate options, but it does do the job.

I’m still a few steps away from having a full featured level editor. Most pressingly the new logic can not yet convert from the simplified orbital representation in the editor to the actual raw positions and velocities needed for the levels. That shouldn’t be too hard to cannibalize from the old logic, but it hasn’t been done yet. Editing mission objectives promises to be a bit tricky, and definitely needed. Editing mission meta-data(name, description, and so forth) is similarly needed but probably easier. Also on the immediate to do list is support for binary stars or planets, which now that I’ve done everything else I’ve talked about here should be pretty simple. There are a few other loose ends in the editor GUI, and if I’m really smart I’ll build an automated way to convert the old CSV levels I’ve made to the new format.

That’s all for this month! Plenty of words this time, next time I’ll strive to have more pretty pictures too.

Atomic Space News #4: New demonstration video

This month I got the plotting controls to a point where I could make a relatively smooth video with them, and then made that video. The video is also narrated, which required some expansion of video editing and recording skills. That’ll come in handy down the line. The video is below, and will take the place of the old video on the landing page for the site. It’s meant to serve as a good entry point for the project, explaining what the game is and how it’s played.

The run-up to that video saw some more tweaks to how the view controls behave, which are best seen in the video. Beyond that most of my efforts this month have been towards getting implementing multiple levels. This is a bit tricky, because at present I don’t really have a level file format, and all my file input/output code to date is a bit rough. I need to figure out a lot about what data makes up a level, and how best to structure that. That’s an ongoing process, but once done I think it’ll be a big step towards taking Atomic Space Race out of the prototype phase.

That’s all for this month. See you next month.

Atomic Space News #3: Relative motion plotting

It’s time for another installment of Atomic Space News! Since I only just thought of that heading for these posts, but will be editing it retroactively into the titles of the existing posts, this is both the first and fourth installment, and since I’m a programmer, it’s post #3.

Last time I talked about some things that I was doing or wanted to do that I’ve since done! Invigorating progress.

First off, the change in how headings are displayed is done. Inputs now mimic a compass, though you’re free to do things like enter in -090 degrees instead of 270. Forcing everything to be displayed in the 0-360 range is on my to-do list, but not a high priority item despite the fact that it should be dead easy to do.

Secondly, I’ve added a second smaller marker to every burn to show when the burn ends. Last post I included a shot of an Io encounter. Here’s what it looks like now! All images are clickable links to full size screenshots.

In addition to that I’ve implemented relative display, meaning you can now view the simulation as if a particular object were the center of the universe. This can lead to quite interesting patterns, and is also helpful at in refining a near encounter into a very close encounter. Here’s that same course shown from the perspective of Ganymede. This view is not especially useful, but it is interesting to look at! Note the circular path of Jupiter, mirroring Ganymede’s own orbit around it, just from a different frame of reference.

In fact using the Io relative display I was able to refine this course down from a three burn, 24.5 km/s delta-V course that takes 22 days, I refined it to a two burn, 17 km/s delta-V course that takes just shy of 5 days.

And again from Io’s perspective, which makes it much easier to see that they definitely encounter each other.

In fact this encounter is so close that in real life your spacecraft would be directly encountering not only Io’s atmosphere, but also it’s surface. Not bad for about a minute’s refinement of the course.

Right now my next goal is more PR related than code, but code is happening as a direct result of it. I’d like to make a narrated video of assembling a winning course with the current tools, like the video linked on the front page of this site but with explanations of what’s going on. Without those it’s quite opaque to people that don’t already know what the game is about, and can get rather dry. I’ve taken a few stabs at this already, but each time I do I find some aspect of the interface is slowing me down and drawing the run time out unacceptably long. Some editing down is possible, but I want to keep it to a minimum in large part due to my lack of familiarity with video editing software.

That’s where the coding comes in, as each time I do this I come up with ideas on how to modify the GUI to speed up the process, and then get to work on implementing those. So next time I should have either a lot of small GUI refinements to talk about, or have a nifty video to share. Until then!

Atomic Space News #2: How Atomic Space Race looks right now.

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 the 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.

Atomic Space News #1: Relearning and reworking

The past month of development has been consumed by refamiliarizing myself with a somewhat stale codebase, trying to refresh it a bit without breaking anything, and doing some expansion of the interface for playability. Today lets talk about the technical side. This is going to get a bit down into the nitty gritty of how the engine works, but what else is a dev diary for?

In order to let you plan out your future course, the game stores the current *and future* positions of all objects for the duration of the gameplay period. The game takes the initial state of the system as defined in the level file, does some math to approximate the proper positions of all the objects a certain distance in the future, and saves both the initial and ending positions, velocities, and accelerations. And then does it again using the new end points as the new end states.

Now, exact equations for the motion due to gravity of more than two objects doesn’t exist, save for some limited cases for three objects. As a result what I’m using is an approximation. A pretty crude one in fact, as I am neither a physicist nor a mathematician. The upshot is that there is unavoidably a degree of error in the calculations. You can improve accuracy by making sure the change between each state is as small as possible, which means less time between each step. There is thus a natural tradeoff between the speed and accuracy of the simulation.

For these reasons the simulation has an adaptive timestep. Objects in more extreme conditions, such as Jupiter’s moon Io, require more accuracy or they’ll be shot off into space quickly. Io in fact requires a simulation step a bit faster than once every ten seconds to keep acceptably accurate. Other objects, like Jupiter itself, might demand a step every few weeks or months. Because storing states for a long play duration has noticeable memory considerations the entire simulation doesn’t run at the rate of the most demanding object in it, instead each object is updated on it’s own clock as needed. This results in thousands of Io states being stored for every Jupiter state that is calculated.

What’s changed this month is how the required timestep for each object is determined. Before, each object would remember what the last step size it used was and start with that, then if the amount its velocity changed in a step was too big or small it would discard that step, adjust the step size, and try again.

This worked well until player-planned maneuvers came into the picture. When a player inserts or removes an order from a ship’s timeline the ship has to discard all it’s states following that order and recalculate them. If these orders are high thrust they can also affect the required size of the timestep for that object. On top of that, objects do not store what the timestep they were attempting to use was at a given past state, they only know what the last timestep they calculated was. That bit of ill-advised state combined with loose bounds on what defined an acceptable step meant that if you added an order to a ship and then removed it, the states following the time of the order after it’s removal might not exactly match the states that existed before it was placed at all. This has the potential for unintended and hard to resolve inconsistencies, and could have become a real problem.

Now instead of having the old recursive search for an acceptable timestep with all it’s extra state I have a targeted change in velocity per step, and the timestep duration is determined exactly based on that. The presence of orders can necessarily impact the step size. If there are orders for an object, it will first check and see if there are any within it’s desired timestep after the initial calculation. If not, it proceeds as normal. If there are, and the desired step size is larger than the minimum step that is allowed, it’ll cut the step short so that the next step starts at the exact time of the next order. If the order is inside the window defined by the minimum step size then the acceleration from the burn is added to the acceleration from gravity to determine the desired timestep size. If the burn is longer than the desired step size it will be divided up into multiple segments so and the process repeats until the burn is complete. When an order is removed from the list that object’s states past the step preceding the order are removed from it and everything is recalculated as if it was never there, avoiding any inexplicable footprint on the simulation.

Thanks for reading. Next time will likely go into the current state of the GUI and how the race prototype currently plays, and where it’s going from there. For now, I’ll leave you with a screenshot of an Io encounter being arranged. Click to see the full size version.


Atomic Space News #0: Introductions

Welcome to the Atomic Space Blog! Atomic Space Navy and the surrounding projects are something I’ve been working on, on and off, for quite a while, and while I’ve posted some about them elsewhere in the past I’ve decided to give the project a new home all its own. I still need to set up some more pages, maybe start a gallery with some development screenshots and that kind of thing, but as I’m squeezing this project into my spare time those are competing with actual development for a rather limited resource, so they’ll trickle in. For now, I’d like to give some background on the project, where I want it to go, and where it stands now.

I am a science fiction fan, if you couldn’t guess already. Star Wars and Star Trek were twin pillars of my childhood. Science fiction comes in many forms, smart and dumb, hard and soft, good and bad, and I don’t think any of those qualities are mutually exclusive with any of the others. When I got online I started joining discussions that would eventually make me realize just how unrealistic the things seen on screen in any movie, show, or game are, particularly when combat comes into play. While obviously we’ve not had a real space war to see how things would really happen, and hypothetical technologies in many settings would throw a wrench into the works, we can still make educated guesses and through them reach a spectrum of possible battle-spaces that look nothing like what we see on screens. Books will sometimes live in this harder sci-fi realm, but almost universally if it involves a visual medium, be it movie, television, or video game what we see is a relative of the WW2-In-Space style that can be seen in classic Star Wars.

To those not familiar, the hallmarks of realistic sci-fi combat, at least as I know it, are as follows: 

  • Most of the time you will be fighting people so far away you can’t make them out with the naked eye as more than a point of light. 
  • You will be traveling so fast that you’ll only be in range of your enemies for moments at a time, or you’ll be exchanging long range fire that takes minutes or hours to reach them and has only the slightest chance of hitting. 
  • With the speeds involved, once there is one pass with the enemy it will take minutes or hours to turn around and arrange another pass. 
  • The weapons will be so deadly that in many cases a single hit will demolish a ship.
  • Everything is constantly in motion, coming to a stop is a meaningless concept. 
  • In many cases the enemy will be far enough away for light-speed lag to play a significant role in the evolution in combat. The speed of light may even be a primary factor in limiting weapon ranges.

Over the years I’ve seen the unreality of sci-fi combat discussed countless times, and in most cases someone will say that of course this is the case, because realistic space combat would be terribly boring. All you’d see is at most a few points of light in the distance moving across a star-field and the occasional distant flash. And perhaps in most cases they’re right. I by no means begrudge those that decide to go the traditional route, I love many things that do it and do it well. But the idea that a realistic space war is impossible to make interesting seems narrow-minded to me. Two main things have strengthened my conviction that a compelling space-war game is possible and inspired me to try to prove wrong the idea that it isn’t. 

First would be Introversion Software’s game Defcon, a wargame about an unwinnable global thermonuclear war that’s over in a day. Defcon does not render the world in a detailed fashion, instead it shows you an abstract war-room map filled with cold glowing icons. It doesn’t pretend to be real-time, it lets you vary time to make the slow boring parts of the war play out quickly and then slow down for the things that need detailed consideration and management.

Second would be the Lost Fleet novels by Jack Campbell. Large sections of these books are taken up by an admiral trying to plot out his battle plans to get the best possible outcomes in a setting that, while not perfectly hard, has many of the same properties as realistic combat would. Much of the drama comes from trying to out-think the enemy and the tension of seeing his plans succeed or fail, but the author still manages to squeeze in opportunities for human virtues or failings to factor into the outcomes of the battles, and each battle is a unique story rather than a dull statistical equation.

What I want to make, then, is a game about planning your motions on a solar-system scale canvas. The motions of the planets and their gravity wells are your terrain, and nothing is static. Your battles play out over weeks, months, or perhaps even years in some cases, but can be planned and played in a single sitting. The combat is modeled just enough to have depth, but abstract enough to let you be the admiral of a fleet rather than the captain of every ship. 

You might say that’s a tall order, and I wouldn’t disagree. It’s asking a lot of me to develop and also a lot of the player. Beyond the audience of a few niche games and an even more niche field of scientists, planning orbital maneuvers is quite alien. I consider setting up a working simulation of orbital motion, making a good interface for planning, and teaching the player to use it to be the biggest hurdles ahead of me. Luckily the first of those proved easier than expected, but the importance of the remaining two led me to split the project into two stages. 

Atomic Space Navy was the original ambition, the ultimate goal, and the game I’ve been describing so far. But it carries with it the additional burden of needing to be a good wargame, which isn’t a trivial thing to begin with. Thus was born Atomic Space Race. ASR is a pure orbital mechanics puzzle game. The player will be given a starting state, a list of conditions they need to fulfill, and a set of resources to fill them with. ASR is a pure crucible for refining the orbital mechanics interfaces and underlying simulation, and it’s what development currently focuses on. There is a prototype that is, while rough, strictly speaking playable and winnable. You have a ship, with currently unlimited possible acceleration and fuel, flying through the moon system of Jupiter, and you’re challenged to arrange flybys with each of the four classic Galilean moons inside an 8 week period.

I’ve found it much easier than expected to plot out a winning course in this prototype, given the primitive tools so far given to the player. The simulation is responsive enough to make trial and error effective for refining your course. The following video shows me implementing a winning course that I’d found on previous plays, with some intentional missteps for demonstration.

It should also be said that for the sake of simplifying a still quite complex problem, the game is planned to be entirely 2D. While mean it is quite unrealistic in it’s own ways, the project is still ambitious I consider it an acceptable sacrifice. In the games I have played involving orbital mechanics, dealing with orbital plane changes is a headache I have little interest in reproducing. If ASN is some day sufficiently successful, a 3D version is a natural next step.

So that’s where the project is now, with a playable prototype in development. As I said earlier in this post, this is a part time project for me currently. It is quite important to me, but it is not the only demand on my time. My goal is to not go more than a month without a new post of some substance on this blog, be it discussion of some aspect of the project’s current state, future goals, or recent development. If you want to know more about something, feel free to comment.