Tag Archives: group games

Group Game #2: Hansel and Gretel

Our game follows Hansel and Gretel as they are getting closer to a Witch and her house. The game is black and white, and it gives the impression that something bad is about to happen.  Their trip is made harder by the falling cones, which sends player back to the start. The witch is waiting in her house. The controls are very simple and the player controls both Hansel and Gretel as they are moving together to the house.  The main goal is to arrive into the Witch house and not get hit by the cones. Screen Shot 2015-04-22 at 10.51.56 AMa When both Hansel and Gretel arrive to the house, the sign “You win.. for now” appears on the screen indicating that the player has successfully passed the first stage, it also implies that there is no real win since the trouble really starts at the witch house. unnamed (1) The game is looking just the way we wanted it to look, dark shadows really giving the sence of something bad about to happen. The game is designed as a two level game and we are hoping that we will finish the second stage as well. The second stage is supposed to see the players in the witch house, where Hansel will be trapped in the cage, and Gretel will have to push the witch in the fire.  

Group Game #2: Streamer

When I first started Streamer, I made 2 related observations about the base code.
  1. It was (at first) difficult to grasp, and therefore would be difficult to change.
  2. It was also interesting on its own, meaning it needn’t be changed too much to provide an interesting application.
From those ideas, I thought about what I could do to make the application my own without heavily modifying the seeker code itself.  The two ideas that presented themselves (and stuck) were changes in graphical representation, and the idea of scrolling or otherwise moving all of the objects along some path. The graphical representation quickly became a grid, both out of love for old, 8-bit graphics and out of my new infatuation with pixellation in general.  The only question remaining on that front was how big the rectangles should be… but that question was answered later.  For the time being I kept my program flexible. og 3x3 bigger biggest After this, it became a matter of what one might want to do in this new, grid-style area. Being able to “paint” squares was probably the first thing to come to mind:love_og Soon after that, the idea of randomly changing colors:love_ugly   (While the above doesn’t look all that great, in general the effect seemed pretty cool.) A little more color play would eventually occur, but after messing around within the same basic application for so long, I felt that the seeking mechanic needed to be changed at least slightly. This is where a few new features came in all at once.  First, the idea of scrolling was pretty natural, as the blocky and colorful graphics reminded me of old 2D shooters like Galaga.  I had a few types of scrolling to choose from, but the one implemented seemed the easiest.  With scrolling came a bug that colored the background with scrolling bars of color.  It ended up being a very cool thing, and after fixing the bug I immediately reimplemented the color bars as a feature. line_2 line_3 line_4 line_5 Finally, I toyed around with various mechanics for spawning and killing semi-randomized seekers, and came up with the finished product. While in dire need of some sound, overall I’m proud of this project.  The program was a great lesson on how minor tweaks and offshoots of ideas can lead to very cool applications.

Group Game #2: Hider/Seeker

Before creating a game using the hider/seeker engine I wanted to practice with it first. So in this simple exercise I created a simple circle that is being chased by a triangle. In this program each quadrant does something different to the size of the chase, the speed of the chaser, or the maxforce of the chaser. The maxforce is basically the ability of the chaser to make tight turns. As the force goes up, the chaser can make sharper and sharper turns. These screenshots show what they do for the most part. Some of the changes only can be seen during the program running since speed and force can’t be captured in a picture. The top left quadrant makes the chaser much bigger, the top right makes it normal, the bottom right makes the chaser very fast and the bottom left makes the chaser very slow. While this isn’t a game I hope use the experience of this program to help make the hider seeker game. o q p

Group Game #1: Bammer

