(a preliminary title screen)

    For my second group game, I’m redesigning my first group game, Relay. I started my redesign by imagining what Relay would look like if Tim Burton were to design the game, and came up with some some sketches: Instead of the bad guys being circles, I changed them into black triangles with red eyes. The black and red colors of the triangles contrast with palette of my game, which is mostly grey and yellow. I decided that instead of simple black rectangles for goals, my goals would be lamps. The object of the game is to avoid the bad guys while keeping the lamps lit. The bad guys want to shoot globs of red at the lamps to put them out. If the bad guys manage to cover the lamps entirely in red, the player loses. After sketching, I created a simple interface: As in Relay, the game starts without any bad guys on screen. But, each time you drag the lamp lighter, bad guys start to appear: The lamp lighter’s eyes also glow when you drag it around. I really like the mechanic of adding bad guys each time the player is dragging, because that way the player has to constantly be engaged with the game. This also gives the player choice – they can choose to drop the lamp lighter, but that will increase the game’s difficulty by making the bad guys more powerful. I also added a behavior to the bad guy that wasn’t present in Relay – it shoots red globs at the lamp to try to put the lamp out:

I want the bad guys to cover the lamp red section by section, but I’m still working on writing that code. Right now, the globs are an array list within my bad guy class, and the bad guys are an array list in the main class. I might change the wrapping pattern of the bad guy so that they’re harder to avoid, or add a different bad guy that does something else, like shooting globs that freeze the player momentarily. I also want to add another lamp so that the player has to cross back and forth between the lamps while avoiding the bad guys.

I still have a lot to work on, but I’m confident that I can get the code written and design a more detailed interface. I’m working on drawing a different lamp lighter on my tablet, who looks more like this:

I also want to design a background that looks like a street in victorian London, and make a better title screen. I look forward to posting about my game when it’s all finished!

      For group game 2, Silas and I are working on a game called Polarity. The image above shows the design concept of this game, which is switching polarities to create diverse movements. For the basic game mechanics, please check out this post. Since this game was originally conceptualized for its game mechanism, during the design process it started to tilt towards a puzzle, so creating a narrative became a challenge. In order to incorporate a bad guy, first we decided to visualize the timer. Instead of having a countdown, a wall will start moving from the left to occupy the playable space. This wall also serves as a giant magnet that attracts other particles and neutralize them so that the player will have less force to reach the target. To create diverse multiple encounters, we decided to have the wall/giant magnet act differently in each level. For example, it can adopt different shape, including ones that have a channel in the center, which will not only transform play strategy, but may also influence the goal of a specific level.  Since the behavior of the wall would change, it will give each level an endogenous meaning while creating diverse and challenging game play. Though the wall will perform the “bad thing,” it may not be expressive enough to carry a whole narrative; therefore we decided to create a real bad guy and make the wall a weapon that he uses. As Jenkins mentioned in “Game Design as Narrative Architecture”, the conflict between interactivity and narrative is often solved by incorporating spatial stories and environmental storytelling into the endogenous world. In the case of our game, the bad guy need to appear in the winning zone (on the right), where he can hold the object that the player is chasing after. Meanwhile he needs to control the movement of the wall, which starts from the left. This spatial separation inspired us to have a chain that goes across the screen, and the “bad thing” is therefore transferred to the bad guy, because he becomes the one pulling.   On the mechanism level, the bad guy does not have any direct encounter with the player. However, he is crucial for a thorough narrative across levels. During the design process, we have discovered similar bad guys in other games who do not have direct collisions with the player. For example, Bowser Koopa in Super Mario often only appear at the end of each level to kidnap the princess to another castle; In Angry Bird, the pig performs bad things only in the cut-scene narratives and do not actually encounters the bird. To a certain extent, those bad guys are giving meanings to the spatial environment. Similarly in the case of our game, the story will be an enacted narrative, which uses features of the environment to move through the plot trajectory.  

Rightfully Yours requires a bit of focus and practice in order to trump your enemy. An ominous shape fires missiles from above while you return with a steady fire of your own. If the player succeeds at striking the enemy with a bullet, the enemy loses some opacity. If the player makes three successful hits, the enemy changes form. With each form change, the enemy gains speed and increases its rate of fire. The player is given three lives. Starting in green, a hit from the enemy turns the player yellow. Another hit – red. If the player is struck by three shots, it’s game over. The game mechanic is therefore quickly recognizable as a one-on-one match to the death. Standing still is obviously not an option. The player is forced to duck and weave between the falling shots, learning which tactics make the greatest difference along the way. It’s no easy feat to land 9 shots total on a target that gets harder and harder to hit. Simultaneously, the stage becomes more and more dangerous to freely traverse. Suspense builds the longer you play. The design of the enemy is loosely influenced by the mechanics of bullet hell games (flooding the screen with obstacles, drastically constricting the players movement). The enemy’s class is built as a single object whose methods are triggered by the actions of the player. While there is no contested object that the player and enemy fight over, there is a sense that both are fighting to overcome one another, and hopefully make it to the rewarding finish… I have loads of room for improvement and advancement. My strongest urge is to vary the enemy’s bullet pattern and design more demanding dodge tactics. I also wish to implement upgrades to throw a bit of chaos into the mix. I feel confident in the structure of my game and my use of ArrayLists and collision.

 

