Ask Questions

Losing the perspective of the player can destroy even the best idea. When this happens you’re more likely to make decisions that have a negative effect on the game as a whole. One method for making sure you are taking the player’s point of view into consideration is to continually ask questions from the user’s perspective. Asking questions can help you nail down why people don’t enjoy your game and can reveal new directions for the game to head in. The list of questions you should ask will change during each stage of development. Regardless of the current stage of development you should always make sure you’re continually reevaluating the game’s concepts based on whether or not they support a good player experience.

More than likely pre-production will contain the most questions or at least some of the biggest ones. Luckily, you don’t necessarily need to have answers for all of them before you start building the game. In fact, your primary focus should be defining just enough of the vision to begin development. Some common questions that should be asked during pre-production are:

  • What should this game be about?
  • Why should someone care to play the game at all?
  • What’s the theme?
  • What are the main mechanics?
  • What is the core game loop?
  • What emotional response do we want this game to evoke?
  • What are the controls?
  • What is the perspective?
  • What does it look like?
  • What platform should it be on?
  • Is there a story? If so what is it and how is it told?

You might not have an immediate answer for anyone of those questions, but you need to start thinking about them and figuring out a way to answer them. I like to build simple non-digital prototypes in order to test mechanics and the core game loop. Building and rebuilding a prototype is a helpful exercise as it allows you to test possible answers to your questions. Prototypes are most useful when you break down a broad question into a specific one. For example, “How do we create exciting combat?” can be reduced to “Is defeating faster enemies more satisfying?”

Iterating with prototypes is a very hands on method of answering questions and can be extremely time consuming. Working with your team to explore ideas is an important addition to this stage. A regular team meeting is a great opportunity for people on the team to bring up additional questions. Make sure you keep the discussion focused on whatever task is currently being solved or you won’t get anywhere. Regular team meetings will produce way more questions and solutions than a few individuals working hard on a prototype. A prototype can serve as a tool to test whether or not a direction is the right one for the project’s vision. Once you’re confident that you have features that support your intended vision it’s time to enter production.

Production can mean a lot of different things, depending on the environment that you’re working in. Whatever your situation is your most important task is making sure the game plays well. Your second most important task is creating final content that contains that great gameplay. Some of the questions you might need to answer during production are:

  • Will the change we’re about to make have a damaging effect on other parts of the game?
  • Are our plans within scope of the team?
  • Are the high level ideas still the right direction to go in?
  • Are we targeting the right platform(s)?
  • What is our business model?

Basically, the two most important questions at this point are “Does this change have a positive impact on the player’s experience?” and “How will this change affect our ability to develop content?” Figuring out if something is good enough to warrant a change is a difficult task. Especially when you have the stress of finalizing the game. It’s far easier to figure out if a change will add a whole lot of work or not. There’s going to be a lot of systems to juggle when you’re considering adding or removing a feature or mechanic. You’ll need to rethink a question in terms of the story, the theme, the platform, the business model, etc. It can be an outrageous amount of parts to compare and contrast. Make sure the team is communicating well and you’ll have an easier time.

When you release your game you’ll be in one of two boats. Either you’ll be completely done and will want to move on to a new project or you’ll be continually updating the game. I would stress that regardless you still need to get an idea of where you went wrong and where you succeeded. You might already have a good idea of what went wrong and why before you even finished the project. However, when you release you’ll have an opportunity to compare your perceived player empathy to how your audience actually reacts. Some general questions you should ask after release are:

  • Does the final version of the game match our intentions during pre-production?
  • What parts of the game do people like?
  • What parts of the game are players skipping?
  • Do all of the game’s elements support one another?
    • Gameplay, story, theme, artistic look, platform, business model, etc
  • Are players missing or misunderstanding certain parts of the game?

These questions are meant to reveal mistakes that you can learn from. If done right you’ll be able to make better educated guesses in future.

If you’re planning on releasing an update you’ll need to think of a lot more questions such as:

  • Are there any technical bugs that should be solved?
  • Are there any game breaking bugs that limit a player’s ability to make progress?
  • Is there a high learning curve?
  • Does the user base want more content or would they prefer more polish on current content?

The answers will help you decide if you’re working on what matters most to your game’s community. Allowing you to prioritize what gets done first.

