Hey guys, this is the first entry in our series called "Making a Game". Hope you find them helpful!
If you really think about it, a game is nothing but two things:
#2: props (optional)
Rules can be written many different ways and props can be anything you use to play your game, be it digital or in meatspace. Because there are only 2 components, that means if your game doesn't use props, or if you already have them available (from looting other games you have on-hand), your game is complete and playable in exactly the amount of the time it takes you to write down the rules. Sometimes you don't even need to write them down! This is the fastest way to start developing a game, and developing a game is the fastest way to start developing a good game. Today I'm going to talk about #1 (rules) and how to get there as quickly as possible.
I was in a game development group at EMU. I showed up to my first meeting and they were trying to decide what kind of game to make. I suggested a board game, everyone else wanted to do a video game. It's not that I like board games more than video games, but the fact is that all a board game prototype requires you to do is write the #1 ingredient of your game (rules) in your native language, on whatever you have handy, to be interpreted by the most intelligent life forms in the known universe, with the creator of the game at their disposal to ask questions to if they get confused. For those keeping score, that's not a lot of overhead. A video game on the other hand requires you to define logic in a machine's language in a way that a computer can execute the rules that you are defining, and if you put a semicolon in the wrong place the whole thing is screwed and you have to restart the server, find your error, push your fix, redeploy, and all your friends don't give a crap anymore because "that took a half an hour Al and now we're going to play Super Smash Brothers." I say this as a professional software developer: the first one is easier. The game design club went with the video game. I finished 2 board games that semester. They finished 0 video games.
But Wait, Al
Why make it easy on yourself?? If you want something good, shouldn't you work to make it exactly perfect? If we're trying to make good games here, let's not be so selfish that we make the game worse for our own laziness! Well if you said that, that's a good point. However, that doesn't mean your starting point has to be so ambitious. There's a concept in software called an "MVP", and it relates to any product or service you are planning to provide. It stands for "Minimum Viable Product," and when they say "minimum," they're not messing around. The idea is that you want to start as small as possible and build and build until you have something that you're happy with. The problem with the game group at EMU was that they were starting too big! Their MVP was not even close to "minimum." They wanted to get into coding in the first week without learning if the rules worked first! Here's how the MVP solves that: pick a thing that you'd like to put in your game. Is it a good idea? Prove it. Do the least you can so you don't waste time and resources. The idea is that you can't know what you're doing in the beginning because it's unproven. The MVP gets you to proving those theories as quickly as possible. Can't release that game yet because the art looks kind of crappy? Prove it. Maybe people actually really like the artwork the way it is and you just saved 3 months of work! The MVP is a tool for learning, and it may not look like a game at all to start out. When we started work on The Origin, it began as a card game. That's right! We didn't care about making a video game yet because that's too much overhead before we start learning if it's a good idea. So we made the quickest, dirtiest, easiest prototype we could. To give you a sense of time, I thought of the idea for the game on the way back from Nick's weekly game night, and that same night prototyped the cards in an hour. This helped us see if our idea was fun first, and then we (slowly) tweaked and added on to our idea. Fun fact: it was a terrible game at first! But we realized that months before we would have if we had started with programming instead of making a quick prototype. Later, we got to proving that the game was better without a moderator (something we always suspected), and we wrote an app. If we were wrong, we could throw out the app and still have a good game without losing any of the work we put into the rest of it.
This is really just scratching the surface of the concept. It is invaluable for game design and for startups in general, since you have such limited resources as a company. For more information, I recommend the books "Lean Startup" and "Lean UX," and the Extra Credits video embedded below, "Fail Faster." EC does a great job explaining it. Check it out, and if you're into game development, subscribe to their channel while you're at it. They have some great content: