Building a Game - the 80/20 rule of game developement
Summary
This is to cover most of the things required to create and release a mobile game. I'm not talking a triple-A title, just a complete game that can sell, and hopefully take off and generate revenue. I have completed and released about 5 games as solo efforts, 1 as a team effort, and contributed to an online game that released after I had left. The focus of this is on the solo indie developer trying to create a game all on their own.
Introduction
First off, it's a lie. None of my solo efforts have been truly solo. I have recruited friends and family to playtest and get feedback on concepts. And that's a good thing! I may have done all of the coding, created all the assets, etc, but all feedback along the way from others is invaluable. It is a a generous gift from them. Even if you don't like the feedback, it is likely still valuable. It all depends on what you do with it.
Second, on every "solo" game I have released, I noticed the 80/20 rule is very much in effect for me. For me, I’m having the most fun when I am coding the gameplay for a particular game or concept. Make a change or two, try it out, then either pivot or keep it. I like solidifying the gameplay early to be able to quickly determine if a game is fun or not. I figure there is no point creating all the artwork, sounds, menus, instructions, etc if the core gameplay isn’t fun.
The part that is the most fun, comes very early in the project. It feels like you have a solid game. It's fun, and it is nowhere near ready to be released. 20% has been done, 80% of the work remains.
The 20%
I love coming up with game concepts, building something and exploring what aspects are fun, and discarding or refining the aspects that aren't. One thing I have learned along the way is that "fun" has to win. Realism means nothing if it isn't fun to play. Well, it does mean something. It means that you will have wasted a lot of time and effort, and will likely get shredded by reviews.
The concepts can be specific mechanics, how to implement a specific effect, a new game, whatever. This is when I am having the most fun. I like the concept of gray-boxing things to test out ideas, but I typically take it a step or two further. Either coloring the boxes or using an emoji symbol to at least give things a little flavor with no effort. I like that for me, but there is value in sticking with literal gray boxes (or cylinders).
Depending on when you show a concept to someone for feedback, if you only use gray-boxes it is a strong visual indicator that the focus is on game play. It is obvious to people that they are not seeing the final graphics. With my method, some people kind of lock on to the graphics and struggle with focusing on game play. Like with anything, there are always tradeoffs.
So, life is good, you've coded your game. The mechanics are fun. The controls/interaction is pleasing. It really feels like you have a successful game on your hands. You can't wait to get it out there and have millions of people enjoying your creation. There is only one little problem.
The 80%
Rest assured, there is still coding to do. If you only enjoy the coding, you can find some comfort in that. Here is a list of things in no particular order that make up the remaining work.
- A splash screen
- Main menu (and any sub-menus)
- Instructions
- Configuration settings
- An in-game tutorial
- Final artwork and animations
- Sound effects
- Designing
- Recording
- Editing
- Music
- Composing
- Recording
- Editing
- Achievement system
- Designing how they are earned
- Coding
- Artwork
- Monetization
- Design (such as ads, in-app purchases, special offers)
- Coding
- App Store configuration
- Marketing
- Game trailer
- Website
- Social media posts
- Game dev blog (I couldn't resist listing this one)
- App Store submission
- Screenshots
- Initial config and legal stuff (if this is your first release)
- Build pipeline
- An in-game hint system
- Usage stats to profile gameplay and make improvements
- A/B testing things
- And a whole lot of testing
The list above is not intended to be comprehensive. A lot of subtle detail has been left out intentionally. (Some foreshadowing here, a lot of the items listed above are worthy their own blog articles.)
As an example of something left out, perhaps you have some in-game text. If you are launching in multiple markets, you will likely need translations. Once you get the translations done, you now need to test everything in every language. Translations are often different lengths and may or may not fit in allotted ares (like a button), or even if contained by auto-scaling, be too small to read on the target device.
All of this stuff takes time. Cumulatively, a lot of time. In fact, approximately 80% of the total time. The problem for me is that while necessary, I don't find it particularly enjoyable. Some of it is definitely a grind.
| Fun 20% | Less Fun (80%) |
|---|
Project Completion
This isn't meant to discourage anyone. Quite the opposite. The key I have found to driving forward is the finished project. The nice thing about game development is that you can immediately see progress. As I complete a task, I get almost instant gratification seeing it in action.
Like if you create a new or better sound effect, you can plug it in, and experience the results. Hopefully in just a few seconds.
I find that having a to-do list with the things listed above keeps me thinking about them as they often affect other parts of the game.* For example, monetization can affect game design. Perhaps you can purchase a specific tool as an in-app purchase. That requires artwork, coding or data adjustments for how the tool operates, and can lead to having to re-balance parts of the game.
I try to put myself in the right mindset, then focus on a particular area, such as sound-effects, and complete them all at once. Marking the item as 'done' feels good, as you know you have made concrete progress. It feels like this blog post just became a little pep-talk for myself.
* = You can use a ticketing system if you want, but if it is just you, a simple text file works. In fact I like it a lot better. I can quickly scroll through the entire list. I prioritize items by moving them up and down in the list. When an item is complete, I write "DONE" at the front of its line, and move it to to the bottom of the list. If I have several related items, I will group them with indentation. Sometimes I cut features or defer work and I put "CUT" or "DEFER" at the front of the line accordingly. I try to break down peices of work into very granular pieces, so the 1 line description includes the acceptance criteria. This is a lot easier as a team of 1, but I have to be careful of not being granular enough when I come back to something after a month. The description always has to stand on its own.