As you start to gather answers to the post-production questions it’s important that you create tasks. The tasks you come up with serve as a list of prioritized work items that should be completed in order to improve or expand upon the newly released game. A set of guidelines would help to smooth the process of completing these tasks. These guidelines should be a combination of experience you’ve gained working with that team, mistakes you’ve made before, and common questions that come up during the creation of specific content. It might even give you a better idea of what development strategies work best for you and your team.

Game development is a continuous loop of ideas, communication, tests, and revisions. Questions help you continue and narrow the focus of that loop. When the loop stops you end up missing opportunities to improve your game.

New Set of Articles

I was recently asked to provide a quote that outlined my experience with a class I took while at Savannah College of Art and Design. The class was a collaboration between SCAD and Microsoft. The content of that class is still under NDA, but I can share the quote.

“I was lucky enough to participate in the CLC Microsoft project with some of the best students SCAD had to offer. My responsibilities revolved around leadership and game design tasks. I enjoyed every minute of the experience and gained some valuable insights. 

  • Continually ask questions from the user’s perspective in order to drive project vision.
  • Build excitement by including the team in high level discussions and exploring a variety of concepts to nail down your goals. 
  • Frequently update people with project direction and status.
  • Keep people within scope by adding constraints.”

Having not written an article in quite some time I thought this quote would provide a great starting point for a new set of articles. Each article will elaborate on one of the bullet points in the quote. I hope to provide more information so that anyone wishing to apply these insights to their own project will know if and when they should.

-Slaton White

The Dark Side of Iterative Design

The game development process involves a lot of work and sometimes it seems almost too much to take on. However, the key is to not take on an entire project at one time. You’ll need to break it up into manageable chunks so that you can focus and work on those to a high polish and so you don’t lose your mind. Iterative design, along with good organization, is one way of breaking a game project up into portions that can be designed, produced, tested, and implemented. I’ve described iterative design before as similar to the scientific method. Put simply it is:

  1. Come up with an idea
  2. Make a prototype that tests that idea
  3. Test and record data by playing the prototype with other members of the team and, more importantly, people that have never heard of the game before
  4. Review the collected data to see if it fits with the original idea and the game idea.
    1. If the collected data found that the prototype didn’t fit with the original idea or the game idea then start over at step 1, but take the collected information into account
    2. If the collected data found that the prototype did fit with the original idea and the game idea then simply move onto a new idea

In Challenges for Game Designers by Brenda Brathwaite and Ian Schreiber, Practical Tips for Independent Game Development by Jacob A. Stevens, and many other books or articles, iterative design is described in roughly the same way. Recently, I’ve discovered that what isn’t discussed, when it comes to iterative design, is the dark side. The dark side of iterative design comes up when you don’t have enough experience, don’t have a solid core or aesthetic, and/or aren’t using iterative design in the correct way. In this article I will discuss iterative design in a more detailed manner that will hopefully give you enough information on how to use iterative design properly.

The iterative design process, like everything else, becomes more useful when you have more experience with it and game development as a whole. Some basic things that I have learned about iterative design are:

  • There are two types of iterative design prototypes
    • The overall project – This should be the first prototype you make. Get your basic gameplay down here.
    • Individual mechanics – Every prototype you make after your basic one is to test individual mechanics and small changes. These mechanics and prototypes should ONLY be tested within the overall project to make sure that they not only work, but work within the game.
    • If you constantly run into issues with specific design ideas, mechanics, or even your core. Don’t be afraid to scrap it and start over. A smaller or shorter high quality game is always better than a long game that is of low quality. Note: The decision to start over should be done during pre-production, otherwise too much money and time will be wasted and you won’t be able to start over.
    • Never depend on iterative design to make your game for you. While iterative design is a powerful tool, you’ll still need to pick the aesthetic, dynamics, and mechanics as the underlying foundation for it. If you try to find a game through rapidly producing prototypes than the game you end up with will just be a mishmash of enjoyable and unrelated mechanics.

If you’re not very experienced with iterative design, the most important part that you can learn is to have an idea beforehand.

