Update!

Long story short, life has it’s ups, downs, and distractions. But while other things come and go, Atomic Space Navy is always on my radar as something I need to do. Most other game projects I start, while they are generally things I’m excited about in their own right, are things I view as exercises that might make ASN better in the long run.

In other words, any other projects I’ve blogged about in the distant past are pretty dead right now, but ASN isn’t. So, what’s happened with it? There’s a number of areas I’ve put time into but haven’t talked about yet. One of these days I may even release a Tools update with some of them.

  • GUI polish: I’ve gone through and reskinned the GUI, and adjusted the layout some to be neater. The default Unity skin looks pretty cheap, largely because it’s so widely used. the new skin is certain to get replaced again in the future, but it’s a nice step forward. I’ve also adjusted some of the drawing logic to be nicer looking.
  • CLI polish: For the console version, the command line interface has been moved over to a more standard library, which makes expansion easier and enforces consistency in the syntax going forward. It will mean a change from the existing syntax, though.
  • Stargen: Something I’ve wanted for a while is to be able to generate random star systems and test them for stability, then just turn it loose on something with a lot of processing power and come back in a few months to find a nifty pile of places to explore. I’ve made inroads to that, though it’s still a work in progress.
  • Testing: I’ve started implementing some automated testing of ASN’s codebase. It’s already shown some results, with missing functionality and quirky bugs popping out of the woodwork and being fixed. There’s a lot more left to test and fix, and it’s a surpisingly fun process.
  • Race Prototype: It’s a long way from something I’d put out to the public, but I have a limited prototype of the Atomic Space Race gameplay that I personally find playable and engaging. Lots of work to be done, but an encouraging step towards a movement interface.

I’m not going to promise more timely updates in the future, but each of those bullet points could have been it’s own blog post when it happened. I’ll be keeping an eye out for such opportunities in the future.

Atomic Space Guts: Talking about how the simulation works

I have created pages for Atomic Space Navy and Tools accessible through the navbar at the top of the blog. It has been suggested that I should talk a little bit about how these programs work, and I will do so while telling you a little bit about how it got to be how it currently is. Atomic Space Navy was an idea that for a long time I couldn’t think of a good way to bring into being. It begin to actually exist when I decided to try an idea that seemed insufficiently clever but turned out to be good enough to start exploring. I will describe in order the goals, the perceived problems, and the solutions as currently implemented.

The design goals are various, but the relevant ones to this conversation are exploration of space warfare on realistic scales in terms of distance, motion, and speed. Most media depictions of space combat are as close to rational predictions as a two man knife fight in a phone booth is to actual modern infantry firefights. Probably a lot further than that, actually. I needed physics that’d handle space at least trillions of meters wide, inhabited by objects as small as a few dozens of meters, moving at speeds of thousands of meters per second or more. Collision detection and actual combat in this environment is something I still haven’t tackled.

More important to the elements I have tackled and thus can talk about in some detail, I want a game where the gravity and motion of the planets forms the terrain rather than taking the typical space game route of constructing unrealistically densely packed spaces filled with dust, rocks and ruins to hid behind and fly around. This poses problems primarily of interface and player experience. The skills people typically need to move around in a game are relatively simple, and related to human experience. In space, that all goes out the window. Everything is in constant motion, and you have to either plan far in advance to get where you want to go, or have ships so powerful that it trivializes the ‘terrain’. The core idea to crack this problem is to allow the player to plan their moves far in advance and have the game show them as quickly as possible what course those moves will put them on.

This predictive plot idea was the core of Atomic Space Navy since its inception, but I was stuck looking for a clever way to make it work. Kerbal Space Program uses a ‘patched conic’ simplification that has seen some use in actual space missions, but I rejected the idea for two reasons. First, it doesn’t allow for certain types of motion that I feel are important to an accurate depiction of a space-based civilization. Second, I had a hard time figuring out how you’d actually implement it. Point two is somewhat less true today, and I may find some use for patched conics as an optimization to give feedback faster, but point one remains true and so they’ll still only be a rough initial pass before other solutions fill in the details.

