Postmortem. Overall I was very happy with how the game turned out. I was pretty lacking in ideas initially but rethinking the design elements was very helpful in conceptualizing the game. By having a clear idea I was then able to create an interesting visual experience. It turned out that simply changing the alpha value vastly altered the experience as the previous frame is visible when the new one is drawn. This means that even in the title screen one can see the remnants of the previous game which helps to create a feeling of permanency. So that it is not as if the players actions are completely erased with every win or loss, they are reminded by the fading trails. Probably the most difficult thing for me was trying to get just one rectangle to appear from the arraylist. I spent an inordinate amount of time on it and it still was not completely resolved. Other than that though, the coding was not too difficult as it was mostly cleaning up the code that was written before. I built upon a solid code base so making alterations and changes was very easy. The real changes I made were to the color palette, shadows, background, and consistency of the ‘star’ in appearing at the correct time. These relatively minor changes had a pretty large effect. However, it felt good to be able to go back and finish up a game properly. It was probably the most ‘finished’ game I did this semester as it fully incorporated a gameloop so revamping it was a good option. I was helped greatly by a clear class structure when making additions. But If I had to do this again, I would from the outset design the game with the gameloop. At times the gameloop code could be quite frustrating as I had essentially created the game and then had to port it over which required substantial refactoring to make it all work properly.
After working out the various bugs of my previous version of Come and Play, I have the final version of Come and Play. The title screen: The Monster got a bit of a redesign: (the central eye worked better with the grow mechanic) I also added the a shrink function for the Moon, so that it really seems like it’s being “eaten” and disappearing. I finally worked out the bugs with the fireball/village collision and I got back the red “burned” village from the very first iteration of this game: I also programmed levels and made two separate level outcomes based on whether the player chooses to have the monster eat the moon or burn the village: I also programmed in some creepy sounds that will hopefully work when I present my project. Looking back, I wish I hadn’t spent so much time figuring out the collision code for the fireball/village collision. I spent so much time trying to get the collision to work from within the fireball class (and not succeeding), but once I tried coding the collision in the main class of the sketch, it only took me a few minutes. I really enjoyed working with this game, and I had a lot of fun tying together code from my various projects. That being said, this game definitely has lots of room for more player choices. I’ve spent as much time with this game as I can for now, but I think that I’ll come back to it and add more to it in the future.
So after coming up with the initial idea of “Come and Play,” I sketched a few more ideas in my sketchbook: I decided to make my monster, an arc instead of a circle, and to use the draggable item/particle system mechanic from my Magic Wand game to make it breath fire from its mouth. I also made my monster draggable, and game him a red eye. My new Monster with a mouth: and my new Monster when pressed and dragged: I also decided to add a face to my moon, so that when you hover over it, it has eyes: To add more player choice, I’ve decided to change the feed monster mechanic – instead of feeding the monster resulting in the monster turning red and shooting fire, the monster instead grows, until the player releases their hand, at which point the moon is moved offscreen. The growing works really well, except for one problem: The eye doesn’t grow with the monster. I’m also trying to code in some fireball/village collision, and I’m struggling with that. Hopefully I can get some fireball collision and eye growth working soon!
As I continued with development I started thinking more and more about a name for the game. Eventually I chose Euclid’s Dream, drawing the connection between the shapes and his role as the ‘father of geometry’. This made it far easier conceptually to think of the design elements and so I chose a set of colors with the help of Adobe Kuler. I also looked at Google’s Material Design framework to see how their guidelines could help me. It turned out that they were using very simple colors in concert with flat but carefully stratified layers. The idea is that different layers are like different pieces of paper laying on top of each other. Paper is thin and maintains a distinct look to it. I tried to emulate that somewhat with the shadows which simply consisted (in the case of a rectangle) of another rectangle offset and black behind the original shape. This created the illusion of shadow and offered depth. Playing through it at this point I was feeling as though it had become too easy to play. Thus I needed to institute a real means offering challenge. However all I could think of was creating more rectangles as aggressors or altering the speed the rectangles moved. One unexpected aspect of implementing wrapping was that it made the game actually feel quite different. It no longer felt as restrained and was somewhat illusory as it made it seem that there were more objects on the screen. My original plan with difficulty was to add another rectangle when one circle was eaten. However this had its own set of problems as my collision code was linked to the draw function and thus registered multiple collision hits per frame. It meant that the arraylist I had made to hold the rectangles would generate a vast amount on the screen. I tried to use boolean flags to guard against this but I was not so successful. Second I attempted to simply add another rectangle following a ‘win’ by incrementing the total rectangles spawned. In the end I was able to make it work by linking it to mousepressed in a similar fashion to the vehicle code. The mousepress resulted in a single rectangle being added but then either would not stop adding more with each mousepress or would not add more with each successive winning round. So It still annoys me that that part is still so buggy. However, the game looks and feels quite a bit better due to the more carefully considered design this time around.
For my conference project, I decided to keep working on the game I’d started working on for the Black & White Exercise #2 assignment. I wanted to expand on the game and make it more interactive and playable. I want this game to be more exploratory – I want the player to have multiple choices and goals and outcomes. Since I want the game to invite users to explore I’m titling the game “Come and Play.” (I also think that title is a little bit creepy, and I want this monster game to be a little creepy.)
For this game I was using the code base of the race to the finish group game I completed with Giles. As such I already had much of the game mechanics fleshed out. This meant that when I went to complete the game further, I looked to more aesthetic changes. Thus in my sketchbook I set about creating a different look through the use of shadows. At this point I was looking to create a more three dimensional look to the quite simple geometric shapes and also utilize a more fully featured palette. The previous design incorporated total grayscale elements which now seemed limiting. Therefore there was scope for improvement. In this early stage I wanted to use quite bright colors with a shadowed look. In addition, I wanted to incorporate a few other gameplay features such as wrapping, greater difficulty and clean up the gameloop. Also the original name Chameleon did not really fit the original grayscale game and so I decided to change that too.
Despite the fact this class doesn’t use the traditional conference formula Neon Rush has been closer to the regular conference projects. Going all the way back to the beginning of the semester is when the design process started from chameleon. A game based around color changing and a lot of hectic movement on screen. The game changed a lot when we shifted to back and white and really emphasized the hectic movement and speed of the game. Getting a lot of inspiration from the game Ikaruga which is know for it’s difficulty. The game was simple in nature. Collect circles and avoid squares and if you kept failing a power up would drop that you could collect to increase the size of circles and decrease the size of squares. When looking at improving the game for conference I wanted to increase what was already fun about. Namely the hectic nature of it. I also wanted to bring color back to the design. The best way to accomplish this was to me implementing the series of particle systems we learned about. The colors i went with were entirely basic to keep everything contrasted to avoid mix up between objects as well as livening up the atmosphere. I was going for a Geometry Wars feel of simplicity but bright and engaging. Giving the player standard particle spew the wanted objects a trail of rings so that you could follow where an object is and where it was. The solar system style of particle is the first new addition to the game. Two vortexes at the ends of the screen are different from the rest of the objects in that they are not related to a good or bad scenario. All they do is move the player to a random location in the middle of the screen which can be either a bad thing or a good thing. I liked adding this entirely optional section to game play. It adds a different way of approaching the game. The only other change was something that i ended up reverting. I originally wanted to change the movement of the player to a vector based system but after having done it i found that it made dragging the really only option where as in The only movement format of easing both dragging and tap were both viable ways to play and also played differently. This was a decision i went back and forth on a few times but am happy I decided to revert the change despite the time I put into the code.
Looking back at Attendance I really enjoyed working on it, both for hider seeker and for conference. I started out with a pretty cool mechanic in the vehicles stopping at certain points, but our original idea of a police chase game was pretty tired and had been done before. Coming up with the idea of students racing to their desks was a fun process that led to a pretty nice result. It felt a lot like that talk by the creator of Braid on making prototypes with a decent mechanic and then applying that mechanic to different games later. For the conference project section of the game the biggest change I made was the addition of the hall monitors on the screen Before After While the change may look really simple, it actually goes a long way towards adding a lot player choice to a pretty simple game. I really enjoyed working with a game for long enough to fully develop ideas, change them completely, add in new things, and just generally really get to know the game making process. My only disappointment with this game is, although it is not nearly as tired as a cop chase game, the game still has a sense that it could be more original. So I think for the future I will put this game kind of on the back-burner for a while until I can come up with a better concept. But all in all I think this turned out to be a really fun game that has the potential to expand and get better the more time goes by. I feel like I learned a lot about the game making process with this game and I’m definitely happy I worked on it, even if this specific prototype of the game doesn’t go much further than this.
The game is done. This is the newest edition of Standoff. It’s a pretty easy game to play that involves basic mechanics. The player is the cop aka triangle at the bottom of the screen, there is the vigilante aka red square who’s at the top of the screen and there is 2 circle shaped hostages and they are between the cop and the vigilante. All of the shapes are bouncing along the x-axis with different speed. The goal for the player is to catch the vigilante. and in order to do that the player has to tap the screen at the same time the cop and the vigilante are around the same y-axis, of course there is a risk of hitting the hostages since they are in between and the player loses in order to do so. The player gets 4 attempts in 1 game. If the red square is caught by player it’s showed by a line and also a text appears “YOU WON” and hostages come down towards the cop aka the safe zone. if you hit one of the hostages same thing happens to the hostage while the text says “YOU LOST”. The restart screen pops up after a tap if you have 0 ammo left or if you hit a target. And if you tap it the game starts again. After the second post I’ve accomplished all my goals I was suppose to do. It loops perfectly and it restarts properly as well. I had to make a “void restart();” function and I cut all the code from “void setup();” and pasted it to here. After that I have put “restart();” under RESET case and it worked properly. I changed the font as well using “PFont” and loading Gungshuh font which I think is way better than the former standard form. Overall I am really satisfied with what I have. It was definitely worth all the hours I sat down and read the print out of the code. It took me forever to solve the restart problem but the way I figured it out by myself made me understand every single piece of coding I’ve written one more time again. I think It ended up being a great game. I am glad I got the learn the processing language and throughout the semester I felt like I got better every day as a coder and definitely want to improve more.
So once I added an extra obstacle to the game I had successfully finished the “build it” phase of my game cycle. I like to condense a game making cycle into three main phases; build it, break it and fix it. The build it phase is the most straight forward, make your game. The break it phase is when you add new objects or functions to the game that probably won’t work well. That’s where the fix it stage comes in, you make this new code with the new function work, and before you know it your back at the build it stage. I completed the first build it stage of my game by the time of the hider seeker turn in, for conference I focused on the break it and fix it stages for my conference project. Here is my break it list I almost didn’t post this image since it isn’t your standard word press post as it isn’t very visual. However I have found that in the break it phase a change list is the most effective to get your ideas down. Once you have the break it phase done, the fix it stage is the most technical just get your code to work. For attendance the build it break it fix it process was really great for adding a new challenge to the game. I already talked pretty in depth about the process of adding a challenge to the game, but the other big thing was trying to find a way to improve the aesthetics of the game to make it feel less like a novelty game. I found that the music was what made the game feel the most tacky, so I really wanted to change the sound in the game. After adding a challenge, this was the biggest point on my break it list. Luckily adding new sound isn’t too hard so my fix it stage turned out to be pretty short.
After a while I worked with the code, I made the necessary changes for standoff to be a better game. At first I changed the color. The background is a dark grey bluish color and the cop(player/triangle) is black while the vigilante(square) is red. The hostages are still white at the meantime. Secondly I fixed all the mistakes that made standoff not to run on a tablet now it works. It was a mistake with “init()” function that wouldn’t make it run on a tablet and it was fixed while I discovered after I attentively read the printouts. Last thing I adjusted was the shooting line. I’ve created a line when the cop(player) hits either of the targets. I have made its “strokeWeight()” big so it looks like he kind of caught him with a whip. There was still something I could not figure out. I used loop to make different cases so it would restart the game. The RESTART level worked so the start page would come back again after you tap it but the game would not restart it would just the bring the old game screen wherever its left from the previous time. I feel accomplished a lot with this game so far but I think it can still be better.
For my conference project I decided to continue working with my hider seeker group game. The main reason I did this was that given this was my first experience with programming I felt that my most recent work was my best. However there was still work to be done to improve the overall experience of the game. The first thing I knew I had to add to improve the the game was adding an extra obstacle. I knew that simply racing against the clock wasn’t the most fun mechanic and I needed something else, a new choice for the player. So I toyed around with a couple of ideas for an extra obstacle in my game. The first idea I had was to have a door that opened and shut so you would have to time when the students would cross, but you couldn’t take too long because the teacher was coming. I liked this idea because it really put the timer in the players hands. If they chose to rush through the door they ran the risk of getting caught and losing, but if they made it they would have more than enough time left on the timer to reach the desks. On the other side if the player is too cautious at the door they run the risk of not getting to the desks in time. The downside of this design was that even though it added some player choice, it was still pretty one dimensional choice, “go” or “don’t go”. While I liked the opening and closing door idea, it fell short of really substantive player choice. So I went back to the drawing board to try and come up with an idea that would add even more choice to my game. The idea I had was a principle who wanders the halls attempting to catch tardy students. So I gave the idea a rough sketch I really liked the idea of not just the teacher but the whole school trying to catch these students being late. That concept was definitely the take away from this sketch it added a great game feel of an us against the world mentality. My only concern with this design was that it was too easy to just dodge one obstacle, even if it had free movement. I know that more doesn’t mean better, its one of the basic rules of design. But for this specific game I really wanted to bring out this us against the world feel in the player. So i think in this circumstance having more did improve the overall feel of the game So here I added multiple obstacles and changed the name from principle to hall monitors. This I think was the perfect obstacle for this game, it provided the player with multiple pathways to victory and a go don’t go decision as the timed the monitors movements. I really think that this design allows players to say “oh that didn’t work let me try this way”. Which I think is what every game designer should want their player to say while playing their game. Here is a screenshot of the game with the hall monitors
After learning the seeker code I first made the opposite of seek which was repel. I found the repel mechanic a lot more compelling than seek. Now the player did not need to have direct control over the vehicles as they could simply react to forces in the world. Therefore I created agents for those forces in the form of orange markers. These would trigger a collision within a certain radius and then repel the vehicles. The original concept was for the background to change color after a certain number of collisions similar to my earlier inversion game. However, I abandoned this as it seemed too simplistic. It needed to act more like a system as we read about in Pond World where one is putting various agents into a world and letting them interact with each other. The desired effect being to create a balance. I am not sure it actually worked out that way. With Giles we set about creating more directed mouse movement as it seemed necessary to herd the vehicles in some fashion. Giles then came upon the idea of using the ring lab and scaling them down to create a trail behind the mouse. The intent being that the trails would show the forces at work, where they were and where they were acting. In our implementation, they also had the unintended effect of simultaneously turning the markers’ outline the same color as the rings. In addition to the rings we added wrapping to the vehicles so that there would be a feeling of continuity as the vehicles would simply appear on the other side of the map. In future I would like to add more forces acting on the vehicles. Perhaps some more enemy behaviour would be interesting to have a more aggressive ‘attacking’ style as perhaps the concerted effort of several markers could try and herd vehicles into a certain spot. Thus the role of the player would be to counteract this threat.
My particle system started as a simple shower of colorful circles. After that was done, I tried to get the circles to react to the cursor/mouse position. I basically wanted a gravity well to be located where the mouse was, but I had a hard time figuring out just how to code that. After some fiddling with it, though, I did manage to get a satisfactory reaction from the circles. The forces are fairly weak, and therefore hard to present through static images, but notice the tendency toward the large white circle (the indicator for the cursor). If you hold the mouse button down/hold your finger to the tablet, the colors, become slightly brighter, and the force applied to each circle is doubled. Overall an interesting little intro into the world of particle systems. I still am quite interested in learning how to properly code a gravity well.
Overall a fairly simple exercise. Using this as practice with matrices, rotations, and translations, I challenged myself to get multiple rotating things to revolve around other rotating things. As the first few parts came together I was reminded of a scrambler: And once I took 2 of those things and split them I was reminded of the DC Shoe Co logo: I threw those things together (with a touch of blue) and came to something sort of interesting: Axing the background and adding just a little extra complexity yielded my Scrambler:
When I started this exercise, I wanted to create an array of slowly rotating rectangles that appeared wherever the player tapped on screen, basically like in this sketch: I had programmed the rectangles to have a completely random color, and a random size within a small range. I also changed to rectMode(CENTER) so that they appeared evenly around wherever the user tapped the screen. I was still having problems with the rotation, though. I couldn’t quite figure out how to get each rectangle to rotate around its center. However, I somehow stumbled across a solution that turned out to be much more aesthetically pleasing, and satisfying to manipulate, than what I had set out to do: I know it doesn’t look like much, but at every point where there’s a rectangle on screen, the program is rendering a new one every frame with a random color and size. So really, each rectangle actually looks something like this sketch to the naked eye: I know it’s hard to tell from the sketch, but the resulting effect onscreen is not unlike a crystal or jewel twinkling in front of a light source. I’ve limited the array to a maximum of 50 different jewels on screen, and each one has a timer that gradually dims it within one to five seconds (a random setting for each jewel). I was very pleased with the results, and found it very enjoyable to tap all over the screen and look at the pretty twinkling lights that ensue!
When I first started Streamer, I made 2 related observations about the base code.
- It was (at first) difficult to grasp, and therefore would be difficult to change.
- It was also interesting on its own, meaning it needn’t be changed too much to provide an interesting application.
Unfortunately, I had no idea how to program the behaviors that were the crux of the games I wanted to create. I started out by looking for different ways to program creating a line. The first way to do it was have it drawn based on mouse position: This wasn’t exactly what I had in mind. I wanted the line to go straight from where you started touching the screen to where you released it, not for it to trace the curves your swipe might make along the way. Another technique I came across was to make a line across two points with a click, or taps: While this setup got me the line I wanted, it wasn’t done with the swiping motion that feels so satisfying and intuitive on a tablet. Eventually, with some help, I found a way to make lines that went directly from where you started you swipe to where you let go without taking in the curves: Even after these developments, the main hurdle that remained was programming the bouncing behavior across paddles the player had to draw. This was simply beyond my programming skill, involving higher level math that I was nowhere near ready to tackle… At this point I was forced to admit defeat when it came to the game being based on paddles drawn by the player. Instead, I chose to stick to what I know, what we’ve learned, which is vectors. The player wouldn’t manipulate a puck, but simply control a vehicle. The vehicle would follow the mouse/finger touches of the player on screen. The other properties of my game remained the same: collect gold coins/tokens and avoid mines as they appear with every coin collected. I decided to make the vehicle a very “smart” one, with a somewhat high maxspeed and very high maxforce. Since this made the player much easier to manipulate onscreen, I also decided to up the challenge by have the mines strobe from black to red, making them temporarily disappear against the background (think Boos from Super Mario), and endow them with random movement. (They sometimes could stray offscreen, but since the gamespace became crowded with them after a short time, I decided to let the ones that stray outside go on their merry way.) The title I eventually settled on for the game was Bokeh. Even if you don’t know the term, you’ve definitely seen them and already know what they are: It’s those lovely translucent circles of light that occur when a light source is way out of focus in a picture or film. The strobing circles that make up the enemies and tokens reminded me of that effect. (It also beats the heck out of other title ideas I’ve had… If you can think of anything better I’m all ears!) I’m definitely satisfied with the final result. Bokeh is a game that I would gladly waste my time with when I have a few minutes to spare, which is exactly what I wanted. I was married to the idea of the swiping/pong mechanic for a long time, and looking back, I should have focused more on the techniques I had already acquired throughout the semester instead of trying to reach for something that was out of my depth. In the end, it was best not to make the perfect the enemy of the good, and Bokeh is a good game.
My main goal for my conference game was to make a game that I would want to pick up and play almost without thinking, the kind of game I see people playing every day to breeze through life’s more mundane moments – on the subway, standing in line, etc. One of my first ideas stuck with me: a kind of single-player pong game where you control the movement of the puck by constantly redrawing a paddle. You would collect gold coins/tokens by steering the puck into them wit your paddle, and for each one you collected a new mine would appear at a random point on screen. Touch a mine and you’re toast. I thought this kind of gameplay would work particularly well on a tablet. I also liked the idea that the length of the game was only limited by player skill: like Snake, you just keep going until the increasing difficulty does you in. The swiping mechanic involved in drawing a line feels intuitive on a tablet, and is the foundation for some very popular games, like Fruit Ninja – I was sitting on a gold mine! I even expanded on the original idea and came up with another game using those same mechanics. In this one, the puck is initially sitting still, and needs to be guided around a minefield of “dead zones” (those large circles with skulls and crossbones in them) to the gold coin/token, again by using paddles you draw. Once you’ve set up your paddles, you release the ball and see how it plays out. This one would involve actually creating mazes/levels for the player instead of letting the challenge develop through the course of gameplay. There might also be a scoring system where you’re rewarded for making it through in a short amount of time, or using the least amount of paddles possible. I wanted the overall aesthetic of the game to be like the vector graphics of old, or at least similar to other games of today that hark back to them, like Geometry Wars: Black background, objects made of bright primary colors (red, yellow) and neon-ish ones, too (cyan, magenta). The overall idea intrigued me throughout the semester.