So for the group game, my group first worked on a project that we called Bridge Builder. And for bridge builder the basic idea was that there was a canyon of death that your character needed to cross and in order to cross it you needed to collect certain shapes to build a bridge and then cross it to the finish line to win. We were really heart broken when we decided that the game was a little too complicated at this point for us to design so we had to table bridge builder in favor of another game. The next game idea we had, which ended up morphing into bammer was a game where you had to avoid several moving triangle and build up your score. Originally the game had no end but death, so we decided that once your score reached a certain number a goal would appear and that was how you won the game. The first edition of the game featured around 16 triangle with their points all randomly moving in different directions. However, we quickly had to ditch this idea because circle triangle collision was causing us loads of issues so we had to come up with another way in which we could program our triangles so collision would work. We discovered an interesting way to do collision in this process and ended up using it. Instead of using distance between points and if that distance was less than 0 making collision, we defined each triangle and the player a given area. And once those areas were defined we were able to create a collision function revolving around whether or not the areas intersected with each other. This worked out extremely well and when the player collided with a triangle the screen would flash red and you would hear an audio clip of me saying “Bam” (thus the name Bammer). The next part we tried to program was the goal at the end. We were able to get the goal to appear however, we went back to trying to use the first collision code rather than use an area code. This proved to be unsuccessful and so our game at this point doesn’t have an end and we were unable to add a game loop because of it. I am interested in going back on this game for conference and making it work completely as well as simplifying a lot of code. .g e f

Group Game #2: Stoke the Fire

After play testing my initial draft of my game in class and receiving some good feedback, I decided to make my game more representative of a “fire.” To start, I made the points, which represent embers, more yellow and orange, like so: Screen Shot 2014-12-08 at 8.03.41 AM I made the player’s circle into an arc because I wanted the object to represent a steel fire starter. I made the vehicle a darker grey to represent a piece of flint: Screen Shot 2014-12-08 at 8.10.22 AM Then, I added two sounds – a background sound of a fireplace crackling, and the sound of a lighter striking whenever the vehicle/flint collides with the player. I also decided to make the points float down the screen vertically, rather than horizontally, like little embers falling through the air. To start the game, I made a basic title screen: Screen Shot 2014-12-08 at 8.03.34 AM Once the player clicks on the screen, the level changes and the objects of the game are displayed. And this is what “Stoke the Fire” looks like towards the end of the game: Screen Shot 2014-12-08 at 8.04.06 AM I set limits on the size of the array, so when there are no points left, or when there are more than 250 points, the game resets and the embers begin to regenerate anew. I’d like to continue to work on this game and move towards designing a better game feel. Ultimately, I don’t think that I gave the player enough choice – there’s not a whole lot to explore in this game. The only options are to void the flint, and get rid of embers, or to let the flint hit you, and generate more embers. I want to code in more ways of affecting the environment, and see where that takes me.

Group Game #2: Hider/Seeker

The game went through two main phases of development i guess you could say. The entire process started with the idea of avoidance being the main aspect of the game rather than collision.  The first iteration was with some simple boids that roamed the screen freely and were repelled by the mouse or by the other circles roaming the screen. Screenshot (4)   The problems we ran into with this was that it only looked great if there were an absurd amount of triangles on screen. far more than a tablet could handle. So we started coming up with ideas and eventually stumbled upon the boids tending toward each other. This turned out to be the biggest help to the project because it lessened the amount of triangles needed but still made it possible to experience the satisfying scatter effect. Screenshot (3)   From this point on the main changes to the game were simple tweaks. We changed the way the mouse worked to be more conducive to tablets by having the mouse only trigger when pressing. We also added a trail effect to when it was repelling to give both a visual idea of what was happening as well as a nice way to keep track of your movement. Some simple color scheme variations was how we finished off the project.  

Group Game #2: Space Journey

