Starfleet Showdown

A space-themed aerial dog-fighting game

Unity
C#
*Note: Since this project was never intended for a wide/public release, many of the assets are placeholders from the Unity asset store or temp audio/images that were meant to be switched out if ever we decided to release it.

Overview

Starfleet Showdown is a space-themed aerial dog-fighting simulator developed in Unity and scripted in C#. Up to 4 players can navigate through a dynamic environment filled with asteroids and large capital ships. Once players find each other, they can eliminate each other using their spaceship’s lasers. The game can be played on controllers or with a computer mouse.

This was my senior design project and a collaborative effort between myself and 3 other computer science students: Andrew Yuan, Joshua Sun, and Brett McCausland. It was completed in an agile environment with two 3 week long sprints and a final 2 week long sprint, for a total development time of 8 weeks.

I was in charge of most of the game's user experience such as branding, user interface, and key map design elements.

Implementation

Branding and User Interface

I saw working on Starfleet Showdown as an opportunity to practice my design skills. I wanted to make the game's branding and UI simple and futuristic looking. I made all of the game's branding and UI in a single Figma Design Workspace. My biggest goal was to make the UI appealing and minimize visual clutter.

In designing the various 2D assets for the game, I would grab some reference photos and then mock up the 2D assets to how I wanted them to look. Then I'd place them on top of screenshots of our current build. Once I tweaked them to how I liked them, I exported the 2D assets to a separate file, imported them into Unity, then implemented them into our game using the Unity C# Scripting API.

The various logos used for Starfleet Showdown

The various logos used for Starfleet Showdown

Main menu mockup. The reference/inspiration photos I used were a poster for Porter Robinson's "Virtual Self" Tour, and the main menus for Halo 3 and Super Smash Brothers Melee.

Main menu mockup. The reference/inspiration photos I used were a poster for Porter Robinson's "Virtual Self" Tour, and the main menus for Halo 3 and Super Smash Brothers Melee.

The mockups for the player victory screens that appear at the end of a game. My references here were Super Smash Brothers Ultimate and Persona 5, because I really liked how they show the winning player spilling over the UI. I also referenced portrait photos from driving simulation games such as Need for Speed and Forza: Horizon to get an idea of how to frame vehicles in a dynamic way.

The mockups for the player victory screens that appear at the end of a game. My references here were Super Smash Brothers Ultimate and Persona 5, because I really liked how they show the winning player spilling over the UI. I also referenced portrait photos from driving simulation games such as Need for Speed and Forza: Horizon to get an idea of how to frame vehicles in a dynamic way.

In game heads up display (HUD) mockup. I referenced Halo and Star Wars Battlefront II (2005) to get the sci-fi aesthetic.

In game heads up display (HUD) mockup. I referenced Halo and Star Wars Battlefront II (2005) to get the sci-fi aesthetic.

Map

Issues with the setting

When we started making the game, I had no idea how much trouble we would have with our outer space setting. Initially we thought all we needed was to find a space themed skybox, throw some players in it, then let them find each other. We were very wrong. There were a litany of problems that needed to be solved for gameplay:

  • In everyday life, we know which way is up and which way is down because we have points of reference like gravity, the floor, and the sky. In space, there is no true "up" or "down". There is no floor and no gravity.

  • In real life, you can tell how fast you're going by looking at the objects around you. Stationary objects will fly right past you, and other moving objects will appear to be moving relative to your speed. In outer space, there are no objects to visually reference your speed.

  • Space is infinite. In any other setting, you can set up walls or fences to keep the player from going outside of the play area. There is no easy equivalent to walls or fences in space.

Clever solutions

Our final map ended up being a ship cluster littered with asteroids. Having four large capital ships solved a couple of problems for us. The player can use them as visual indicators for where they are on the map. They can also perceive their speed better by seeing how fast the static ship is when it is flying by them. Lastly, the player knows when they've wandered too far when they can't see the massive ships anymore.

Our final map. Four capital ships and a slew of asteroids. They serve as visual indicators, landmarks, and obstacles for the player.

Our final map. Four capital ships and a slew of asteroids. They serve as visual indicators, landmarks, and obstacles for the player.

An in-game single player screenshot. Without the ships or asteroids (or even the planet in the background on the left), the player has no idea which way is up and down.

An in-game single player screenshot. Without the ships or asteroids (or even the planet in the background on the left), the player has no idea which way is up and down.

There was still the problem of players deliberately flying out of the play area. Beyond the ship cluster there is more nothingness, and a repeat of our previous problem of not knowing where you are. My solution for this was a lot more involved than just placing static assets from the Unity store into the map.

I implemented what I called "smart boundaries" for the map. This is a large pill-shaped mesh collider that encapsulates the entirety of our intended play area. Each player is given a boolean value called insidePlayArea that is initially set to true. Once the player leaves the smart boundary mesh collider, insidePlayArea is set to false.

The smart boundary, a large pill-shaped collider that envelopes the map. It is invisible during gameplay.

The smart boundary, a large pill-shaped collider that envelopes the map. It is invisible during gameplay.

I then added a prompt to the player's UI canvas, the object that overlays UI elements on to the player's screen during gameplay. The prompt is a bright red screen and white text tells the player that they are leaving the battlefield. It is set to 0% opacity during normal gameplay. Once insidePlayArea is set to false, the prompt flashes from 0% to 75% opacity every 1.5 seconds. Also for good measure, the player's in-game health goes down by 4% every second that they are outside of the play area.

The out of bounds prompt on the player's UI canvas.

The out of bounds prompt on the player's UI canvas.

A player trying to leave the map.

A player trying to leave the map.

Once the player re-enters the smart boundary, the insidePlayArea is set back to true. The prompt fades away and their health no longer depletes.

Lessons learned

Making a game UI isn't all that different from making a UI for a website or application. There's a ton of overlap between the two processes; that includes but isn't limited to getting proper reference materials, trying to reduce visual clutter, and making the overall process of using the interface easy for the user.

The biggest challenges I worked on for this project didn't have very easy solutions, but clever thinking and perseverance made it possible to come up with proper solutions for those problems. Visualizing and properly defining the problem is the first step to solving it.