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.


So where’s that game? Here’s that game.

Game prototype really. It’s still rough enough that I’m not putting a playable version up.

The weekend game jam didn’t really achieve the goal of kicking my ass into gear, but the problems this game poses are important enough for me to solve that I wasn’t going to leave it by the wayside. I’m still hacking at it.

The game is a simple Real Time Strategy game, the working title of which was Really Tiny Strategy, but I’m now calling it Whitespace. Working with colored shapes in a white void is a visual that I like.

The RTS is a relatively complicated game to make compared to the simple shooters I’ve put together in the past. Lots of layered complex behaviors. My goals for this project are in order:

  • Basic usable RTS user interface
  • Functional enemy AI
  • Multiplayer
  • Android deployment

At present the first two are working, though both could be refined a lot. My immediate tasks are code cleanup and core functionality fixing, as well as doing some visual design for the UI. My end goal is to have something I can put on my phone and proudly show to people if they ask me about this whole game development thing. Lots of work left ahead of me, but I didn’t want to leave the blog silent any longer.

1GAM, Jams, and me.

So I’ve been pretty bad at One Game A Month(1GAM). When I have had the focus and desire to work on game dev I’ve focused on Atomic Space Navy. I don’t really regret that, because ASN is important to me, but I still believe in the benefits of getting games done and out the door, and I think that ASN would be better for me having that experience.

Game jams are a pretty good way to get things done, with pressure and community. There are a few going on this weekend. For one reason or another, none of them really are clicking with me as something I want to participate in, but I still want to jam in general. So I will. Tonight after dinner I’ll mark the start of my own private challenge, 72 hours to get a new game playable and show-able. I’ll chronicle the progress on twitter @EatThePath and post the game and info about it here afterwards.

I’ve already got some ideas on what I want to achieve, and it should be fun!

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

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.

Bathtime: Breakout Bats and Unity Physics

Alright, since I need to blog more about development, AND talking to someone about my problems often helps me solve it, this will be the first of potentially many posts where I stream-of-consciousness about a problem until I run solve it or run out of steam. I’ll think of a clever title later.

Right now I’m making a breakout clone, titled Breakthrough until I think of something more original. To avoid programming the physics from scratch, I’m using Unity physics, which isn’t 100% intuitive to me.

Objects using the physics engine to control their motion require a collider and a ‘rigidbody’ component, both of which have several configurable settings. The ball has both of these components, and that’s simple. On a basic level, it just goes.

Blocks have no rigidbody but do have a collider. This means they get collision messages and the ball bounces off them, but they don’t move. That’s good.

The bat is were life gets tricky, since it’s motion is not dictated by the physics engine but by player input, but it has to interact with things that are solely controlled by the physics. So far, I’ve found a few options for dealing with this, some of which work. You can slap on a rigidbody and have player input apply forces to the object. That works, but has a problem, in that the ball bouncing off the bat pushes the bat down.

EUREKA: An idea I haven’t tried is having the bat rebound after it gets hit. This seems like it’d look cool and fix the problems. Not trivial to implement, so I’ll keep going and try it after finishing this post.

I’ve tried to solve this problem two ways. First is to turn on the rigidbody flags that restrict motion in particular directions. This turns out to be a terrible idea, because it apparently makes conservation of momentum break down and makes the ball stop moving.

EUREKA 2: I need to set up a minimum speed for the ball in addition to a max speed to keep unforseen physics quirks from tanking gameplay. Also enforce a minimum amount of the vector being vertical motion to keep from getting stuck in flat trajectories.

The second solution is to jack up the bat’s mass so that the vertical motion imparted upon it is utterly undetectable. That works, but it means you are hitting the ball, massing 1 kilogram, with a bat massing 1 million metric tons. Understandably this transfers a lot of momentum into the ball, making it hit my speed cap pretty hard. Not exactly ideal.

Alternately, I can tag the rigidbody as kinematic and directly manipulate its position. This works, but it feels like some of the bounces of the ball off the moving bat are wrong. This doesn’t particularly surprise me, but I’m not sure if it’s just perception or not. I’m also not sure what to do about it.

If the ball bounces off the immobile blocks when they don’t have rigidbodies, can I just pull the rigidbody off the bat? I haven’t tried that, but it seems as though it’d sacrifice some of the advantage of using the physics engine, namely the ability to impart sideways motion by hitting moving the bat as the ball hits it. This may not be any better or worse than a kinematic rigidbody. I’ll try it.

Turns out that seems to be the best solution. No sudden hyperballs, the bounces all seem right, and I feel like I have more control over where the ball goes than I did before. I guess the moral of the story is once again KISS.