Although Space Journey is certainly a fun game to play, its primary purpose is not to encourage players to win or lose — rather, it is to simulate an interactive system, in which nearly every member has a positive or negative effect on other members of the system. As Shiyuan pointed out in her post, this particular game took heavy inspiration from the aquatic system described in chapter 3 of our textbook. But, rather than stick to Earthly concerns, we took our game into space! Screenshot_2014-12-03-04-20-15 As the primary method of interaction we were working with was the speeding up and slowing down of objects, it only seemed natural to create a ‘black hole’ that would bend gravity and slow down the oncoming vehicles. We also created a sci-fi-esque ‘white hole’ that has the opposite effect — all objects that approach it speed up. Both ‘holes’ slowly move around the screen, adding additional interest for the player. From there, a deep navy background successfully creates the feeling of being in outer space. Screenshot_2014-12-03-04-20-20 The player controls the yellow circle, and is pursued by an orange space-ship-like vehicle. In turn, the orange vehicle is chased by a blue triangle, followed by a trail of smaller blue circles. Each time the orange ship collides with the player, a futuristic sound plays, and some ripples emerge on impact. Each time the orange ship gets the player, it increases in size, until it can become almost impossible to avoid. Conversely, each time the blue triangle successfully catches the orange ship, it decreases the size of the ship, and it can become quite easy to avoid. This returns the game to the idea of an ‘eco-system’ of interaction, in which the player must deal with multiple environmental variables.

Group Game #2: Skinnydipper

Interface and first ideas about our game We wanted to make a skinny dipping game, incorporating the Flocking labs. The player will be chased around the screen, scoring points for dipping in pools (which are randomly placed for variety’s sake).  If the seeker catches you, that’s GAME OVER. We made a little skin-tone dot to represent the player, but we had trouble getting it to move how we wanted it to (automatically, steering towards the cursor/finger).   We ended up with a player character that just teleports to wherever the mouse is clicked.  There’s a (police) Vehicle chasing him. The skeleton is more or less there. What we need is to get the movement down, and to figure out how to record score when you’re in pools, and to detect collision between the player and the vehicle. dipper Developing the game and figuring out the problems we’ve had
To solve the movement problem, we just replaced the little player-dot with a second vehicle that chases the cursor while being chased by the enemy vehicle.  This made collision difficult to figure out. We thought that putting the player character in its own class would help, but it did not. We also still had no idea how to make the code detect when vehicles were in water, since the parameters/coordinates were randomized. And so there could be no score. Also, we made the colors awful :) but that is something we could fix of course!! dipper1.5 Rudimentarily-Finished Skinnydipper
All the mechanics that we set out to create have been created, and they all work!
      • Corrected the hideous color palette, first and foremost.
      • Had do give up on the randomized pools because they made the next part impossible:
      • Vehicle-in-pool detection, which is the basis for SCORING.
      • Vehicle slowdown (reduction of maxspeed) while in the water.  The chaser vehicle is slightly more affected by this than the player’s vehicle is.
Added collision detection but there’s no consequence for colliding. Collision is supposed to equal GAME OVER. dipper_2
Actually-Finished Skinnydipper
  • Vehicle-in-pool detection now gives the player a SCORE (one point per frame spent in the water)
  • Collision now actually ends the game, and the police carry you off the screen.
  • The Player character is back in his own class.
  • Gave the player character has his peachy skintone back, and the enemy is navy blue because he’s the police.
sketch

Group Game #2: Skinnydipper

png For our group game, we decided to use the hider/seeker labs to make a game about running naked through people’s pools while getting chased by police. You score points by being in pools, and if you get caught, it’s over. dipper1 We first made a little skin-tone dot to represent the player, and a vehicle chasing it. We wrote the code so that pools would appear in 3 random spots for the sake of variety.  But we had trouble getting it to move how we wanted it to (automatically, steering towards the cursor/finger). We ended up with a player character that just teleports to wherever the mouse is clicked.  That’s as far as it went for a while. dipper1-5 To solve the movement problem, we just replaced the little player-dot with a second vehicle, in its own class, that chases the cursor while being chased by the enemy vehicle.  Collision was still difficult to figure out. We thought that putting the player character in its own class would help, but it didn’t. We also still had no idea how to make the code detect when vehicles were in water, since the parameters/coordinates were randomized. And so there could be no score. Also, we made the colors awful. sketch We changed the hideous color palette.  We eliminated the player’s class.  It’s now just Vehicles one and two — the peach-skinned arrow is the player, and the navy blue arrow is the police. We had to ditch the random pools idea because it made the next part super difficult: vehicle-in water detection, and vehicle slowdown while in water, which affects the enemy slightly more than the player. We’ve got a score-counter going as well. Collision between vehicles now ends the game, with a ‘Game Over’ message as the police escort you off the screen.  We had a breakthrough — every mechanic works as it should.

