If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.
You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

Thomas_Benson

Page history last edited by TBenson94 7 years, 10 months ago

Programming for Play
Rapid Physical Game Prototyping
Final Project: Cthulu Ctharetaker

Programming for Play

Exercise 1: Remixed Game from Existing Project

Collaborators (1a):

Tommy Benson

Description of Assignment (1a):

Our goal was to create a game structure by re-skinning and re-purposing an example file.

My approach (1a):

I approached this exercise by swapping out existing sprites and getting instantiated prefabs to have a scripted effect on the player upon their creation.

Documentation (1a):

Project Download (1a):

Benson_Programming4Play_Challenge1.zip

Exercise 2: Collaborative Hybrid of 2(+) Games

Collaborators (2a):

Tommy Benson

Ben Efram

Stone Fisher

Description of Assignment (2a):

Using the re-skinned games from exercise 1, work with one other person to combine your two different ideas into one game.

Our Approach (2a):

We took Ben's story concept of a fruit fly who had to fly to gather an apple and mixed it with my existing car game that would adjust the player's health based on which pickups they ran over. The final result was a game that involved a flying fruit fly attempting to dodge fly paper and the negative pickups while trying to grab the apple at the top of a refrigerator.

Documentation (2a):

Project Download (2a):

Benson_Programming4Play_Challenge2.zip

Exercise 3: Social, Creative, Narrative, or Imaginative Play using Cooperation and Timers (aka Trust Fail)

Collaborators (3a):

Tommy Benson

Ben Efram

Kelia Murata

Description of Assignment (3a):

The aim of this assignment was to find a way to incorporate some form of social, creative, narrative, or imaginative type of play into a cooperative game while also building mechanics that involved the use of in-game timers.

Our Approach (3a):

Our group came up with a game involving social play by breaking the controls of a single protagonist across two different controllers. Player one controls the character's left-right movement, while player two can control jumping and realigning the character's position on screen. This splitting of controls was our group's approach at creating social play, requiring players to collaborate in the real world to communicate when to move and when to jump. There is added difficulty through falling objects that can knock the character around. In addition, we placed a timer on each instantiated platform in the level to cause the platform to disappear after a set number of seconds. To help convey this timed destruction, each platform is also tinted progressively more red to let the player know they need to keep moving forward. Lastly, we attempted to implement a scoring system that would mark the farthest distance the character would travel each playthrough. The scoring works as intended, but we were unable to implement a High Score system that would persist through multiple playthroughs.

Documentation (3a):

Project Download:

P4P Challenge 3 TB BE KM.zip

Exercise 4: Physics and 5:1 Ratio Challenge

Collaborators (4a):

Tommy Benson

Alex Cano McConnell

Jeffrey Mutchnik

Hanna Pardee

Description of Assignment (4a): This assignment was intended to implement a more robust use of the rigidbodiesand 2D physics systems found in Unity. This could include one of the following: proximity and repulsion (attracting or repelling objects), collisions that do not include projectiles, physics acting on non player objects. In addition, this assignment had a visual design challenge of designing the game in a 5:1 or 1:5 aspect ratio. This assignment also asked for the implementation of animation and diegetic sound effects.

Our Approach (4a): The original concept for our game came about from the idea of designing a platformer where the player would control a basic moving character inside the world of a tetris game. The player would have to bait the falling pieces into the correct location to use them as staircases to progress to the end of the level. To implement physics into our game, we applied physics materials to non-player objects that were also not projectiles. This pieces were randomly instantiated to have varying sizes, masses, and physics materials to act in a variety of different ways. This was intended to add challenge for the player to navigate the level by picking and choosing which pieces to move around and successfully jump on to, to progress through the level. These building block pieces would also disappear after a set amount of time (which we visually indicated by having the pieces become more transparent). Our hope with this was to give a sense of urgency to the player while also avoiding making the screen to cluttered. Our playable character did include idle and walking animations, and the diegetic sounds we used were for the jump action and a congratulations for completing the level.

Documentation (4a):

Project Download (4a):

Challenge4_Final_TB HP ACM JM.zip

Rapid Physical Game Prototyping

Challenge 1: 2-Person Game Rule Set

Puzzle Communication Challenge

Collaborators (1b):

Thomas Benson, Hanna Pardee, and Jeremy Salo

Rules (1b):

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 five minutes (5:00)
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.

Images (1b):

