Author Archives: EatThePath

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.