We had several problems arise while working on our Scaring Cats idea. We tried to begin simply by looking at the movement of the cat through an obstacle course. By then, we had already generated a number of objects that the cat could interact with (a bag would attract the cat and cause the cat to slide across the floor, a hairdryer would scare the cat away, etc.) We wanted to be able to model the cat's interaction with both the objects and the player (a dog who could scare the cat in certain directions) in real time. We attempted to do so by using a grid-based game space and allowing the players to alternate movements (as if in a turn-based game). We were forced to decide how fast the cat and dog could move. The cat, we decided, could move at one of three speeds (1 square/ turn, 2 squares, 3 squares) and the dog could only move at the cat's medium speed at the fastest (2 squares). We set up several play-throughs to test this motion, wherein one team member set up an obstacle course (with the goal that the cat would move from point A to B simply by influence from the objects attractiveness/ repellent power) and the others moved the cat and dog. We quickly discovered that we had not defined the cat's interaction with the objects closely enough. Here's an overview of what we found:

The problem with our current play-testing is that there are too many variables that determine whether the cat interacts with the object:

1. Each object has a different radius of interaction AND
2. The nature of this radius depends on the direction from which the cat approaches the object AND
3. The nature of this radius depends on the speed that the cat approaches at

If the interaction occurs at all (unclear) it is then difficult to determine HOW the cat interacts with the object:

1. Does the cat interact at all?
2. Which is the resultant cat vector direction (can depend on speed, entrance angle)?
3. What is the resultant cat magnitude?

Example:

So this means that our bag (which is only accessible from the 'front' and has a radius of the spaces located at (-1,1) (0,1) (1,1) ) has 6 directions from which it can be uniquely approached . [E.g. if that cat approaches from <0 1> it will always enter the bag, but if it comes from <0 -1> it will never enter the bag]. Notice how difficult already it is to describe interactions when the cat is not approaching from one of the 8 primary directions. For instance if the cat is traveling from (1,2) to (1,1) to (1,0), this is completely unique from a diagonal approach and yet had not been included in our original analysis.

The cat can also be traveling at one of three speeds, each of which may have a unique effect on the interaction. E.g. If the cat is to the North East of the box and traveling Westward (different spatial thinking then we were using before, but necessary to describe the movement) then it will enter at (0,1) if traveling at speed 1, (-1,1) if traveling at speed 2, and not at all if traveling speed three. So three speeds, six directions... that means there are 18 unique interactions that must be defined for each object. That's too many for a naive user to be able to just 'pick up on' while trying out the game.
If this seems confusing, that's because it is.

Solutions:

- Should we simplify objects down to basic properties? Similar to the excel sheet we were working on--need simpler objects with less unique properties.
- Should we scrap this idea and move to sinks and sources? May be even harder to model.
- Should we eliminate the ability to move diagonally?
- Should we reduce the number of speeds?
- Should we alter our thinking here--should the cat interact with the SPACES around an object the same way every time (regardless of the direction it entered the space) and maybe only vary based on speed.

o There are a lot of problems with thinking in 'vectors'

Posted by Genevieve Conley to Research | Permalink | Comments (0)  

Our primary goal with these prototypes was to explore the role of communication and information exchange within the game, particularly in terms of how this mechanism could be used to influence NPC characters. We wanted to examine a) how a player could obtain information regarding NPC's goals/ character/ desires, b) how a player could use this information to influence the NPCs to accomplish a common goal, and, to a lesser extent, c) how selective or lacking information would affect the scenario's outcome. Play testers (naive group members) were informed that their goal was to elicit the information from NPCs necessary to obtain a given objective.

Version e: Save Drew, Save the World

We approached this prototype by beginning with the scenario and working backwards to the characters. The scene was set with two houses. DREW was visible to the player and was in the YELLOW HOUSE. The player could also see DORIS and MATT who were hidden behind a ROCK. There was also a RED HOUSE to the north.