Challenge 2: 6-7 Person Group for a 4-person Game

Zookeeper v. Orcas

Collaborators (2b):

Tommy Benson, Stone Fisher, Julia Jones, Jeffrey Mutchnik, Brock Soicher, and Hannah Tindal

Rules (2b):

Objective:

A zookeeper has fallen in the orca cage and must escape before being killed.

- -

Overview of board.

Rules:

-Zookeeper must get to the opposite side in three minutes.

-All players must start at one corner.

-Zookeeper can move forward, backward, side to side, can move back previous spaces, stand still, and move diagonally. Zookeeper cannot swap spaces with Ocra, if they swap, the Zookeeper loses.

-Orcas can only move forward, backward, and side to side but cannot go to most prior previous square. Two orcas are allowed to swap spaces with each other.

-If two Orcas move to same spot, they must play rock, paper, scissors, to determine who is out of the game, therefore limiting down the number of orcas to the zookeeper.

-Zookeeper must get to the opposite side in three minutes.

-Zookeeper counts down from 3 (3,2,1…) then all move.

Notes from Playtesting:

Clarify “opposite side of the square” so they know to go diagonally across
Specify that it is 3 (orcas) v 1 (zookeeper)
What does opposite side of board mean? (The opposite diagonal)
Might add the rule that people need to point
Indication of what the cone means
“Each player starts in a different corner”
Clearer indication of checkerboard (confusing squares for some players)

Using ‘X’s to indicate “other” color square
Possibly use string to indicate play space

Good asymmetric gameplay
Movement is kind of an issue
What kind of revisions can be made to the pointing?

Felt a little rigid/difficult to manage pointing and moving simultaneously.
With everybody moving all at once, how can an honor system be maintained?

Maybe everyone moves blind?

Movement is a skill in our game that can be improved over multiple playthroughs

Point, reconcile, move based turns
“As we played, it did start to feel more natural”
“Became fun once you could move in the space quickly. It did take a while to get to this point”

“Pointing takes away a little fun from the experience because it takes away some of the spontaneity of the game.”
“Pointing might actually weaken an honor system between players”

Apparently the grid doesn't make sense (More tape? String?)
What if the countdown wasn’t as loose? What if it was more rhythmic, interval based moves.
Should there be

a penalty for the orcas going back to the previous space?

Get sent back to the cone?

Gameplay Tweaks from Playthroughs:

Zookeeper going to opposite corner and back
Quicker turn intervals

Return to their own corner or return to zookeeper corner

Time limit
Point system
Round system
Winner becomes zookeeper

In a round system players switch/rotate roles : Game variant

