This month the time I’ve been able to put to the project has gone towards beefing up my math skills. My own higher math education is somewhat lacking, and up till now I’ve been able to muddle through, but there are limits. I’ve been running up against problems where I lack the ability to even ask the right questions, let alone understand the answers. Luckily there are helpful people to point me in the right direction and some amazing education resources out there, so this is a speed bump, not a roadblock. So far this seems to be going well, but is not yielding much to talk about or show in the blog. Regardless, the project yet lives.
Several aspects of the full game, such as level baking or score verification, require the ability to run a command-line no-graphics version of it, and ideally be able to do it on a Linux system to boot. Doing so requires a careful separation of Unity-specific code from the simulation-specific code, and in part because of my lack of knowledge when starting out.
Over time I’ve been working to make the barriers between the two parts of the program more solid, but the lines still blur in places. When redoing the objectives logic the last time some unity references dripped down into the level file format that shouldn’t have, and repairing that misstep has been the primary work this month.
Tricky February almost snuck past me!
The work this month was focused on expanding the capabilities of the trajectory plot mouseover, as well as straightening out some kinks in the backing code. Now when you mouse over it not only shows you the time frame of the object you are mousing over, but also displays marks for the positions of all the other objects at that moment in time. This should help in planning intercepts as it makes it much easier to scan back and forth over a time period to see when objects line up right.
Shown here with the UI and thus context menu turned off, because I love that neon glow.
The display can now also be frozen by clicking, making way for an interactable context menu. The context menu doesn’t currently do anything, but options I intend to explore include creating orders at the selected time, copying the time to a currently selected order, and selecting the nearest order forward or backward in time. I’m a big fan of context menus as a GUI feature in general, so getting this working is pretty exciting for me.
That’s all, see you next month.
It has been too long since the last update. It was my goal originally to not have a month go past without an update, and now that’s solidly failed. Reasonably speaking News#18 doesn’t really count, and news #17 was over three months ago. I can only apologize for that, both to you and myself, and continue to move forward.
It’s often tough to pick a project back up after an interruption, and that’s effectively what’s been going on here. While never having been a full time dev project, for a few months there it got shoved further back burner than before and went a little cold. At the same time there were some things in the code that needed doing that were giving me conceptual problems. Now as I’m getting some momentum and breaking those mental blocks, progress is happening again. So, let’s talk about that.
The Atomic Space Project exists at all because I stopped trying to figure out the perfect ideal way to write the simulation my dream game needed. Instead I implemented it the most obvious way and got something that worked. A few relatively straightforward math improvements later I had the foundation that everything now rests upon. That taught me a lesson about development that’s been very important to me, but that I occasionally forget.
Many improvements in the systems of the game have been waiting on a standardized way to view the system in terms of keplerian orbital elements rather than raw state. While a pure-kepler based simulation leads to many nuances of orbital motion being lost the information it provides is still highly useful. While the math for this is not especially hard, in fact parts of the sim were already doing most of it, I was stuck in the trap of premature optimization. Out of concern that some of the parts of the game that will depend on it might end up bogging down I spent far too much time agonizing over how to build the most efficient data structure and cleverly cache the results of kepler queries, and so forth.
Generally it’s best to optimize what you know for certain is slow, rather than spend huge amounts of effort optimizing something that may turn out to be nowhere near as big a problem as it seems. The irony in this case is that I’ve identified places in need of optimization, and they’ve been waiting on the kepler querying to be implemented before I can properly attack them. Real identified as necessary optimizations held up by premature optimization.
After talking over the state of the project with a friend who is better at development than myself I finally recognized this fact. Once I had I set out to clear the slate of all my overly complex stumbles and simply add dead-simple kepler querying to the sim with little to no optimization. That didn’t take very long at all. After moving the existing ad-hoc kepler conversions in other parts of the sim over to the new centralized method I did some profiling and found that currently it has no noticeable performance footprint. Since it’s all on a unified infrastructure now, if expanded use in the future does start to have an impact I can implement caching for it without any changes to the rest of the game’s code.
Once I’d gotten that mental stumbling block out of the way I realized I was similarly over-complicating what I’d need to do to make mouse-based interactivity work, and got a start on that. The under-the-hood simulation improvements are always good for the future of the game, but things that immediately alter the experience of playing the game are great for stoking the fires of development.
Right now the only thing you can do with a mouse is to hover over a trajectory line and see what time that point in the plot represents, but the under the hood bits that make that possible should also enable the implementation of a number of other UI bells and whistles that other orbital mechanics games have, to significant player benefit.
(NO) PICTURES OF COOL SYSTEMS
Last blog I was planning on gathering requests for cool fictional or extra-solar planet systems that I’d put in game and show pictures of. Unfortunately, while I did get some requests, the information needed to implement those requests was quite thin on the ground. Even pretty hard-SF properties pin down the elements of their locations quite rarely,and this was meant to be an exercise in implementation, not invention.
Instead, I’ll give you a pictured of my current, updated development to-do graph.
This past month has seen the least development time on the project of any month since I started this blog. Still not zero, but the progress I have made is not very flashy. December will be more fruitful, and the project is still alive.
So, instead of information, this time I have a request. If you have a favorite star system, real or fictional, make a comment telling me what it is. If I can find enough information about it online I’ll recreate it in the game and post pictures in the next update.
Last time I talked about tighter coupling of gameplay logic to the core simulation. A deeply connected and equally important effort has been uncoupling the game display and that simulation. Over time some simple, easy first-effort implementations of features have given the user interface direct access to the core simulation data. The interface obviously needs some way to get that data to display anything, but full unfettered access can lead to trouble and rigid code that is hard to update later. A lot of my work since the last post has been me finally pulling off that band-aid, cutting off access that the user interface has completely and fixing everything that breaks. I believe that’s pretty well finished, and everything works now.
In addition to clearing away that technical debt I’ve been able to get some important simulation features in place, the first fruit of which is engine recognition of barycenters. As previously discussed when talking about adding binary stars to the level editor, a barycenter is the point around which a pair of objects orbit. Strictly speaking all cases where we would say one object orbits another are actually two objects orbiting a shared barycenter, but if one of those two is significantly more massive than the other the barycenter and the center of the more massive object are so close together that it the difference can be ignored.
When two objects are similar in size however, and assuming that no outside forces affect their motion, then both move noticeably around a single empty point in space. You see this in binary stars, or more rarely in binary planets. Pluto and its moon Charon form such a binary system, and some have argued the earth and moon ought to qualify too.
While it’s been possible to set up that structure in the level editor for months now, there’s been no ability to see them while actually playing the level. Now there is! Below is a snapshot of a binary star system under this function.
The trajectory-line drawing code doesn’t know how far forward to draw the lines in this case yet, and is still figuring it as if the heavier star were stationary, but that’ll clear up in time. You can still see that the secondary star(Naanlil) is orbiting around the barycenter, instead of the primary star(Anlil). The other limitation at present is that it doesn’t have a good way to detect appropriate places to put barycenters or a means to have level objectives refer to them. That is in the cards, though. The systems that allow this will also provide a framework for working with Lagrange points more richly.
About Objectives Again
Last time was talking a lot about the partially finished work with objectives. Now I do have a functional level with those systems, testing objective chaining, duration, and alternate conditions. Take a look!
This also shows the greatly expanded information in the objective display section. That’s subject to plenty of revision, but should remove a lot of guesswork at what you’re supposed to do. In time more visual signposting will be worked into the main rendering itself, but having the written version of the objectives should make it a lot easier to learn what those visuals mean.
Now seems like a decent time to share one of the tools I use to keep track of my plans for ASR. So, below is my high-level to-do list, made with the wonderful Graphviz tool.
Unfilled are things that aren’t implemented at all yet, blue are things I think are probably complete, and light blue are things that are functional but I expect to have to do more work on. Of course this list shouldn’t be seen as set in stone, things may be dropped from it or added to it, but that’s the plan at present.
A final note, I’ve seen a big uptick in spambot activity here getting past my existing filtering. AApologiesin advance if I miss approving a comment in the sea of noise.
At its heart Atomic Space Race is a puzzle game. Puzzle games live and die on the puzzles they present, and there must be room for some complexity if the game is to have any staying power. One form of complexity is in giving the players additional tools. While I do have some ideas for that, it’s not a long list. Another major form is in what you’re tasked to do. To date the objectives in a level, or track, in ASR have been relatively simple, always taking the form of getting within a set distance from an object at some point in the level’s set duration. This has been a good start, but I’ve wanted to open up more options there. To that end I’ve rewritten objective logic and handling to that end, with a number of aspects.
The new system allows the designer a choice between the objective being to have your distance above a set value instead of below. This could be used for disallowing approaches too close to an object, or directives to escape an object.
The old system only allowed objectives of the form ‘meet this requirement at least once’, the new one also supports ‘meet this requirement once and then continue to meet it’, which can be used to impose additional requirements on the shape of a course after meeting the objective.
The new system allows objectives to be chained, so you can require they be completed in a certain order. An example use of this is a mission where you need to flyby the moon, then return to the earth. Approximating long multi-stop cargo trips also presents itself as an option. An objective can be valid before or after the objective it is dependent on.
Objectives can have a time limit that they must be completed within, and if they are a link in a chain objective that time limit can be relative to the completion time of the parent objective. Objectives can also have a duration, where their conditions must be met for at least that long before being considered complete. This could for example complexify a round trip objective by requiring you to spend at least one orbit’s worth of time around each destination. Then you need more burns than just a simple flyby.
A related change is that levels will now be run for a stretch of time after their ‘finish line’, definable by the level editor, to allow levels where part of the challenge is to get your course in a state that remains stable without active correction for a ‘cooldown’ period.
The kinks are still getting ironed out on all the possibilities here, but most of the pieces are in place. This has led to some restructuring both in my level editor code, which happens every time I touch it. It’s also seen me move the entirety of the objective handling code from the unity layer, where it was uncomfortably intertwined with the UI code, and into the underlying engine layer with some carefully chosen parts exposed to that UI.
I’d previously wanted to keep the engine layer as gameplay-agnostic as possible, but I’ve come to the conclusion that most gameplay needs tighter coupling with the simulation than is healthy for other parts of the program to have. As I intend to have a unity-free, ‘headless’ version of the simulation that can do various gameplay supporting operations(level baking, solution verifying) and some of those need a concept of level logic to properly function. The rewrite and tighter connection to the simulation has also fixed some issues with the old system not always detecting objective passage if the player ship was moving sufficiently fast, while still performing plenty acceptably.
With luck next time I’ll have some levels that take advantage of this new system to show off! I’ll likely implement delta-V caps(aka fuel limits) for levels as well to put a bit more pressure on level solutions, at least on a trial basis.
A quick followup on the game jam mentioned in last month’s post. Despite some difficulties with my own energy level throughout, I felt I did quite well at stretching my boundaries with the game I made, doing some sprite work for the first time and approaching the structure of the code in a different way than I typically would. The game I made in many ways mimicked the economic model of Supreme Commander, and I was very satisfied with how much of that model I was able to put together in the time available. The game fell down somewhat on presentation, not adapting well to varied resolutions nor explaining it’s mechanics well. I’ve found that people who are already familiar with Supreme Commander have a better chance of getting hooked to some degree. As always with Ludum Dare, an imperfect game, but a great learning experience.
The game, made from start to finish in a 48 hour period, is available for anyone to play at this link.
Lastly, I want to thank everyone who has filled out the tester sign-up lately. I’m holding off on the next wave of testers until I get the next major UI change in place so that I’ll have some fresh eyes and hands as well as people who’ve learned how the game plays already. However if you want to hang out and chat with myself or other interested people on the public portion of the discord server, this invite link will take you there.
Previously all objects were drawn as simple dots no matter the zoom level. For the largest parts of most courses this is quite sufficient, but when you get to the interesting bits near planets it can become important to see where the space ends and the ground or sky begins. At present there is still no collision with the ground, but object size is now stored and, if viewed closely enough to visible, displayed. I’ve found it provides a nice reference point for scale when you get close to things and the curve of large orbits falls away.
Here’s some looks at familiar locations in the solar system.
Beyond that, I’ve been able to refine some aspects of UI responsiveness and resilience based on tester feedback, as well as iron out kinks in my build preparing scripts. Nothing very exciting, but the game plays a little better as a result now. Reminder, if you’re interested in testing you can still fill out the form.
Finally, this weekend I’ll be participating in the 42nd Ludum Dare, a 48 hour game jam. It starts at 5pm central time(GMT-5), about 4 hours from time of writing. In the past I’ve found it to be a very valuable exercise. I will be attempting to stream my efforts with it via my twitch channel, and if that for whatever reason proves impractical I will be updating through my twitter, if you are interested in following my progress. When it’s done I’ll edit this section as is appropriate.
It is common advice to test your game as early as possible and keep testing it constantly throughout development, with as many fresh eyes as possible. I’m sure it’s very good advice, but it’s hard to follow when starting from zero in terms of following and budget, especially the fresh eyes part. I’ve gotten a few friends to test earlier versions of Atomic Space Race some time ago, but it’s time to cast that net again. If you want to be involved I’ve set up a signup form here. I’d prefer to coordinate tests by means of a Discord server, but if that doesn’t work for some interested potential testers I’m open to other ideas, and the form has a place to suggest. The comments section here works for suggestions and discussion too.
Currently I’m building versions for Mac OSX and Linux as well as windows, but don’t have enviroments to test them myself.
One of the challenges with testing is drawing the line on when enough has been implemented to push it out the door. There’s always one more thing you want to do before it’s ready, especially when there are large parts unfinished.
Many things have been advanced a little, but only a few item have come to fruition since the last posting. One is a basic options menu, presently just a color option and some volume controls. The other is sound and music for those options to control. Sound design and music production are areas I have no expertise in, but there’s some good resources out there. In particular I’d like to highlight Gravity Sound who has produced several tracks I’m using in the current build, and has plenty of other good work I’m not using.
Another challenge is minimizing the amount of repeated work every time you need to release a version. I’ve got a build-and-package script from when I made the Atomic Space Tools builds, but that was at least one computer and several adjustments of the file structure ago. My ideas about proper package structuring and naming conventions have also evolved, so I’m revising all that before getting myself locked into anything.
Lastly I’ve moved the project from Unity 5.x to Unity 2017. Constantly moving up versions isn’t a great idea for an ongoing project, but there’s a few behind the scenes features of newer versions that I’d like to have on hand, and 2017 is the basis for Unity’s current Long-Term Support version that promises to get stability and compatability updates for a while without the major feature changes of the ongoing verison, so I made the decision to make the jump to that rather than Unity 2017. This time at least it was a rather painless update.
Again, if you are interested in participating in testing, check out the signup form. First testers will probably get given links within the next week.