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.

Some Framing

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

Engines Used:

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:

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

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

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

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

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

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

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 newskills was to alter one central element for each new game. The new element could almost be anything:

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.

Example: Nivearum

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.

Example: You Don’t Know the Half of It: Fins of the Father

Several games mentioned in previous lessons wear their messages on their sleeves. As an example of what I mean by “every game has a message,” here is a game with a message buried deep. You Don’t Know the Half of It: Fins of the Father is about attention management in stressful situations. It contains complex fish-racing lore and tells a tale of redemption, BUT it forces all this information on the player as they race. It’s a double-edged sword: do you learn about why you race, or do you just race?

Ultimately, no matter how hard you try and no matter how much you know about the backstory, it won’t change the outcome. The game’s message is “You can never control everything or know everything. Enjoy the ride while it lasts.”

Tip: Think “could be,” not “should be” – Rather than assume a message should be told in a particular way, consider how different art styles and mechanics affect your message. Genres are ok for starting off, but don’t let them hinder your message because of what that genre “should” be. What trappings of a genre could be shed to support your message?

7: What You Enjoy Playing May Not be What You’re Good at Making; What You’re Good at Making May Not be What You Enjoy Making (or Playing)

There is a general assumption that if we enjoy playing a game, we would enjoy making games of that type, and it isn’t necessarily true. Nor is it true that we will enjoy making the games we’re good at making.

Yikes! Example: War on X-Mass

When I started making games, I didn’t have a genre in mind for what I wanted to make. With that said, I do love playing Real Time Strategy (RTS) games and I’ve learned that it’s a genre I stink at creating. This game was meant to be a riff on the war on Christmas idea, except it’s a war on the planet named X-Mass – it was fun to reinterpret “War on X-Mass” to mean a Starship Troopers-esque campaign on an alien planet. Admittedly, I enjoyed juicing up the game and art-ing it. I simply had less to offer here than I did with other genres.

Yay! Example: EnviroGolf

I never enjoyed playing sports games, but EnviroGolf turned out great, and I loved making it! Shown at EGX Leftfield Collection back in 2014, it was my first game to be covered in Kotaku.

Tip: Genre Explore – Try making games in genres you don’t enjoy playing, and make them into something you would enjoy playing.

8: Every Baby Can Be Thrown Out with the Bath Water

Anyone who wants to make games should be ready to draft multiple developable concepts. All game ideas will age, often not gracefully. Striving to make just a single game isn’t sustainable. We need to learn how to let go of our darlings, regardless of why. We’re all capable of concepting millions of darling ideas and none are sacred.

Example: Minianda Janes

A student project during my time at Miami of Ohio, the idea was “Lemmingsmeets Indiana Jones.” It wouldn’t matter how many Minianda Janes made it to the goal as long as one made it. Learning the engine GameSalad, I coded the game and led the student team. That alone made the experience valuable. However, classrooms can take a toll on projects due to myriad complications. While I loved the premise of Minianda Janes, it wasn’t sustainable beyond the class.

9: Fun is Bad

Fun is awful. It’s a garbage word, yuk. Some people think napping is fun. Some people think exercising is fun. Some people think spicy food is fun. Fun is a word that means something different to everyone. Opposite activities are fun to different people. It’s a bizarre open word, and one that is used as a signal of personal enjoyment more than an actual game quality.

A word that captures the essence of “fun” without the baggage is “engaged.” It means we have the player’s attention, regardless of if the game is sad, scary, happy, or anxious. To some people, it might be a meaningless semantic point, but it helped a lot when experimenting to conjure different emotions through games. We don’t need players to have fun for a game to be good: we just need players to be engaged.

Example: You Must be 18 or Older to Enter

Probably my most prominent game (and still banned on Steam), You Must be 18 or Older to Enter is a horror game about being a kid in the 1990s looking at porn for the first time. Even though it is horror, it forgoes the normal trappings of horror by omitting violence, monsters, and death. I wouldn’t call You Must be 18 or Older to Enter a fun game. It wasn’t made to be a fun game. I even hesitate to call it nostalgic. Who fondly reminisces about being a kid exploring adult topics, scared of being caught? Perhaps not fun, You Must be 18 or Older to Enter is engaging.

10: Release and Embrace Failure

Failure is ok, and more than that, it is good to release failure. Be it postmortems of failed games or playable builds of failed games, releasing failure is an amazing exercise in learning to let go. Without learning from mistakes, both our own and others, we’re bound to repeat them.

Example: X

Most of these 10 lessons were learned from failures, but one of the largest lessons I learned was from X. Consisting of 9 games from the 100, X was meant to be a creeping horror that encompassed a social media backstory as well as a series of digital games.

Time wise, it took a month to make all the components: 68 Tumblr posts that my fictional protagonist would post throughout June and July and 9 haunted games that he would upload in August. However, without hyping the horror or truncating the timeline, the clues were too mundane and too thinly spaced out. More so, to make it feel more real, I never associated with this project, releasing it under a pen name. The posts never gained traction as I uploaded them, and without a base, the project floundered. Even though these nine games were a failure in terms of my success formula, I’m glad I carried through and released X.

While I know how I would redo this project, the greater lesson learned was about reality checks, especially when personal attachment to a project is too great – and the importance of learning from failed experiments. Three months to learn this is lenient in the grand scope of things. And thankfully, rather than on a higher stakes project, it was something learned through the course of this 100 games challenge!

Final Tip: Enjoy Life

Game making can be incredibly rewarding. It can also be a stressful hell. Suffering isn’t mandatory. Although there were highs and lows, making 100 games in 5 years wasn’t awful for me. I am not a perfectionist and am predisposed to cranking out media. For example, I made 11 games the year before deciding to pursue the goal, I’ve written a few things that technicallycount as novels (they’re real page turners), and might have had a hand in a bad film or few. The challenge fit my nature, and even if I hadn’t set a goal of 100 games, I would have still created a lot.

Ultimately, do what YOU find rewarding, not what others promote as rewarding. If it happens to be games, I hope some of these experiences can help!

@Just404it