I’m making a tycoon game about raking leaves. At first, it was slow going, partly because I lost focus on what I was really trying to accomplish, and partly because I was treating it’s development as something that needed to be fully formed from nothing.
Then I realized that most of the player interactions are menu based, and the GUI and related content would be independent of the game play itself, which is going to be geared towards the development of the invisible economy and the player’s feedback related to the consequences of his/her actions.
I normally think of prototyping along the lines of my handy-dandy physical prototyping toolbox, in which I use paper and drawn lines with wooden pieces and stones to represent objects. I could prototype menus on paper, which I think would work well for getting the feel of the GUI, but I don’t think it would work as well for what should be on the menus in the first place.
So I’m creating a command line version of my game. The UI is fairly stripped down, and it’s easy to code. I just accept input as numbers, and the relevant choices in a given menu are processed. Simple.
And effective! I was surprised what only a few hours of development churned out. I even have a basic weather system in place.
MAIN MENU
1: See neighborhood
2: View inventory
3: View weather report
4: Quit current game3
Today: Mostly cloudy with a 86% chance of rain
Tomorrow: Mostly sunny with a few clouds with a 15% chance of rain
I can quickly play the game as it is being developed because build times take mere moments. I’m spending time designing rather than coding infrastructure because the infrastructure is so lightweight.
But what about the bigger design decisions?
In this tycoon game, I had a general idea of the player being able to set a rate, do some work, and get paid for it. Simple, right?
But when I started to play, I realized this simple idea has a lot of unanswered questions. Do you set your rate before you get clients? Do you set it on a client by client basis? Do you charge hourly, or for a finished leaf raking job by the size of the yard, or is it a static rate? Does the game track time in hours, meaning you need to decide which yards to work on in a given day based on how long they take, or in days, so your decision is which yard you tackle on a given day?
This is a core decision that determines how the game will be experienced. It’s terrifying because this decision basically says what the game won’t be like. You can’t include all of them because they’re mutually exclusive, and you can’t put off the decision because without it, you have no game.
How do you make such a decision?
I have criteria to measure my options against, such as whether or not the option fits my design goals. An educational game would play differently from a physics puzzler. But what about deciding between a number of options that all seem to fit the higher level design?
In Lemonade Stand, you set the price of a glass of lemonade before the day starts. Then you start the day, and you find out at the end of the day how many glasses people bought and how much income you got.
There’s no haggling. There’s no adjustment during a given day. It’s a simple abstraction to a real life situation and quite accessible to the children it was geared towards.
But since it’s a game, it could have gone in any number of directions. The game could have had you interacting with each individual customer, making many minor decisions such as how much to fill each glass or if you should charge someone more or less. It could have become a higher fidelity simulation, but it would have been more difficult to play. It would have been a different game entirely geared towards a different audience.
Similarly, as a designer, I need to figure out the course of my game. I could see this as a huge decision and go through a lot of analysis about which is best before picking a direction, and even then I can only hope I made the right choice.
But I could also just try all of them and see what happens.
When prototyping, a cheap and quick implementation allows you to experience the real thing instead of wondering. You could implement the simplest solution, see how it feels, and either add to it and tweak it or discard it and try something else.
Maybe I’ll be surprised at how the simpler solution actually feels perfectly fine, or maybe I’ll discover that two different approaches are just variations on the same design. Maybe I’ll decide on an approach, but after developing a good amount of the game around it, I decide it doesn’t quite work and pick up one of the other approaches again because I realize it has some benefits now that I didn’t see before.
Read about the changing design of Threes by Asher Vollmer and Greg Wohlwend, or multiple prototypes of the board game New York 1901 by Chénier La Salle, and you can get an idea of how much sweat it takes to design a game.
It’s hard work. Game design isn’t just playing games and it isn’t just writing a story for your platformer or FPS. It’s more like trying to determine which of 10,000 materials to use to make a lightbulb than it is about shining a flashlight in the right direction in an attempt to discover the fun.
The more options you try out, the more informed a decision you can make about the play experience, but it takes effort and time.
So in the end, the answer to the question of how you decide on core game play is to continually prototype and play test.
What else helped you make such core game play decisions in the past?