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.

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

http://www.gamasutra.com/blogs/MattChristian/20110622/7836/Four_Steps_to_Detailed_Quest_Lines.php

 

Practical Tips for Independent Game Development by Jacob A. Stevens

http://www.gamedev.net/page/resources/_/business/practical-tips-for-independent-game-development-r2687

 

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 www.kinvalley.com and sign up for the beta.

-Slaton White

Busy

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. http://juliasmagnificentmishap.com 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.