Archive for October 31, 2011
It’s not a command; it’s a title. I’m not exactly sure why. Maybe I’m going for a Cactus aesthetic (and by the way, his new game Keyboard Drumset Fucking Werewolf is awesome). I originally just designed the title screen to encourage the player to start then realized I had no room for an actual title, liked the vibe, and kept it.
The game is a simple action game that uses particle interaction to spice things up a bit. The player must avoid touching the spinning purple objects all around them. The number of these objects quickly grows beyond what anybody could avoid, so they must use their shield to deflect hits. This is where the particles come into play: rather than just being a forcefield around the player, the shield is made up of hundreds of small particles that are attracted the the players ship. They follow, and repel each other enough that when the player is still, they form a circle around them, but the player must be careful when moving because fast movement will leave some of the space around the ship vulnerable.
The shield also utilizes a mechanic I first saw in Bit Pilot by Zach Gage. In it, the player can gain shields, but each new shield is larger than the last, making it harder for the player avoid the asteroids of the space. In mine, as more particles spawn, they will take up more and more space around the player, creating a similar effect. And it is obviously worth noting, that the game play of Bit Pilot was very influential in Play This Damn Game.
Also complicating the game (or making it more interesting if you want to think like me) is the terrain. The play field is made up of hills and valleys that the particles and the player can slide along. The impact of the landscape can be easily overcome by the player’s own speed, but it does affect how the particles follow and how they disperse around the player. The obstacles are unaffected by this terrain. The terrain itself is generated by a noise function, so it can be explored infinitely in any direction, although if the player retraces their steps, it will be the same.
Each pixel of the landscape receives a value between 0 and 255 from the noise function. These values are used to determine if a given set of pixels constitutes a hill or a valley, and which direction it should be pushing the particles in. To create the visual effect used for the background (which wound up informing the visual style of the entire game), I simply only draw the red values (0-255) that are divisible by 6, leaving the rest black. This creates something that looks like a topographical map from Tron.
I am still testing the game, and it may undergo some changes in the enar future, but for now, check out the Mac app here.
And as always: source code.
This week I’m making browser based Elementary Cellular Automata using forms.
Cellular Automata are lovely little systems that create complex interaction out of the most simple rules. I find them fascinating and often like to see how they can be applied in unusual ways. In the past, I have created programs that convert black and white images into cells for Conway’s Game of Life, and I have no idea how much time I have wasted just playing with them on my phone.
If you are unaware of Cellular Automata at all, each one is basically a set of rules that allows a grid (or line or box) to evolve over time with cells becoming either alive or dead with each iteration, although there are some that allow for a wider range of values than simply alive or dead. The rules that govern whether a cell lives or dies is just the number of neighbors it has at the start of a cycle. While at first glance these rules would not seem to create anything sophisticated, nothing could be further from the truth, with complex machinations arising out of the right placement of the original cells (Check out the Gosper Glider Gun created in Conway’s Game Of Life if you don’t believe me). This page has a pretty good explanation of how these systems work.
On to my web form. Conway’s Game Of Life gets all of the love, but there are other great Cellular Automata out there! I decided to take a look at the varied Wolfram 1-dimensional cellular automata. Stephen Wolfram was pretty much the go to guy for the study of cellular automata and history was kind enough to attach his name to what is known as Elementary Cellular Automata. These are automata that exist in only a single dimension: just a line of cells that are either on or off. This creates an interesting situation for two reasons.
One, there is a limited amount of rules that can exist. A cell only has three if we count itself (and we do). There are only 8 different combinations in which three cells can be on or off, so all Elementary Cellular Automata can be described by which of the potential 8 situations will result in a live cell. Breaking this down further, these rules can each be noted as being on or off, so the entire rule set can be described as an 8 digit binary number, meaning there are only 255 possible elementary cellular automata. Cool!
Second, because a line doesn’t take up much space, resulting generations of the rule set can be shown underneath each other. For many of the possible rulesets, this creates amazing patterns and fractals. Others less so. You just need to play around with it.
Why check boxes and forms? Because it is interesting to see what these basic building blocks can do and how they can be pushed in interesting ways. Check boxes are just binary switches and there’s no reason why I can’t use them to simulate life. The Scroll Clock by Toki-Woki, which uses scrollbars, was a huge inspiration. The scroll bar is something easily overlooked in 99% of webpages and they managed to do something really clever and innovative with it. I wanted to see what I could do with a form besides just collect information.
Bellow are some fun rule sets to key in. Much thanks to http://mathworld.wolfram.com/ for creating these images and being a wonderful resource in general.
VIDEO CONTAINS SPOILERS IF YOU WANT TO PLAY THE GAME
This week I was assigned to create a composition using vector fields for my Algorithmic Animation class at Parsons MFADT (Notice how a lot of the projects form that class wind up on here?). I could have done a normal composition, but being a game designer, I decided to see what I could do with the physics systems we’d been learning about. he result is a physics puzzle game called Emitter.
In it, the player must push particles to one or more goals by placing emitters. Each level has a set number of emitters that can be used. Complicating issues is the use of more than one spawn point as well as holes that suck in nearby particles (but which can be used to curve their paths). Given that this was a one week assignment, I was only able to make six levels, so the difficulty ramps up fairly quickly. Likewise, I would have like to be able to create some tutorial levels, but there simply wasn’t time.
In the past, I have come up with puzzle mechanics that I liked, but I found that I always had difficulty coming up with the actual puzzles. The level design always became overly simplistic. Working on this one, though, I realized that I had much better results by simply creating scenes that looked visually interesting to me, then removing the emitters I used to create it. I did not think much about the puzzle, but just on creating an engaging system. Once I had this, I could remove some of the pieces and suddenly I had a puzzle.
Also included in the game is a sandbox mode for those who just want to fool around the the physics system.
Unfortunately, I only have it available as a mac app. If I decide to expand it, though, I will certainly offer it for PC.
This past weekend marked the first Parsons/Babycastles game jam, hosted by The New School Game Club, a competition in which teams formed at the event to spend 48 hours creating a digital game. If you are unaware, Babycastles is a fantastic organization in New York dedicated not only to giving a voice and a public space to game makers, but also to having fun with game culture. In this spirit, the theme for this jam was the spam-bot gone rogue twitter feed, Horse_ebooks. More on that in a moment. I wound up heading a four person team to create Disaster Wedding Starring Chance Cowboy, A katamari style game about a cowboy hell bent on smashing up a wedding. Play it here.
A quick note about the theme: horse_ebooks is a twitter feed that attempts to sell e-books about horses. It is a script that reposts things from the internet in hopes of drumming up interest in their site, except that is it is broken in a beautiful way resulting in a repository of fantastically compelling insanity. I could post my favorites, but they tend to be amazing and I really recommend you follow the link and just look at the first few to get a sense of the sort of things posted. The theme of this game jam was simply to find a post and make a game out of it. Some of the ones considered while forming teams were:
“The television is blaring. The baby is screaming”
“It will catch up to you”
“ALL DOGS CAN ATTACK”
“Phantom Horse in danger”
As you can imagine, we setled on on “Disaster Wedding” with “Chance Cowboy” being out supporting cast. The general idea for the game grew out of an idea for “It will catch up to you” where the player had to run from an ever encroaching unknown force. In our game, the player must run through a wedding, smashing it to pieces, and avoiding the wedding guests’ attempts to stop them. As he gains speed, Chance Cowboy is able to smash bigger and bigger things. Why does the cowboy hate weddings? We may never know.
The game combines a beat-em up view with a Katamari style gameplay. Although the player is constantly gaining speed, allowing them to smash bigger objects, they receive a boost for breaking objects, so destroying smaller things helps them destroy larger ones. The control is limited to rotating the direction clockwise or counter clockwise, which makes the game more and more challenging as the player gains speed. If an object that can’t be broken yet or a wedding guest is hit, the player looses a substantial portion of their speed. Larry and Jane managed to churn out an impressive amount of art, and the game came together really nicely within the small time frame.
Although being very fun once understood, the game presented some large problems, which were useful to see when the games were being demoed. The game can be really fun, but many players were not able to get to that point. In many ways, it is overly complex. This is proven by the four pages of instruction that proceed the game. Each page is short, and we made a deliberate decision to chunk the information as opposed to showing a wall of text, and we used a fair bit of space on flavor, but there is still a lot of information to take in. Many players simply chose to skip this, and the game became largely unplayable to them as a result.
One way I’d like to adress this moving forward with the game would be to include several levels. Some elements, such as the wedding guests, could have been introduced gradually, so that only a few game play elements would have been introduced at a time.
This would have also helped solve the control issue. Rotating a character that constantly moves forward clearly made sense to some players, but not the majority. This element made sense in the game as it made the increased speed a difficult thing to manage, but it threw many players off at first. Having an introductory level with very few large objects would have allowed players to experiment with the control system in a low risk environment. Because we only had one level, many players wasted half of their allotted time accidentally running into objects they didn’t mean to.
There was also some issue with showing what could and couldn’t be destroyed given the current speed of the player. All objects that can’t be destroyed are heavily tinted red, but not every player read the instructions which while frustrating, is an inevitable part of any game, especially a casual one. One potential change there is to make the objects that can be hit glow green to attract players.
The game values themselves largely seemed solid. We had very little time to test and tweak, but they came out well for the most part. The acceleration and ramping up all felt good. One thing that could change significantly is the amount of speed lost when too big an object is hit. Currently, the player looses just over half of their speed, but this should be much less. Originally, we had hitting an object take the player’s speed down to zero, and gradually eased it up, but this was one value that needs t be more forgiving. It’s far too easy to make a harsh game when the only people testing it have been playing it from the get go.
On the whole, though, I am very pleased with the game. In only 48 hours we created a very engaging game that has a distinct skill curve, evidenced by the fact that people were competing for top scores. The framing is fun and compelling, and once the controls are mastered, the game play creates an interesting challenge. There are certainly things I would change, but overall, Disaster Wedding succeeds as a game. We won 2nd place in the game jam and will be showing the game at the Babycastles show on November 4th (with a show by the Wu-Tang Clan). See you there!
The real challenge I found was getting the bouncing angle to work just right. I had to play with he math for a while, both on screen and on paper. In the past, I have mainly had things bouncing off vertical or horizontal walls, for which the math is extremely easy, but mapping this effect to unusual angles proved to be an interesting task.
On a more conceptual level I realized that part of the genius of Nimoy’s design was the complete lack of friction. When creating a particle system, there is a natural inclination to include friction so that objects slow down a bit over time (and especially on impact) and appear more natural in the way they move. What gives this toy such vibrance and energy is the fact that the balls never lose any momentum: if they hit the ground straight on, they will bounce back exactly as high as they fell from. This slight break from reality, while counter intuitive, allows for the massive setups that people can create with it since the only thing that will ever end a balls path through the lines is falling out of the frame.
While testing the toy, I realized that there was a fun game to be played by moving a single line around, trying to keep a ball in the frame for as long as possible. So I reworked the code and made a simple game out of it. The player is given a line, with one end anchored at the botom of the screen, and the other one going to wherever the mouse is at that moment. Balls are fed to the player and they earn points for the time they keep the ball going, with that score being multiplied by the number of balls they can juggle simultaneously. If they ever lose all of the balls, the round is over and their score is recorded.