Tag Archives: Group Game #1

Group Game #1: Permission

Permission (formerly Ion Rush and Ion Deluge) is a game about…permission. With very few differences from its beta, Permission is still a game about waiting for the opportune moment. 2 The most significant and recognizable change to occur in this version is the code structure. Now entirely legible, customizable and malleable, beams can easily be placed in any location with any rate of change. They can even move on their own! 1 I feel that porting this to the tablet worked wonders, as the simple back and forth movement of the player is made for touch controls. The only real vulnerability of this update is the lack of changing background colors. Nonetheless, Permission remains a product I’d happily defend and continue to develop in the the future.

Group Game # 1: Frog Laser

In my game I attempted to create a bad guy that would not be interacted with directly. Its movement patterns then do not actively harm the player instead affecting the accuracy of the player’s shots.  When the player scores a hit on the enemy by aligning with it and shooting it, the area the bad guy can move in is decreased. Through bouncing and a wrapped movement, the bad guy attempts to avoid being targeted. If it hits the walls of its area enough times the boundaries will increase and if unchecked will envelop the whole screen. frogLaser frogLaser Conversely, when the player shoots and is aligned with the bad guy, a laser is emitted. Pressing either x or z will trigger one of two lasers. x will result in a larger laser with a greater result but with limited shots. z delivers a short laser that can be used infinitely. With this I hoped to create some measure of player choice. Although in future I hope to include a charging mechanic whereby the player can either release a shot instantly or hold it for a larger laser. I would say that the bad guy exploits the terrain as the player an bad guy cannot affect each other directly. They must interact through the terrain to damage each other. However I only really have one type of failure and that is absolute. There are not really small failures in the game to learn from though the advancing wall quickly teaches the player to shoot. As part of my change list I instituted a second level which inverts the perspective of the first level and offers a different color palette.  In addition, I made a more visible laser and two different laser modes. I also tried to make the player more visible by adding shadow and changing the blue color so as to offer contrast with the background. frogLaser   In the future I would like to definitely work out a charging mechanic and perhaps introduce more movements for the bad guy.

Group Game #1: Climb

  climb (2)   “Climb” is a single-player game that uses keyboard as the main input. The player acts as the character at the bottom of the screen, and the goal is to climb up to reach the dotted line.  The character’s arms and legs are mapped with “F” “J” “V” “N” keys, and the player is free to step up. climb (3)   In the yellow text bubble, an instruction is provided for the player to follow. If this random-generated pattern is not followed strictly, as a punishment the green bar would fall and push the player back to the initial position. climb (4)     In the “I Lose, Therefore I think” article, Lee talks about game being  defined as “an interactive structure of endogenous meaning that requires players to struggle toward a goal.” In this game, this struggle comes from the danger of falling brick (cancelling of past effort.) In the play testing session, I found that instead of following the message, players tend to randomly press keys when first starting the game. Usually after several unsuccessful trials, they realize that it is not possible to win using this method, and therefore they would start paying attention to the text bubble. In this case, the falling brick is a form of instruction that asks the player to pay attention to the interface.   climb (1)   During the play testing session, I received feedback mostly on two areas: firstly, since the instruction bubble was originally placed above the dotted line, it can be difficult to notice when the player concentrates on the bottom half of the screen. To solve this problem, I have now placed it on the bottom and have it move alongside the player. Another important feedback is on the color palette. instead of using two high-contrast colors for the dotted line and the brick, I decided to use the same green so that they form a separated domain that is different from the player’s side.   Meanwhile, I have also added the difficulty of the game by introducing the “not to do” message. Those messages randomly appear on the text bubble and if the player press the key while told not to do so, the brick will fall as a punishment. To take this game to the next level, I’m hoping to: 1, adding details to the character 2. adding time limitation and show it graphically 3. adding sounds    

Group Game #1: Deep Sea Rescue