The solution that seemed too simple but turned out to be what I used is as follows: Every simulation step simply calculate the forces on every object and calculate their new positions based on the simple physical laws. To allow for the planning and predictive plot mechanics, the simulation stores a record of every objects state at each calculated time, and can calculate the forces on an object at a given position and time.

This solution has problems. First off, I’m doing the math in essentially the simplest way possible. I’ve learned or internalized a lot of things that were still fairly greek to me when I started, and there’s a lot still to go. Apparently I’m doing numerical integration with the backwards Euler method, but there’s always the chance that I’m actually doing something a bit different and don’t know it.

A consequence of this approach is that if the time step between saved states is allowed to be too large the simulation starts to become unstable and inaccurate. Lowering the timestep is in some cases sensible, but when dealing with even a small portion of the solar system it can be problematic. Some details to explain why. The vast majority of motion in the solar system is dependent on the gravity of the sun, and most of the rest is owed to the gravity and motion of Jupiter. Any simulation of the solar system essentially needs Jupiter if it’s going to have any pretension towards accuracy. Jupiter’s orbit around the sun takes almost twelve years to complete, and the rate at which you need to calculate an object’s motion to keep reasonable accuracy is roughly related to it’s orbital period. At a rough estimate, I’d say my simulation needs to calculate Jupiter’s position once every 19 days for accuracy.

One of the most interesting and fast moving locations in the solar system is in fact Jupiter’s moon system, in particular the four largest, the Galilean moons. They’re serving as the stage for a lot of my practice with orbital maneuvers. Inner-most of these four moons is Io, which orbits Jupiter every 42 hours. It takes less than two days for Io to complete the same kind of motion that takes our moon a month, or our planet a year. It’s moving fast. To get a good simulation of it’s motion I estimate that my program needs to make a calculation of it’s orbit every 1.4 seconds.

The problem comes from when you have both of these orbits in the same simulation. If you run the simulation fast enough to keep Io in its proper orbit, then you are doing the calculation of Jupiter’s motion roughly a million times more often than you need to, and since I’m storing all the states for reference during player maneuver planning, you’re taking up a million times more memory than needed. This is, obviously, somewhat undesirable.

The solution I hit on is in itself a bit of a mixed bag, in that it doesn’t entirely wipe out the processing load that Io adds to a simulation, but it does avoid the crippling memory overhead it creates. Every object in the simulation determines its own timestep rate, determined by the magnitude of the acceleration it is under. The stored state includes velocity and acceleration at each simulated timestep, and when an object is asked for a position at a timestep it doesn’t have exact data for it can refer to the state at the simulation state immediately proceeding that time and extrapolate what its state should be. This obviously has some inaccuracy, but in testing so far seems to be sufficient.

This required some effort to make advancing the simulation work properly. To be clear on why, I’ll re-summarize what happens when an object simulates a step.

  1. The object asks the ‘universe’ object what the force of gravity is at its location at the start of the simulation step.
  2. The universe asks every object but the one being simulated what their mass is and where they are at the instant in question
  3. The universe sums up all the forces on the location in question and returns a force.
  4. The object computes its acceleration under that force and compares it to the allowable acceleration per simulation step, and adjusts its timestep to fit within the allowed bounds
  5. The object calculates its new velocity based on its acceleration, calculates its new position based on its velocity, saves all that info to a new state and sticks that on its list of states.

The problem is that during the first steps it can only ask the question of objects that already have calculated their data for the domain in which it is asking. The consequence is that unless the time states of two or more objects are in perfect sync the simulation can only have the information it needs to calculate the next state on any one object at a time. The main simulation loop must be built to take this into account, and unfortunately this also means that this is a part of the game that probably can’t be multi-threaded.

And that’s how the gravitational simulation of Atomic Space Navy works in a nutshell. There’s some more to be said about how maneuvering is handled, but that all builds on this.

Atomic Space Tools Version 1 Release

AST v1 Orbit Toy

As noted in the previous post, Orbit Toy and System Builder now come together, as Atomic Space Tools. This makes it a bit easier for me to make improvements to both at the same time, and makes swapping between designing and simulating a system a lot quicker.

AST v1 - System Builder