The goal of the scenario was to rescue DREW. DREW was stuck inside a house that was BARRICADED to keep out zombies (this was a point of contention at one point, see notes). The ability to take down BARRIERS was not available to all characters. The player was told that he/she was a good fighter and would win 5/6 times.

CHARACTERS:

DREW

- Loyal
o High follow orders
- Afraid
o Low fighting
- Weak
o 2/6 chance of winning fight

MATT:

- Trusts Doris
o High group with DORIS
o Follows DORRIS' orders
- Knows were PHILLIP is
- Normal fighter
o Kills 3/6 zombies

DORIS:

- Badass
o Kills 5/6 zombies
- Independent
o Will not follow orders that put her at risk

PHILLIP:

- Friends with DREW
o High will to group with DREW
- Knows how to build BARRIERS

We designed the level with the intention that the player would approach the YELLOW house to save DREW. Upon reaching the YELLOW HOUSE the player learned that DREW did not know how to take down BARRIERs and was trapped. The player could choose to fight the zombies at this point, seek out the NPCs, or visit the RED HOUSE. If the player approached the RED HOUSE, they would see a barricaded house and would not be able to enter. The player had to talk to MATT and DORIS to see PHILLIP. Upon talking to MATT and DORIS, the player would learn about the NPC's inner states. If the player asked them to join his/her party, DORIS would decline, explaining that she would not join the player if there was not a benefit to her/ MATT. The player could either demonstrate his/her benefit by killing the zombies or by furthering the conversation. If the player inquired whether MATT or DORIS knew how to take down barriers, MATT would respond that he could not, and if he could, he would save PHILLIP, who was in the RED HOUSE. The player could offer to save PHILLIP. Still, DORIS and MATT would not leave the ROCK unless sufficient danger was removed. Once the zombies were killed, DORIS and MATT joined the player's party and proceeded to the RED HOUSE. At the RED HOUSE, the player, MATT, and DORIS could together generate enough volume to alert PHILLIP to their presence. From here, PHILLIP dismantled the BARRIERS and would talk to the player's party. The player needed to convince PHILLIP to join his/her party. PHILLIP could be convinced if he was told the player wanted to rescue DREW as PHILLIP was friends with DREW. The player's party could proceed to the YELLOW HOUSE where they would rescue DREW. PHILLIP could take apart the BARIERS but DREW would not come out if there were zombies. The player could choose either to kill the remaining zombies or try to convince DREW to follow his/her lead. If the player ordered DREW to follow, DREW would follow, providing the player did not get too close to zombies.

NOTES:

- The dice rolling mechanism for fighting zombie's didn't work out so well, due to the still relatively high probability of death

• The randomization of the fighting was included for two reasons-- primarily to simplify the scenario, and secondarily to provide the player with a good reason *not* to engage the zombies. We wanted to include a sense of risk to knocking out zombies.
•This was not fully accomplished by the dice, as there was no real penalty in losing (play began over again).
•Perhaps a better way to model would include the use of a limited resource for fighting, so players must carefully choose which zombies to engage. This may also represent the players 'willingness to fight' as explained in previous posts.

- We needed to explain why DREW couldn't undo the barricades. The best explanation was, perhaps, because DREW entered the building with someone else who had been bitten. The person barricaded the room and then died. This was still a stretch.

• When using a GM to manage paper prototype playtests, this person must know the game *very well*. This is a problem we have encountered several times. A GM must be able to produce conversation on the fly and be able to explain why the set-up is the way it is. They must have a very clear understanding of the rules, and know how and when to answer questions. This is critical to a quality playthrough of the prototype.

Posted by Genevieve Conley to Research | Permalink | Comments (0)  

This week's Games At GAMBIT will feature a selection of games from Japanese developer Treasure, perhaps best known for Gunstar Heroes and Ikaruga. The games this week are lesser-known but all excellent in their own right, including:

• Radiant Silvergun
• Guardian Heroes
• Silhouette Mirage
• Sin & Punishment
• Mischief Makers
• Astro Boy

Games will run from 4:00pm to 6:00pm in NE25.

Posted by Jason Begy to Events | Permalink | Comments (0)