Group Game #2: Particle Synthesizer

I’ve been applying the aspects of the hider/seeker code with particle systems to create interesting particle systems that are fun to manipulate around on screen. At one point I got the idea that it would be really cool if the particles were somehow generating audio based on their position, or other aspects of their movement. Enter a little research into the Beads extension for Processing, and a couple of headaches, along with having to sacrifice the ability to run on Android for Java only (right now). I’ll start by discussing the motion built into the program: sketch ^^ Here’s what happens when you click or hold your finger onscreen. The variable controlling the ‘force’ of the seeking motion of the particles increases to 10, and their speed increases to 60. This causes the particles to ‘tighten’ in towards the mouse cursor and form a tighter ball. The color of the particle also changes to lighter colors. The colors are generated within random ranges, so they appear to have diversity. They also fade as they get older and the alpha value decreases. sketch2   ^^When the mouse or tap is released, the force and speed decrease in value, which causes the particles to ‘back off’ of the cursor and form much wider archs. Their colors also change to blue tones. For me, the system by which the particles seek has enough ‘wiggle room’ to invite play, and to get the particles to do interesting things. Haven’t playtested. sketch4   The audio is handled by creating a sin wave and a series of harmonics for each particle. The frequency of the fundamental of each particle is dictated by it’s position from left to right on the screen. Far left is lower, far right is higher. As they move down, the particles increase in volume (currently un-intuitive and needs to be refined), and as they move up, the particles decrease in volume. At first this generated pure noise… There were so many different frequencies playing at once, it sounded like a swirling of air… It was awesome because it made the particles seem like some kind of living, air-breathing, reactive organic object. BUT it wasn’t good for making music. I solved this by breaking up the x-axis into zones which play specific frequencies if the particles fall into them. This allows me to ensure that the particles have a harmonic relationship, and will create a more ‘pleasing’ sound. Here’s the code that shows the breakdown of frequencies.
if(xpos<0) xpos = 100; if(xpos<200 && xpos>0) xpos = 200; if(xpos<400 && xpos>200) xpos = 250; if(xpos<600 && xpos>400) xpos = 300; if(xpos<800 && xpos>600) xpos = 350; if(xpos<1000 && xpos>800) xpos = 400; if(xpos<1200 && xpos>1000) xpos = 450; if(xpos<1400 && xpos>1200) xpos = 500; if(xpos<1600 && xpos>1400) xpos = 1000; if(xpos<1800 && xpos>1600) xpos = 2000; if(xpos<2000 && xpos>1800) xpos = 3000; baseFrequency = xpos;
     

Group Game #2: Space Journey

