Tools of a Game Designer: What I use and What is out There

There are a variety of ways to go about designing a game. Luckily enough I’ve had enough projects to work on and enough freedom to try different ways to design them. Some ways have completely failed me and others have shown real promise. In this post I will discuss both the general design tools and methods that are out there as well as what works for me as a designer. My basic template for designing a game is:

Before you start building your game you need to decide what the mechanics, dynamics, and aesthetics (MDA) are. It is generally suggested that you begin with your aesthetics first even though mechanics and dynamics are usually referred to first. I can confirm that moving from aesthetics to dynamics to mechanics works better in terms of overall game quality and consistency because I have tried both. When you think of aesthetics you might be thinking of how the game looks, but in this instance it actually refers to how the player feels when they play the game. Once you figure out what you want the player to feel when they play your game, you can figure out what actions they need to do to cause those feelings. The actions the player takes are called dynamics. For example, say I wanted the player to feel really sad or evil. To make the player feel sad or evil I might have a dynamic where they need to kill off one of their cute and loveable pets in order to do something. Remember that dynamics are pretty broad actions such as leveling up or attacking. After you’ve figured out your dynamics you can figure out the mechanics. The mechanics are the extremely detailed rules that dictate what exactly happens when an action happens. Where dynamics are broad actions, mechanics are what specifically happens when the player does those actions. To go back to the “killing a pet” example, the mechanics for killing your pet might be that every time you kill one of your pets the other pets level up. Once I figure out my MDA I will immediately, if I haven’t already, make a prototype to test whether or not my mechanics and dynamics actually cause me to feel the desired aesthetic.

Making a prototype, testing it, documenting what was successful and what caused problems, and then making a new prototype that tries to fix those problems is called iterative design. Much like the scientific method it involves:

As a game designer, iterative design is my favorite method for solving problems and testing new ideas. At the end of the day, I can think all I want about what kind of an effect such-and-such a mechanic will have on the player, but you get a much better idea of what it will do once you actually implement and test it. While it might seem like it takes a lot of time away from the other elements of production, in the end it will help immensely. While you’re designing and prototyping the game you are actually making versions, or at the very least sections of the game, that can be used later in production. It allows your team to work together to make quick and to the point prototypes that will end up strengthening your team. This is especially helpful if the team or members of the team haven’t worked together yet. It will be much easier in the long run to have them make mistakes and learn how to work with one another on prototypes than on the polished version. Iterative design can be a very useful tool, but without having good player empathy, you will never be able to fully utilize it.

                Player empathy is the ability to look and play your game through the eyes of a player and not someone who knows what you or anyone on your team knows about the game. It is the most important tool you can use as a game designer because what you think the player might do at any given point could be completely different from what they actually do. For this reason it’s very important to make sure you can see your puzzles and levels without the knowledge that comes with working on them. How you actually accomplish this is basically a form of roleplaying. For example, say I’m making a casual puzzle game and I’m currently trying to think of a control scheme and mechanic to use for it. At some point I think that a cool control scheme to use would be the typical one found in first person shooters. So W, A, S, D moves the characters and the mouse is used for looking in different directions as well as shooting in a specific direction. Now I ask myself, if I were the typical type of player that goes for casual puzzle games, would I be able to figure out this control scheme and would I be able to use it? If it wasn’t immediately obvious to me that the FPS control scheme was too complicated for that particular type of game and I wasn’t really sure what casual players were used to I would try to play every popular casual game and then the unpopular casual games.  While playing those games I would make note of what the norm and popular game elements are as well as what the unusual and unpopular game elements are. Those points of data would hopefully give me enough information to look at my idea through the eyes of a casual player. When using player empathy I try to ask myself these general questions first:

After I answer the general questions, more specific questions come up based on what type of player I am looking to test or more likely what type of game I’m trying to make. If I’m designing a FPS/RPG I will make sure that the RPG elements in the game are fun and make sense to FPS players and that the RPG players will be able to have fun and understand the FPS elements. Depending on who your game is for you will most likely need to pay attention to more than one type of player that will play your game. If you just look at your game through one particular play style or worse, what kind of player you are, then you’re not getting a good sense for how the elements in your game will be received. It’s important to remember that what types of players you base your decisions on will ultimately dictate what target market the gameplay is targeted for.

When you release a game it can be very nerve wracking to see how many people play it and what kind of feedback you get. To get the biggest amount of people to play your game you might want to make your game as generally appealing as possible. However, I would advise against it, because most of your time will be used to make sure that there is something for everyone in your game rather than making a consistent and high quality experience. If you were to make a generally appealing game you would have to make sure the gameplay is easy enough for new players while keeping in mind that hardcore players will want it to be challenging. You would need to make sure that the theme of the game appeals to everyone, which means doing lots and lots of research and focus testing just on the particular theme that you’re using. All the time you spend on making the game appealing to the masses is wasted, because after all that work is done, you still don’t have a game. All you would have is a whole lot of constraints, a lot less time, a story or aesthetic that you might not even care about, and a hell of a lot of play testing to do. Now if you start instead with a specific target market in mind or if you let the MDA dictate what specific target market would find the game appealing then you’ll be able to test with those players in mind and you will hopefully enjoy what you’re doing a lot more. Having a specific target market will allow you to focus on making a game that is tailored to a narrow audience. You might not get as many players, but what players you do get will have a high quality game that is meant for them. The best way to get a target market is to let the game’s development and direction dictate what target market you’re going for. It might seem backwards, but waiting for the game to take shape to see what target market it suits gives you more time for development and allows you to make the game how it should be made, instead of changing it to suit a particular market. This is especially helpful if the direction the game is going is something important to you. You’re even likely to put more polish, time, sweat, blood, tears, and thought into it then if you were just worried about selling one million copies. With this in mind, don’t wait till the project is close to shipping to choose a target market. You should choose one fairly early because it lets you focus your testing on specific types of problems rather than trying to accommodate every type of play style and person out there.