Our game will be made out of the paper prototype that we came up with in class. Because it was a paper prototype, we had created objects beyond our time and ability to code. Thanks to Amy, we were able to come up with a reasonable solution to creating our game. In the game we hope to create, the player (Red Riding Hood) must escort Granny and the magic buns to the cottage before Granny transforms into the Big Bad Wolf.

Our bad guy is a group of rabid squirrels. They exploit the landscape by moving among the forest canopy in a v-shaped pattern. On every third step, they attack the player in an attempt to get one of the buns. In turn, Granny moves one step closer to turning into a wolf, and the environment begins to move closer to night time. The squirrel’s first stage of attack is jumping towards the player. If the collision is successful, the squirrels eat a bun and gain the ability to move faster. If a second collision occurs, the squirrels gain the ability to create a pot hole. If the player walks into the pothole when the squirrels are still within it, the player lose a bun. On the third and final collision, the squirrel grows larger making it harder for the player to avoid. If the player loses all of their buns to the squirrels, Granny transforms becoming an enemy and the player loses (is eaten?).

The player begins the game with the ability to spray the rabid squirrels with a water bottle. In the game, the player will be alerted to the ability by the object flashing brightly when a squirrel enters a perimeter trigger. The player will also have the ability to manipulate the squirrel’s attacks by using empty potholes to avoid collisions. The player will be able to learn from their failures, by seeing how Granny is slowly turning with each bun they lose. The player will control the actions of Red Riding Hood by using the mouse-dragged (to move player left and right across the path and the mouse pressed code to activate the water bottle and hide.

In the code, I will be working on the primarily in the squirrel class by creating their path and collisions. Because we worked so hard on the illustrations of our game, we wanted to incorporate the actual pieces of our prototype within the game. I will also be focusing on the graphic and animated parts of the code by making them image files from the paper prototype small enough to run in the code. I will also be working on the animations of granny’s face changing over time, and the squirrels getting larger. -Danielle Brusco   Our group game is developing from our paper prototype. Our first draft of the prototype lacked a few essentials, such as, having many different encounters, and a few other aspects, which we chose to address in our second draft of the prototype.The idea is to make a game with a paper cut out look. I drew our bad guy (squirrels) rabid looking to contrast with the happy looking fall forest environment. The squirrels follow a precise up-down-up pattern. They utilize the environment by hiding in the trees and creating potholes. After drawing the squirrels, I drew Little Red Riding Hood and acorns. Little Red is our good guy and the acorns are used as projectiles between the good and bad guy. The goal of the squirrel is to collide with Little Red and take her magical hot crossed buns to make them stronger. Each time a bun is taken a new type of encounter happens. As the player begins to lose the squirrels become more powerful (they get big and faster, they throw acorns, and they create potholes) and eventually becomes a mega squirrel. As the bad guy changes Little Red also has new choices available to her, for example when a squirrel throws an acorn she can dodge it then throw it back, or when a pothole is made she can also hide in there herself. The goal for the player is to escort their granny, who is progressively getting sicker with the big bad wolf curse to her home, the more encounters Little Red has with the squirrels the more wolflike she becomes, and if the player fails she becomes the big bad wolf and teams up with the squirrels. We are planning to make the squirrels an array list and Little Red as a class in order to portray our game in code. We plan on having multiple collisions coded for each encounter between the squirrels and Little Red, as well as having a changing environment according to the player’s progress within the game.  In the weeks to come I will be working with the collision for the squirrels with Little Red and the collision with the potholes, in addition to anything else my group requires. -Destiny Colon   When we decided we wanted to make our paper prototype a reality, I was initially concerned that we wouldn’t be able to keep the awesome ideas we generated when we weren’t worried about being able to actually code the game. I think it was pretty clear to all of us that, while we wanted to maintain the integrity of our game and keep the best ideas, there would also be a lot that we would have to strip down or simplify so that this could be something we could realistically code in a few weeks. So, during our re-design process, I effectively became the Resident Wet Blanket. I did my best to toss out ideas that were far too difficult for relative novices to code, eliminate details that were cool and theoretically possible to code but would ultimately end up taking too much time when considered on top of everything else we’d need to work on, and to simplify core aspects of our game’s narrative and our game’s mechanic so that they would be code-able *and* play-able. The end result of our two-hour design meeting is a game that I believe will be a challenge to code, but is much simpler than our original idea, and in its simplicity even manages to improve upon our original paper prototype while still including all the narrative and design elements that made us love working on this game so much in the first place. In the coming weeks, I will be working on making sure the environmental changes are timed correctly (particularly granny’s shift from woman to wolf as the sun sets), as well as providing general help and trouble-shooting whenever my fellow group members run into any issues. -Amy York Image from Jessica’s notes

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. 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.   In the future I would like to definitely work out a charging mechanic and perhaps introduce more movements for the bad guy.

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

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   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!   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   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).             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

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