Space Journey is a single-player game based on the hider/seeker concept. In this game, the player is controlling a yellow circle that can move anywhere in the screen. An orange triangle, the seeker, is chasing after the player. At the same time, the orange vehicle also has its own seeker—a blue triangle with a tail. Screenshot_2014-11-30-23-45-35 When the orange vehicle successfully touch the player, two things will happen: the size of the vehicle will increase, and a ripple effect is produced. The ripple effect is accompanied by a sound intended to create a space, futuristic feeling. The effect itself is built based on an array of white rings that sets off and recycles according to the screen touch. When the orange vehicle is chased down by its seeker, counter effect will take place: its size will decrease until it is almost invisible.   Screenshot_2014-11-30-23-46-07 Besides the basic chasing mechanism, there are two environmental variations: two circles are doing clockwise and counterclockwise circular motions. When the player reaches the black zone, the orange chaser will slow down significantly. With the blue vehicle’s effect, its size will diminish very quickly.If the player reaches the white zone, the orange vehicle will immediately speed up, and accordingly it will enlarge quickly.   Screenshot_2014-11-30-23-46-45 The inspiration of the game come from the idea of dynalinking (Preece, chapter3). Within a pond ecosystem, perch, beetle, stickleback, and tadpole form a food web that each has its own prey, enemy, and also some irrelevant, mutual-existing members. In this game, I want to simulate this web so that not only the player is chased by a seeker, but the seeker itself is also being chased by something else. Similarly, there is no interaction between player and the blue vehicle, just like perch and tadpole in the ecosystem. 20141201032523 Screenshot_2014-11-30-23-46-55 For future improvement, I want to add several other environmental variations that can introduce new members and actions to the system. It does not have to be triggered by the player, like the black and white regions. The orange vehicle and the blue vehicle (and its tail) can be initiators, as well as subjects of new movements.

Group Game #2: Airship

I’m really enjoying coding Inversion because each time I run the code, I feel the difference in play from the tweaking I do. Initially, I had the player (square) move around freely while the enemies (triangles) did the same. sk2 Then I had the enemies chase the player while the mouse was pressed. I thought I’d make barriers, and the objective would be to make enemies run into them and destroy themselves. sk4 sk3 I changed my mind. The enemies chase the player UNTIL the mouse is pressed, however, while the mouse is pressed, an obstacle rises from the bottom of the screen. Right now, I’m working on collision, as well as different positioning of the growing obstacle, perhaps coming from a different side of the screen. I’m also thinking about adding particles once I’ve coded the collisions. sk1

Group Game #2: Attendance

In our group game, rather than choose between designing a simulation based on behavior or designing a game with a goal state, Ben and I decided to combine the two. We designed our game “Attendance” to make players understand and use the behavior of the system in order to achieve a goal. In our game you play a caring T.A. who wants to make sure all the students  are in their desks before the teacher arrives. Attendance start screen The timer in the center of the screen shows how long you have until the teacher arrives. Although it is hard to tell in this screenshot all the students are colored in correlation to their desks. So you must get the red student to the red desk, and the blue student to the blue desk etc.. All the students have different maxspeed and maxforce so as the player you must respond to the different behaviors of the system in order to achieve your goal. If you succeed in getting all the students to their desks before the timer runs out the teacher (starring the lovely Angela Ferraiolo) emerges pleased to see that her students are punctual. Attendance win state   However if you fail in getting all the students to their desks in time Angela emerges again, only this time not so pleased and the student’s grades suffer. Attendance lose state   The most difficult part of making this game was definitely getting the students to stop first at any desk at all, and then just to stop at their desks. I think the best way to improve on this game would be to improve the aesthetics, the simple colors on a white background leave much to be desired artificially.

Group Game #1: Triangles Revisited

Looking back on the Triangles game, there were quite a few things that went really well and also some things that made me want to tear my hair out. However even the most frustrating things proved to be really educational. An interesting part of this game is that we actually went into the coding phase with a completely different game in mind. When we coded for random movement in the triangles we ended up with a really cool looking interface that we decided to run with it. After redesigning our game we were ready to go about coding again. The most difficult part of the coding was definitely coding the triangle collision. Since we had to code all three of the points of the triangle individually, it was difficult to make the program sense the collision for the shape as a whole. However once we got that collision to work the rest of the game was easy enough to code. Even though there were parts of this game that were a nightmare to put together, mainly triangle collision, the game as a whole was a lot of fun to work on. I definitely learned a lot about solving problems in code when there is no pre-written answers. After coding this game I definitely feel more equipped to code more games.

Group Game #1: Standoff Revisited

