next »

[EatThePath]

What it is:

Atomic Space Race is a game about flying a space ship through simulated solar systems and meeting mission objectives. The focus is on making realistic physics, distances, and time scales manageable and fun. Currently the game has a playable single mission prototype in which gameplay and user interface are being iterated. The gameplay is a thing of planning rather than action, the player plans out maneuvers and sees their consequences simulated out, then refines until they are satisfied with the result. Development at the moment is focused on a level editor in service of taking it from the single level prototype to a multi-level alpha, with some hopefully healthy codebase refreshes along the way.

How it works:

The game is made in Unity, with a full n-body gravitational simulation running on relatively simple numerical integration allowing for variable timestep. No patched conics approximation here. While it's true that this sort of system scales up poorly to higher object counts, within the sorts of systems the game calls for simulation speeds are comfortably fast for giving players good feedback on their moves.

Why?

For a long time I've wanted to see a realistic depiction of space warfare in game form, if only to prove wrong people who have said it's impossible to do in a fun or engaging way. Atomic Space Race is a stepping stone towards that ambition, but one I believe can be a fun niche game in its own right. This is not a project I expect to be highly profitable, but one I want to see made a reality for it's own sake, and intend to see through to the end.

Tell me more!
I plan to, that's the point of a devblog thread right? But I have posted some stuff elsewhere already.

• 
  
  
• Project website with monthly blog posts

[EatThePath]

After much hacking I got a version of binary objects in to the editor. The math is definitely wrong on the details, but I can refine that now that I've got the mechanics down. There'll be a bit more work needed too for getting binary plants working instead of just binary stars, but that's just gruntwork at this point.

Also I need to figure out a good way to do gifs in places that don't have a system for embedding gfycats, I guess.

[EatThePath]

After some research I discovered that my definitely wrong math on how semi-major axis is split between binary pairs based on their relative masses is actually right. So that's cool. Here's hoping my guesses on how the math works for calculating their velocities turns out right too, but I need to actually teach the new editor and the existing simulation module a way to talk to each other first before finding out for sure.

Saving and loading binary stars gave be a spot of trouble, but is now working. The automatic serialization available in C# has some not surprising trouble with the interconnected object references involved, requiring me to add a bit more extra data to the objects and some post-deserialization code to reconnect broken references. That kind of thing makes me nervous, as it's the kind of code I expect to look back on in a year and wonder at my own bone-headedness, but it works at the moment and that's what I really need.

Pictured below, a binary star system in the track editor.

[EatThePath]

Stepped away from the editor for a bit to add something to the race prototype: a visualization for the objectives. Objectives are next on the chopping block for the editor, so it'd help to be able to see them!

In this(cropped) screen cap I've massively increased the size of the Io objective to test rendering at different sizes, which incidentally means it also shows off the color coding on completion. I tried to pick colors that would work for most forms of colorblindness.


Making the lines look good at any scaling is tricky enough, making them look good at all scalings is going to be an ongoing challenge. Lines are scaled to a fixed number of display pixels in width, which is done to handle the massive width of scales encompassed in the game, but for a line like this it causes visual weirdness as the ratio of circle radius to line width changes dramatically. I think I'm either going to have to have the tiling of the line change at certain breakpoints to avoid the smooshing visible there, or let line width vary a little with zoom for objectives, or possibly both. Changing the tiling is concerning to me because I don't think I'll like how it looks when it crosses the thresholds, but I could be wrong.

Certain aspects of the unity line render I'm using to draw these that I didn't understand made setting this up more of a headache than I expected. Specifically, setting the tiling of the texture lengthwise along the line is done with respect to worldspace length, rather than being number of times the texture should repeat along the whole line. On the other hand, tiling the other way, widthwise, is done with respect to the total width of the line. So, a length 20 line set to a texture scale of 2,2 will tile 10 times lengthwise, and only twice widthwise. I didn't stumble across any documentation explaining this, and it took a bit of time to do the right test that illuminated things. Made for some frustration, but now it works! Unfortunately the fact that it works this way does mean that if I ever want to use marks on a line texture to indicate the speed or general motion of an object rather than having them being solid lines I'll probably have to write my own line building script instead of using unity's, since I'll need to have the scale be variable from point to point. But that's a battle for another day!

[EatThePath]

Monday I put up my monthly blog post summarizing the progress I made in october. Mostly things I've already posted about here. At the end of it I mentioned that I was very close to a major milestone, that being creating fully functional test levels in the editor and loading them into a playable state. To date the gameplay testing has all been on levels hard coded into the script files. That objective has since been reached, and I've been able to build an entirely new level in a matter of minutes! So that bodes well. I'm doing some polishing and bughunting now, as a few issues have developed from issues to problems along the way.

A good chunk of today has been devoted to smoothing out the line rendering. Previously, an object's trajectory was drawn by simply getting a start and end time(ideally equal to one orbit in the simplest cases, in other cases... that's a whole other rabbit hole I need to go back down at least once more), 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.



The other problem is that a maneuvering object, like the player's ship, may have even more variable needs for it's point distribution.

Right now I'm trying a system that makes a very rough line using a varation of the old system, then refines that line until all the angles in it are relatively smooth.



There are a few corner cases to this approach that I need to iron out, but outside of those it's definitely producing better results than the old approach.