Three Tortoises:

Three Lessons I Learned Making my First Three Video Games

At the beginning of last year, I put “Make a video game” on my list of New Years’ Resolutions. As of about a month ago, I’ve made three.

Each of them starred a tortoise character I created for a series of daily micro-fiction called koan of the day, and while all three of the games use the same assets, they feature entirely different game mechanics.

Making each of these games, I learned a lesson about game development, and I want to share these lessons with you so that you can learn from my successes as well as my disappointments.

Hopefully, this article will help aspiring gamedevs make their first game. One thing it won’t do, however, is teach you how to code. Fortunately, there are tons of articles about that online, and if you Google, you’ll find them.

Tortoise One: Tortoise Trails

Too often, when people want to make a game, they want to make a 3D first-person MMORPG with a realistic economy.

That’s fine to have as an ambition, but you have to realize that this simply can’t be done without years of experience, a team of talented and dedicated people, and money. Loads and loads of money.

When World of Warcraft was made, its budget was $40 million. And since then, Blizzard has spent more than $200 million on it.

So, put your MMORPG ambition aside for a moment, and figure out the simplest game you can possibly make. What assets do you have? If you can draw, incorporate the art. If you’re a musician, incorporate your music.

For my first game, I initially used only five sprites, which I found online under appropriate licenses. They are featured to the left there.

I am not a good artist, so it was important to make a game that avoided animation. Also, I felt that this produced a nice minimalist aesthetic, which I wanted in keeping with my koans.

That aesthetic minimalism is reflected in the game, as well.

The game randomly places a bunch of trees on a map, and then sets you out to find lettuce. There is no timer. There is nothing that can hurt you.

To make it a little more engaging, I added a procedural music generator that plays when you move. I thought this was a great way to use my rudimentary musical knowledge. And I also hid three sunflowers in special places around the game, because I’ve always been a fan of Easter Eggs.

This is the whole game. It’s gentle, relaxing, peaceful, and far too simple to be that fun. But, most importantly, I did it. I made my first game. And I called it tortoise trails.

So, my first lesson: Keep it small and simple.

By keeping my ambitions simple, by making my goals attainable, I was able to make a game and put it out there and learn from my successes and my failures. Here are some additional lessons I learned from this game:

  • People need some sort of stakes to make a game interesting. This game, with no timer or way to fail, was simply too easy.
  • Hiding sunflowers was a fun way to encourage people to spend more time investigating the game and to reward those who did. I love the experience of finding secrets, so I wanted to put that in the game.
  • Google problems. Look at source code for other games. Post questions online. Interact with other people. And tweet about your game.

It’s very easy to have huge ambitions for your first game and want to pour every single idea you’ve ever had into it. But you have to keep a check on this drive, or you’ll never actually make a game.

Tortoise Two: 60 Shells

For my next game, I wanted to make something hard. A friend mentioned that she had been playing hidden object games, and I had the idea of hiding the tortoise sprite from the first game in the tree sprites from the first game.

This way, I could reuse the same assets with a new mechanic, to see if I could make a completely different game out of them. And since my first game suffered from being too easy, I wanted this one to be hard.

I went through several iterations of the basic game mechanic until I hit upon one that seemed fun and challenging: you would attempt to find and click on the tortoise 60 times in a certain amount of time. Clicking the tortoise gives you bonus time, but one incorrect click ended the game.

Since, in some levels, it was difficult to find the tortoise, I gave the player three heads of lettuce that they could click on, revealing the tortoise.

This gave players a difficult decision in levels where they can’t find the tortoise: do they keep looking, wasting valuable seconds, or do you spend one of your three heads of lettuce?

Additionally, I added a rising tone for each correct click, so that whenever you found a tortoise, the tone went up a little. I remember this from an article by a Peggle dev on how to make games more addictive.

And, when you finished the game, instead of just displaying a high score, the game gave you a little quote from one of the koan characters. This gave people a reason to tweet their scores and, at this point, I could have used any of the following as the ‘lesson’ for this game:

  • Reuse code, assets, whatever you can. The more you can borrow from your past games, the quicker you can make future ones.
  • Create meaningful play through difficult decisions.
  • Have friends play the game to see if they understand. Players will never understand or play the game as well as you do.
  • Use music to engage and have tones rise when the player is doing something good. This is a way to explain things to the player.
  • Make game goals very difficult, but seemingly attainable. With 60 shells, all you have to do is click tortoises. But when you try to do it, it’s much harder than it seems.

But that wasn’t the lesson. Because, when I was iterating the game, I had an idea: it was so difficult to click 60 tortoises, that I thought people needed an extra push to accomplish it.

So I decided to offer a cash prize for anyone who beat it.

