Every day I have a routine. I read a chapter from a book, I do some stretches/exercises, I eat breakfast, I practice Italian lessons with Duolingo, I play Wordle and share my result with my wife, I draw a doodle, etc. All of these don’t take up a lot of time, and some are designed to help me maintain or improve some part of my life.
So how do I improve my game design skills each day?
Recently I was thinking about how having a day job means that I have very little time left in my day to work game development, business development, or anything related to GBGames. Well, I think about it a lot.
But specifically I thought about how it also means I don’t have extra time to improve my craft.
Using a sports metaphor, my game development time is game time, and I don’t usually give myself practice time.
Using a different metaphor, I don’t usually let myself sharpen the saw as I am trying to take advantage of the little time I have to chop wood.
I need better metaphors.
Anyway, years ago (uh, ok, apparently 17 years ago?!), I realized that I didn’t have a lot of game design experience/skill.
10 years later, I thought about what the soft and hard skills of game design would be, but I didn’t have much in the way of answers at the time.
Hard skills are things you can practice outside of any context. Soft skills are usually built upon the hard skills.
Basketball players can practice shooting three-pointers over and over outside of the context of a real game. During a game, knowing when to take a three-point shot is a soft skill, which depends on reading the defense, knowing the shot clock, and keeping in mind the current score.
Game design involves a lot of that latter part. Changing a similar mechanic in two different games might result in two wildly different results, because each game can have complex systems that respond to those changes in different ways. Jumping in checkers works differently from jumping in chess, and so modifying how far a piece can jump would seriously impact the games, but importantly, the change wouldn’t be the same in each game. You would need to pay attention the context of the specific game.
And when you are trying to ship a game in the form of a commercial product, there’s usually only so much time to try things like changing how the mechanic of jumping works, especially when it impacts everything from level design, animation, etc.
Even if you are working on a game without schedule and/or commercial pressure, many significant games take a relatively long time to work on from start to finish.
That’s a long feedback loop to develop your game design skills.
Rami Ismail once suggested that making a game a week as “a challenge that forces aspiring developers to create a high volume of games. That is not the only valid way to gain experience, and it is definitely not reflective of the only type of games you can make. Regardless of what you want to make, going through the full development cycle frequently will make you better at making games.”
A week seems like a good timeline for creating and finishing a small game, for building up the experience of not going making games but also shipping them. A week isn’t too long, nor is it too short, and you can get relatively quick feedback about what works and what doesn’t.
Still, I want to do something daily, not just part of something daily.
When I wanted to get better at drawing, I gave myself the challenge of doing at least one doodle a day. My early doodles are clearly very different in quality to my more recent doodles.
Each day I learned more about anatomy or shading or line weight because along with my doodle I was able to quickly assess it and wonder how to make it better, and then the next day I tried again, maybe after watching a tutorial or reading some advice.
I want a daily game design exercise analogous to the daily doodle that I did to improve my drawing skills.
Ideally, it would be something that takes between 15 minutes to an hour, but still results in something tangible.
So I wrote a list of potential exercises. Some of these come from articles I found online, books such as Challenges for Game Designers and Game Design Workshop, and suggestions from others. I challenged myself to come up with 20 of them:
- Create as many game themes as I can in 5 minutes
- Write up a proposed improvement to a single element of an existing game
- 20 minutes: Create a game using only dice (with rulebook, UI/UX)
- 20 minutes: Create a game using only cards (with rulebook, UI/UX)
- 20 minutes: Create a game using only paper/pencil (with rulebook, UI/UX)
- Analyze a “bad” game, write what made it bad, and propose how it could be improved
- Keep a game journal – play a game each day and write about choices, feelings, and mechanics that support those feelings
- Try to change a 1-player game so it accommodates 2 players (or from 2 to 3 players)
- Revise a chance-based game to not be dependent on chance (Candy Land, War)
- Add hidden info to a game w/ open/perfect info; analyze impact
- Take a book/article – list systematic elements of subject (objectives, rules, procedures, resources, conflicts, skills)
- Deconstruct a game; analyze formal, dramatic, and dynamic elements
- Deconstruct a board game; watch people play it for the first time; analyze how they learned how to play
- Create a playtest script – intro, warm-up, play session, discussion, wrap-up
- Recruit play testers
- Add a constraints to an existing game
- Create a 1-page design (see this GDC 2010 presentation by Stone Librande)
- Change a board game’s dimensions (10×10 vs 12×12 or 6×6 chessboard)
- 20 minutes: grab a handful of random components from my game design prototype toolbox, play with them
- Use today’s headline to create a 1st iteration of a game using only one type of component (tiles, dice, cards, etc)
Out of all of these, I liked the last two ideas the most. 20 minutes is a very short time, and I don’t make use of my toolbox as much as I would like. However, unstructured play might be too unconstrained.
Having a daily news headline to work with and the goal of having a 1st iteration of a game completed in that time? It focuses things, plus I can imagine that some news items will be more challenging than others. It’s kind of like xkcd’s daily geocaching hashing in a way.
Yesterday’s news item from NPR was almost perfect as a first attempt at making a game ripped from the headlines: An astronomer thinks alien tech could be on the ocean floor. Not everyone agrees
Eight years ago, a meteor believed to have been 2 feet long entered Earth’s atmosphere at more than 100,000 miles an hour before exploding into tiny, hot fragments and falling into the South Pacific Ocean.
Some scientists believe it came from another star system, which would make it the first known interstellar object of its size to impact Earth.
Now, professor Avi Loeb, of the Harvard-Smithsonian Center for Astrophysics, is planning an expedition to retrieve fragments of the meteor from the ocean floor. By analyzing the debris, he is hoping to determine the object’s origins — even going so far as to make the extraordinary suggestion that it could be a technological object created by aliens.
Yet astronomers are wary of his claims, citing a lack of data on the object and insufficient evidence to support his bold conjectures about alien life.
If you read the entire piece, it’s got a needle in a haystack, science drama, a race against time, government/military secrets, and potentially aliens. Wow! If any news can inspire the creation of a game design, it’s this one. Thanks, Kai McNamee!
In my quick gathering of info, I also came across this excellent piece by Ethan Siegel called The Uncensored Guide To ‘Oumuamua, Aliens, And That Harvard Astronomer which talks about how Loeb is bizarrely very quick to attribute things to aliens despite the lack of evidence and seems uninterested in addressing scientific objections from astronomers.
So, I decided to make a game with highlighting and promoting actual scientific thinking as a goal. I picked the name “Avi Loeb Proves Them All Wrong” despite the fact that the game is about the lack of such proof.
The Game Design
To help me constrain the potential scope, I decided to grab the game Iota off my shelf. I could have used a regular deck of cards, but the cards in Iota have numbers, colors, and shapes, which give me some flexibility.
64 of the 66 Iota cards have a number (1 through 4), a color (red, blue, green, or yellow), and a shape (square, circle, plus, and triangle). Two of the cards are wild cards.
I wanted the player to be in the role of running Avi Loeb’s expedition, and the goal was to find pieces of the meteor and hopefully evidence of aliens.
I created 5 piles of 10 face-down cards each, and these piles represented the ocean that is being explored.
I gave the player 4 cards in their starting hand, and the remaining 12 cards were the draw pile, which represented the player’s funding.
Turn order was as follows:
- Draw a card from the funds into your hand
- Play a card from your hand
I ignored colors, and focused on the shape and numbers on the cards.
Plus cards revealed the top of the piles. A plus card with the number 3 meant that you can reveal three cards. If a pile already has a card revealed, you can’t reveal more from that pile.
Circle cards allowed you to take cards from the piles. A circle card with the number 2 meant that you could take up to two cards. Originally I restricted it to picking from different piles, but I decided to let the player explore a single pile deeply if they wanted to.
Triangle cards allowed you to “ignore evidence”, meaning that you could discard a number of cards from your hand. A triangle card with the number 4 let you discard 4 other cards from your hand.
Square cards originally let you take a card from a pile and reveal the next one, but I decided that square cards represented finding nothing, and they did nothing when in your hand. By the end, I wasn’t sure if I should make them more useful.
I didn’t know how to “win” or “lose” the game yet, but after a couple of playthroughs and rule changes I was reminded that there were wild cards, and so I decided to make them the actual meteor pieces. There are only two of them, so they should be hard to find. I had to ensure that the rules specified that they were shuffled into the ocean part of the deck and not in the funds or the player’s hand.
I decided on victory and loss conditions. The player wins when they collect the two meteor pieces, but loses if they use up all of their funds before then.
Then, to make it more in keeping with the theme about scientific rigor, I wanted the rules to require that in order to convert the wild cards to evidence, you would need to add up the sum of the numbers on triangle cards to at least 4. That is, you could use a single 4 triangle, or a combination of 1, 2, and 3 triangle cards. It required potentially more cards to accomplish and therefore was more difficult. I think.
So triangle cards served two purposes and worked slightly differently depending on if you were ignoring evidence or finding evidence.
Now, why would you use triangle cards to discard cards and ignore evidence? I tried to change the loss condition so that if you have in your hand a combination of 4 of the same number, shape, or color cards (four blue cards or four 3s, for examples), then the evidence was overwhelming and you lost.
I decided to ease up because it was too easy to collect so many cards, and instead if you end up with 4 of a kind, you automatically discard those cards, as you are ignoring the overwhelming evidence in front of you.
But you can use triangle cards to get rid of the cards you choose so that you aren’t forced to discard cards you want to keep.
So in the end, I had a game about exploring an ocean to find evidence of alien technology before your funding runs out, and the need to ignore the greater scientific community’s data to make it possible.
Game Design Lessons from Avi Loeb Proves Them All Wrong
I was able to quickly put together some mechanics that seemed straightforward enough, and the core of drawing a card and playing a card was constant. Effectively, this exercise had me explore a game based around those two actions, and primarily the second action.
On the other hand, I wish I had started with a smaller set of cards. Iota has 66 cards, and I used all of them. It was a bit unwieldy and might have obscured the dynamics because I was simultaneously dealing with figuring out my rule changes AND with the existing how it interacted with the sheer quantity of shuffled cards.
When I had what seemed like an interesting set of rules, I ran into the problem of the game not ending satisfactorily and being too random, so some games were over almost right away and some took forever to end. Having fewer cards might have helped me iterate more quickly.
I tend to start too big. In earlier tile-based games, I would have a what i now see as a massive grid, something on the order of 64×48 or whatever I could fit on a screen.
So the next time I decide to make a tile or card game, I will try to limit the quantity of cards. Maybe I will start with only 10 cards total, and I can always add more if I find it too limiting.
The game also felt too volatile. You are basically guessing what part of the ocean to explore, and while plus cards might make it easier to see what’s available, it is still a very limited view, and you might not get a lot of plus cards in your hand at any given point. I might have been able to ensure the wild cards were near the bottom half of a given pile so that they wouldn’t pop up right away, but it was still random which pile they were in, and with only 12ish turns, you aren’t likely to find them unless you get lucky with circle cards.
In the end, I spent way more time on this game than I intended. I ignored my time constraint completely, so instead of it being a 20 minute exercise, it took much longer. I don’t know, as I didn’t track my time, and part of my time was spent recording my experience here in this blog post.
I know I had a quick initial iteration, and maybe that’s where I should stop for future exercises. Perhaps I should set an actual 20 minute timer, and put my game design tools down at the end, encouraging me to make tighter iteration cycles as fast as I can in that time.
Whatever tweaks I might make to the exercise going forward, I believe I might have found a new daily habit that will help me improve my game design skills.