Just as you would have a hypothesis when going through the scientific method, you need a main idea for the game in order to use the iterative design process properly. While you’ll still be able to find out if the prototype is enjoyable and understandable, you won’t have a good idea of how well it meshes with your other ideas. Obviously you could test it with every combination of ideas you have, but it’s much better to just have a goal that you’re headed towards and then come up with ideas that will suit that goal. Some game developers prefer to start a game with a mechanic, and then make their game based on that. Just as any other development method, you’ll need to find which method works best for you. For people that prefer to start with a mechanic first, they will test their mechanic against various themes and play styles to see which one it suits best. An important element to remember is to not use iterative design in a vacuum. You’ll need to constantly compare your prototype and the additions you make to it with your overall idea for what you want the game to be. If you don’t have an overall idea of where you want the game to go, then you will ultimately have a game that is a confusing collection of unrelated elements that alone might be enjoyable, but together make little to no sense. Every time I have started a project with a main idea in mind such as an aesthetic or core idea, instead of just rapidly prototyping mechanics, I have ended up with a much higher quality game. The most overlooked part of iterative design is that it is a tool to be used among other tools in order to create a final game.

The correct way to use iterative design is to not use it alone. For example, iterative design could be somewhat confused with testing, but one should never be used without the other. Iterative design is about constantly retrying new ideas to find the best combination of ideas. Testing is about looking at what you have in the light of how it works and how it is perceived by your target audience. Iterative design is mainly a pre-production tool, but can also be used when testing finds mechanics or aspects of the game to be unfit for release. Testing is used throughout the entire production of the game. It might seem like the entire pre-production process just involves a lot of iterative design, but while you are trying to find the best combination of mechanics you or other teams will be figuring out other aspects to the game.

One aspect that will need to be worked on is the look of your game. During pre-production this will involve a lot of concept art. If your prototypes have been mainly paper ones, you will also need to find a game engine and start creating a digital prototype. While the pre-production process involves a lot of concept art, it might not always be obvious when to start developing and implementing final art. Most companies start a digital prototype with very rough art, sometimes to the point of just blocking things out with square shapes. This might seem strange but waiting to implement final art until the prototype is farther along will reduce the amount of art that ends up being thrown away. It’s important to remember that a lot of work that goes into a game will ultimately go unused.

Try to reduce the amount of unused work, not by forcing that work into the game, but by figuring out exactly what needs to be done and what will be used before you have your art team start creating. If you think there will be a level in the game that features a gigantic ship that the player might go into, have a level designer create a very rough level that features such a ship and use iterative design to test whether or not the ship portion of that level fits. While testing the ship, your concept artists should be coming up with different looks for the ship. If all goes well and the ship fits within the level, then your art team can work on final iterations of it. Notice that I say iterations, because just like with the game, your art and assets will also go through iterations. Most of the iterations of assets should be done with the concept art since concept art is much easier to create than full textured models. There is a lot of time and work that goes into making a game so be sure to make the most of every tool you use. Iterative design is yet another tool that can be used to improve the quality of your game and improve the efficiency to which you use your time.


Related articles:

Four Steps to Detailed Quest Lines by Matt Christian


Practical Tips for Independent Game Development by Jacob A. Stevens


The Problem with Fun

Something that I’ve been trying to wrap my head around lately is why people continue to blanket games as fun. The problem with the word fun, pointed out by many such as Warren Spector in “Fun” is a Four Letter Word, is that it lacks the information to adequately describe the breadth of reactions and experiences that games can bring. At the end of his article, he asks that we start thinking about if games can be only be fun. Five years after Spector wrote that article, I believe we are past thinking about games as being merely a vessel for fun and are at the point where games are much more than any single descriptive word can provide. What we need to do now is change the way we discuss games so that as developers and as an industry we can further develop our craft.

The best way to help improve our ability to talk about games and game development is to develop ways to discuss games in a more detailed manner. Labeling games, in general, as fun ends up hindering the ability of someone else from responding or gaining anything from such a description. Obviously the most important part of a discussion is the back and forth. In order for this exchange of ideas to happen, the right information needs to be portrayed. This information that you need to put forth consists of many different aspects of the game such as story, theme, mechanics, dynamics, aesthetics, target market, flow, difficulty, design, and development process. When someone uses the word fun to describe a game, more than likely they are describing what the game makes them feel. While fun has many different meanings to many different people, what most people mean is that the experience provided by the game makes them feel happy. Games should of course continue to give people these wonderful experiences, but games have a much greater range than simply just that.

