Tuesday, February 14, 2012

It's a bird!-It's a Plane!-No! It's PLAYTESTING!!!

Playtesting is our most powerful tool we can use to make our game and our player's experience better/more fun/what we intend. Like prototyping, play testing should be used to answer a question or questions about your game/player experience of your game. Without this first part it's almost useless (unless you're play-testing because you don't know which question(s) to ask, in which case the question would be "what questions should my play-test be asking?")
Here are some tips and tricks I've picked up from Jesse Schell's The Art of Game Design, and Tracy Fullerton's Game Design Workshop. If you feel the urge to delve deeper into this rabbit hole the information is on pages 256-265 in Fullerton and 390-401 in Schell.

The singular most important part of the act of playtesting, no matter what method is used, is note taking. We'll get into specifics in a minute, but if something occurred during playtesting that seemed important write down what happened and when it occurred during gameplay

If the play-tester at any time becomes stuck or too confused to move on during game play two things should happen:
1) It should be written down. This tells you something about this part of the game needs to be fixed.
2) Don't tell them what to do. If this occurs ask them what they think they should do and then have them try their solution. Also remind them to think aloud.
Note: This second one is extremely difficult and failure to comply with it may at some point be understandably unavoidable. Just do your best to lead the tester as little as possible.

Now, as to not just rewrite all of the subject matter Schell and Fullerton already wrote, I'm just going to give some examples of the types of questions that should be kept in mind while play testing

  • Are players:
Playing the way that was intended

  • Is the game too

  • Do players understand how to play?
  • Is level 3 too short?
  • Do players have enough to do?
  • Do players have too much to do?
  • Are players over whelmed?
  • Etc..

The list can go on and on, but the most important thing to remember remains:


Friday, February 10, 2012

Student Perspective on Immersive Learning

A visiting scholar from the across the pond popped into a few of our meetings and discussions this week over in the Games, Fun, and Learning camp. His goal behind seeing how we operate is to see if the style of experience that Ball State has dubbed "Immersive Learning" lends itself well to higher education.

I thought about this for a while, and I've come to the conclusion that Immersive Learning, studio-based learning, or whatever you want to call this type of experience works very well in most cases.

Looking back on my education at Ball State University, I realize that my introductory Computer Science courses wouldn't have worked as well in this type of a learning environment. This environment is too free, it's too open, and it's too easy to become distracted for typical 19 year old college freshmen. Sometimes even us "experienced" college students get distracted.

But once that foundation is established, the old model of lecture, test, lecture, test just isn't necessary, and in some cases is counterproductive. It's not engaging enough, for the most part, and the lessons don't ring through quite as loudly.

Myself, I've been involved with three projects that fit the bill of "Immersive Learning." I've learned important lessons that were really driven home by the fact that I did them while working on something I cared about. I have something tangible - if you can call software that - from which I can remember these lessons learned. Now, when I think of the Morgan's Raid project, I think of volunteering to come in on a weekend and rework some unsightly code with Ryan Thompson and Dr. Gestwicki. The lessons learned that weekend stuck with me that much more because I have an artifact associated with it, not a letter grade after 15 weeks.

Would any other class have allowed me to do something like this? How much am I going to interact with my professor and classmates when I see them for a combined 3 hours a week, tops? The course I just mentioned was a small, almost microscopic version of what we're up to this semester. Imagine being given free-reign over an entire 3 story house and essentially given every resource you might need. It's a 180 from the conventional classes, and it's a great change of pace.

One of the other great things about Immersive Learning opportunities, especially the Virginia Ball Center projects, is that the students can get a lot of 1-on-1 time with each other, as well as with the instructor. If you want to get a multidisciplinary team to cross-pollinate ideas within itself then give them a tough problem, allow them to work as they see fit (while guiding them when necessary, without preventing small, meaningful failures), and watch. It isn't necessary to drill your students, and being given a bit of freedom can unleash a great deal of creativity and productivity.

This afternoon a subgroup of the VBC students spoke with this visiting scholar, speaking at length about some of the things I mentioned above. I had to step out of the conversation before it ended, but the other students all felt very positively about their experience so far at the VBC. The overwhelming theme that arose was that they all (and I agree) were tired of the K-12 experience, consisting of being guided along through various subjects. We all agreed that we much prefer to be allowed to explore topics and learn lessons that deal with our specific project.

