Mars Descent Design & Development

My Role

Designer, Developer, Director

Developer

Low Key Sirius

Tools

Figma, Unity, VS Code

Project Length

Eight Weeks

Overview

I designed, developed, and produced a mobile app in December 2020 on my own, with engineering oversight and assistance from my game development partner, Andrew. I started development on December 1st, 2020, and released version 1.0.0 on the App Store and Google Play on February 14, 2021. I developed this independently, with the goal to have a project on my portfolio that showcases both my teachability and my drive—and to that end, the app will always be free to play.

The Goal

The goal for the game was simple—create a delightful and casual experience both through visuals and gameplay. I wanted to create a product I could proudly put at the top of my portfolio, one that I owned completely, and one that I was responsible for from inception to ship.

After brainstorming dozens of ideas, I decided on a space-themed game, using Atari's Lunar Lander, which was a moderately popular arcade game in the 70s, for inspiration. Lunar Lander played perfectly into the 1970s zeitgeist of space exploration, launching just a few years after the Apollo 11 crew landed the Eagle on the moon. I set off to make my own game in the backdrop of today's zeitgeist of human exploration in space: Mars.

In order to build what I had in mind, I first had to learn C# and the Unity game engine. I taught myself how in November 2020, working every night for four hours after I put my kids to bed.

Research

Competitive Analysis

Because the goal was to create a casual mobile experience, I downloaded and played several casual games to get a feel for how they were designed to promote user interactivity and engagement, as well as how they created the underlying satisfaction that comes from playing a game.

Direct Competitor #1

Mario Run

A game I've played before (and one that my son enjoys), Mario Run does several things well, such as challenging levels, simple gameplay, and engaging content that changes and provides an endless experience.

Direct Competitor #2

Alto's Adventure

Developed by an independent team, this game shows mastery in microinteractions, visual experience, and a sense of self that gives the game a strong personality.

Opportunity #1

Establishing the Core

Lots of games I played didn't have a personality, or were too boring for me to want to continue playing after long. It's apparent that great games have that sense of self—an understanding of what they are and what they aim to do.

Opportunity #2

Visual Flow

Great games have a visual flow to them, both in the hierarchy of UI elements and they way they behave, as well as in the way the graphics inform the gameplay. For example, Mario Run has classic Nintendo style graphics with bubble-like UI elements to match.

Opportunity #3

Simple Controls

The best games have simple controls. There are many mobile games that use simulated joystick controls, and they usually tend to behave poorly and lend to unintended user error. Simple user inputs that allow maximum control over the gameplay offer the best casual gaming experiences on mobile.

Gameplay Research

In order to make the game as realistic as possible, I researched some basic facts about Mars, and learned as much as I could about the current exploration of the planet.

Insight #1

Mars's gravity is 62% less than the rate on Earth. Since my game is a space craft attempting to make a landing on the red planet, this was incredibly useful in simulating the correct gravity scale.

Insight #2

NASA's InSight lander was able to capture the atmospheric sounds that exist on Mars. Mostly, it's wind. During InSight's recording, the spacecraft made lots of interesting mechanical noises. I used these to simulate atmospheric and player sounds for the game.

Insight #3

Mars has the largest mountains in the galaxy. They're not long ranges like they are on earth, but tall and round and flat. I used this to inform the shape of the landscape.

User Research

I mainly wanted to understand what made users want to play casual games in the first place, as well as what made them want to continue playing after they started. As a gamer myself, I had to separate my instincts from my expectations. The designer is not the user, after all, and everyone experiences games in their own way. With a short, self-imposed deadline, I was only able to speak with a few people, though I did collect some important insights.

Insight #1

Gamers that I spoke with consistently agreed that a sense of progress is usually what keeps them playing a game. I had to figure out how to turn progress into a tool the user could use to become attached to the gameplay.

Insight #2

Difficulty has a lot to do with how people engage with game content. Too easy, and they stop playing. Too hard, and they stop playing. Gameplay has to strike a balance of being just easy enough to get used to it, and just hard enough to pose a challenge.

Insight #3

Repetition is just as important as difficulty. If a player encounters too much repetition, they grow bored and stop playing. Increasing difficulty as time goes and allowing customizable options are great ways to avoid repetition.

Defining the Product

Based on the research I conducted, along with the product I wanted to create, I came up with a product statement that would help guide the design:

The casual gamer wants a mobile experience that provides just enough of a stimulating challenge so they have to exercise their reflexes and intellect because they want to feel that sense of competition and accomplishment from achieving something simple, yet challenging.

Ideating and Iterating

Concepts

I started coming up with visuals by playing around in Figma and creating basic vector shapes that would make up the graphics. I knew I wanted to keep things simple, so I grabbed some reference images of mars taken by the Curiosity rover and used the colors and shapes to inform the backdrop.

I initially planned on calling this game "Mars Vertical," and wanted it to be a vertically-oriented game, rather than horizontal. Once I began building, though, it became apparent that there just wasn't enough horizontal screen space for the type of game I had in mind. You can see how much changed from this initial concept sketch to the beta product below.

Unity Builds

Due to the short timeframe I allotted myself, I elected to build a low-fidelity prototype using Unity and programming it myself, rather than building a user flow prototype with Figma's prototyping tool.

I imported my Figma vector images into Unity and started building, using VS Code to program.