Regardless of what your opinion on “serious games” or “art games” is, I can’t imagine you haven’t had an experience with a game that was more meaningful than simply entertaining yourself for a few hours. Personally anytime I get together with a bunch of friends to play a game, I have a wonderful time. My experience when I play games with friends is, of course, much more involved than simply providing me with a few hours of entertainment, because I’m playing with friends. It provides an environment for my friends and me to further bond and share an experience. Looking at it a different way, when you play a sport or watch one of your favorite sport teams you are likely having fun. If you or the team were to win a big championship you would of course enjoy that experience as well, but I can’t imagine that the word fun would describe the full range of emotions that you feel when the buzzer sounds and you find yourselves the winners of an important game. One more way, but in no way a final type of experience you can have, is playing a game that allows you to fully express yourself without fear of social repercussions. Games, for many people, are a way to explore who they are and how to communicate with others while safely being behind the shroud of an avatar. For people that use games in that manner, I’m sure the experiences while entertaining are far more important to them than the word “fun” would describe. For all of the experiences that you can have in a game, words like engaging, entertaining, and compelling are much more suited to helping describe games. However, while I bring up the problems with fun and what could be considered more appropriate words, what will really help is not trying to find a single word to describe games.

Games, while currently seen as a commodity to many, are complicated pieces of entertainment that can be used for purely entertainment purposes, to educate, to help someone cope with something, to explore an idea, or combinations of them and a variety of others. With how many ways you can apply games there will never be a word that encapsulates the full range of applications that games have. What will ultimately help communication between the areas of game development as well as between developers is making sure you can put forth your ideas in a way that people can understand as well as making sure you understand what people are saying back.

This problem with fun is merely a symptom of the problems with language and what many would consider cultural differences. I don’t have an answer, nor should I try to come up with one, that generalizes this problem and tries to fix it. However, a solution to this that won’t necessarily fix it, but instead help it, is to continue to discuss games anytime you can. During these discussions make sure you try to gain something from them by taking the time to adequately describe your position and absorb the response. Make sure that when someone responds to you that you fully understand their point of view before responding and if you don’t understand, make it a point to try to. To some of you, this might sound like the most obvious series of statements someone can make, but I bring it up because far too often I will see really bright people not speaking up because they’re worried that what they have to say might be considered invalid. While there are mistakes to make during a discussion such as simply interrupting someone or using a word incorrectly, discussing your point of view is always valid and never a mistake. The reason being is that discussions are really just an exchange of ideas, both good and bad, that will ultimately uncover an idea that adds to the ability of the people involved or the concept at large.



Related articles:

What is Fun? by Lauren Vespoli


Deep Thoughts: Why Games are so Weirdly Fun by Brian Hertler


“Fun” is a Four-Letter Word by Warren Spector


Starting Again – Part 1: Problems With The Word Game by Darren Tomlyn


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:

  1. Come up with the aesthetic(s)
  2. Find what dynamics support the aesthetic(s)
  3. Build mechanics that make the dynamics work
  4. Use iterative design to test how close my idea of the game is to the actual game
  5. Go through the entire game with player empathy in mind
  6. See what target market works best for the game
  7. Testing, testing, testing, and more testing

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:

  1.  Coming up with a prototype
  2. Playing and testing that prototype
  3. Recording data
  4. Looking at the data to make sure it supports the overall MDA and making note of the problems that cause it not to be successful
  5. Making a new prototype that attempts to fix those problems.

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:

  1. Will they be able to understand and play it?
  2. Will it be fun to a particular type of play style?

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.

The Future of Games: Can Games Impact your Life?

Edit: I’ve changed the article just a bit to include a section on making games more accessible to people with disabilities as well as making games that help people cope with disabilities


Games don’t have the best image in the world today. They’re branded as toys, bad influences, evil, and they are definitely not as respected as other mediums of expressions. However, I believe there will be a change of the public’s perception when it comes to games if we set our sights high enough. Many games and game development companies are already setting their sights higher. All we need now is for commercial games to catch on. So how much chance do we have of commercial games becoming more than they currently are? I’ll be discussing the chances of just that based on reviewing survey results, looking at games that have a big impact, and what some commercial games get right.

In order to get a better picture of how exactly people’s lives are affected by games and in what ways I made a Google survey. I asked people to participate in it via Twitter and Facebook. On this survey I asked people’s occupation, what their favorite game currently is, what their ideal game is, if games have had a noticeable impact on their lives and how. I received 23 responses and while it isn’t enough data to come up with a ratio of people whose lives have been affected to the amount that haven’t been affected by games, I can go into the vast variety of reasons that games have affected people’s lives. 22 people said that their lives were affected by games in some way.  What ways they were affected differed vastly. A vast majority of them gained social, vocabulary, and reading skills from games. Others were drawn to a career in game development. Some families were drawn closer together because of games. A few were helped to forget that they were extremely ill or break them out of their shell. One, almost universal effect was bringing friends together in a way that would forever become a fond memory. Not all the responses in regards to a game’s effect were life changing, but they don’t have to be to be meaningful.