But instead of giving the cash to the player, I decided to donate it to charity. I did a bunch of research to find the perfect charity, and I ultimately chose American Tortoise Rescue, for three reasons:

  • They’e local, so I could actually visit.
  • They’re small, so I could talk to the head honchos.
  • They’re totally tortoise-focused, which fit my theme.

I recommend these three criterion be met whenever you raise money for a charity. If the charity is too far away, you have no way of knowing if it’s legitimate. If they’re too large, you won’t actually be able to make an impact. And if their goals are too broad, people won’t get excited about it.

Because they fit, though, I was able to tie my game to a larger issue, bring awareness to a cause, and make my players feel good for playing. I thought this would cause them to share it with others, and I was right.

The game was shared and reshared on tumblr. It made the frontpage of /r/gaming. People tweeted about it a lot. The game was a huge success, for me: more than 40,000 people played it in the first week it was released.

So, my second lesson: Make your game about something.

Once I had finished this game, the idea of a Tortoise Trilogy began to percolate into my consciousness. I had reused the same assets once to create an entirely different game. Perhaps I could do it again.

Tortoise Three: Lettuce Walk

There is an arcade in Heaven.

It has the most amazing games you’ve ever played, games that challenge the art form, games that transform your notions of what it means to be a game, and you’ve never played a single one of them before.

This is the Hall of Unfinished Games.

So many people start games, get halfway through, and never finish them. It’s so much easier to start a game — to mock up a prototype or draw a couple of sprites — than it is to finish it.

When you start a game, it’s all possibility. But when you start to close in on the finish line, it’s all failures and missed opportunities. But you have to finish your game. And you have to release it.

This was what I told myself as I worked on my third tortoise game: Lettuce Walk. It was a procedurally-designed Knight’s Tour. You had to get your tortoise from a starting square, to a head of lettuce, and back to the starting square without landing on the same space twice.

The more I fiddled with it, the more time it took.

I wanted to make it hard and easy. I wanted you to be able to play through it once, but get a less satisfying experience than if you had played to its fullest capacity. So I made it possible to return home before you have landed on every square, and instead of earning a head of lettuce, you earn a head of cabbage. I added a moon that you could land on that gave you do-overs. I had the end of the game procedurally generate a poem. I wrote a short story for the game manual.

I improved the graphics, taking the game from this:

To this:

With each one of these additions, I felt I was improving the experience of the game. Yet still, when I played it, I had the slow realization that this game just wasn’t fun. When I had people play it, they remarked on the music, the design, the ethereal feeling of it, but they never said it was fun.

The puzzle was simply too cerebral, and I couldn’t figure out a way to make it intuitive and fun. Instead, it was the kind of thing you needed a pencil and paper to solve. And so, with each addition, I was simply dressing up what was ultimately a middling game.

At this point, I had three choices:

  • Continue to re-imagine and revise the game forever, searching for some mythical point where the game would magically become Super Awesome.
  • Abandon the game forever.
  • Just release it.

For the longest time, I let it languish on my hard drive and I worked on other things. But finally, I decided to just finish it off, fix the last few bugs, and put it out there. Here it is.

It didn’t go over great. But I got it out there. And I got valuable feedback. And now it’s done. I don’t worry about it anymore. I don’t feel guilt about not releasing it.

In fact, I’m fired up about my next game. Putting it out there freed up a chunk of my time and my brain that was otherwise focused on polishing this one game. Releasing a game doesn’t just give you valuable feedback: it lets you focus on other things.

And Finally…

These were the chief lessons that I learned from these three games, but they weren’t the only ones. Here are some more:

  • Players will look at your game profoundly differently than you will. They will not understand the controls unless you explicitly explain them. They will not intuitively understand what makes a puzzle interesting. They will not indulge themselves in your game unless you make it fun.
  • Music and sound effects change everything. If you’re not putting music and sound effects in your games, you might as well be making silent films. You might as well be painting on cave walls. In short, juice the game.
  • Get your game up and running as soon as you can, and then play test everything. Watch your friends play your game. You’ll be surprised. Ideas that are great in your head are often bad in execution, and you won’t know until you try it.
  • Put whatever skills, knowledge, worldview, personal philosophy, or anything else you possess into the game. If you have a friend who is a brilliant artist, ask if he’ll draw the sprites. If you know a talented musician, ask if he’ll compose (or contribute) the score. Collaborate!
  • Do not be afraid of people stealing your ideas. People will not steal your ideas. If your ideas were good, you would be rich already. Your ideas are probably just as good as everyone else’s. Much more common than someone stealing your idea is someone having the exact same idea at the exact same time but then beating you to the release.

I hope that these lessons help others in making fun and engaging games. Games are one of the basic activities that unite all people, and video games are increasingly becoming the dominant mode of consumed art.

Movie attendance is down. Reading is down. Nobody listens to the radio anymore. But games are ascendent.

And that might be the biggest lesson of them all:

  • Make games. You won’t regret it.
One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.