Deep Orbit is a resource management game where the player must build orbital infrastructure and research technology in order to discover faster-than-light travel. Gameplay starts slow as the player learns the ropes, but escalates as they simultaneously build their infrastructure, hire crew, and deal with random events and disasters that grow increasingly difficult. Random events are mini games to add varying gameplay besides just point-and-click. Late gameplay requires the player to multitask and stay on top of the needs of their crew, infrastructure maintenance, and avert disasters.
This project was made in Unity using C#. It was made by a team of six other game designers, myself, six artists, and a producer at Full Sail University as our final project. My main responsibilities in the development of Deep Orbit were the research system, the UI/UX, and one of the random event mini-games. I also contributed to iterative playtesting, balancing, design decisions and discussions, and bug identifying, verifying, and fixing.
Research System
The research feature is the primary means of progression and sets the pace for the whole game. It unlocks buildable infrastructure, upgrades, and eventually the FTL drive which is needed to win the game. The early prototype of the system had bottlenecks in progress for the player due to the perquisite “Tier” research taking longer to complete than the sub-items. To fix this, we allowed the player to complete 50% of the tier research progress at the cost of more resources. Through iterative playtesting and the use of spreadsheets, I balanced the cost, research time, and return value of upgrades to give the player a good sense of progression while still keeping a full playthrough at the target time of one hour.
UI/UX
I finished prototyping the research system early on in the project development, which gave me time to contribute to other areas in the project. My team liked the menu I had made for the research screen, so they wanted me to make more of the UI. Since this was a resource management game, the UI had to give a lot of information and control to the player, so making it not overwhelming or confusing was a challenge. To combat this, I hid as many of the UI elements as I could early in the game, then introduce those elements as the player progresses. Later on we also added voice lines, a message system, and a tutorial to guide the player through early stages of the game. I got all the game icons on gameicons.net and when artists joined our team, we thought the icons were good and decided to keep them.
Asteroid Minigame
After play testing the prototype, we thought overall gameplay was too repetitive, too close to a mobile idle game, and we weren’t happy with the fact it could be played entirely with one hand. So, we added minigame random events to be loaded into the persistent level. A few of us each made one minigame. I made the 3D asteroid field minigame where the player must pilot a drone safely through an asteroid field. The asteroids are procedurally generated in size and placement. Each time the player wins, the asteroids will be larger and more numerous, and the drone’s light will be dimmer the next time the random event is triggered. One of the challenges of this was optimizing the minigame. When the higher difficulties were reached, performance dropped significantly. I changed the asteroids to be generated in chunks in front of the player, then be destroyed behind them. I was able to hide this by taking advantage of the fact I had made the drone fly in orbit around the planet, and so I could us the horizon line as the point where the asteroids were added.
Post Mortem
In the end, I am quite proud of this project and we got a lot of good feedback on it. However, there were some things I wish I had to gotten the chance to work on more. I had finished the research system early on and made it easily extendable so we could add new researchable items or skills later in development. Sadly, we never did this and much of the current skills are the same original ones. The addition of random event mini-games would have been a great opportunity to tie the research system in with the event system. I feel like some rough spots in gameplay could have been smoothed out by adding optional researchable skills that weren’t core to progression, necessarily, but improved quality of life for the player and reduced the difficulty of some mechanics. The team decided it was too late in development to add more work integrating systems, implementing and balancing the new skills.
Also, within the development process, we had some team management problems. One team member continued to work on a save system after it was cut. Since the game was meant to have a play time of around an hour, it was decided a save system wasn’t necessary and our producer wanted to us focus on gameplay features. The team member assigned to that feature refused to work on anything else, so as a team we were forced to give him poor teammate reviews. The lead designer and producer spoke with him and got him to contribute in other areas. As a game developer, I understand sometimes features will be cut, and despite however much work has gone into them already, it’s better to move on and contribute in more impactful ways.
Alex Hester - Game Developer Portfolio 