A meaningful game whose aim is to drastically affect you in some way, influence a change in society, stir such strong emotions that long after they still reside when the player quits, forever a part of you, is rare. They’re almost non-existent, but they are out there and they can change your life. Take for example a well-known board game in the game development community, Train by Brenda Brathwaite. In this board game you and two other people compete to get people from one place on the map to another. This is accomplished through the use of a train boxcar which you use to carry all the people. You also have various actions that you can use to obstruct the other players. While the concept has been seen before, the end, where you find out what the destination was, is where Train hits you. If you reach the goal before the other players you not only win, but find out where you took all those people, Auschwitz. An article on Escapist Magazine wrote of one instance in which Brenda Brathwaite took Train for a public audience to play. Upon revealing the destination one woman became so emotionally touched that she burst out into tears and left the conference room.(1) One of the great subtleties about Train is how differently people will play, if at all, after they’ve learned the destination. Games of this caliber are rare to bringing up such a devastating event as the Holocaust; some will just improve lifesaving skill.

During 2001-2003 Rosser JC Jr and his researchers conducted a study about video games improving the reflexes and overall skill in laparoscopic surgery. (2.a – pg. 154) They compiled the results of the study in an article called The Impact of Video Games on Training Surgeons in the 21st Century. 33 participants were recruited and were submitted to tests and skill before and after they played 3 video games that were chosen specifically for this study. (2.a – pg. 154) Overall the 33 participants scored 33% better on a skill test called Top Gun. (2.b) Participants that played more than 3 hours a week scored 42% better. Many surgeons now play video games that require precise movements similar to those used in laparoscopic surgery in order to keep their ability and reflexes high.

Along those same lines is a game called Capable Shopper created by Jennifer Ash, Zach Barth, Peter Mueller, other students, and the Adult Services Division in Albany. This game helps people with disabilities gain confidence and ability in doing everyday things. In Capable Shopper there are two screens, one with a list of dishes they can prepare and another which gives them a view of a grocery store. The player navigates through the grocery store finding each ingredient they need. The game was so successful that they were asked to install the game and its necessary components in a permanent installation at the Center for Disability Service’s Adult Services Division. (3) Making it easier for people with disabilities to gain skills and confidence in necessary activates through a game might not be a mainstream commercial success, but does that really matter if it can help someone? If you don’t have a disability or know someone with one you might not be able to answer that question. However, how about a game that can help cure a deadly disease?

AIDS has had many breakthroughs to help fight it, but one problem has troubled AIDS researchers for years, what a protease looks like. Foldit, a game designed by Seth Cooper, is a puzzle game where players try to change shapes in order to make a specific stable protein. The more stable your protein is the more points you get. Foldit is similar to a program called Rosetta which relies on distributed computing to run thousands of different scenarios for proteins. (4) Where Foldit differs is using players instead of distributive computers to find the most stable proteins.  Utilizing the Foldit community, Firas Khatib from the University of Washington, entered the community into a contest called CASP (Critical Assessment of Techniques for Protein Structure Predicition) (4). Initially, the solutions the community came up with didn’t really work. However, after Khatib stepped in to randomize the starting proteins the community starting coming up with some of the best answers for protein structures in the competition. (4) To find more about Foldit, you can read this article or visit the Foldit website where you can also download the game, here.

Obviously, I don’t expect every game to aim as high as affecting AIDS research, but affecting someone’s life is not as difficult as it sounds. Whether the change is as small as getting your players to care about the character or as big as breaking someone out of their shell, making games that mean something is not only possible, but something companies should be aiming for. Games should no longer be looked upon as children’s toys and shouldn’t have goals of selling millions of copies or gaining enough interest to warrant making a sequel. Instead they should be a meaningful part of someone’s life and should help people coup and understand a problem or at least face it.