Screen Capture #007 In an attempt to introduce some kind of player choice to our black and white hostage game, we’ve decided to simply display different messages depending on which shape the player ends up murdering.  This seems appropriate since the only real mechanic is murdering people, albeit abstractly.  One of the hostage circles is a bank teller, and the other is The Doctor, who was just passing through. The player character is a hard-boiled alcoholic detective far past his prime, whose marksmanship is not what it used to be.  The enemy square is some mafioso character whose backstory doesn’t matter because he’s only there to get shot. That’s all pretty inconsequential but in this case it’s the only way of actually making the player’s choice mean something.  However bound we are to the cops-and-robbers template, in which the good guys shoot the bad guys, the good guys always have the option of doing some heinous villainy.  We haven’t included any motivation to murder the innocent circles, but without a plot or a scoring system there’s no real motivation to properly do your police job, either.  So the imagined dramatic arc is more of a thematic skeleton.  But that’s a summation of the player’s choice in ‘Take The Shot, Murphy’. It’s Groundhog Day but with only 4 possible outcomes, and they’re all rather nasty.   Screen Capture #008 our detective is the triangle object and doctor and bank teller are the hostages which are shown as a circle and the bad guy is represented with a square. All 4 of the objects are bouncing on the x axis and the player has 3 attempts too shoot the bad guy which means has 3 attempts to be on the same x-axis with the bad guy. The goal is to be able to press the button/ tap the screen while they are sharing almost the same x values. Screen Capture #010 Once you win the game this screen pops up and lets you know that you are the winner Screen Capture #009 While you are trying to shoot the square the circle might get on the way and that kills the hostage which means you automatically lose the game. After you either win or lose a game over screen pops up Screen Capture #012 After you press one more time loop initializes and game restarts.   Ege Ozcan Chris Manfugas

Group Game #1: Triangles Game

