But somehow, this “I have a great idea for an app” turned into one of the highest rated mobile games in the stores. Let’s tell the story about how this happened.
Okay, so, great games sell themselves by creating a unique and unforgettable experience. More than just a game, an interesting experience must have:
So, the next logical step was coming up with a game idea (that’s what we are calling it here). Just so you know, a game idea is a brief description of the game.
Game idea: “Planet X”. An airplane crash lands in the planet X with a main character of an alien Bud. The main objective is to collect stuff to build a spaceship and fly back home. There are more than 100 levels, and the game is free to play.
Keeping this in mind, we worked on:
We chose Unity because of its track record and stability. Designing a game this large and complex needs a solid foundation. Unity’s flexibility allowed us to focus more on our game and less on the underlying code.
The setting shows us who the characters are and helps us relate to them. It creates an emotional state before we start the gameplay, which ultimately makes our gameplay better.
Mechanics are the way players interact in a game. In Monopoly, players roll dice to make strategy-defining moves. In chess, mechanics allow for intricate movement on a grid-based board.
For this project, we had the goal of creating a game with customizable units, a multiplayer feature, and an action-adventure environment. We developed Planet X, our proof of concept, with these features so that we could test them before implementing them into another game.
This game design document (GDD) was written as a set of specifications for the game Planet-X. The purpose of this document was to clearly define what must be done to build the final product, so we could then use it for developing, testing, and debugging.
It addressed 3 of these key questions:
While most systems were fully validated during the proof-of-concept phase, it was still important for us to create a playable prototype for the target platform. Our prototype included the most important game elements and embodied the core play experience. Here’s a snapshot of the steps followed:
We started by specifying that our game will be composed of features A, B, and C. We then explored the design space covered by these features to get the right mix of building blocks. With this approach, we built many possible combinations leading to different player experiences. We used those to create playtesting versions of the game.
Those versions were tested against a group of players in an online survey with a scoring system. All results were collected and analyzed to identify which combinations will offer the best balance of player experience and gameplay.
The next obvious step was development. With game development quickly evolving, we knew that an agile methodology would help streamline our game development process. We also realized that early delivery of an MVP was important to the motivation and involvement of the QA team. This perfectly sums up our development process:
QA and beta testers joined the team as soon as the game was close to being version 1.0-ready. We used this sprint to test the game in the wild to make sure there were no weak spots, and we updated the game until it was acceptable according to user feedback.
Getting the users’ attention is one thing and keeping them engaged for long is another. Updates are a must. With related features and game content, we aim to keep them hooked. And give them a reason to keep coming back.
Our regular updates include bug fixes, new content, balance adjustments, etc.
Hope you enjoy playing as much as we did while building it from scratch.