Will commercial game companies take this path? Sadly, probably not because let’s face it. Companies that make games are mostly making games so that they can make money. Few of them have goals that go beyond making money. There is however a game company that is striving for more, that is making sure that when you play their game you don’t just have something to occupy 30 minutes of your time while you wait for such and such to happen. The company thatgamecompany have made such popular games as Flower and flOw that have had a big impact on how games are made. TGC’s goals as a company, found on their front page, are to push the boundaries of interactive entertainment and provide meaningful and enriching experiences that inspire their players. Their current project, Journey is no different. Their aim is to enforce the wonder of another human being instead of focusing on the powers and abilities of your character in game. (5) Will Journey accomplish this goal? I can’t say for sure, I hope so, but what’s great about TGC is that they’re aiming for something more than just a piece of entertainment. They try to change people’s lives or even the medium of expression they’re using, video games.

There’s a side to this argument that mainstream commercial companies should really be looking at. About 54 million people in America alone could be buying and playing games but because of a lack of support from game developers and hardware manufacturers these people are unable to. (6) Disabled individuals have a wide range of physical and mental disabilities that disable them from playing games. Take for example Chuck Bittner who is a quadriplegic, but regardless of his disabilities is a huge fan of video games. He can play games such as Brink because it allows him to remap the keys since he is unable to use a controller as intended. However, Red Dead Redemption does not allow him to remap the controls to the point that he is able to play the game. It simply does not give the player the ability to fully customize how the player interacts with the game to fit their need or play style. (7) The amount of financial gain alone is worth taking the time to implement customizable controls. Customizable controls aren’t even the easiest addition that can aid people with disabilities play games. Subtitles that show audio cues and dialogue are easy to add and can help the millions of people who are deaf and would otherwise miss the entire audio portion of a video game. Commercial games don’t need to do a lot to make a difference in whether or not someone can play a game. They don’t even need to put a lot of effort in to have a big impact on someone’s life.

Looking at the list of answers I got from people about their ideal game, not all of them talk about a game that changes their lives. So of course there will always be a place for companies to make pieces of entertainment purely for entertainment value. Not every game company will turn into TGC and actually I’d prefer every company to make their own goals, but hopefully those goals turn out to be more than “Let’s sell 5 million copies” or “Let’s get enough publicity to make 2 more sequels.” Companies don’t even have to change much because a lot of games already have a big impact as they are. What’s important to focus on is quality, not quantity and with that life changing games will come. Some companies, like TGC, are already going in that direction and I believe many more will come in some form or another. You can have an impact on someone’s life in big or small ways, but what’s important is that you made a game that is meaningful to someone.

You might not have played a game that affected your life in a meaningful way or even in a noticeable way, but I imagine something that you read, watched, or experienced did have an impact. If other forms of expression can have an effect, why not games? Games are the only form of expression that requires the player to interact with it. There is something extremely powerful in that requirement and as game designers we need to tap into it to not only improve the image of games, but also improve how meaningful they are.

Special Thanks


Josh Evans



Saam Pahlavan



Matthew Allen


Shane Stoneman

Corvus Elrod

Darius Kazemi

Kelly Wrinkle


Eric Stover

Kristy Cornell


Scott Spadea

Matt McConnell


Bryan Di Fatta


As well as everyone else who participated in my online survey.

Some changes have been made…

I finally finished the bulk of changes I’ve wanted to make to my site for some time. All I have left is a few positional tweaks to make and it’ll be fine.

Currently, I don’t have any of my projects up yet because I just switched to a new way of organizing my WordPress site. I should have them all up within the week.

You might also notice that you can now leave comments on my posts. I added this feature because in the coming weeks I will be writing a series of articles on various aspects of game development. Right now, my topics are:

1. The Future of Games: Can Games Impact your Life?

2. The Hopeful Future of Flow

3. What is Fun?

4. Iterative Design

Over the next few weeks I will be conducting research, interviews, and writing various drafts concerning these topics. You should see a final post concerning one of those topics every two weeks or so.


If you’d like to help with the research, please answer this survey.

Kin Valley LLC

The company I’ve been working at, Kin Valley LLC, has finally announced the beta for Kin Valley! Kin Valley provides a way for families to safely enjoy social networking. In order to provide a safe social networking space Kin Valley follows the Child Online Privacy Protection Act (COPPA) which, when followed, protects children on the internet. Even while following the act we are still able to provide meaningful interaction between you, your kids, and the rest of your family and friends while using Kin Valley.

