• 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!

View
 

Brock_Soicher

Page history last edited by Brock Soicher 7 years, 10 months ago

placeholder where they will place the documentation for Rapid Physical Game Design and Programming For Play.

Rapid Physical Game Design

Challenges:

  • Challenge 1:

Initially we made a game where one person was blindfolded, and had help of an assistant to try to knock over cones set up in an area.  Although it was some fun because it was controlled chaos, it was near impossible, so we had to go through a few iterations.  We added a die such that you can only speak a number of words depending on the number that you rolled because it would be more interesting, and potentially make people choose their words more carefully to try to be as efficient as possible.  Again, it was extremely difficult, so we added a ring around the cones to make it possible to score some points just be being near the target area.  Not only that, but at first you could move around the entire environment, but that led to people getting disoriented and losing their place, so in the end you are only allowed to stand still and simply pivot.  In the end, the game has rings and movement limitations to make the game easier, while keeping the die to still make it more interesting.  The game is fun because whenever people are blinded, there is always a level of discomfort and laughing, which is a good sign that people are enjoying themselves.

  • Challenge 2:

We messed around with this game for a while, but what we knew at first is that we wanted a game where you had to move around a room in a chess-like fashion, while each person had movement limitation.  First we had it so you could only move if you threw a ball to a teammate, but we soon had an idea to see what it would be like to have a game that was 3 v 1.  We made it so that the 1 person had to get to the opposite side of the board, and three others had to stop them.  You did this so that at the start, the 1 player (we eventually called the player a "zookeeper" and the 3 enemies "orcas") counted down from three.  During the countdown, each person had to decide which spot they would move to.  Zookeeprs could move in any direction they wanted or stay still, but could never directly cross paths or occupy the same square as an orca. Orcas could not move diagonally or occupy the last snare they were in, but they could swap spots with other orcas if they wanted.  This balance made it so that the zookeeper had many more tactical options, but the three orcas had more manpower and ability to corner the zookeeper.  We have played around with extra rules such as no diagonals, or you had to get to the edge of the board and back, but those are extra rules that can be added or subtracted.  The game turned out quite balanced and people seemed to enjoy it.

  • Challenge 3:

This game took much longer to make because we had quite a few issues at first.  In the beginning, my team was so focused on making the game accessible to  those who might be in some way disabled, that the game we made had little to no moment whatsoever.  The game itself was a trivia game, and it was interesting, but it might as well had been a board game.  Even though it would need some heavy revisions for people who would be disabled, the game we made was essentially a 5 person tag.  We knew we wanted this idea where everyone was "it" at the same time, and after lost of play testing we found it worked when each player had to get something from the center and had to stay in as long as possible. By adding balls in the center for each player, it becomes a fun game where often times everyone is almost paralyzed in moving because they know that one wrong move will get them out.  It fluctuates between fast and slow paced depending on how nervous the players are, so it turned out to be quite fun and balanced.  Again, an issue is that it might not be completely accessible to those who are disabled potentially because if everyone is running and grabbing stuff, it would be harder for people who has those issues.  I think it was a good exercise though because in the end it really does show how you do have to think outside of the box to include everyone, and the more people that you can get to play the better.

  • Challenge 4:

This game for some reason was extremely hard to come up with initially, but it came out quite well in my opinion.  It took us the entirety of two class periods to come up with the idea, but we eventually came up with a scenario where two teams had to competitively make drawings.  Since we needed to have 8 players and two separate spaces, we made it such that it's two teams of 4, both of which are then separated into a group of 2, and they must all work together to make more drawings than the other team.  Each pair of 2 gets a drawing board and to keep it interesting they must separate the board into two halves and one player draws one half of the object, and the other player draws the other half.  The runners then relay this information to the other players on the team because at the end of the 3 minute rounds, each team's drawing boards must have the same exact drawings, and the judges (runners) must be able to tell what the drawings are.  The game is very fun because it does create a lot of chaos where everyone is drawing as fast as they can, not to mention that teams need to come up with strategies to make up for players who have no drawing ability whatsoever.  It is fairly fast paced and people seem to truly enjoy it, so it came out very successful.   

Programming For Play:

Challenges:

For the first challenge I changed the car game such that it would display "You win!" after collecting 4 of the green objects.  For a small addition of difficulty, I added a collider around the avoid tokens so that if you hit them, it would stop you in your tracks.

 I worked with Hannah Tindal on this project to combine our games.  Her main feature of her game was that the avoid tokens would spin around and make it much harder for the player to move around.  We combined our games so the player would need to get as many green tokens as required by the game controller, and if you were hit by the spinning red tokens then the game would restart.  We changed the avoid prefab to a token with 3 children on it so it was similar to the fire obstacles in Mario.  This made it so that there was a clear objective for the player, but also a good degree of difficulty and clear lose states.

 

 This game I made with Stone Fisher and was the two player game where both developers have to switch off their keyboards.  The idea for this was that the players would have to work together to get to the end of the level, and both players were vitally important.  One player uses the keyboard to move their player while the other player uses the touchscreen on the laptop to place down platforms for the player to jump on.  The levels are impossible to beat if the player does not reach the end, and there are drops that will restart the level if the player falls, so both players must work in sync if they want to reach the end.  The levels progress in difficulty, ranging from extremely easy to extremely hard.  The levels are 100% possible, but the later ones require lots of communication and talent between the two players to make it all the way.   I think it is a fun dynamic because the two players really do need each other, and that can either strengthen the relationship between the two or hinder it.  People who efficiently work together will feel that bond and it will be clear that they work together well, but if one of the players drop the ball a lot, then it will strain things quite a bit.  I like the idea that it could definitely go either way with cooperative play.

 

Admittedly, this game came out a bit rough and unpolished because of many complications.   The game ended up so that you use the touch screen to touch a spot on the level, and depending on whichever mode is enabled, the ball will either be attracted to or repelled by the touch.  You use those forces as a way of guiding the ball through the environment and reach the end.  All of that was intended from the start, but complications soon arose.  First off, because my last game was also touch enabled, it was mentioned that the game should use a standard controller so it would not be too much like the last game.  After working on it for a class period to redo all the movement, it became apparent that the game was actually not very entertaining in that way.  The ball either moved too slow to move over obstacles, or too fast that you had little control, so it was scrapped and we went back to the touch mode because it was consistently more fun.  Another issue was that it was planned that when you reached one end of the level, you go to the next one, but because the person who was in charge of making levels missed out of the majority of the class sessions, only one level was ever completed, and there was no real way to work on it.  Because of these reasons, the final product is a timed challenge where you simply try to get to the end of the level as fast as possible to beat your high score.  The game is enjoyable and does have some fun physics scenarios, but it is admittedly a bit on the shallow side.  

 

 

Mingo Mango Mongo Final Game:

Team introspective

The introspective is a google doc that has pictures, videos, concept art, and each person's documentation.

Final Game Zip

The zip contains the two melee, race, and kinect scenes, all prefabs, art, and code.

The code I did was the RoundController, Player, SoundController, MainCanvas,, and PowerController.  I also helped out a lot with Alex's GameController and Richard's Player1Move.

Comments (0)

You don't have permission to comment on this page.