It sounded as if the scholar agreed with what we were saying, and I hope he found the conversation helpful. A big issue that we all noted with this style of learning is that it is difficult to get more students involved with Immersive Learning projects. Some professors and some majors make it difficult for students to get credit, while other students truly don't understand what these projects even are. Hopefully Ball State University can address this issue so that more students can see the positive effects of Immersive Learning. I myself am a strong believer in student-led projects, where the students and the faculty mentors are learning in parallel. I give a ton of credit to one of my past Immersive Learning projects for bringing me out of my shell socially and helping me realize a deeper interest in my field that I didn't realize I possessed.

Immersive UI Design

Yesterday I started playing L.A. Noire (don't worry, no spoilers), a game in which you play the role of a detective in 1940's Los Angeles. It is published by Rockstar Games, makers of such games as the Grand Theft Auto series and Red Dead Redemption. The missions in these games mainly consist of going to a marked location on your map and shooting people at that location. Rinse and repeat. Some interesting characters and a bit of a narrative keep things moving, but this is really just icing. I have played several of these games and have failed to finish a single one. They just don't draw me in or motivate me to keep playing. Despite this misgivings, I had heard some interesting things about L.A. Noire and a sale on Steam convinced me to give it a shot.

Five minutes into the game I was more engaged than at any point in the publisher's past games. This was almost certainly due to the incredible immersive UI design. It begins with the opening menu:

Opening menu

In case it's not clear from the above image, the menu options are shown as shadows on the wall. At this point I just thought it was merely an interesting artistic choice and started a new game. The game begins with some fairly standard narration describing the general setting (who are you, where are you, what are you doing), but you soon arrive at a crime scene. There has been a murder and it's your job to search for evidence. As I picked up a piece of evidence, I was expecting a short cinematic explaining what I had found. Instead I was greeting with something like the following image (I was examining a gun instead):

Investigating evidence

Your controls rotate the image in your hand as you look it over for clues. Hold steady on a certain area for a moment and you are rewarded with an exclamation from your in-game character, "Serial number 01138, let's get to the local gun shop and check for some leads." The game designers could have chosen to just play a video showing the player what clue was discovered, but instead they let you hold the evidence and look it over for yourself. The result is the same either way, but one is altogether more engaging.

After discovering this new lead, I am told to hit 'tab' to open my journal and review the evidence. I expected a traditional menu showing where I should go next, but I was greeting with the following:

The notebook menu

Your cursor is gone, replaced by a pencil hovering next to the currently selected line of text. Again, a traditional menu would have provided the same functionality, but it also would have served as a reminder that I was playing a video game.

Good books are great at immersive story telling. The scene is described by the author and the imagination takes over, placing the reader right in the middle of the action. Movies and theater can also accomplish this feat if done well. Games, despite their inherit interactivity, usually do quite poorly at this task. Heads-Up-Displays and obtrusive menus serve as a constant reminder that you are playing a game. You are not an LAPD officer in the 1940's, you are sitting at home in front of a computer. By making the menus and interactions more organic, L.A. Noire attempts to succeed where most games fail. It still has several traditional menus and a mini-map in the corner of the screen, but the game was certainly designed with player immersion in mind.

I wonder if the Mystery at the Museum game could benefit from a similar treatment. The photo mechanic certainly lends itself to an immersive, first-person experience, as does the exploration element. I would be interested to see if a minimal, true to life UI could used in this game. Instead of cards in an inventory menu, maybe the player is shown a hand holding several polaroid pictures. The main game board might not be needed at all if the scenes included doors for the player to walk through into the next room. It would be a difficult design challenge, but I am interested in hearing some opinions about whether it might be something worth pursuing.

Wednesday, February 8, 2012

Discerning the Transmundane of Game Design

I was reading excerpts Jesse Schell's The Art of Game Design and I came across several gems that I feel we(game designers) need to remember throughout the entire process of making these things that we call games. I'll try to make this to the point as much as possible.

Schell starts off by defining the skills a game designer needs which are listed alphabetically as follows:
  • Animation
  • Anthropology
  • architecture
  • Brainstorming
  • Business
  • Cinematography
  • Communication
  • Creative writing
  • Economics
  • Engineering
  • History
  • Management
  • Mathematics
  • Music
  • Psychology
  • Public Speaking
  • Sond Design
  • Technical Writing
  • Visual Arts

Yep. So thats it. Just those. No big deal. Except for the small inconvenience of all of them minus "brainstorming" being an entire major in and of itself.

This list isn't meant to scare. It's just meant to point out how interdisciplinary game design actually is.

However the most important skill that Schell mentions didn't even make that list. The most important skill he mentions is Listening. Schell goes on to say that it doesn't just require listening to someone's words when they speaking to you, but also listening to what someone isn't saying and being able to read between the lines to determine the message someone is actually trying or not trying, to convey through speech body language. You also need to listen to more than just other people. The different types of listening Schell describes are:
  • Team
  • Audience
  • Client
  • Self
  • and Game
The last two need a bit more explaining. Listening to yourself might sound simple enough, but accurate introspective analysis takes practice. Some do it through meditation and others do it by keeping a journal(or a blog). It is important because it can help you to be more creative, more empathetic, and ultimately help you solve the ever impending question of "how do I do that?".
Listening to the Game sounds stupid. It certainly felt stupid reading it. It felt stupid writing it. "What are we going to get all tree-huggin-hippy-there-is-no-spoon-zen now?" I thought to myself. The answer was/is "kinda". The analogy Schell used is listening(paying attention to) how your car runs. If the starts making a funny noise, or the engine light, comes on, or it just won't start you examine and assess the problem (or pay someone to) and then fix whatever that problem is. Whether your game needs a new fuse or it threw a rod, it's important to be able to recognize what is actually occurring during game play and not just what you see happening.

Schell presents 8 questions to test whether or not your prototype is "finished", "ready", "done", "complete", or any other term meaning "I'm not going to attempt to make this better any more (for now)".
  • Artistic Impulse- This is your gut feeling or intuition in relation to your opinion of whatever it is you are working on at the time. How do I feel about this?
  • Demographic- Is this right for my audience?
  • Experience Design- Is the game well designed/is the player experience what was intended?
  • Innovation- Is it a novel game/is it new or different enough to make it stand out/is it a clone?
  • Business-Will it sell?
  • Engineering- Is it technologically possible to create?
  • Social/Community- Does the game meet its intended social requirements?
  • Play Testing- Do play testers like it?
If at any time during the prototyping process you ask one of these questions and the answer is either negative or just not the answer you wanted, stop what you are doing and make a change to your prototype to get a positive answer, the answer you do want, or at least closer to the answer you want.
Note: If what you were doing at the time you asked yourself the question was attempting to answer that question or a different question finish what you are doing then move on to the next question if necessary.

These filters should be used after every iteration of a prototype until a prototype passes through all of them unscathed. It's important to understand that they aren't intended to create more work for yourself, but to make sure you are actually working towards creating the Experience you want players to have. Schell points out that point explicitly when he defines a Game Designer. Designing the actual game, whether digital or physical, is inherently secondary to what a Game Designer is actually supposed to do: Design and Experience. To that end the game itself could even be considered irrelevant. Just a means to an end. If a player experiences what I, as a game designer, intended them to experience then I win. Now the only downfall of that is that we as Game Designers can only directly design the game, not the experience. Which is why we still need to focus on the game itself in tandem with the experience, because without knowing how to change, fix, or design a game, the only way we could ever hope to design an experience is sheer unadulterated luck.

Which brings us to:


First of all, if whatever it is you do or did, if at any point you able to look back on it and say "I learned something", then that event, period of time, or action automatically becomes NOT a waste of time.

However, there should be a question that every iteration of a prototype should be trying to answer. I don't meant questions like "why are we here?" or "what is the meaning of life?". These questions are usually quite specific and should be answered one at time i.e. "what if we use dice instead of a spinner?", "will it still be fun if the theme is different?", "what happens if I add a time constraint?".
If at anytime during the creation of a prototype you cannot answer the question "What question is my prototype trying to answer?" with a coherent one-sentence question then you MUST STOP WHAT YOU ARE DOING because you are in fact currently WASTING TIME. A prototype should only be built if it is trying to answer a question, other wise what you make isn't really a prototype. It's just a thing.
After reading this out of Schell's book I immediately realized retrospectively that the last prototype I made had been a waste of time. However, because I realized that it was a waste of time, I now understand more what that looks like and how to identify it. So it wasn't really.

A waste of time.


...That it wasn't really wasted time
-Don Henley

Tuesday, February 7, 2012

Writing for _Video Games_by Steve Ince

As we continue down the adventure of game design during this immersive learning seminar, we dig deeper to discover a balance between learning and fun for our target audience. At this point, an obstacle we are against is going beyond the development and pushing the limits to find something really valuable.

For the “Humanities Group” (aka. Non-Computer Science (majors)), we have designed a list of literature necessary for us to comprehend to iron out kinks in our system (as well as for accreditation purposes). The list includes, but is not limited to the following:

What Video Games Have to Teach Us About Learning and Literacy

A New Culture of Learning

Ultimate Guide to Game Writing/Design

Writing for Video Games

Making Transmedia

Reality is Broken

Exodus to the Virtual World

Indirect Procedures: Musician’s Guide to Alexander Technique

Digital Storytelling: A Creator’s Guide to Interactive Entertainment

Philosophy Through Video Games

Chris Crawford on Game Design

The Art of Game Design

Game Design Workshop

Steve Ince said in his book Writing for Video Games "...what players love are the characters and the stories told about the whole world they inhabit..." This book explains how vital the role of a writer is when it comes to the collaborative game design experience. The audience will be captivated by the setting, plot, characters, conflict, etc. rather than the point-click of a game.

In the past, designers used to be the writers. According to Ince, now novelists and storytellers are brought onto the team to enhance the overall quality of the game and player satisfaction. Designers and publishers recognize the value of a good story, strong characters, and a well written dialogue.

Ince describes professionalism in game design as essential. Through design to production, delivering on time is crucial. An acceptance of criticism must be expected, but furthermore, the consideration of said criticism and adjustments to prototypes need to be seriously considered. Anything less than professional is cheating players out of the experience and threatens their future financial support.

Interactivity is seen in endless modes throughout genres of games. Ince uses the example of cut scenes. Cut scenes can be rewarding for a player if it is shown at the end of a level. An option to spread audience captivation is to allow a player to skip past the cut scene. The diversity is opened up by doing so, rather than limiting players to a specific niche. This is best done when a player feels the story unfolding rather than meeting premeditated outcomes.

Though Ince thoroughly explains a handful of genre's, two specific fields are relative to this project. Children's games need to designed to have an easy interface, clear instructions, a unique reward unusual to more mature audiences, and generally run on smaller budgets. Educational games generally run on a series of fun activities rather than puzzles, fun sound effects and characters as incentives to play, and often have printable options to physically show progression outside of the game. I believe these are key goals that should be incorporated into our project this semester as we build an educational game for a targeted audience of approximately age ten.

Our paper prototypes are rapidly changing at this state in the process. I think that now we are at mid-sprint, it is important to make concrete decisions on the mechanics of our prototypes and remember our two key goals. 1.) Stick to a learning objective and 2.) Make something fun. Somehow there is a science in balance of those two goals with a beautifully written script and aesthetics. Is that the value we are looking for?

