ATOMIC SPACE NEWS #17

 

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.

 

Runtime barycenters

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.

 

Planning

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.

Leave a Reply