In this game you play as a black circle who’s main objective is to dodge triangles long enough for a portal to appear and teleport you to safety. screenshot1 In this first screenshot, you can see the circle as well as the two triangles. This the typical start screen and the “before” state of the game. What makes this game most interesting is the random movement of the triangles shown in this screenshot. screenshot2 By setting the triangle movement to random, there is no control over where the triangles go or what they do so every time you play the game you end up with different designs and patterns. Any collision between the circle and either triangle causes the screen to flash red and set the score back to zero. Once the score reaches a certain amount a red “portal” appears that is your gateway to safety. However as the score climbs the portal moves, so you need to move quickly to catch the portal before it teleports, perhaps to somewhere where the triangle covers it, making it unreachable until it moves again. Screenshot 3a shows the portal’s first appearance, 3b shous its second appearance. 3a . screenshot3a 3b . screenshot3b When you successfully get your player to the portal you win the game! The game has a clear beginning and end state making it a race to the finish. The game is full of player choice; you can choose the best path to avoid the triangles, you can also choose which portals to go for and which to wait out.` By far the hardest part of this game to code was the collision with triangles. However once we labored through that bit, the rest of the code was pretty straight forward and didn’t create many problems.

Group Game #1: Bammer

I’ve been experimenting with the original code for “Bammer” and warping it into more of a sandbox art piece. The form of the game is constantly shifting, and one of the ways I did this was by adding a score to the bottom of the screen. The score constantly climbs over time, and is reset to 0 upon collision.

screen 2

If the score reaches a certain number, say 1500, a few events will happen. For example, one of the triangle’s points is now mapped to the user’s X or Y coordinate, or there’s a black rectangle taking up one vertical half of the screen. Other changes include the growing/shrinking of the user’s circle as it hits certain X and Y coordinates, as well as changes in the speed of the triangle’s random morphing.

screen 3

One last part about this game: you can intentionally collide with the triangles, with the only punishment being a score reset, but the triangles keep the shape you’ve put them in before the point of collision. The game could be played just as something that you can alter visually with your decisions and movements.

screen1

Originally, “Bammer” was a game of a player-controlled circle attempting to avoid numerous pulsating/vibrating triangle obstacles. Over time, the triangles grew in size, and their motion was hard to track (as it is randomly generated), but we needed to further design the game and add new elements. Each member of the team started coding their own version based off the random triangle code, and I chose to design something that’s more aesthetically pleasing; I wanted to see how cool I could make a game look using only the colors black and white.

Group Game #1: Standoff

Standoff game version 1 screenshot 1

Standoff game version 1 screenshot 1

Screen Capture #010Screen Capture #011 Standoff Version 1 Screenshot 2    
Our game is an abstracted sort of hostage scenario simulation.  We’ve created the player-controlled triangle, the enemy square and the neutral circle(s), all white against a black background.  The concept is that when the screen/mouse is tapped (which is the player’s only input), the triangle (who in this case is a cop or something) fires a shot and instantly kills the object directly above him.  The aim is to not hit any circle-hostages (which we’ll soon create more of) and to wait for the right moment to tap/click, killing the enemy square and then maybe advancing to another screen.At present, all objects are bouncing back and forth across the screen horizontally.  We plan on adding circular motion as soon as we figure out how to include it in the same class as the bouncing circles.  We also want to try and make some collision/bouncing happen between circles, which seems like it’d be characteristic of panicky hostages running amok.  Where we’re running into problems is widening the target area (hitbox?), or the invisible line/column between player and target that determines whether you hit or miss.  Right now the objects technically only cross each others’ y-axes for something like a millisecond, which makes the central mechanic almost totally dysfunctional.
Possible addition: Make everything invisible except for whatever passes through the triangle’s column of vision, forcing the player to do estimate where everyone is, heightening tension and making things more difficult.  It may also be fun to limit the number of shots the player’s allowed to take. If done effectively a one-shot game could be a lot of fun.
That covers the interaction design but not player choice, which so far is the least-developed element of the game (this will change once the basic skeleton is working as it should).  Right now if you tap at the right time and ‘hit’ a circle, text appears for a moment that says “Hostage is down” or “Misfire” or something to that effect.  However there is no consequence for doing so. Neither is there any feedback for ‘hitting’ the enemy square.  One concept that we’re messing with, once the basic skeleton is moving as intended, is using the postmortem negative space of the game screen to graph all the dead shapes.  The coordinates at which they died could remain filled-in in the next round, and those spots might then become walls/obstacles for characters to bounce off of or hide behind.    

Group Game #1: Evasion!

Designing Player Experience in Evasion Evasion is a simple race to the end game in which the player navigates a circle to a goal while avoiding obstacles that will destroy him. The background of the screen is black, while all the objects the player interacts with are white. The game has two major obstacles – triangles, which move randomly around the screen and threaten to hit the player, and a wall which moves from the left of the screen, slowly encroaching upon the player and simultaneously decreasing the space that the player can freely move around in. We chose to represent the moving obstacles as triangles because they seem sharp and menacing. Cam wrote code to make the triangles move randomly, rather than simply up and down or side to side. The random motion is not only harder to avoid, but it makes the triangles seem more chaotic and unbalanced, adding to their threatening demeanor. Initially, the moving triangles were the only obstacle included in the design, but we chose to add the wall to ensure that the player keeps moving and is forced into the thick of gameplay. The goal is represented by a large white circle, which contains a smaller circle cut out of it about the same size of the player. Since circles represent unity and balance, and the player’s circle will fit perfectly inside the larger circle, we believe this will be interpreted intuitively as the goal for the player. When we were asked to add another choice for the player, we decided to make “safe zones,” represented by small white squares. When the player’s circle touches one of these squares, they cannot be harmed by the moving triangles. Therefore as the player approaches the goal, they can choose to move to-and-from the safe zone as they navigate around the moving obstacles towards the goal. However, the large threatening wall moving in from behind will still harm the player, so the safe zone is therefore only a temporary solace. The player must keep moving toward the goal if they want to survive. Group Members: Annie Flynn, Cameron Basham, Jon Lloyd Screenshot_2014-10-13-20-52-17 Screenshot_2014-10-13-20-54-43