2Hops was a personal project that served as a learning experience for myself to learn Unity and an introduction to game design. I designed and developed the game. I used and credited Kevin Macleod for using his music licensed under a Creative Commons License.
Why did I want to make a game?
Video games are a culmination of art, design, and technology, which was a perfect opportunity for me to leverage my background in painting, graphic design, and programming to work on something from start to finish that was all my own. It took me about 14 months to ship 2Hops on iPhone and Android platforms in February 2016.
Note: Since Apple requires a fee to keep apps in the store every year, I decided to remove 2Hops from the Apple Store. You can still download 2Hops at on the Android Store.
Title screen for 2Hops.
Before I started making a game, I needed to answer some important questions.
What kind of game was I going to make? Was it going to be a puzzle game, a action game, or narratively driven one? What platform was I going to build it on? And what engine was I going to use?
Being my first game, it needed to be small in scope and I wanted to target the largest audience possible: mobile gamers. That meant using Unity, which is a lightweight engine perfect for that purpose. I decided to design for the most tried and true genre: platformers. How to do it right and wrong is was well understood since the early days of gaming.
Prototype level built in Unity early in development.
Knowing what kind of game I was making and with what tool, I needed to get prototyping as soon as possible.
Game design was about quick iteration. After all, there's really only one way to test if your idea works, and more importantly, if it's fun. I got a quick prototype done in a weeks time and it answered a few things for me: Could I leverage touch controls to make a platformer? And could I make it possible to play with one hand--an important rule to thumb among mobile game designers. Answer was yes and yes.
Proof of concept built in Unity.
As I started designing more complex levels, the gameplay didn't feel right.
Classical platformers are fast, skill-based games that required quick reactions from the player. However, the input model had implemented didn't lend itself to this type of gameplay. I implemented another model that leveraged the gyroscope to move the player. The result was something more reminiscent to classical platformers. However, the compromise was this method did require two hands to play, but I believed it was worth it.
Tap and drag movement model was slower than classical platformer gameplay.
Tilt movement model enabled quick, reflexive movement and air control.
Level designs can be teaching moments, introducing controls and game mechanics.
I designed my levels in groups of three. The first level introduces a new game mechanic in a safe environment where failure has no consequences and the player is free to learn. The second level is uses this same mechanic in a more difficult scenario where failure means the player must restart the level. The third level leverages this mechanic in a unexpected way. The levels that follow will build on top of this mechanic that the player has now learned.
In the first of three levels, the first level introduces the new mechanic of falling platforms in a safe, danger-free environment.
The second level introduces consequences for failure if the player doesn't traverse consecutive falling platforms over a gap.
The third level unexpectedly requires the player remain on the falling platform for a time before jumping to safety.
Always have a little wiggle room.
An unpleasant feeling of unresponsiveness is very apparent without some element of forgiveness. The first being what's called edge forgiveness. The game tracks when a player is on the ground and thus able to jump. This check happens every frame, or 30 times a second. When a player attempts to run and jump at the edge of a ledge, he may over step an edge by a frame, fall, and die. The result is a feeling of responsiveness. It's typical to add one or two frames of buffer before registering that a player has left the ground to avoid this feeling of unresponsiveness.
In order to give some leniency, players could jump a bit late after leaving the ground.
Things I wish I did better: Compromises and difficulty.
Remember when I said that the compromise to switch to a control model that required two hands was worth it? I’m not so sure post-launch. Outside of games, there often aren’t times when a phone apps requires you to use both hands, and it’s a bit discomforting when having to suddenly do so. In addition, context which my game couldn’t be played included riding the bus, lying down, perhaps in public because you look ridicous tilting your phone around.
But the larger problem was the difficulty curve. When making a game, get it in the hands of someone else as soon as possible. I played my game from beginning to end numerous times, worried it was too easy. But the opposite was true. I learned this the hard way when I received feedback that the game was too difficult right from the beginning. Few players got past the second level.
Again if you want to try out the game you can find it in the Android Store.