Twice per week in December, I met with my game development partner, Andrew, who helped me solve complex calculations and integrate advanced scripting methods. This was an incredibly useful collaboration—it gave me the experience of working directly with an engineer, and showed me how to collaborate with them on designing a practical solution for user problems with both architecture and engineering. There are dozens of ways to solve any given problem, but the best solutions can happen when the designer and the engineer put their heads together to create a cohesive system for problem solving.

(If you want to see everything that went into building the prototype, you can view my game design Google Doc, with several pages of notes on what to design).

Gameplay Design

I wanted the gameplay to be both simple and engaging, while at the same time offering an immersive experience that the player could choose to either be intense and action-filled, or serene and relaxing.


I designed basic user controls to allow the player to engage with the ship, navigate around hazards, and collect coins on their way to the surface of the Red Planet. I also incorporated fuel and velocity elements. Run out of fuel, and you lose control of the ship. Hit the ground with too much velocity, your ship explodes. These gave the game more elements that kept the user engaged and involved, while posing a challenge. I also created difficulty levels to meet the player's choice of gameplay. Select easy, and you have an enjoyable, relaxing experience. While on the other end, impossible mode is, well, really hard.


Music was also really important to users—an engaging score will help immerse a player fully in the experience of the game. I have been writing and playing music for as long as I can remember, so I created a simple cinematic loop that the player can listen to, and asked a friend of mine, Sam Johnson, to come up with a lofi hiphop beat for the player to select from.

With all of this in place, I had an engaging product to offer to casual players, I simply needed to create a UI for the player to control the game with.

The User Interface Design

One of the challenges I faced when implementing my UI was that Unity is so different when it comes to sizing, placing, and organizing interactive features than Figma is, which I was much more used to at the beginning of the project.

I wanted to keep the UI simple, to match the simple vector graphics of the gameplay, so I used black and white UI elements to contrast the colorful backdrop of the game and make them stand out.

Gameplay Testing

Four weeks into the project, I had a playable alpha prototype that I began testing with twelve users on iOS and Android to uncover usability issues as well as programming errors.

I uncovered several bugs and design flaws during this alpha test that I was able to correct for the beta launch. Here are some of the highlights:

Pause Screen

The problem here was that when the player pressed play, the pause screen would fade out, but the game wouldn't unpause. Which obviously meant the game was broken, and I needed to find out why.

Too Many Coins

An interesting problem I had to solve, though one that users actually liked, was that picking up a single coin would add dozens of coins to the coin count in the UI. Of course, that was a bug in the code, but it affected the experience.

Updated UI

One thing I had to resolve was that users found the UI too "all over the place." The image on the left is a very early version of the UI. I'd go from there to create UI elements in each of the corners (the fuel indicator was initially placed in the bottom right). However, that spread too much information across the whole screen, and with the user needing to focus on the ship so as to not crash, I elected to pull the UI elements to the corners, where they would be easier for the player to engage with.

In addition to rearranging the on-screen elements, I elected to make the typeface larger. Several users reported that it was readable, but still small—anyone with trouble reading up close might have a problem with it.

Version 1.0.0

Launch

After I'd implemented the bug fixes and redesigns mentioned above, I completed one more round of user testing, and then prepared to launch the app on the App Store and Google Play. I submitted the app to Apple and Google in February 2021, and it was approved for their markets. The app is now available and free to play.

*2023 Update: The app is still free to play; however, the game has been moved from the Google Play and App Store to itch.io.

Next Steps & Future Recs

A product like this is never truly "finished." Although the game is available to play, there are changes that can be made to enhance the player's experience, and updates that will need to happen as iOS and Android systems advance and develop further into the future. Things I'd like to see implemented into the gameplay are social sharing, Game Center and Google Play achievements, Leaderboards, and weekly challenges. All of these things go hand-in-hand with engaging users and keeping them active in the app.

What I Learned Designing Mars Descent

Learning #1

Teachability is Important

There were times when I sat down to work on this that I felt I had no idea what I was doing. Thankfully, there are dozens of tools and resources available to aid those who are learning new skills. The most important part is perseverance. And when working on something new, it's important to keep an open mind and not assume that you know everything already.

It's safe to assume that you should always assume that you're going to learn things as you go.

Learning #2

UX Design is Not One Thing

In school, they teach a process. And that process is a great one to follow. Empathize, define, ideate, prototype, test. That's what I tend to think of UX as. But UX is not just that one thing. A user's experience is tied to the entire product. Everything that goes into a product determines how the user experiences it—the programming, the visuals, the music, the sounds, the haptic feedback. It's all part of the experience, and designing that experience shouldn't end once testing is complete. UX design has to happen constantly throughout the life cycle of the project.

Learning #3

We Can Build Anything

I've wanted to design and build games my whole life. It's never something I've prioritized until now, but because of the breadth of knowledge that's out there and the amazing tools that exist, I learned how on my own and can continue developing this game and many others for the rest of my life. More importantly, though, we can design whatever we put our minds to. If we dream it up, the tools exist to build it. And that makes me excited about the future of both technology and video games.

Conclusion

I set out to build a mobile app, and I did it. I learned what I needed to, used what I already knew, and asked for the help I needed. It's far from perfect–there are plenty of additions and changes that can be made (as I've already pointed out), but it's something I'm proud to put at the top of my portfolio and highlight as a major personal and career achievement.