Posts Tagged ‘Algo’
This week I have two relatively simple projects that play with text as the user enters it. Each one takes the text and imagines it in a new, abstracted way.
The first one, Letter Piles, takes advantage of openFramework’s ability to break text down into the vector shapes. Using this, I created a simple particle system in which letters are created as a series of points that fall to the ground, piling on top of one another.
Mac App: http://teaching.thesystemis.com/algo11/students/andrew/hw10/letterParticlesAppWallace.zip
Source Code: http://teaching.thesystemis.com/algo11/students/andrew/hw10/letterParticlesWallace.zip
UPDATE: Play with the Processing version in your browser here. Chrome sometimes has trouble with Processing.
The second is something of a grade school grammar exercise gone awry. Sentences that the user types out are mapped as a series of nodes, with letters clustering around their word node, which is in turn situated around a sentence node, which is finally attached to a base node in the center of the screen. Certain keystrokes, such as a space and punctuation tell the program to create a new branch of the tree. The result is a highly orderred chart that does very little to show the original message that was typed. Sure, it might favor organization over clarity, but that’s what we have every other text editor for.
Mac App: http://teaching.thesystemis.com/algo11/students/andrew/hw10/sentenceMapAppWallace.zip
Source Code: http://teaching.thesystemis.com/algo11/students/andrew/hw10/sentenceMapWallace.zip
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.
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.
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.
I spent the weekend mostly making things that made me laugh, which is always a good way to spend it.
First up is a project called Vomit Tracer, created for Algorithmic Animation. The assignment was to capture the motion of the mouse, replay it and use it as a control for something else. My sketch shows the mouse movement, rotating it around a central point, and uses it to control just how much a character vomits. Draw by holding down the mouse and moving it. You can have up to 5 faces and clear them off with space.
And that’s all I’ve got for now. We’ll see if things get less goofy next time around.
Algorithmic animation is a class I am particularly excited about taking this year. Taught by Zack Lieberman and focusing on creating life-like animation in code using openFrameworks, it was right up my alley. I have no doubt that a lot of the blog post here will come as a direct result of that class.
I’d like to spotlight 2 assignments I have from this week that really just scratch the surface of what I’m hoping we’ll get into.
This first is this simple little creature who follows the mouse. He’s a curious fellow and wants to no more about the mouse, but never grows completely comfortable with it. If I have some time later, I’d love to incorporate some computer vision so that users could hold up a piece of food for him and have him swim over to nip at it.
The second is an animation I made (with code, of course) done in the style of John Whitney. I created three distinct sections and had a lot of fun playing with shifting points in shapes as well as sine waves.
We’ll see what else I wind up making. I’ll highlight the ones I like, but all of my Algo work can be found here.
For my algorithmic animation class at Parsons, we were set with the task of recording three activities and tracing their motion out on film. I became quite fond of mine, and wanted to apply a nice soundtrack for it. If you have not scene The Life Aquatic with Steve Zissou, or at least did not pay particularly close attention to the music, Mark mark Mothersbaugh (of Devo fame) did a fantastic job of the soundtrack, and it seemed to have the right vibe for my video.