- Rapid Physical Game Design:
- Rapid Physical Game Design:
Rapid Physical Game Design:
Challenge 1: Puzzle Problem
Game Rules:
Collaboration with Tommy Benson and Jeremy Salo
-
This is a game for two players.
-
What You’ll need:
-
A timer or stopwatch
-
A set of playing pieces (provided)
-
A physical barrier that prevents the two players from seeing each other’s materials.
-
Deck of the puzzles (shuffle before playing)
-
The two roles
-
The Descriptor: Using a set of images that cannot be viewed by the constructor, the Descriptor’s role is to verbally explain the structure they see in their set of images.
-
When the round starts, the descriptor grabs one puzzle from their deck of puzzles. Once the descriptor sees the puzzle, they ask if the constructor is ready. When the constructor says yes, the round begins. Use the stopwatch to time the round.
-
The Constructor: Using the verbal information from the descriptor, they are expected to reconstruct the structure with their set of pieces/props.
-
Players switch roles after each round.
-
Note: The youngest player is the descriptor first.
-
Constraints
-
The two players cannot see what each other has.
-
The Descriptor cannot see what the Constructor is making
-
The Constructor cannot see the images the Descriptor is using.
-
The Constructor cannot ask questions to the Descriptor, but they can ask the Descriptor to clarify what they’ve said.
-
The Descriptor can only communicate the instructions verbally. They can not show any visual information.
-
Rules/Scoring
-
Each round only lasts two minutes and thirty seconds (2:30)
-
At the end of each round, the barrier is put down and the image and the physical set are compared. The two players win if the image matches the constructor’s set.
Examples:
-----------------------------------------------------------------------------------
Challenge 2: Blind Fire
Game Rules:
Collaboration with Alex Cano McConnel, Kelia Murata, Quincie Neale, Ben Efram, and Richard Bui
Players:
-
4 players separated into two teams, each team has
-
An Attacker
-
This player is blindfolded
-
They cannot speak or their team loses
-
They start out with their arms at their sides
-
A Watcher
-
Cannot go into play space, but can move around it
-
Watchers are paired with Attackers, one of each type on each team..
Goal:
-
Hit the gut (front) of the opponent at elbow length.
-
E.g. elbows have to be bolted at the side
Rules:
-
At the start of the game Watchers spin the opposing team’s Attacker and place them somewhere in the 8x8ft. play space (marked with cones/tape/anything).
-
No one can talk during this point of the game
-
This is the only time Watchers can enter the play space square
-
The team with the youngest player gets to call out the first move
-
Watchers lead their own Attackers using verbal communication
-
At any command except ‘Attack’, the Attacker’s arms must be at their sides
-
Watchers takes turns commanding Attackers
-
Watchers can only use one word commands
-
Suggestions for communication:
-
‘Forward’
-
‘Backwards’
-
‘Left’
-
‘Right’
-
‘Turn’ (Tip: Watchers could move around the space to dictate direction of attacker.)
-
‘Attack’
-
Once the Watcher is confident that their Attacker is in place they can give the ‘Attack’ command. To attack, with elbows bolted to their sides, raise arms straight up in attempt to hit opponents chest as seen below. Hit must hit the stomach/chest of opposing attacker to be considered viable.
-
If an Attacker steps out of bounds, then their team is disqualified
-
If the Attacker moves without consent, then their team is disqualified
-
If the Watchers step into the play area, then their team is disqualified
Attacking motion:
Playtesting Prototype Notes:
-----------------------------------------------------------------------------------
Challenge 3: Starry Five
Collaboration with Julia Jones and Jeremy Salo
Game Rules:
This game is meant for five players.
Each player will be a designated color: Red, Orange, Yellow, Green, and Blue and have five beanbags of their respective color.
-
Each player will be in their respective territory lines
-
Players may stand in any of the four rings directly in front of them, but must be on one foot
-
Once the game begins players toss their beanbags into rings NOT within their own territory
-
To score a point, one of a player’s bags must land in a ring of the corresponding color
-
Players may block incoming bags using one foot.
-
Players lose a point if one of the rings in their territory has a bag (of any color) in it.
-
At the end of the game, points are tallied. The player with the highest total points wins
Playtesting Notes: People misunderstood what to do with the extra beanbag
More than one beanbag in one ring - just one point (clarify this in rules)
Are beabags out? - use your best judgement
Players got into tiebreaker - figured out that they cannot defend
-----------------------------------------------------------------------------------
Challenge 4: Collaboration Nation Infiltration
Collaboration team: Hannah Tindal, Alex Cano McConnell, Ben Efram, Jeremy Salo, Hanna Pardee, Kelia Murata, Tommy Benson
Objective of the game:
This is a game for 8 players, two teams of 4 each in a separate space. Each of the 4 players will start in different corners of the play space. The teams will have to work together to retrieve balls of a certain color from the bowl, this color determines what corner you must return to (the corners color is dictated by its cone, which cannot be moved) as well as arrive there with the matching colored ring. (ie by the end of the game your ball, ring, and cone/corner must all be the same color, but not necessarily the same color that you started with)
Set up:
Both teams of four have 5 minutes to set up the opposing team’s obstacles. This includes setting up the string (security lasers) and the location of the bowl of balls (jewel case) within the space, and choosing what rings go in what corner.
Each team will have one NPC runner who is able to return the travel ring, determine whether a player touches the trip wire.
Restrictions:
-
The string may only have up to 8 anchor points and may ONLY be attached using tape to the four walls around the space. You may not wrap the string around the tables/walls. The tables/board/walls may not be moved.
-
The bowl of balls must stay within the space and not placed inside any of the rings, but may be placed next to a ring.
-
Each corner must have a cone and a ring (red, blue, green, or yellow. They do not need to match) The movement ring (purple) must be placed by any one of the four corner rings(within stepping distance).
-
See image below
During Play:
-
All four players simultaneously attempt to reach the bowl without knocking it over and grab a ball, then travel to the corner with a cone of the same color as the ball they retrieved.
-
Players may not share rings (Be in the same ring)
-
Players may ONLY have one ball at a time but may hand another player a ball.
Movement
-
You are considered standing “inside a ring” as long as you have two points of contact within your ring (i.e. if a player must put down a hand when traveling through trip wires, they are allowed to do so if they have two points of contact inside their available rings).
-
Players may ONLY move by stepping into the travel ring, and passing the ring they stepped out of to another player (that ring becomes the new travel ring) .
-
At the start of the game the purple ring is the travel ring. There is only one travel ring at a time.
-
The current player with the travel ring steps into that ring and passes their previous ring to another player to allow the next player to move. The previous ring then becomes the new travel ring.
-
When the player passes the movement ring, players must move to where the ring lands, they cannot adjust its new location.
-
If the movement ring is unreachable, players can recruit the help of one of the NPCs to retrieve the ring and give it back to the original thrower.
-
Players must slide the fifth ring (the Travel Ring) to each other to allow movement through the space (you may slide in any order).
-
When passing the ring, players cannot slide the ring to move themselves and must coordinate with the other three players to move.
-
Players have a choice to either step into the travel ring or they can pass it to another player.
Player Reset
-
If you are caught outside a ring, touching a tripwire, or if you knock over the bowl players must reset the space (this changes based on what you touch).
-
Note: tripwires only triggers when contacted with the body, not loose clothing. NPC runner judges use best judgement
-
If you fall outside your ring or hit one of the tripwires, you must return to the corner you began the game in with your current ring and must return your ball to the bowl.
-
If you knock the bowl over during this kind of reset, it doesn’t count as a full reset for the team.
-
If you knock over the bowl, all players return to their starting corner and must return all the balls to the bowl.
-
If a player has successfully made it to their correct corner with the correct ball and ring, they become immune to these reset conditions.
Win State
-
Once you have a ball and you are in the same colored space, you must be standing in the ring of the SAME COLOR as the ball you are holding. Once all players have met this requirement they have completed the game. The first team to complete their task wins.
Example of win state
Playtesting Notes
-----------------------------------------------------------------------------------
Programming for Play:
Project 1: The Beginning
Pardee_Programming4Play_Challenge1.zip
Modified the car class as well as created a scene with my own sprite with its own scripts.
(Photo is N/A as the original file was modified for Project 2)
-----------------------------------------------------------------------------------
Project 2: Combining Forces
Collaboration with Kelia Murata
We combined our two projects together. I used the car scene with collecting tokens. The objective of my game was to collect 5 green tokens whereas Kelia's game took place in the space game. She had the player collect satellites while avoiding asteroids. As a result, our goals were too similar. We decided to combine forces and created a new goal. We had the player collect at least, 5 satellites and return back to earth. We added a background, bounding boxes, a new end goal sprite (earth), healing tokens from the car scene.
-----------------------------------------------------------------------------------
Project 3: Inferno
Collaboration with Richard Bui
BuiPardee_Assignment2(Update3).zip
A multiplayer game where a sister and brother got separated and caught in a house fire. Using the arrows keys and WASD keys, the players must work together. They must navigate through the maze, gather and exchange keys and escape the location together under a time limit.
Playtesting notes:
Players seemed to confused to the 'windows' where the keys are exchanged.
Suggested that the players shouldn't have to backtrack to the windows
Players kept getting trapped in corners - both positive and negative feedback about the corners;
Good: works with the burning house narrative
Bad: May frustrate the player when playing
Enjoyed the aspect of the mazes changing each time played as it gives variety and changes difficulty.
Need to add a exit collider for players who are not at the window as the players exchanged keys when one player left the window area. (Key basically teleported)
-----------------------------------------------------------------------------------
Project 4: Blue Blob Bounce
Collaboration with Tommy Benson, Alex Cano McConnell, Jeff Mutchnik
A obstacle course game that was inspired by tetris and super mario. The players objective is to navigate through a terrain with falling blocks that they must use in order to pass the obstacles.
Playtesting Notes:
-People had issues navigating through the obstacles as people get stuck under the blocks, incapable of movement.
-Jumping is weird when on certain areas.
-Most people liked the concept however!
Final Game Project: Vapor
Collaboration with Kelia Murata, Jeffery Mutchnik, and Stone Fisher
Indigo ________ Posse presents
Objective:
Vapor is a multiplayer, collaborative based game where a Kinect player, who has control of gravity and help two players who play as Novis and Aquaphis navigate through various mazes to collect their respective gems and reach the door.
Restrictions:
-The game must have at least three players
-Employ a Kinect Sensor as well as a large scale projection in ways that is responsive to bodies moving in the space
-The game must be simultaneous
-The game must be programmed for 2D in Unity
Diversifiers used:
-Conceptual Constraint: Unify/Divide
-Bit Shifter: Electronic wireless networking of non-contigious spaces
-Untethered Control: Meaningfully makes use of wireless controllers
The Game-making Process:
The Players and roles:
Aquaphis and Novis:
During the brainstorming phase, my team, Indigo___Posse and I decided on the two themes of Unify/Divide and came up with the two sprites of Aquaphis and Novis that represents fire and water. In the sense of opposing elements, they are divided. However, we also came up with a third element of the game, steam. When water and fire merge together, they create steam, representing unity. This idea became a new mechanic we wanted to add into the game where the two players merge together in order to fit through tight spaces, introducing a new element in the game. Unfortunately, due to time constraints as well as unexpected obstacles, this element never made it to the final game.
The players control their respective player with a wireless Playstation controller with a fix, zoomed in screens that follows the players. These players have the ability to jump, move left and right, pick up gems, and switch cameras.
The Kinect:
The kinect player had the overview of the entire maze unlike the players who are zoomed in. Their objective is to use the gravity lever accordingly and ensure that the players are in position before the gravity switch. In the brainstorming process, the kinect player had two functions. A gravity-changing lever and a pointer. Because the player's screens were zoomed in, they would need some guidance in order to get in the correct position. Like the steam, the pointer did not make it into the final game. The lever however worked very well in the final game prototype!
Hardware:
1 Vapor game executable
2 Macbook Pro computers
3 HDMI Cables (at least one 25ft, one 20ft, and one 6ft long HDMI cables)
HDMI to Thunderbolt converters if necessary
2 projector
1 TV or other projector
2 Projector screens
Alienware bundle
Alienware box
Display Screen
HDMI cable
Power cord
Keyboard
Mouse
PC Kinect V2 bundle
PC Kinect V2
Power cord
PC Kinect converter USB Dangle
2 PS3 wireless controllers
8 free power outlets
Software:
Kinect V2 OSC
KinectA
Hardware complications...
Originally we were going to use three displays with just my laptop along with three displays and it was working well for a good week until display 1 on the main monitor just...stopped working. As a alternative, we worked with the OSC networking to make the functioning as intended.
My Contributions as a Programmer:
I am pleased to say this game has challenged my skills as a programmer and I have improved as well as learned a lot. While I did have existing experience with Unity, I did not believe that I was experienced enough to truly succeed. Through determination and help (from Bill and others; thank you so much!), I was able to get the scripts needed for the game.
The Kinect and OSC networking tested my patience as it was a brand new territory to work with but I am happy that I rose to the challenge because I have learned tremendously about the two. It has improved my programming skills.
The scripts I created and/or worked with...
-CameraFollow
Works with the camera that follows the players and switches between the two players when a certain button is pressed. Originally used FollowPlayers Script but it contained rotation values that could not work with the OSC. so new script was created. (I also want to mention that I did grab some code from the internet for FollowPlayers so that script is not entirely mine. However it was not used ingame)
-Camera Activation
Is used for the different displays that is projects on different screens. Display 1 being Kinect perspective, Display 2 and 3 the players perspectives. (Display 3 being upside down using the projectors settings).
-GravityShift
Script that shifts the gravity aka changing the sprite's local scale of y as well as the gravity scale found within the RigidBody2D.
-CollisionWButton
A script that allows interaction with the lever used for the Kinect.
-FinishLevel
A script that is attached to the door that checks to see if the two gems are brought to the door and moves to the next scene/level if both are present.
-fireGemPickUp
-waterGemPickUp
A script that is attached to the gems and checks to see if the respective sprite (Novis with fire gem and Aquaphis with water gem) collides with the gem and attaches it to the sprite if collided.
-FireMovement
-WaterMovement
Stone started this script and I modified as well as added some part to make movement working ingame.
-Respawn
Attached to the colliders on the 'death areas' that respawns the sprites in the initial respawn areas.
-GameControlScript
A script that keeps track of the currentLevel to ensure correct scene transition and helps with other scripts that relates to the current scene.
-ManageInput
-ManageInput1
-ManageInput2
-The Kinect Scripts that detects certain parts of the body, works with the kinect function and communicates with it.
-OSCReaderScript
-Allows OSC between devices.
-GravityManageIn
-Receives the signal from the other machine to indicate gravity shift.
-LevelZeroMenu
-StartMenu
Both of these worked with the OSC networking and buttons that switches scenes for controls and main menu.
-OutMenu
-Sends the signal to the other machine when to change to the controls.
-OutputLocations
-Started by bill and continued by me and Kelia that communicates the fire/water sprites' location to the other computer.
Playtesting:
Pros:
-The majority of the game was functional and playable! (yay)
-The OSC networking worked as intended
-The players had a lot of fun playing the game
-Enjoyed the aspect of disorientation of the upside down screen.
-Enjoyed the art (Props to you Kelia and Jeff)
-Fun! (yaaaay)
-The teamwork aspect worked really well with this
Cons:
-Bugs...bugs everywhere
-One of the screens is a scene behind sadly
-The Kinect close hand was not responding through OSC (it seemed to be closed all the time, it was strange)
-Controllers didn't work, keyboard was used instead
-A lot of the concepts intended from the beginning didn't make the cut
KinectOverview 2(9;55).zip - Kinect Overview perspective file
Closeups(1).zip - Two players file