Are your typing skills getting rusty from all the "texting" you kids have been doing? Have you forgotten which keys are in the home row, or how to spell complete words?
Well, put on your headphones, turn up the volume and take a spin on the Touch Typist to get reacquainted with your estranged keyboard, and you'll be back to pounding out whole sentences in no time! Be sure to come back to the blog and post your high WPM average!
Tuesday, November 6, 2007
Play Prototype #2!
Wednesday, October 24, 2007
Prototype #1 Post-Mortem
Composed by Chris Crone, Programmer
After Prototype 0, we decided that Prototype 1 would be about an ethical dilemma about deleting an android’s memories, and that I would champion the effort. Prototype 1 would feature puzzle games representing the player hacking into the android’s brain. During puzzle games, the player would hear emotive sounds from the android, and these sounds would convey information necessary for solving the puzzles. Ostensibly, the goal of Prototype 1 was to show that players will become more aware of emotive sounds if those sounds also carry information relevant to the players’ game goals.
What Went Right
From the beginning of work on Prototype 1, we shaped a design that would incorporate a sizeable amount of work from each of our respective disciplines: art, programming, and writing. This allowed each of us to focus on doing the best work possible with our individual disciplines, without worrying too much about pipeline dependency issues. By the end of work on prototype 1, each of us had produced good quality work as individuals, and we had a coherent game that incorporated that work.
About half way through work on Prototype 1, we got some very useful ideas and feedback from Jesse Schell about the direction of the prototype, and we subsequently refined the goal of the project. From that point, we started focusing our efforts more specifically on making players feel conflicted over whether they should delete the android’s memories, or whether they should continue to investigate the memories. If we could craft the game such that half of players would want to investigate all the android’s memories, while the other half of players would stop investigating the memories because they felt bad about causing pain to the android, then we could conclude that players were emotionally involved in the game’s decisions. Targeting the development of the prototype towards this goal lent some clarity of focus to our work.
When we stopped work on Prototype 1, it was complete in that it had all of the features we had planned for, and we were able to conduct instructive external tests with the finished prototype. Although the prototype wasn’t successful in making players feel conflicted over whether or not to continue investigating the android’s memories, we were able to gather useful information about why players weren’t conflicted, and what we could have done differently to amend that situation.
Experimental Findings and Analysis
We had more than a dozen external players test the game, and all of them wanted to investigate the android’s memories to completion. Some of them didn’t actually investigate the memories to completion, instead getting stuck at some point in the puzzle and deleting the android’s memories out of sheer frustration. However, no one deleted the memories out of pity for the android.
After collating feedback from the test players, we could identify a number of reasons why people would want to investigate all of the memories:
1) The memory movies tell a story of increasing interest. People want to see the memories’ story through to conclusion, and they want to understand the game’s back story.
2) There is an authoritative character who clearly instructs players to continue investigating the android’s memories. This is an especially relevant factor for players who may be confused with the interface, or generally players taking some time to understand what the game wants from them.
3) Investigating the android’s memories is done by solving the game’s puzzles, and there were some players who were simply compelled to complete the puzzles for their own sake.
Most players said that they did feel empathy toward the android, but that those empathetic feelings didn’t factor into their choice to investigate the android’s memories. In other words, players were aware of both the consequences affecting the android, and of their choice to affect the android; however they did not feel a significant connection between their choices and the consequences for the android.
When asked why they didn’t feel this connection between choice and consequence, some players suggested that they would have felt more responsible for the android if she had provided more feedback to their actions. For example, when the player makes an action that brings the puzzle closer to solution, the android could say something like “Stop, you’ll make me remember Janey dying!” This type of feedback would make it clearer to players the relationship between their choices and the consequences affecting the android. In other words, players would have been more emotionally involved in the decision about the android’s memories if the android had been a more reactive character. Prototype 1 exemplifies that reactivity in virtual characters not only makes those characters more plausible and immersive in general, it is especially important for emotionally investing players in their choices regarding those characters.
As for what we can conclude about the supposed experimental goal of the Prototype 1, whether players gain heightened awareness of emotive sounds when those sounds carry information useful for the game, conclusions are harder to draw. Towards the end of developing Prototype 1, we had to settle for a puzzle design where sounds are extraneous information to the player, because puzzles that required information from the sounds in order to be solved were too difficult for players. Because the emotive sounds were redundant with other, visually presented information, players did not pay much attention to them or comment on them.
What Went Wrong
That we couldn’t draw conclusions about sound as a game feedback device was but one symptom of some underlying, deep-rooted problems plaguing our project. What happened in the case of sound was that there was some ambiguity over who was responsible for handling sound design tasks, and those tasks were delayed while we focused more on our respective individual disciplines (art, writing, and programming).
The underlying problem on this prototype was an absence of clearly stated goals that we could all agree to. I said in the background of this document that the goal of this prototype was “ostensibly” to experiment with emotive sound as a game feedback device, but in fact we did not share the understanding that that was our goal throughout the development cycle. As a result, the prototype suffered feature creep (some features were added that were not strictly necessary for the purpose of our experiment), and some work that would have made the experiment more successful was neglected.
While in retrospect it may seem like a painfully obvious mistake to proceed in development without clearly stating and agreeing to our goal, it is important to examine the reasons why we didn’t do so:
1) Although we did not have a clear, shared goal, we did have a shared plan for the design of Prototype 1 from day one of development. We thought this meant we were in agreement about what we were doing, and we were wrong. Without a goal, nothing will guide the inevitable changes that happen to a design, and nothing specifies which parts of the design are critical, and which parts can be put off until later. Having a shared design without a shared goal gave us a false sense of security about the team’s communication process.
2) Personally, I was reluctant to impose my ideas and objectives on my teammates more than necessary, and hence I failed to be more pro-active with clarifying our goals (and I think the rest of the team might share variations on this sentiment). I erroneously thought that this would allow each of us to have more creative input and be more invested in our work. This thinking was a critical mistake: While it is important for each team member to have creative input and control over his/her own work, the desire for these things absolutely cannot come before the need to have a single, shared goal that everyone agrees is the top priority. Otherwise, it’s not the work of a team.
Conclusions
Analysis of feedback from our test session suggests that making virtual characters reactive to player actions is especially important for making the player cognitive of the connection between the player’s choices and consequences that affect the virtual character.
For our team moving forward with later prototypes, it is essential that we are pro-active about clarifying exactly what goals we’re trying to achieve with each prototype. In each case, we need to reach a consensus about these goals. Furthermore, we need to be willing to have critical discussions about our prototype designs, where we consider which parts of the design are most important for reaching our agreed goals and take subsequent action.
Background
Project Context is a student-pitched project at the Entertainment Technology Center, initially with the goal of creating a gameplay system based on character interaction. Early in the semester, we the team members were not reaching consensus as to how to create such a gameplay system, and a change of plans became necessary. Our faculty advisors identified that, while we had different opinions about how a character-based gameplay system could be created, we all shared a desire to make games more emotionally immersive. We agreed to a new project goal: “To create prototypes that find new ways of emotionally investing video game players.” To pursue this goal, we would create a series of prototypes, each in two weeks, and each with a different team member serving as the champion / director of the prototype. Before creating experimental prototypes in earnest, we quickly created Prototype 0 to establish our work pipeline.
Friday, October 19, 2007
Play Prototype #1!
It's the near future. You have been tasked with retrieving memories from a damaged android, in order to find out how its charge, a young girl of about ten, died.
There is, of course, a catch.
By solving the sound puzzles that hide the memories, you place the droid in an extreme amount of pain. The situation becomes exasperated once you realize that by the girl's story, you force the companion droid to relive the death of its master, again and again. Do you continue blindly on your assignment, or do you take pity on the droid and wipe its memory, freeing it from the misery of the past?
Click here to visit our project site, and then head back to the front page and answer the poll! Read More...Thinking about the Funny
"In How To Write Funny, Esther M. Friesner writes, 'Your story need not be one long laugh-fest. Humor is dead serious stuff. In fact, humor gains depth when it’s about something more than just making the reader laugh. Food for thought—serious thought—goes down a lot more readily if it’s coated with a little laughter. Humor observes, analyzes and comments on the human condition, which can sometimes be a pretty scary thing to face head-on. Humor helps us cope with some of life’s harsher realities through laughter.'”
--From an essay by Tim Jackson
"Analyzing humor is like dissecting a frog. Few people are interested and the frog dies of it.” — E.B. White
Monday, October 15, 2007
Comedy "Secrets" from THE SECRET OF MONKEY ISLAND
So, with our new project goal of "trying to create a prototype where comedy is an essential game mechanic," the team did a lot of investigation into the history of games, looking for examples where comedy was the most successful. This brought me back to a game from my childhood that I remembered being extremely funny (and upon playing it again, I found it still holds up), which was Lucasarts' THE SECRET OF MONKEY ISLAND. Partly the brainchild of industry legend Tim Schafer, the team on MONKEY ISLAND took what could have easily been a standard "point and click" adventure game, and turned it into something quite a bit more memorable by lacing the entire experience with ripe, unexpected comedy.
Most of the comedy with MONKEY ISLAND is indeed a direct result of the writing, but its strength comes from the fact that the game’s writers accepted that most players will tend to make silly, unpredictable decisions in games, just to see what will often happen. This required a lot of guesswork on the writers' part in guessing the player's emotional state, and how that is likely to influence their moves and motivations. Schafer himself said it best:
The one truly innovative comedic game mechanic within
MONKEY ISLAND was mainly successful as a game, because it was the product of a lot of talented people that were unafraid to do something crazy within the adventure genre. I think if we are equally unafraid about our prototype, then we can potentially mine a brand new comedy mechanic as ingenious as "insult sword fighting."
Tim Schafer quotes pulled from Gamespot's "A Brief History of Video Game Humor" article:
http://www.gamespot.com/features/6114407/p-2.html
Tuesday, October 9, 2007
Post-Mortem for Prototype #0
When the semester started, the entire project existed in a swirling vortex of caution and indecision. When pitching the idea last spring, we knew that we wanted to create a story-based game that focused on emotions outside of the typical adrenaline/fear/frustration cycle so prevalent in the market today; that was the easy part. Knowing how to do that, though, is the tough part [notice how I said "is," as in "there's no perfect solution"]. We talked some over the summer, going back and forth on scripts and basic mechanics.
Then Fall came around. The entire team talked in circles, for the first two weeks, tossing around ideas that only our mothers would be kind enough to condescendingly remark, "Nice try," and pat us on the head. Luckily, Brenda and Jesse were not so benign.
This prototype came about after some difficult discussions with our advisors about the direction of our project. We decided that it would be a more efficient use of our time if, instead of focusing on one solution for the entire semester, we branched out and tried many different things. So, we got our goal in order, so as to provide focus, and brainstormed scenarios and mechanics for #0.
Within eight days, our first prototype was playable. While it doesn't represent the extent of what we hope to accomplish, we all learned many valuable lessons.
What Went Right
1. We built an interactive story.
Having a tangible result of all of our meetings, theories and experiences was a huge confidence boost for the entire team. We had proof that we could work together to create something, even though the structure was very similar to "Choose Your Own Adventure," just with less page turning.
2. We learned how to use Flash, AS 3 and XML.
Basically, everyone got a handle on the tools we would be using for the rest of the semester. Flash was used for animation, AS 3 for the coding, and XML for calling text to be displayed. The coding side was especially important, as we were able to build a framework to use for the rest of our prototypes.
3. We got more experience in voice direction.
Previously, we had used voice actors in other projects, mostly for our respective Building Virtual Worlds course. There was less emphasis on casting and quality then, and we felt that there was a great opportunity to use voice as another means of getting the player invested in the story. In addition to focusing less on quality, there was generally only one person in BVW recording and directing the actors. This time, we got a taste of having the writer and the producer agreeing on how the actor could approach a line, and then clearly convey that thought.
4. We made people laugh.
An unexpected reaction was that we made people laugh. It happened at first when we showed incomplete builds to some faculty members. Then, it happened again when we presented it to the university president's guests over the appropriately-titled President's Weekend. It was encouraging to see people responding well to our combined efforts, and maybe even planted a seed in our minds for future prototypes...
What Went Wrong
1. No Revolution, Only Evolution - Kinda
The system of controlling the intensity of a character's emotional reaction has the potential for interesting gameplay, but since it was coupled with a simple branching story, the impact of the mechanic was not felt by players. Perhaps if the intensity was an aspect of a larger system that gave the player a better idea of what their choice would result in, then there could be greater success.
2. Assets coming in from across the Pacific
In our team of five, we only have one artist. Toward the end of development, he went to the Tokyo Game Show, a trip that had been scheduled earlier in the month. It just so happened that there were still characters that we needed by time he left. These were built in less-than-productive conditions, and around the show's tight schedule. We ended up having to tweak Cathy right before the President's Weekend, but as mentioned before, the showing ended up going well.
3. No iteration
Even before we were done with this prototype, everyone was eager to move onto the next project. As soon as it was in working order, any enthusiasm that we had for #0 dissipated. As such, iteration was the last thing on people's mind. Also, since we were so far behind in creating anything, we were satisfied with getting into a project that we felt was strong enough to iterate on repeatedly.
What We Learned
The most important lesson learned was that enthusiasm is paramount to the success of any project. It is one thing to say that enthusiasm is key; it is quite another to know this fact and to see it in action. #0 also gave us a strong example of a safe prototype, something that wasn't bold in any way. It will always serve as a reminder, letting us know that we can do more.
Friday, October 5, 2007
"Greetings."
We request that you extract any relevant memory files within the android. Due their limited capacities, Model 37 droids have active storage for memories of immediate use, and compress unrelated files in their banks. This particular android has chosen to compress all of its files, and refuses to release them. Once you successfully isolate a memory, you will need to place a lock on it, so the droid cannot re-compress it. This will cause the machine pain, since it wishes to not recall these files. While the memories will be active constantly in its head, this is the only guaranteed method the authorities have to access these files for analysis. >>>Loading Manual Memory Access Program---------------- Thus begins the story of Zoë [pictured above] and Prototype #1. It will be playable this coming Monday, and polished for Wednesday's testing session. Check back soon!
"One of our Model 37 androids has malfunctioned, and the death of a human child may be involved. The local police department is investigating this matter, but has been unable to get a statement from the droid, as its vocal circuits and other functions are damaged.
Subscribe to:
Posts (Atom)