You Can Make a Mobile Game
13 Useful Tips for Making Your First Game
I’ve wanted to make a game for many years. About six months ago, I finally buckled in and dedicated myself to fulfilling that dream. After many late nights and early mornings, I now have an iOS puzzle game called SERO in the App Store. As with any new adventure, I had difficulties along the way. After reflecting on what went well and not so well, I thought others could benefit from what I learned.
This is not a “how-to” or development focused article. It’s the article I wish I had read before starting the process of learning a new programming language and trying to build a mobile game.
So, if you want to make a game, either on your own or with a small team, keep reading!
1. Get inspired
I was able to finish SERO because I was inspired and motivated. I spent a fair amount of time searching for inspiration and finally found it in a childhood drawing. The drawing depicted a contraption that allowed balls to run through tubes, fly off ramps and bounce off walls. As a kid, I was fascinated by chain reactions. My favorite game was Mouse Trap.
I have fond memories of making these types of drawings and always wanted to create some sort of elaborate contraption. I really liked the idea of fulfilling my childhood dream and was able to use that as motivation when things got difficult.
Things WILL get difficult. Make sure you have something important to hold on to when you feel like giving up. If you need some extra motivation, I highly recommend checking out Steven Pressfield’s The War of Art.
2. Learn as you go
Design and development skills along with an understanding of game theory will certainly help when making a game. Having said that, you can develop your skills along the way — that’s what I did. I’m a designer who works on applications and software (not games) and had no experience with Swift. If you’re motivated and put in the hours, you can do it.
My weakest skill was programming so I didn’t worry about creating clean code at first. It was frustrating at times (that’s putting it lightly) but I didn’t need to invest a bunch of hours learning things that didn’t apply to what I was making. I wasn’t learning Swift, I was making a game.
3. Start with paper then move to code
If you’re not a designer or artist by trade, it’s OK. The key is to explore — don’t try to sketch final designs. I used maybe 5% of what I sketched. It’s not the actual sketch that matters, it’s the exploration it facilitates.
As soon as I had sketched some basic ideas, I jumped straight into code before making any high fidelity mock-ups. This strategy helped me in three ways:
- I learned Swift by starting small and focusing on core functionality.
- I received immediate feedback on what I could build in a short period of time.
- I had early prototypes I could test to help refine gameplay.
Once you start coding basic functionality you’ll immediately discover ways to make your game better. Let your experiments in code influence your design and don’t be afraid to explore multiple directions.
4. Keep it simple
Save the fancy stuff for game number two or three. Limiting your scope allows you to focus on key interactions and really make them great. The more things you have going on the more likely something will go wrong (bugs, development roadblocks, confusing interactions, etc.).
5. Test on a real device
Everything looks and feels much different on an actual device. On screen device previews are great for debugging multiple devices but not for refining core interactions. Plug in a real device and preview it there.
6. Don’t plan the whole thing
My brain went on overdrive trying to create a clever storyline for SERO. I studied the hero’s journey and planned dialog between multiple characters. My initial storylines were not impressive. I gave up and continued working on the game without a solid plan.
The idea of telling a story in the form of quotes came to me after I’d been working on the game for nearly 4 months. Once the idea came, I knew it was exactly what I was looking for — simple and mysterious.
Don’t try to figure everything out at once. Making a game takes time and you’ll have plenty of opportunities for those “Eureka!” moments.
7. Switch up your focus
To help avoid burnout, I switched back and forth between design and code multiple times. I’d spend maybe a week focusing on one task (design or code) at a time. Not only did this help prevent burnout but it allowed happy accidents in code to affect my designs without needing to rethink everything.
8. Don’t use code as a band-aid for bad design
Once I got more proficient with Swift I caught myself trying to solve problems with code, not design. Always use creativity, not your coding skills, to solve problems.
Example: In SERO, a key piece of feedback was given using sound. If the device was muted this feedback was lost. With code, I attempted to detect if the mute switch was on so I could present a message saying something like “Please turn on your sound.” I spent hours trying to implement this without success. After wasting an entire day of work, I wen’t back to the drawing board and came up with a way to present visual feedback along with the auditory feedback. It actually ended up working better and was much easier to implement.
9. Test, early and often
Games open up a whole new realm of interactions that need to be tested to ensure they actually work. My advice is to test your game sooner than you think you need to. Let people play with your early prototypes and pay attention to the issues that arise.
Example: My Dad asked how things were going with the game I had been spending so much time on. Since I had gotten into code early, I had a very basic prototype on my phone. I handed him the phone and let him play without any explanation of what to expect.
As he played, the entire concept fell apart. In SERO, you use shapes to bounce a ball (i.e. SERO) and collect spinning triangles. Once all the triangles have been collected the end target (a door) opens and you can enter. Simple, right? WRONG. My Dad didn’t understand this at all and further testing revealed others struggled with it as well.
I realized there was no obvious connection between collecting triangles and opening the door. To fix this, I added subtle triangle shapes above the door and lit them up as the main triangles were collected. This helped connect the two elements for the player.
10. Don’t forget about iPhone 4…
After months of work, I had finally finished SERO. When I clicked “Submit For Review,” I got an error saying I needed to upload screenshots for a 3.5" screen size. What? But I didn’t make this for a 3.5" screen size…
As of right now, you need to support the smaller screen size or Apple will reject your app. My advice is to not worry about iPhone 4 right away but to test on multiple screen sizes once your game has taken shape and you’re no longer prototyping.
11. Make it universal
After launching SERO, I did a bit of research and learned that making your game universal (optimized for both iPhone and iPad) opens a lot of doors. Apple (and other sites) love featuring universal apps because they are accessible by more people. If Apple promotes an iPhone only game, they’re loosing a spot to feature a universal app that could be downloaded on many other devices.
After SERO was in the App Store for a few weeks, I went back and updated SERO to work on iPad. It was a frustrating process and would have been much easier if I had tested on an iPad earlier in the process. My recommendation would be to start with a solid prototype on one device, then expand it to work on all devices you want to support before building out the game.
I’m really happy I did make SERO universal — it turned out to be super fun to play on iPad!
12. Use TestFlight and collect quantifiable data
TestFlight is an Apple app that allows people to download a beta version of your app on their personal device. All you need is someone’s approval and the email address attached to their Apple account to invite them. To really get the most out of testing you need a way to collect quantitative data (in addition to qualitative data) from your participants. This could be time played, level attempts, high score, etc.
Example: Once I was ready to send SERO to a larger audience for testing, I realized I had no way of knowing how well they were doing other than what they told me. I went back into code and added a way track the number of attempts it took to complete each level. After a couple weeks of testing with TestFlight, I asked all the test participants to send me a screenshot showing their attempts.
13. Don’t be afraid of the approval process
If your game gets rejected, just take the feedback and fix it. It’s not uncommon to be rejected once or twice. The overall submission process is pretty simple and painless. Approval times vary so I used this website to gauge how long to expect.
Also, make sure to follow tip #4 and keep it simple. If you’re dealing with user accounts or in-app purchases it’s more likely you’ll need to make tweaks before being approved. Start small and add complexity later as it’s needed.
Bonus Tip: Have a loyal companion
Trying to balance family time, work, and a large side project was difficult. There were plenty of late nights and early mornings. Having a loyal companion helped me stay sane.
Here is the official trailer and you can see more gameplay here: