Posts Tagged ‘openFrameworks’
Particle Mace is going on the back burner for a bit while I work on Doodle Defense, but in the meantime it has evolved quite a bit. The game now features:
-Different modes of play. The game has Normal, Hard and Asteroid Field. Each of these modes tweak the rules the game uses to generate the universe. Normal and Hard are obvious; Asteroid Field has no enemies, but tons of huge asteroids. In this mode the particle weapon becomes a dangerous ball and chain that can smash the asteroids around you into smaller, more dangerous chunks.
-Missions. Each mode has a custom set of missions that change the game each round. These represent special challenges that can be preformed in a given round (a la Jetpack Joyride). I really feel that these greatly extend the play of the game by presenting new goals besides just lasting as long as possible (already an impressive feat given the hostile nature of Particle Mace). These missions include killing more foes, not killing foes, flying as far as possible, smashing asteroids, going on suicide runs, and many more. In the final game, completing these missions will allow the player to unlock new skins and other aspects of the game.
– Super tight controls thanks to using the lower third of the screen as a control pad, as you can see in the video. I went back and forth on this for a while since it meant sacrificing so much of the screen real estate, but what I realized was that the number one complaint I got about the game was the problem of covering up vital information with the finger. This not only fixes that problem, but makes it so that the player has far tighter control by being able to make smaller gestures in a field that stays steady instead of being relative to the ship.
Once Doodle Defense is finished up, Particle Mace will come roaring back. It only needs a little work, and then this vicious little arcade game should hit the app store.
As the final for Code Play gets closer, I’ve been doing work on Word Cave, my collaborative spelling game for two iOS devices. Most of the new work consisted of adding some art to the damn thing (a non-trivial task given that I can’t even draw a straight line). There were some minor changes to the game play as well.
For those unfamiliar with the game, Word Cave is a spelling game played by two players, each on their own iOS device (either iPhone or iPad). The speller must spell words from the stalactites at the top of the screen, dropping them onto the enemies below. The shooter must run around on the bottom avoiding the enemies and collecting the coins that appear when the speller spells a word or makes a kill. The shooter also has the ability to shoot stalactites and cause them to drop either to help the speller or just to defend themselves. When the speller spells larger words, they create more coins and earn more ammo or even extra lives for the shooter.
I thought about the art for a while since visuals really aren’t my forte. Eventually, though, I decided to embrace my total inability to draw and go for a very sketchy, notebook feel for the graphics. I essentially planned each image out as a vector shape and traced it with the pencil tool in Flash. I went with Flash because the pencil tool in that particular wing of the Adobe suite smooths itself in a way that I happen to like, and I used to use Flash a lot so I already have a flow for doing animation in it.
The end result is not the prettiest art in the world, but it is consistent, and has the right vibe for the game. One issue I did encounter was with the font used for the stalactites. Right now, the font inside the stalactites is the only part of the game that does not have the same sketchy vibe. This is because the font I used for the rest of the game (Noteworthy) was hard enough to read that it really impacted player’s ability to play the game. This was obviously no good, so I setled on a much more readable font but one that still had an analog feel by choosing a typewriter font.
At this point, the game is getting close enough to being done, that it really needed instructions to be able to test it properly. I tried to boil the game down in as few slides as possible, but decided to combine both roles instead of having players just look at instructions for “their” role. Since both roles are important, both players should have an understanding of what’s going on. I also took this chance to point out that people playing this game should be talking to each other. I designed the game with the two players speaking (and hopefully shouting) to one another as they spot words that could be used. Noting this in the instructions feels a bit prescriptive, but I wanted to dissuade the players from the assumption that this was a network game that they just happened to be playing in the same room.
One larger gameplay change since my last post is that the game now punished three letter words. A common piece of feedback that I received was that the game should do something to discourage small words. Just receiving more points really wasn’t enough since most players are primarily concerned with killing the foes. To counteract this, any foes on screen when a three letter word is spelled receive a permanent speed boost. Any foes spawned after the fact are unaffected to prevent it from being too punishing, and the penalty is negated if all of the on screen foes are killed, but it still gives players pause before hammering out a small word.
Before I present on Friday I also want to set certain letters (such as Q and X) to give more coins for being used as a way to reward players for using tricky letters in much the same way that nearly every spelling game does.
Although the game is fairly locked in for Friday, if I decide to continue with the project, I may remove the shooting mechanic. The shooter still isn’t as involved as I’d like them to be, and still exist primarily as a subordinate to the speller. I may try having their movement more directly affect the available letters, possibly having the jump cause the stalactite above it to fall. Hopefully this will make it so that both players will have to be mindful of the shooter’s position. Even if this is not the solution, I’d like to find some way to further engage the player on the ground.
But for Friday, I am pleased with the game. It has been consistently testing well, and now it has a distinct look. And after a few hours work, a bizarre-o load image that I’m pretty pleased with:
As part of my first foray into the world of iOS development, I remade and improved upon an older Flash game of mine that I liked, but which had some galring faults. Bounce Box is a retro feeling arcade reflex game with trance visuals where the player must move a paddle to keep several balls in the box while the background shifts with every bounce. It’s something of a solo Pong with pretty colors. I was also able to get awesome chip-tuner Bubblyfish to lend some tracks to the game’s soundtrack.
The previous version of the game featured a safety net on each side of the box that would absorb a single miss, but since the game already has a number of lives, this really just overcomplicated the whole thing. The second, and much larger change was that there was an exploit in the previous version where simply tapping the arrow keys rapid fire would prevent the player form ever losing. I made sure to test the iOS version of the game to make sure that no degree of brute force could guarantee a high score.
And high scores do matter in this release as part of my experimentation with the game was to integrate Game Center into the app to save high scores and achievements.
Although I made this game primarily as a test before creating more complex games in the future, I think it’s a really fun game to play on the subway while you’re waiting for your stop. It was interesting for me too, to revisit an older game of mine and iron out some of the problems that had prevented it from working in the past as well as coding it in a different language.
The rules are simple, but probably could have been been better defined. The game jam game is what it is, though, so I don’t want to edit it. I will, however, post the rules here:
-The goal is to destroy balls until there are five or fewer on screen.
-Clicking a ball selects it, clicking another one pulls the first ball to the second.
-Any balls hit along the way are destroyed
-Once a ball has been used to attract another, it cannot be selected
Play it here: http://www.glorioustrainwrecks.com/node/3168
One of the fun parts of being a creative coder is creating applications just for fun. I recently had a birthday party that was themed around legendary spam-bot, @horse_ebooks. I spent about a day fiddling around with openFrameworks to create an app that finds faces and places word balloons containing the bot’s tweets in them.
Stepping back for a moment, let me provide a quick explanation of @horse_ebooks for those that are unaware. Twitter tends to be good at spotting spam bots, banning them outright. To get around this various spammers have created bots that try to post lifelike tweets in addition to their ads. One such bot is aimed at selling ebooks about horses, which is a little funny in its own right. As far as I can discern, it uses a learning algorithm to grab random phrases form the internet. The result is a dadaist mix of random, half-sentences taken from all over the web. Gems such as:
“is the best time.”
“The television is blaring, the baby is screaming”
We had out guests illustrate their favorite posts, and to help them find them, they could look at my app, which functioned as something of an augmented reality program. It presented a mirror image, but added a word balloon to any faces it found. This balloon contained a random tweet, and followed the face around. The system handles many faces, keeping track of the location of each face to make up for the fact that they may be recognized in a different order each frame.
Sentence Tree from my last post was featured on CreativeApplications’ twitter feed. Thanks guys!
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.