Besides the integration there haven’t been any huge new features, but there are a lot of usability and in some cases accuracy changes. Perhaps most notable is that before ‘phase angle'(true anomaly) in System Builder was incorrectly saved and loaded. That is now fixed.

I’ve also thrown in a few more exoplanet systems and a close but not quite completely accurate rendition of the solar system from the game

Read More to find downloads and changelog
Continue reading

Atomic Space Navy: On Names and Updates.

For a while now the ASN project has had three major planned phases. Atomic Space Navy itself, the full war-game in all its glory, sold as a for real PC game. Before ASN can come to fruition, there will be Atomic Space Race, an orbit puzzle game about trying to maneuver your spacecraft to achieve certain objectives under certain constraints. ASR is most likely to be treated as a free portal game, serving to teach me things about both orbital maneuvers and the interface required for them, and to generate some interest in ASN. And before ASR, there is the stage I’m in now, working on tools and data structures and making these things available for free to people who will get use out of them. I’ve struggled for a while with what to call these things. In retrospect it seems obvious, but both Orbit Toy and System Builder will in the future be part of the Atomic Space Tools package. The individual tools will still have their descriptive names of course, but since they are fairly intertwined it makes sense to me to update and release them together. Saves work in a lot of places.

So that’s names, here’s updates. Orbit Toy and System Builder have a lot of issues, and many of them I’m aware of and have either already fixed or am planning on fixing before the next release. Let me list a few.

  • Both of them have their cameras below the solar system instead of above, so they appear mirrored from how they should look
  • Orbit Toy’s primitive line rendering makes it impossible to see detail in many situations
  • The ‘orbital phase’ parameter is mishandled by System Builder

There are a lot more display and interface things I can do to make the tools more usable too, but I’ll keep those under my hat for now as I’m not yet fully decided on which ones will get into the next round of changes and which won’t.

System Builder released

SystemBuilder0017
System Builder is now available. Another step down the path towards Atomic Space Navy, System Builder lets you easily define star systems and save them for later viewing or use with Orbit Toy.

System Builder is not a simulation. Systems created with it are not gaurenteed to be stable when loaded into Orbit Toy.

The following star systems are included with the download

  • Sol, including all recognized planets and dwarf planets, with several of their moons.
  • 55 Cnc
  • HD 10180
  • Kepler-11
  • Kepler-20
  • Kepler-62

Extrasolar planet data was taken from http://exoplanets.org/. Systems were chosen that have five or more planets and enough data to make for interesting orbits.

Download links:

If you find any problems with the program, or produce any interesting star systems, please let me know!

System Builder, the Orbit Toy level editor.

Around Christmas I released Orbit Toy, and while it achieved it’s goals it does have a problem. Simulating the solar system is all well and good, but Orbit Toy(and by extension Atomic Space Navy) is meant for fictional science as well as reality. Building a fictional star system of Orbit Toy is possible, I’ve done it, but it takes a lot of math and hand editing of text files. The time between putting new values into a file and seeing results is also long enough to make trial and error pretty rough.

Luckily there exist ways to describe the shape of an orbit that are quite convenient. This past week I’ve been working on a sort of level editor for Orbit Toy called System Builder. System Builder allows you to edit a star system in a graphical interface, seeing orbits change shape immediately, and then save the results in a format that Orbit Toy can read.

Pre-release System Builder

System Builder is not a simulation. If your system is stable its display should be relatively accurate, but it not then all bets are off. If for example you make the earth heavier than the sun, System Builder will still assume that the earth, and all the other planets, will be orbiting the sun despite the fact that when you load that file into Orbit Toy at best everything will orbit the Earth, and more likely everything will be ejected from the solar system. The moon will still be given the right orbital velocity, but even then Orbit Toy’s simulation is unlikely to be able to handle an orbit that tight and fast.

Future versions of Orbit Toy will at least come packaged with a copy of System Builder, and may actually incorporate it directly into the program.

The initial version of System Builder will be available soon. The default system it comes with will include all the planets(you get Pluto as a bonus, and possibly the other four recognized dwarf planets too) and several of the major moons of the solar system. If anyone makes interesting systems and sends them to me, they may be included in future releases.