After reviewing the labs our initial ideas were brought to fruition, such as randomly generated objects of which determined the speed of our bad guy (though from the first set of labs this mechanic was not yet available). We were also able to create a functional player model. From here our ideas evolved with the code which enabled us to add the functionality to the moving objects and interaction between the player and our bad guy. At some point our randomly generated objects evolved to moving objects. We even included a winning and ending ‘animation’ to our build. Our bad guy, the shark, would increase it’s speed if the player, a lifeguard, came into contact with a bad square. Adversely if the lifeguard came into contact with a good square, a swimmer, it would slow down the shark. The path of the shark would not be altered, therefore creating a set patterned path. Contact with the shark lead to the player’s immediate player, resulting in ‘bleeding out’. The next step was to make the game clearer to our initial concept of “Deep Sea Rescue”. Therefore adjusting the colors to produce a beach and sea background and create a realistic shark.​ -Jessica Sanchez amysketchbook1   Our bad guy is a shark, so we decided that it would make the most sense to have him slowly move throughout the entire game screen. He follows a relatively predictable pattern, bouncing off the sides of the game screen each time he collides with our boundaries. He is able to more effectively exploit the terrain when the player collides with a black squares; he speeds up, and it becomes more difficult for the player to avoid him. Each time the player collides with him, they are ‘bitten’ and sent back to the deepest part of the seas. When the player has been bitten three times, they are permanently killed. Clearly, this will teach the player to avoid the black squares, and the sharks! amysketchbook2   Our play-testers had a little bit of difficulty finding the goal at first, so we enacted a gradient to help visually steer them towards the shore. They also found the player’s responsiveness to the mouse made the game a little bit too easy, so we have turned the player into a draggable, where the user must click and hold the mouse button in order to pull him towards shore. When working on the game, I worked primarily on making sure collision functioned, adding in dying animations for the shark, implementing the gradient background, cleaning up and consolidating code, and turning the player character into a draggable. -Amy York IMG_2008   The original plan was to have a circle bad guy who moves around the terrain (bouncing) preventing the player (a square at the time) from reaching  the opposite side. For the first round of playtest for “Deep Sea Rescue” I worked on creating and randomizing the good and bad squares (prior to learning about classes), as well as creating the finish line/end zone (the player’s goal). The squares were intended to either help the player to succeed(ex. slow down bad guy) or cause the bad guy to do bad things (ex. speed up). IMG_2009             The second round I worked on the Good Square class and the Bad Square class and limiting the range on where the squares can randomly appear which fixed our first issue with the squares. I also attempted along with Danielle and the help of Amy, to create a counter for each time the player collides with the shark resulting in a number of “limbsEaten”. However, it became rather difficult to figure out why our counter would show  3 consecutive collisions when only one would happen, at that point Amy was able to find the proper solution and help Danielle and I. The purpose of the counter was to give the player a choice to continue in their attempts to succeed. For the final playtest version of the game I worked on the color scheme, reworking the shark image, and creating the dead shark image. It took a chart to organize all the points where each triangle would meet the body of the shark and to help keep track of placement on a visual level.  We were asked to make the color scheme more “deep sea” like and make the shark more “shark like”. The shark went from a gray circle to an oval with fins, a tail, and even an eye. -Destiny Colon

Group Game #1: Ion Rush

IonRush (click for .zip) Ion Rush is a game of patience and timing. It forces the player to pay attention to the enemies’ patterns in order to proceed. screen1 Each “laser beam” flickers (at a constant rate) between two colors – green indicates a safe passage and red a sudden death. I programmed the beams to be re-positionable, which gifts them the ability to section off the terrain and force the player into smaller and smaller “beamless” territories. screen2 The significance of the beam colors becomes immediately apparent once contact is made. On a collision with a red beam, the player is sent back to the start. This form of failure instructs the player to pay attention to the flashing colors and gives them the choice to either hastily rush into the beams or take their time. screen3 This game has been constantly rewritten and is currently built for even more revisions and features. The major jumps so far have been: – Code structure to support beam width and location- Multiple beams – Backgrounds that change color with player movement – Clean(er) gui that indicates level completion I’m looking to implement the following points: – Revise code structure to accommodate for different color patterns/speeds/durations – Have the beams move around – Less rigid player movement (especially on a touch screen) I have many ideas for this project and hope to continue working on its evolution! – Dean Russo

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 #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.


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