10 Lessons from Making 100 Games in 5 Years was originally given as a talk at IndieCade 2017. This is an adaptation of that talk.
It’s over! From June 2012 through June 2017, I made 100 games in 5 years.
Before we dive in, it’s important to have some framing about the 100 games in 5 years, why I’m writing about it now, and lend some quick numbers and facts about the games themselves.
Back in 2012, I considered the challenge a long-term safe strategy. I figured that, by the end of the 5 years, I would know for certain if game development was both something I would enjoy doing and something I would be good at doing.
I also knew that even if the games themselves were bad (many of which are), at least the challenge itself would be noteworthy. While I can’t say that I learned more through making 100 games than I would have on another path, 2012-James was right about a few qualities of the ambition. The 100-in-5 placed me in Forbes 30 Under 30 2017, solidified a well-founded design voice, and introduced me to more wonderful, insightful, intelligent games folk than I ever anticipated. I fondly call the goal “the smartest idea young me ever had.”
It’s important to mention that I was supported throughout the challenge. For starters, I was a student for the duration of it: first as undergraduate at Miami University of Ohio and then as a graduate student at the University of Southern California – institutions where teachers were profoundly helpful. The challenge was of my own design and my own volition, but it wasn’t self-funded, nor should it be seen as such. It did open doors and help me secure financial aid, but my parents and grandparents helped as well. In addition, there was a lot of encouragement and support along the way – more support than I will be able to repay.
To mentors, peers, parents, family, collaborators, players, and all: thank you for making this possible.
Why Write Now?
The final game was made in June 2017, exactly a year ago from when I’m writing and posting this 10 Lessons piece. Why wait so long? The honest answer: I needed a break – I needed time to collect my thoughts and adjust to living outside of the goal. Five years is a long stretch. Spanning from age 21 to 26, the challenge was almost a fifth of my life. That’s a lot of time to devote to rapid iteration!
Not to say I haven’t been busy since, it’s just been a different kind of busy, one with slower paces and real-world deadlines. Since the challenge, I have made a few games: 4 tiny ones. I’m also still working on eCheese Zone. In development for 6 months now, eCheese Zone is tied with You Must be 18 or Older to Enter and The World the Children Made for the longest development period I’ve spent on a single project. But now, on the anniversary of completing the 100 games in 5 years, enough time has ebbed for me to write about it.
A Few Quick Snips from the Outcome
- GameMaker Studio
In total, there were 12 analog games (non-digital) and 88 digital. Over 60 of the digital games were made with GameMaker and GameMaker Studio. While all free, a few allow donations.
Regarding donations, my goal with this challenge was never to earn from it. I had not considered monetizing the 100 until late in the challenge – as late as 2017. As of now, total donations (from the few games that allow it) have made less than $400. For the whole challenge, I was a full-time student, so game development was a hobby. Even so, I am happy to say that both Miami of Ohio and USC often provided travel grants and financial scholarships for my work, but it isn’t the same as actual income. As such, I wouldn’t recommend anyone to aim for a similar goal unless they have appropriate backing to do it – both social and financial.
Relevant here and to the lessons, the way I defined success was:
Success of a game = audience reception / (development time + personal attachment)
To be clear, this is how I defined success for these games – it isn’t an expectation to be projected on others. Gauging game development as a potential career path, it was important to have a tangible (albeit subjective) metric of success.Generally, one in eight exceeded my expectations.
For general trends with the 100 games, they were all small – the longest two, The World the Children Made and Innovative Food Company, take about 30 minutes to play. The majority are without menu screens or save systems. None have online multiplayer. Lastly, none of them were truly made alone. Be it direct collaboration, the use of an artist’s music, or through being inspired by others’ work, they all have community contributions.
VIP of the 100 games is my brother Joe Cox, who worked on over 40 of the games through art, design, or often music and sound effects (as I have no musical ability). We are now running our studio Seemingly Pointless and wrapping up development on eCheese Zone – a very rude crowd punishment party game, ow!
Additionally, something I had not anticipated from this challenge was the resulting interactive portfolio. I now have a strong body of working examples: experiments I want to expand and experiments I learned not to repeat. It’s easier for me to evaluate new projects based on this library of prior work.
Final Notes Before the Lessons
I learned these 10 lessons through this challenge – lessons that could potentially be learned in other ways, yet ones I picked up while making the 100 games. I hope they may be useful one way or another.
Keep in mind that I was making short form freeware games – experiences designed and built to be audience ready quickly. This development framework came about from my internal rule for releasing: I would only release a game when I felt it was complete. I had to be able to explain to myself how the game was audience ready. Therefore, I usually created games in quick compartmentalized stages – focusing on making a polished core experience before adding on extras. This way, if I had to stop development on any project, I could just release it. Many of my games had features cut in this way.
This method of development can easily clash with processes used to create longer games. For instance, it doesn’t navigate well with deeply intricate systems. As my focus was to make sure the game could launch after each additional feature, there was effort exerted into polish at each additional feature that would not be prudent to implement on larger projects until later.
The applicability of each lesson will vary depending on individual situations.Each lesson will be accompanied by an example or two from the 100. The number-of-plays noted in examples were current as of June 2018.
On to the lessons!
1: More Development Won’t Save a Game
Polishing and juicing a game that doesn’t have oomph early on won’t yield much extra oomph – You can only squeeze so much out of an experience that was already lackluster.
Yikes! Example: RUNNER
- 27th game of 100
- 2 months to make
- Only 158 plays
This game was a cross-genre experiment between idle games and infinite runners. You hold down the right arrow key and your character runs. As you beat each level, the track lengthens, the runner’s pace slows, and the wind resistance increases. Yet, the extra months of additions, new juiciness, and balance tinkering were not worth it. Early on, it was apparent that the game wasn’t going to be well received, but I had such a personal attachment to the idea, I pushed on anyways.
Yay! Example: Temporality
- 61st game of 100
- 4 days to make
- Jury select at Japan Media Arts Festival
- Bronze at Serious Play
- Official Selection at A Maze. / Johannesburg
- Over 34,000 plays
In Temporality, you only have A and D as input. D pushes time forward, A pushes it backwards; abstaining pauses time. Made in only 4 days, this game was already more solid than RUNNER and it wouldn’t require any extra work to communicate its message. Temporality was more emotionally powerful than RUNNER ever would be.
Tip: Limit the game’s length – Limiting playtime helps reduce feature creep and over-scoping. Temporality was designed to fit the length of a single 10-minute song. Though more time could have been spent developing Temporality, there is only so much you can fit into such a short experience without it becoming overgrown and ingrown.
2: You’ll Know if Your Game is Shaping Up Within Two Days of Prototyped Play
Once your core is prototyped, it will be exciting for you and others to play. The feedback given from all parties should communicate that they know what you’re aiming for. Otherwise you may need to rethink the experience.Yikes! Example: Par-T Babe-E
- 97th game of 100
- 7 days to make
- Only 31 plays
Within days of developing Par-T Babe-E, it was obviously not engaging for anyone, myself included. While people had feedback on how to improve it, their collective thoughts were scattershot and indicated that the game lacked focus and lacked an interesting core. Cutting losses, I stopped developing new content. However, rather than cancel the project, I pivoted. Truncating the play, the game became an experiment to test a new art style.
Yay! Example: Don’t Kill the Cow
- 3rd game of 100
- One month to make
- Over 61,000 plays
Within two days of developing, people were enthusiastic about Don’t Kill the Cow and had constructive parallel advice. They knew what the game’s message and goals were, and they had ideas to help focus and highlight the core play. In Don’t Kill the Cow, you must choose between killing a cow to feed a starving companion or resist killing the cow to win the game. Advice from early players was to add additional items – alternative food sources for the player to desperately offer to their starving companion instead of killing the cow. This idea was incorporated in the form of collectable offerings: water, corn, and cow dung.
3: Experimental is Better
This lesson is overtly shaped by my own journey as a freeware and indie developer. It isn’t a new concept for indies either – for instance, Nick Popovich of Monomi Park outlines similar thoughts in his GDC talk Slime Rancher: A Preemptive Postmortem. The general idea is that it is easier to carve out your own territory than compete with major studios. Invent your own genre and you will have the best game of that genre on the market. (We’ll deal with the idea of genres later).
Yikes! Example: Snake Pit
- 95th game of 100
- 1 week to make
- 36 plays
Snake Pit is a small endless-wave fighting game. The goal was to simplify endurance games to their bare minimum. Unfortunately, the micro-innovation of Snake Pit doesn’t save it from standing against all other games that occupy the same territory. There isn’t anything new in Snake Pit. Without a unique hook or experimental draw, it didn’t stand a chance. It’s easy to write a game like Snake Pit off without considering what went wrong. More so, how could a game made in a week go wrong? We have to remember that Temporality(example game from the first lesson) was made in fewer days, had less code, had simpler play, and still gained way more traction. The key difference is Temporality’s experimental nature.
Yay! Example: The World the Children Made
- 43rd game of 100
- 6 months to make
- Awarded Silver at Serious Play Conference
- Funded by an Undergraduate Grant
- Over 25,000 plays
An adaptation of Ray Bradbury’s The Veldt, the goal of The World the Children Made was to adapt The Veldt to an interactive format – an idea that suited the story well. At the time, there were no games (that I knew of) that pitted uninspired daily tasks against the draws of flashy virtual reality. As the game progresses, an in-game VR room slowly strips away the false freedom it offers, replacing them with grounded hostility. As such, The World the Children Madeholds traditional familiar game elements hostage as an atmospheric tool – all supporting the narrative which inspired it.
Tip: Even with experimental, don’t rely on weird; it’s unstable – Weird is volatile and hard to predict. For instance, Murder Clown, 42nd game of the 100, ended up with over 10,000 plays. Yet a lot of that came from an early Markiplier Let’s Play. On the other hand, Moist Curds (92nd game of 100) only landed 33 plays.
4: Rapid Development is a Useful Skill
Expanding on the Experimental Gameplay Project’s findings, I’d like to say that rapid development isn’t just a way of life. Rapid Development is a skill you can hone and practice. When you discover your rhythm and learn your strengths and weaknesses, you can create at much greater speeds.
My 9th game was An Occurrence at Owl Creek Bridge, released in 2013. It took 3 months (roughly 13 weeks) to develop, lasts for 5 minutes, and is a linear story with a single level – it is a walking simulator. With that said, it did critically well for such a small early game: awarded Silver at Serious Play Conference and shown at the inaugural Smithsonian Pop-up arcade.
My 46th game was Bottle Rockets, released in 2014. This game took 4 days to develop and plays for 6 minutes. It has 9 different puzzle rooms. Compared to An Occurrence at Owl Creek Bridge, Bottle Rockets only took about 5% of An Occurrence at Owl Creek Bridge’s development period and still yielded extra play time.
My 87th game was Innovative Food Company, released in 2017. Development time was 2 weeks. However, for those 14 days – a 350% development time increase from Bottle Rockets – it yielded 500% more play time with a solid 30 minutes of gameplay compared to Bottle Rockets’ 6 minutes, and it contained 60 puzzle levels, compared to Bottle Rockets’ 9.
Tip: Try something new in every game – A way I was able to keep increasing my development pace while learning new skills was to alter one central element for each new game. The new element could almost be anything:
- New theme
- New art style
- Unfamiliar code
This allowed each game to be a comfortable learning experience while still allowing for rapid development.
5: Feature Pruning is as Valuable as Your Core Content
Do not let time constraints prune features for you. Prune early and prune often. Each additional feature will muddy your message. Prune to make your message shine.
- 75th of the 100
- 1 month to make
Set in a frozen waste, the player must use a physical map to keep track of their location in the game. Originally, I had planned for the player to fight wooly mammoths and fend off other stranded. Yet combat would have only distracted from the physical map aspect. Forcing players to react to combat on the fly in Nivearum countered my goal of giving players time to mark up their maps. Pruning the combat strengthened the core play and shaved off a week, if not more, of development time.
6: Every Game Has a Message
Knowing what your message is will inform every other aspect of your game. Even if you don’t plan for your game to have a message, players will still draw meaning from it.