You and other people on your team should begin testing it as soon as you have a working prototype. During the tests you need to make sure you or someone else is documenting everything that works and everything that doesn’t work. The data you should collect should range from where on the level they died or failed the mission to what mechanic is being used the most. All this data will help you in making decisions and course corrections later in the production timeline. For example, say you have a variety of weapons in your game and are trying to find what weapons are working and what aren’t. Testing finds that one of the weapons, Light Pistol, is being used less than 1%. Less than 1% would dictate that a drastic change needs to occur. It might be better to take the weapon out completely to reduce the amount of time your art department spends on texturing, modeling, and polishing it. However, if the Light Pistol was extremely important to the story or the game in some way, than you might want to make it more powerful. Making sure you organize the data is also important. Using software such as Excel or Google Analytics will help to make all the data you collect actually useable to the people that need. Without organizing the data, people will be unable to make any sense of it or find specific points of data that applies to them. Along with testing within the team you should get people that have never heard or played the game before to play it. Make sure that you don’t help public play testers with the game at all. You won’t be around when someone 5,000 miles away plays your game and isn’t sure what to do so it’s better to let play testers make mistakes. When players make mistakes or are unable to do something in game, it shows you what needs to be fixed. After play testing has finished, review the data and try to solve the problems that came up. If it isn’t immediately obvious what needs to be done to solve a problem, try making a few prototypes with different fixes. Then test those prototypes to see which fix is the most successful. Be sure have a questionnaire ready for them to answer after they finish play testing. Questionnaires are important because it allows you to see if your observations were correct and to gather data that you can’t observe, such as if they would play again. You’ll need to test for a lot of things to make sure your game is accessible and entertaining, but something paramount to a game’s success is flow and immersion.

Flow is the concept of making sure the game has enough challenge to meet the skills of the players that plays it. Have too much challenge and the game is frustrating and difficult. Have too little challenge and the game is boring and no fun to play. Immersion is the idea that a player will constantly believe that they are in the world that the game is portraying and will forget that they are playing a game. Obvious ways that immersion is broken include when the game crashes or has glitches. More subtle ways of breaking it include having inconsistent art styles between the cut scene graphics and the game engine graphics, as well as taking control from the player during a cut scene. With flow you can help both how entertained they are and how immersed they are in the game world. One way immersion is gained with flow is when the player enters the flow zone. The player is in the flow zone when the challenge of the game meets the skill of the player. In the flow zone they are more immersed in the game and will sometimes lose track of time. This loss of time is due to the game being difficult enough to require they pay attention, but not so difficult that they are constantly reminded that they are playing a game. If you’ve ever started playing a game at some point during the day and looked up to notice it’s now nighttime and somehow 4 hours have passed then you have been in the flow zone. The idea of having good flow could be summarized in making sure the attention of the player stays on the game. However, when you design elements that improve immersion and make sure the game allows the player to enter into the flow zone, than the player will have more believability and trust in the game world. Ultimately this trust and believability will help in portraying the story of the game and will cause the player to be more susceptible to the emotions you set out to cause. If you’d like to learn more about flow then I recommend reading Flow: The Psychology of Optimal Experience by Mihaly Csikszentmihalyi. If you’d like to read more about how flow applies to game design then I recommend reading Jenova Chen’s thesis, Flow in Games.  A new technique, that is slowly gaining steam, called dynamic difficulty adjustment helps with flow by changing how difficult the game is based on the skill of the player.

Dynamic difficulty adjustment (DDA) is the process of changing how difficult the game is on the fly. There are numerous systems around that deal with DDA and one such system involves taking input from the player such as health lost, accuracy, time it takes to solve a puzzle as well as many others. After the system records this data it then changes the later difficulties in the game to meet those data points. The problems with it, pointed out by Jenova Chen in this thesis on flow, is that the system doesn’t know if the data it is collecting is representative of the actual skill of the player. Say you’re playing a game and you decide that you want to get to the top of a specific building or mountain just to see if you can. While doing this the system would see that it’s taking a lot of time for you to finish an objective and if you’re avoiding enemies it might think that you don’t know how to deal with them. Trying to help you, the system might change the next level to be easier to navigate and populate it with enemies that are easier to beat. While I love the idea of DDA, the obvious problems with it keep me from trying to implement it in any games I make. What you can take from DDA, flow, and player empathy is that building up to more difficult areas can sometimes help players become more and more experienced with the game. This technique doesn’t help players that struggle to get through the first few levels. It also doesn’t help players that breeze through a majority of the levels and find the last few levels extremely boring. Use that technique sparingly and change how quickly it ramps up in difficulty based on testing and your target market. Using a dynamic difficulty system by itself in your own project will most likely be too time consuming with how much you will need to tweak it. Hopefully companies will crop up whose purpose it is to produce and update a DDA system that a game development company can then buy and use within their game. Much like companies that produce physics or animation engines that game developers buy for their games, these completed and updated DDA systems would allow the game developer to work more on the game and less on the technical aspects of it. Whatever tools you use to design and develop your game, don’t be afraid to try ones that you aren’t familiar with.

The great thing about game design and development is that since it is fairly new, compared to other mediums of expression, it has a lot of room to grow. Due to this growth, new ways to design and develop crop up all the time so don’t be afraid to try different methods of design, because you never know what might work for you. Just keep in mind that what decides if your game is liked or not is how much effort you put into the production of the game. Ideas are cheap, whether or not the player gets the concept, is able to play it, and is entertained by it is due to your player empathy and how well you use game design and development tools.