ATOMIC SPACE NEWS #12: Time, mass, and names.

This post goes up close to two weeks behind when it should. Sorry about that. I will try to get the next one out in a little under a month to wind that back. That said, the development since last update has been largely invisible. I’ve mostly been doing more under the hood improvements that pave the way for other features, as well as code cleanup and planning. No pictures this time, but I did bring some words.

Investigating Level Baking

For context, I will give a quick refresher on the architecture of the game; when you start a level the motion of everything in the system is simulated forward as fast as possible and stored in memory. Thus, when the player changes their planned course, the motion of the other objects doesn’t need to be resimulated, only the motion of the ship does. It stands to reason then that the next step is to simulate the system once when the level is created and save the positions to disk rather than memory. This would ease the load on lower end machines and make practical more complex levels than would otherwise be viable.

That opens another can of worms, though. If freed from the need to simulate them at runtime, highly demanding systems such as ones including the sun, Jupiter, and Io for multiple Jupiter years start sounding like things you might want to do. But in the present state, that’s not possible. Holding that much state for Io in memory at once isn’t possible at the resolution needed to keep Io stable.

It would make sense then to simulate it at a high enough resolution to ensure stability, then save out a lower resolution set of points that can be interpolated between. The conceptually hard problem then becomes, for me at least, finding a general way to measure error in this process to ensure the right number of points can be saved. For instance, from a far enough view Io’s motion around the sun looks just like Jupiter’s, but if that’s all that’s saved then we’ve got a big problem. The primary way that I’ve come up with to best deal with this need for context would probably slow the simulation down, but if we’re pre-baking the levels anyway that’s acceptable up to a point.

Picking the right way to do the math on the interpolation should be less difficult, but I want a way to measure any error it introduces to ensure that I’ve done it right, and that leads us right back to the same question again.

These problems are ones I ground my brain against for a while, then put back on the shelf for the time being since it wasn’t getting anywhere and there are some other ones that yield more immediate returns in game-ness.

Tutorials and more abstract levels

Which brings us to the next point, tutorial levels. I’ve some design on how to introduce concepts in their smallest possible steps, which is important for something like this, and I want them at least partially realized before I hand this off to any testers(which hopefully will happen soon.) Getting those from idea to level has needed some expansions to the types of objects and data the level editor can handle.

I thought that would be the hard part, and while it was tedious it turned out that I’d left myself a surprise in the code. Quite a few parts of the simulation, and the game on top of it, had been built with the unexamined assumption that there’d be at least one object present with mass. It’s a fair assumption for any full blown levels that emulate a physical location, but some of the tutorial levels break that rule. I had to go on a small safari through the code base to whack all the moles that one surfaced. Now that works, but I’ve got a good chunk more work to do on replacing the rather bare-bones objective definition and evaluation code to do before the tutorials are really done.

Parts of the capabilities I’m building here will likely also go towards making levels with non-physically-founded features similar to those in some science fiction universes. Because seeing how that would work out is fun.

Ship names

Finally, a somewhat fluffier matter! Back when objects were identified by name, the player’s ship had to be named ship always. Now it’s set up so that in the level editor it can be named anything, and a very low hanging fruit is to rename it from a list of options(later on I mean to let the player pick a name of their own if they’d like, too). I’ve made a short list to pull from of my own, some with personal meaning, some of historical spacecraft, and some with sci-fi meaning.

If you have anything you think would be at home in such a list, feel free to suggest it in the comments! Though keep in mind that in the case of sci-fi sourced names I’d be more inclined to include names that make sense when separated from their source. For instance, Enterprise may make most people think of a particular property first, but it’s been used for real ships many times(and it’s in the list of space shuttle names, so it’s in anyway). ‘Galactica’ on the other hand is pretty married to its property, so it’s not in. But if you think it really belongs, feel free to suggest it anyway!

2 Responses

  1. “If freed from the need to simulate them at runtime, highly demanding systems such as ones including the sun, Jupiter, and Io for multiple Jupiter years start sounding like things you might want to do. But in the present state, that’s not possible. Holding that much state for Io in memory at once isn’t possible at the resolution needed to keep Io stable.”

    Wait, are you simulating the motions of the planets and moons themselves with the N-body physics simulator?

    Why not just have the large celestial bodies’ motion fixed (on rails) and only apply a high resolution simulation of N-body physics to the spaceship alone?

    I am certain the errors and deviations from reality would be measured in millimeters.

    For the names: why a drop-down list? Why not go simple and just have a text box that the player can type a name into and save it as the name of the spaceship?

    1. “Why not just have the large celestial bodies’ motion fixed (on rails) and only apply a high resolution simulation of N-body physics to the spaceship alone?”

      They’re not on rails yet, but they will be. Having the motion be ‘on rails’ means either pure keplerian motion, like how Kerbal Space Program does it, or be pre-simulated and loaded. Pure kepler would rule out certain types of system, or portray those systems inaccurately. Pre-simulated and loaded is the solution I discuss in the above post, and has always been on the to-do list. I need a simulation to do it anyway, so I’ve focused on just keeping the simulation and gameplay coupled. It’s not the ideal solution, but it does work.

      “Why a drop-down list? Why not go simple and just have a text box that the player can type a name into and save it as the name of the spaceship?”

      I don’t intend to have a dropdown list, but rather just a namelist file that’s randomly loaded from every level-start. This grants some novelty, and doesn’t ask the player to make any decisions before starting a level, which would be a friction point to play. Neither of these is a huge factor, but I think they’re important to consider. If people want to play with their own picked name, the permanent override will be waiting in the options menu.

Leave a Reply