Initial Work

The story of FIRST ORBIT! began on February 24, 2023 with the release of Kerbal Space Program 2. I was very excited for KSP 2 and had been eagerly awaiting its release for months. When it finally released I found myself disappointed in the state of the game. Seeing the condition of KSP 2 got me thinking about what all went into making a game like that. What were the challenges the developers faced? If it were me, how would I tackle them? The more I thought about it, I realized I had the skillset to find out for myself. And with that, I started to work on my own spaceflight game which would eventually become FIRST ORBIT!

Early work on the project was just focused on the n-body simulation of the solar system. At the time I did not yet have a clear vision for what the game would be. This is one of the earliest functioning demos, showing some planets and moons orbiting each other:

A critical part of any n-body simulation is the choice of integrator. I used MATLAB and Julia to explore different options. Most game developers are familiar with a method called Forward Euler, whether they know it by that name or not. That's when one simply finds the new position and velocity of an object by:

• newVel = oldVel + acc*dt
• newPos = oldPos + oldVel*dt

This works great for simple platformers and other games, but it is insufficient for simulating orbits. Forward Euler is susceptible to energy drift, which causes an object in orbit to gradually drift away from its parent. The image below shows the difference between Forward Euler and Modified Euler (aka Midpoint) in terms of energy drift for an object in orbit:

I forgot to label the axes, but they represent position in meters. With Forward Euler, the spacecraft gradually spirals away in an unrealistic manner. Midpoint is a much better choice, but it has its own problems. Another aspect of integrators is their stability. For certain time step sizes, an integrator's results can become unstable and fail to converge on a solution. In game, this instability appears as a zig-zagging and jitter in the trajectory. This image is a close up of multiple orbit passes of a spacecraft and shows such zig-zags:

The final version of FIRST ORBIT! uses a third order symplectic integrator. Symplectic integrators do a better job preventing energy drift, and I found them to be more stable for larger time steps. The exact integrator used is described in the paper "Construction of Higher Order Symplectic Integrators" by Haruo Yoshida. It is also discussed in the paper "Fourth Order Symplectic Integration" by Etienne Forest and Ronald Ruth.

There is a saying that "all models are wrong, but some are useful" and it applies here. The goal of FIRST ORBIT! is not to be an extremely accurate, state of the art model. The goal is instead to be accurate enough to reproduce many trajectories used in real spaceflight. I am sure there are better choices of integrator and different ways of approaching the n-body problem, but I believe my choice is good enough for its intended purpose.

Defining the Project

Work on the game stopped in spring when classes and finals became too demanding. It wasn't until late July when I started working on it again. Upon resuming work I decided that I wanted to make a finished game from what I started. I put together a document to solidify my scope and requirements. This became the "bible" I followed from then on keep the project on track. I had 3 core purposes for the game:

• To provide a way to actively explore and play with n-body trajectories
• To apply what I learned in school
• To work on a game from concept to completion

I also wrote down core design principles I wanted to follow:

• Gameplay > Accuracy (except for n-body stuff)
• Work on mechanics and playability first, art later
• Document everything!
• This game is a Sandbox

And lastly some key objectives to define the scope of the game:

• A one player game
• A 2D spaceflight simulator with n-body physics for spacecraft
• Players can fly to and land on other planets
• A sandbox design with no progression systems
• Spacecraft persistence, so multiple spacecraft can exist across the solar system
• Menus and a simple soundtrack

I followed these as close as I could to try and avoid scope creep. Spacecraft persistence and a soundtrack were descoped later in the project to keep focus on more critical elements. I also wrote this statement in answer to the question, "who is the player?":

"Who do I see as the player? I want the game to be playable for as many people as possible. To put this into more specific terms, I don't want the game to require an understanding of astrodynamics at first. I want the game to have basic controls, where someone can pick it up and navigate space immediately. Their experience flying around should gradually teach them the astrodynamics at play. While this is the case, I also want the game to be worthwhile for those that do understand astrodynamics. This is part of why accurate n-body trajectories like Lagrange points and ballistic transfers are a core of the game."

Early Versions

FIRST ORBIT! uses a custom engine made with Processing. Processing (terrible name, I know) is a graphics library for Java. For a computation heavy game like this, C++ would probably be the normal choice. Since I was busy with classes though I chose Processing in order to make progress faster. I still believe it was a good choice, though the scope of this project is likely bigger than what Processing was intended for.

Early on the game had the working name "Gerbil Space Program" in homage to the KSP meme. The rocket had a gerbil astronaut named Gerald.

At this point in development, the scale of the solar system hadn't been decided on. The Earth and Moon were smaller and closer together. I knew I wanted a small solar system, with planets on the order of 100s of meters across. This makes the gameplay loop of getting to orbit and flying around much faster. At real scale, reaching orbit takes on the order of minutes. At small scale, maybe 15 seconds. A lot of work in these early versions was focused on trajectory drawing and the camera system.

After some major aspects of the game were finally coming together, I took a break from programming and did a first art pass. I like the look of this era of the game, but I also felt the vector art was not unique enough to really give the game its own character. This is part of why I set the goal of doing art design later, because I am very indecisive about art design and nothing would get done if I did it early on.

Development continued at a good pace and I then had an idea for another art pass. Goodbye Gerbils, now it's time for SPACE FROGS! Yeah so at one point the game was going to be about frogs, a reference to another meme about Kerbals being space frogs. This did not last too long but it marked the beginning of work on the UI and collision system for planets.

The collision system is fairly straight forward. Both the planet and ship have circular hitboxes, and once a collision is detected work is done to handle the physics of the interaction. The ship can bounce and slide along the surface depending on the angle and speed of impact. A lot of this isn't immediately noticeable though since the ship's safe landing speed is fairly low. This took quite a bit of work despite how simple it sounds. I think that describes most game development.

The most confusing part of development was the trajectory drawing. Specifically, drawing the trajectory in rotating reference frames. It is necessary to do this in order to effectively see motion around Lagrange points. On a fundamental level it is not that complicated, but things get confusing very fast. The whole effort really deserves its own dev log, so for now I'll just say I was extremely relieved to finally see this:

This is an orbit around the L4 point, drawn in the Earth-Moon Barycenter Rotating frame.

Coming Together

The game found its final identity fairly late in development. I stumbled upon an amazing blender halftone shader made by Mrmo Tarius https://mrmotarius.itch.io/. I started playing around with it and decided it was perfect. The final art pass gave the game a retro / comic book vibe. This inspired the name FIRST ORBIT! It's a reference to Sputnik and the beginnings of the Space Age, as well as the fact many players would be achieving their own first orbit when playing. 

At this point it was now September. Most major hurdles had been crossed, but as the saying goes the last 10% of the project takes as much time as the first 90%. Lots of work was left doing bug fixes and quality of life improvements. By late September the game was ready for playtesting. The next few weeks saw the game being tested by friends and their feedback being implemented. This closed beta lasted longer than expected, but it really helped get the game in shape. 

This playtesting is also when I really started to believe this game could be a powerful tool for aerospace education. Many of those who tested it were friends and fellow aerospace graduates. When they told me how helpful it was to them for understanding concepts taught in school, I knew the game could really make a difference.

Final Thoughts

I have worked on a number of small games in the past, but they never progressed past little demos. This is the first game I have gone from concept to finished product. It's been quite the journey and I have learned a lot from it. I hope you have enjoyed reading this and getting a glimpse into how the game came to be. At some point in the future I think I will do more dev logs on it, where I can go into more depth about certain features of the game.