Cases where Orcas forget to move`
A fixed interval for the zookeeper? (3...2...1)

Documentation (2b):

https://www.youtube.com/watch?v=_j5Rmlu-Lmw

https://www.youtube.com/watch?v=gj0l8ZZApKE

https://www.youtube.com/watch?v=isKUQjX3c4A

https://www.youtube.com/watch?v=ZFSg__wNkn4

https://www.youtube.com/watch?v=98vtJeMLrkg

https://www.youtube.com/watch?v=4eTnRTC3haQ

https://www.youtube.com/watch?v=kXVu0MxsvqM

https://www.youtube.com/watch?v=nvjUCkZXwx0

https://www.youtube.com/watch?v=NOgMqlkT0sw

Challenge 3: 2-3 Person Group for a 5-person Game

Happy Circle

Collaborators (3b):

Tommy Benson, Alex Cano McConnell, and Brock Soicher

Rules (3b):

Each person can choose where they start on the edge of the circle and place their bowl at the starting position
Each person’s objective is to get as many balls from the center bowl into their own
You can only grab one ball at a time and cannot purposefully move the stack of balls, or any of the bowls once the game has started
Each person also has the ability to tag other players, and to be tagged.
If you are tagged, you are out and your score is the amount you had before being tagged
If two people tag each other at the same time, they are both out.
Safe zone: no tagging outside of the ‘happy circle’
Each player gets a scooper that they must use to transport the balls. Each player must also choose which hand they will use for the scooper because they cannot tag with that hand
Balls that end up out of the circle are not able to be picked up
The round ends when everyone is out or if there are not balls left to collect
If the game ends with a tie (2 or more players have the same score), then there is one extra round where there will only be a single ball in the center. If all players are out at the end of that round there it is a tie

Documentation (3b):

**Note: These images were taken in the prototyping phase, sadly. I have no documentation of the final version of the game.If I am able to find any images or videos, I will update this section.

Challenge 4: 6-7 Person Group for an 8-person, Non-contiguous Game

Collaboration Nation Infiltration

Collaborators (4b):

Tommy Benson,

Alex Cano McConnell,

Ben Efram, Kelia Murata,

Hanna Pardee,

Kelia Murata,

Jeremy Salo,

and Hannah Tindal

Rules (4b):

Object 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:

Documentation (4b):

https://www.flickr.com/photos/sweat/26579744996/in/album-72157666306098254/

https://www.flickr.com/photos/sweat/26579709216/in/album-72157666306098254/

https://www.flickr.com/photos/sweat/26000329324/in/album-72157666306098254/

https://www.flickr.com/photos/sweat/26579707036/in/album-72157666306098254/

https://www.flickr.com/photos/sweat/26000326864/in/album-72157666306098254/

https://www.flickr.com/photos/sweat/26579706116/in/album-72157666306098254/

https://www.flickr.com/photos/sweat/26579703606/in/album-72157666306098254/

https://www.flickr.com/photos/sweat/26000324944/in/album-72157666306098254/

https://www.flickr.com/photos/sweat/26579702126/in/album-72157666306098254/

https://www.flickr.com/photos/sweat/26579698466/in/album-72157666306098254/

https://www.flickr.com/photos/sweat/26606001325/in/album-72157666306098254/

https://www.flickr.com/photos/sweat/26000305174/in/album-72157666306098254/

Final Project: Cthulu Ctharetaker

Collaborators:

Tommy Benson

Ben Efram

Quincie Neale

Jeremy Salo

The Project:

Cthulu Caretaker is a 3-person, cooperative hybrid game that involves players maneuvering characters in a digital space while also managing movement in a physical environment. The goal of the game is to have the two players with controllers (the Cthuloids) navigate the mazelike wreckage of a sunken ship back to an interdimensional portal that will reunite them with their parent, Cthulu. The player operating the Kinect take on the role of guiding Cthulu's tentacles throughout the game by moving their hands around the screen. For each hand, tentacles on each side of the screen would be attracted to to corresponding hand (i.e. the tentacles on the right side of the screen would be attracted to the right hand). As players progress through the game they will encounter switches that are cloaked in a specific color barrier (red, green, yellow, or blue), players in the real world must step on one of those corresponding color switches to deactivate the barrier, so players in the game can activate the game switch. This multi-layering of switches would affect the environment in a multitude of ways including: moving platforms, opening gates, activating elevators, stopping platforms, and dropping objects. There is no timer or death condition in the game, so the goal is both a challenge of intellect and dexterity for the three players to navigate the digital maze while manipulating their physical environment.

My Experience with the Project:

When our group began this project, I was surprised that people considered me the lead programmer of the group. In previous projects (mostly outside of these courses), I have tended to take on the role of hybrid-artist, designer, or writer, so I was a little surprised in how confident my team was in making me lead programmer. As such, my approach for this project was to build as many small mechanical things that could be used to mix and expand upon for our level designer, Jeremy Salo. Once we learned the team breakdowns for our class, we immediately went to work on figuring out what kind of game we were going to make. All four of us saw that one of the themes we could use for the project was "Tentacle/Tendril" which intrigued us because it seemed like it would be challenging and something most people wouldn't likely gravitate towards in terms of design. I am happy to report that our project had a very solid aesthetic from the start. We collectively came up with the narrative that Cthulu had lost its baby Cthuloid children, and the only way to get them back would be using its inter-dimensional tentacles to guide and ultimately rescue its offspring.

With our aesthetic in mind, my first task was to create the core of our game: the tentacle. By the end of our project, the tentacle had undergone three separate versions, increasing in complexity both visually and mechanically. The final in-game version can be mapped to one of the two kinect icons (so it will follow the left or right hand respectively), includes art, has different angular momentum for the different joints, and has smaller pieces towards the tip making the entire structure more realistically dexterous. Although I didn't document the exact amount of hours I spent working on the tentacles, I can say that we had the final version of the structure completed halfway through the second week of the project. My next task was implementing smaller things like player movement (which was appropriated from an early example provided in class), setting up physics materials, establishing a collision matrix for the players and tentacles, mapping controls so the game could support three players, and setting up the UI for the main menu screen. Another thing I did at the start of the project was setup a group repository using the SourceTree application and BitBucket as a digital storage system. With this repository, our group could easily update the project while working remotely from their own computers. This also allowed us to work on the project and avoid constantly making and exporting packages and versions of the project between computers.

Quincie was in charge of making the art for our game, and it was my job to implement her artwork into the game itself. This meant, I would tell her what kind of sprites we needed, she would make them, and I would attach them to the various objects in our game. Some of the first art I implemented from her included the joints for the tentacle and animation sheets for the player characters. While Quincie was working on art, I was working on small juicing effects for our game including things like: randomized coloration of players upon startup, a physics based button that would light up when pressed, a lock around the button based on physical button messages sent through the Arduino microprocessor, an altered jump that would make the character rise quickly and fall slowly (as though they were swimming underwater), and a programmatically generated water mesh that would react, splash and ripple based on other objects interactions with the surface of the mesh. Sadly, of all of these juicing effects, the most complex did not make its way into the final version of the game. The water mesh was working perfectly, but for some reason, we couldn't get it to render in our level. When we checked, it was being added into the scene, but due to a lot of adjustments with the layering system of Unity, it continually fell behind the objects in our scene. After building my assortment of mechanics and in-game objects (that were turned into prefabs), I passed the project to Jeremy who would take what I made and construct a puzzle-based platformer level.

The second half of the project had me working closely with Ben, who took on the role of co-programmer, where he did the bulk of the coding for both the Arduino and Kinect, while I helped troubleshoot the code and test both forms of sensors. Our working together was vital for the project because our task was to bridge the language of Kinect and Arduino to Unity. This made my approach from the beginning interesting because each object I designed had to be simple enough to receive messages from OSC and the Arduino to connect everything together. This was by far the greatest challenge of our project because of weird issues with the Arduino and Kinect. Specifically, we struggled to get string messages to work properly with the Arduino and had to make a work around system that was a mixture of integers and strings to send the proper messages. As for the Kinect, the only issue we faced was tracking hands towards the bottom fifth of the screen. Since the bottom of the screen was on the edge of where the Kinect could track with high accuracy, we couldn't find an efficient way to mitigate this within the system, so we just asked Jeremy to design levels that didn't rely on having the kinect player utilizing that portion of the screen.

The last stages of our project involved the final implementations of art assets: title splash art, background, jump animation, falling animation, and textures for the level as well as polishing all remaining code between the Arduino, Kinect, and Unity. My role during this final phase was essentially managing the task of pulling everyone's work together. After we had art implemented, I worked extensively with Ben to troubleshoot code and resolve as many errors and warnings as possible. This led to an intense final push for our team that truly revolutionized the game. As Jeremy said hours before finishing, "It's been less than a day and the difference in our game is night and day."

After showcasing our game in front of the class the things I would have liked to have worked on more would be testing the level with more participants and getting as much feedback as possible. Towards the end of our project, we were forced to make quick fixes that I would avoid using in the future that caused our final playtesters to find new ways to break our game and solve our puzzles in ways we would have never considered. That being said, I enjoyed this project and loved working with the people in my group. It was a very dedicated team that was passionate about making the game and put quality of work above quantity every time.

Group Members' Contributions:

While I touched on this in the previous section here is just a quick breakdown of what each member contributed:

Tommy Benson: Lead programmer. Worked almost exclusively in Unity building most background game system and all in-game objects. I was also in-charge of managing the group repository, ensuring everyone was up-to-date and everyone's contributions to the project were added without major conflicts with other people's work.
Ben Efram: Co-programmer. Ben was in charge of setting up Kinect Mapping, building our pressure sensors, and getting messages sent arcross multiple sytsems for both the Arduino and Kinect. Ben also coded functionality for the tentacles to "flex" which would lock a portion of the tentacle in place when the kinect player would close one of their hands.
Quincie Neale: Lead Artist. Quincie worked exclusively on producing art for this project and I am incredibly grateful for the work she produced. She made all of the animations, backgrounds, textures, and buttons for our game by hand. In addition, towards the final moments of our project, she would adjust any of her existing assets to accommodate the system specifications of Unity as needed.
Jeremy Salo: Lead Designer. Jeremy was in charge of taking the objects I had built and create a level from them. He worked through many versions of the same level to make one that was challenging, yet beatable. Jeremy also helped Ben and I troubleshoot our code and help test the systems that operated between physical and digital space.