I have been working on Kin Valley since December of 2010 as a Jr Designer and until now have had to keep it under wraps. Hopefully I will get the chance to discuss more of my involvement with the social media company, but until then check out and sign up for the beta.

-Slaton White

Andrew Looney Lecture at GDN-SCAD

A few weeks ago the Game Developers Network at SCAD had Andrew Looney give a lecture on designing games. The lecture consisted of how he designs games, what it takes to design games, and some advice on where else to go for information on designing games.


Andrew Looney compares making a game to making a soup. All sorts of ingredients go into it and the best soups are ones where you constantly test it see what else it needs.
* Along with testing the full game, you can also test “ingredients” or portions/mechanics of the game to see if they work alone

Whenever you can cut something out, do it
* Rules that are not needed
o Optimizing the rules instead of completely cutting helps too

Is your game Mechanic Driven or Theme Driven?
Mechanic driven example: Black Ice
Theme Driven example: Chrononauts

Thinking like a programmer is extremely useful
* If you haven’t programmed before, try it
* When making a rule sheet, think like a programmer

Make a prototype!
* Write down rules, even as you prototype it. This forces you to fully explain how the game works.
* Trial by Rule Sheet: Make someone play without you helping. This tests the game as well as the rule sheet. Testing both is key to making a great game because you won’t always be there to tell someone they’re playing your game wrong.
* Playtest! Playtest! Playtest!
* Use placeholder art to save time
o Don’t let prototypes with placeholder art leave the office if you don’t own the rights to that artwork.
o Make sure to remove placeholder art before selling, especially if you don’t own the rights to the artwork.
* When you have fixed and improved everything you can, don’t forget to build the final prototype with art that you or your company has made. Don’t use placeholder art for your final prototype!

Get feedback!

* Make sure you can take criticism well
* Honest feedback is hard to find, so when you find it, make sure you use it.
* The best feedback gives you better ideas.
* Get lots of different people to play it and replay it
* Make sure you get old and new groups of people to playtest each versions of your game after you have applied previous feedback to fixing and improving it.

Keep an inventors diary with dates

* Write down every idea you have
* Draw diagrams and roughs of game ideas you have
* It’s not only helpful when you can’t think of an idea later in life, but it also gives your case some credibility if you are filing for a patent

A good game makes everyone feel like they could win right up to the end

Patent your game!
Go to Nolo press for IP patenting information.


The Game Inventor’s Guidebook by Brian Tinsman
The Game Inventor’s Handbook by Stephen Peek

Update March 31st 2011:
Andrew Looney has posted some information about the talk from his perspective and even the handout he gave us.


Wow, I can’t believe my last post was so long ago. I always wonder how my juggling of keeping up with my blog up to date with everything that I’m doing and actually doing everything.

Anyway, in the past few months I have started back at SCAD and I absolutely love my new classes. I think they this might be the most fun quarter yet.
Along with school I am working with Team Mishap again on Julia’s Magnificant Mishap for IGF 2012. I’m really glad we’re starting so early because starting on the 2011 version last year so close to the deadline was a real nail biter.

I’m really looking forward to working with the team again on the project and making something better. There are even talks of getting some sort of college credit for the project, but I’m not sure what the likelihood of that happening is.

Another project I’m working on, The Pirate’s Pledge, a board game that several of my fellow students and myself made in a class and are currently working on to improve and hopefully get published. While we have lost a member, I still absolutely love our board game and everyone that has played it has showed interest in wanting to buy a copy, that has to be a good sign, right? Either way, it looks good as is. If we put in a lot of work over the next two quarters, get a commercial of it made, and if it doesn’t get published, at least we will have an even better portfolio piece to show off. The only problem then will be fighting over who gets the copy of the game haha.

In other news I got an internship with New Zone Games, but sadly I can’t really talk about it. All I can say is that I’m a Jr. Designer there and I will be sure to post something when I can.

I just finished working on a UDK level for Level Mechanics class and I have to say I really like where this class is going. In Environment and Level Design I was really disappointed that we had to make our own assets to populate our level with when it was a level design class, however in Level Mechanics for the very first project we were allowed to use all of the assets that were available in UDK or use any that we had made. On a side note, to my surprise it seems that showing a level that you made, even with assets that come with UDK is ok as long as you are applying for a level designer. In retrospect that makes a lot of sense, there is just something about showing a company something that wasn’t all entirely made from scratch that is kind of unnerving to me.