Hey, at least this is only Sprint 2!

Thursday, February 2, 2012

Just one perspective: Sprint 1

Game design is hard. As somebody with little programing experience, the tediousness of play testing edits/versions of a game has been the most challenging aspect for me thus far. Every round is thoroughly critiqued and ideas are spit-balled by the dozens.

For new readers: our semester is broken up into two-week sprints. At the beginning of each sprint the team meets and conducts a morning meeting evaluating the goals we need to reach, the steps to accomplish the task, and time management those steps. Each day we have a SCRUM meeting for roughly 15 minutes where we individually give a brief and informative speech on what we accomplished yesterday, the goals for today, and hurdles we for-see having to cross. The final day of the sprint, the team reconvenes to evaluate the execution of the goals we set earlier.

Sprint 1 was intense. We had our individual responsibilities, but the main goal was to develop as many prototypes as possible. Prototypes of games needed to include key feature such as: be fun, relate to a list of topics that parallel to exhibits at the Indianapolis Children’s Museum, and function logically after play testing.

Several people had many proposals. The primary focus: Creating a “fun” game. A majority of prototypes were sent to the “graveyard” in the first day’s trial. Personally, most of my ideas didn’t make it to paper prototype stages let alone even to play testing stages.

At the end of the sprint, the entire group discussed prototypes that out shined the others. Though a large handful made it to the white boards, three of which were heavily preferred when asked the big question, “Which do you want to present to the Indianapolis Children’s Museum?”

Thankfully each of the three teams has great minds working together, accepting creative progress, analyzing the best outcome, and working collaboratively to design pretty amazing prototypes. We will present these to the Indianapolis Children’s Museum within the month once we polish up the details.

There is a lot of respect between members and individual incentive is overall outstanding. Through the frustrations we strive and resolve to productive solutions. I wouldn’t jinx it by saying it out loud, but this is quite possibly one of the best environments for college students to create something amazing. It is inevitable for problems to arise throughout development. Our goal is to design the best solution in order for the final outcome to be fun, educational, polished, and meet our target audience's expectation. Game design is hard.