Ludum Dare 25 Postmortem

This past weekend I took part in the 25th Ludum Dare 48 hour game making competition! The theme this time was "You are the villain", so I googled "villain" and then just made a puzzle game about a railway tycoon using trains to rid the world of damsels. The game "Cruel Cruel Dastard" can be found here and it's competition page is over here. 

In traditional game jam fashion, here's a postmortem listing three things that went well and three things that didn't go so well while making the game. 

Things that went well

Recording my own sounds: 

Usually when I'm working on jam games I tend to make heavy use of free sound libraries (such as freesound.org) and content generators (such as bfxr). Since the main Ludum Dare Compo disallows use of sound libraries, I decided to give recording my own sounds a try. It turns out recording sounds was actually a lot easier than I imagined (and also a ton of fun). 

Under normal circumstances, I might have spent ages searching through a free sound library for a train sound. While recording my own sounds, all I had to do was record myself blowing into paper and then tweak the result in Audacity to get what I wanted. Everyone who plays the game seems to love the evil laugh I included as a victory noise. That thing is basically just my own voice sped-up and it only took me about a minute to make, so I'll definitely be recording my own sounds more in the future. 

Re-doing the controls halfway through:  

When I started making the game, the idea was that it had a simple "click to place things on screen" control scheme. To build a large amount of train tracks, the player would have to place each piece of the track individually and switch to a different shape every time the track turned. To illustrate, here's a screenshot from the game on day one:

Notice how each shape has its own menu item

If this sounds like a terrible and tedious control scheme to you, well you're right! About halfway through the competition, I decided to scrap this scheme and make a much more intelligent track building system that allows the player to lay tracks or re-route existing tracks just by dragging their mouse across the screen. Even though it took a good chunk of time to implement, I think it was a pretty good idea, particularly since it's now much easier to build tracks in the game than in my level editor. 

Still have to choose pieces by hand

Practicing Art Beforehand: 

As I mentioned in this post, I was practicing making art really fast this week. What I didn't mention was that I was using the Make Pixel Art web app. I like this program because it's really simple and it has super useful "lighten" and "darken" tools that I can't seem to find anywhere else (if you know how to get the same thing in photoshop or gimp, please tell me).

Of course, it's simplicity has some drawbacks, such as not being able to easily constrain the size of your drawings. Fortunately, with a week of practice, I was able to get past these problems via silly solutions such as creating "frame" templates.  

Things that didn't go so well

No Time for Levels: 

Hey look at that! I kind of mismanaged my time for this jam. My original intention for the last day was to do some basic polish, make a few designed levels to introduce the mechanics (complete with tutorial text), and then build a procedural generation system for making the game more of an arcade style puzzle game (like tetris) rather than a deterministic puzzle game (like a rubiks cube). 

If that sounds kind of over-scoped to you, you're correct! I was still adding polish on Sunday when I looked at the clock and realized I only had one hour left and no levels to speak of yet. It didn't help that my level editor wasn't fully set up yet either. 

In the end, I had to scramble all ten of the levels together in less than 20 minutes, which basically meant I got the tutorial levels in and not much else. Whoops!

Poor Prioritization: 

Part of the reason I ran out of time on Sunday was definitely due to poor prioritization. There are a bunch of mechanics in the game that are either not explored fully or not properly implemented at all (such as the rope mechanic). I think if I had done a better job pruning these ideas down to only about two or three basic mechanics (say, laying railroad tracks and dynamite), I wouldn't have run out of time towards the end. 

Also, certain pieces of polish that would be essential for a larger release--The "undo" button in particular--might not have been really necessary for a 48 hour game, particularly one as short as this one, so I might have benefitted from focusing more on the core gameplay. 

Playing it "Safe":

One of my goals for this weekend was to create something fairly polished that I could easily expand upon for a bigger release. In practice, this meant that I discarded a bunch of ideas during the planning phase that were a lot more experimental or interesting because I wasn't sure I could expand them into something worthwhile in only 48 hours. 

Of course, this means I ended up designing a game that was distressingly similar to games I've made in the past. While this isn't necessarily a bad thing (plenty of people riff on the similar concepts several times before moving on), I think I could have benefited from going with one of my wilder ideas. 

Another game with 3x3 explosions

I think I still might be able to differentiate this game from some of my previous work by implementing the "arcade mode" which I didn't get around to, so I'll keep updating as I do post-competition work on it. 

That's about it. Thanks for reading!

Preventing Score Forgery on Online Leader Boards

Hey guys,

This semester I took a class on computer security with a completely open-ended final project. Since I somehow trick all of my final projects into being about games, the problem my group decided to look at and try to solve was that of fake scores on leader board services such as the iOS Game Center, Kongregate, and others.

As outlined in this article, cheating can be pretty easy and prevalent on these leader boards, particularly on the iOS Game Center. Speaking as someone who was playing Super Hexagon way too much earlier this semester primarily because of competition at the top of the leader boards, I know firsthand how polluted leader boards can negatively affect a game. For example, here's the leader board from when I managed to reach number two in the world:

My Pride

And here it is now:

As you can imagine, seeing a score five orders of magnitude higher than what seems humanely possibly can be a real deterrent for people trying to play legitimately.

With that in mind, what did we do to try to fix this problem? If you want to read a big technical document, check out the paper I wrote on the project. Otherwise, here's the condensed version.

Most exploits work by just communicating with the leader board server pretending to be the game and saying "I got [X] Score!" In most systems that we researched, the server will simply say "Okay!" and that's it. Way too easy.

An obvious attempt to prevent this is to have the game somehow prove that it's the one talking to the server (as opposed to some shady cheater). This is usually done by having the game cryptographically sign score postings with a secret it shares with the server, an approach taken by Newgrounds, Adultswim.com, and others. The problem with this approach is that the secret shared by the game and the server has to be stored on the player's machine. If the player is relatively resourceful, it's not too hard to peek into memory or use a decompiler to find the secret, leak it to the internet, and then we're back to square one.

For our project, we built a system that verifies claimed scores based on a simple assumption. We assumed that a player can be said to have "earned" a score if they are able to produce a series of inputs that will reproduce the score when run on a trusted version of the game's code. This assumption isn't always valid, particularly if players are cheating by playing the game with bots, but it seems to be reasonable enough to prevent straight-up forgeries.

Using this assumption, we built a library for the Flixel game engine that makes use of Flixel's replay system (originally a debugging feature) to record input logs and send them to the score server where they can be verified by a trusted version of the game code.

The server hard at work

The system seems to work pretty well. Depending on the game, the logs sent to the server grow at rates somewhere between 30KB-1MB per hour and can be subject to some heavy optimization. Also, we were able to modify my game Roller Derby Riot Queens (sadly very vulnerable to score forgery) to use the system with fewer than 10 additional lines of code. Not too bad!

Other game engines can easily be expanded to provide this protection. If you're interested in learning more, I'd recommend checking out the full paper.

Thanks for reading!

Making Mediocre Things Fast!

One of my philosophies for a while has been that you have to learn to make shitty things fast before you can make good things fast. Obviously speed isn't always a necessary component for making things, so this isn't the best philosophy in all cases. In general I tend to enjoy working quickly, so it's a philosophy that seems to work well for me.

With that in mind, I'm probably going to be participating in the Ludum Dare competition this coming weekend. Since this is a solo competition, I have to bust out all the art myself. If you know me well, you know that art hasn't exactly been my strong point ever. Also, in a 48-hour competition, "fast" is pretty much the only speed in town, so something I'm going to try to do this week is make so many crappy drawings in a short time frame that I can hopefully upgrade from making shitty things fast to at least making mediocre things fast.

Anyways, here are some experiments from yesterday. First up, a terrified cake.

She's scared of her candle being blown out perhaps

Here's a party pirate. Is he at the same party as the cake?

Finally, an undead rooster. I'm not sure how scary this would be in real life. 

I've been informed that the rotting wounds look like nipple tassels. Whoops

I'll keep posting these this week. You can decide if the quality improves. 

Thanks for reading!

Making Failure Fun and Why it Matters

Here's a lesson I had to learn the hard way about making failure in games entertaining.

It came to me while I was watching players play both Conway's Inferno and Roller Derby Riot Queens, a game that I made in a week over the summer which was kind of a failure itself.

The main idea is that players will be more tolerant of failure when it's entertaining. Kind of obvious when stated like that, but it wasn't something I thought about much before witnessing it. To illustrate, here is a common pattern I observed whenever I watched a new player play Conway's Inferno. Below is the first level from the game.

When confronted with this level and minimal instructions, players would almost always do one of two things. Some players would place a fire on the cells in the center like so:

which of course is the "solution"and results in the player winning the first level and gaining an understanding of the game's mechanics. 

The other major thing the players would do is set one of the trees on fire like this: 

Which would lead to a big forest fire: 

And ultimately the game's minimal failure screen: 

But even despite failing, the players who chose the second option would often just laugh and reset the game. My takeaway is that even though they failed, at least they got to burn a forest down, and burning stuff down is at least marginally entertaining. 

In contrast, in RDRQ, when the player fails: 

The player disappears and a failure screen pops up. Now that's not particularly entertaining, but at least it's better than RDRQ's other failure screen... 

Which is the "the level has become unsolvable, but the game doesn't tell you that or limit your moves or anything, so shucks!" screen. Dang, this is basically an embarrassing example of the worst kind of failure a game can present you with. Not only is it not entertaining, it's not obvious at all!

After releasing this thing, I watched players play the same level for ages without realizing there was no hope in the universe of solving it and that they should just hit reset. Needless to say, they weren't too enthused to keep playing after encountering this style of failure.

Now you might ask why I let a game with such an obvious glaring flaw into the light of day. Well the answer is that I didn't really do much play-testing for RDRQ. As I mentioned before, it was made in a week, but what I didn't mention before is that it was made in a work week. So yep, after working on this thing everyday in my spare time after work, I was totally sick of it and wanted to shove it out the door immediately. Also unfortunately, of the play-testers I did have, most had watched me develop the game, so they kinda intuitively knew when they had fubar'd the level. Oh well, at least it was an entertaining failure for me (kinda).

Anyways, one takeaway from these two experiences is that it's usually a good idea to make failure both entertaining and obvious when designing a game, particularly if your game involves a lot of failure. This is something games like Spelunky, Super Meat Boy, and even Angry Birds do a great job with. 

My other takeaway is that I basically always always always always need to test my games. Yup.

Thanks for reading!

The Floor is Lava!

Hello,

So something I've been working on this week is adding "Trap Tiles" to Jungle.com. These are floor tiles that can live underneath other objects and hurt the player when she walks over them.

Since I'm working with placeholder art for the time being, I made my trap tiles by recoloring the normal floor tile with a red tint and pretending it's lava. The floor is lava!

One goal of the lava tiles is to give the player another reason to use the "scooter" item. The scooter was originally envisioned to allow the player to escape tigers by moving really quickly. Unfortunately, the way the game evolved, the levels ended up being too densely packed with walls for the scooter to ever be particularly useful.

That's why, if the player manages to walk over the lava tiles at high speed (either by using the scooter or via some other method), she won't take damage from the lava.

I'll probably make some level generation templates with big lava paths for the player zip over on scooters.

Of course, scooters aren't the only way to traverse lava. Since one of the primary actions in the game is lifting and moving items around, I thought it would be fun if the player could build "Bridges" across lava tiles. The placeholder item I chose to represent these bridges are these poorly drawn "Rugs".

Now I know rugs would burn up in the lava just the same as the player, but I've been thinking of it as not real lava anyways. More "the floor is lava" kind of lava. Anyways, I'll have to figure out what lava and rugs actually are eventually. Meanwhile, rugs totally make sweet lava bridges.

Except the player is almost invisible whoops

Now here's another fun thing about lava tiles. When a tiger is in patrol mode, it will avoid lava like any other reasonable mammal.

However, when a tiger is chasing the player...

As you can see, all bets are off. I like adding ways for the player to trick enemies into hurting themselves or looking dumb, so this was a fun addition.

Anyways, that's all I've got for lava tiles for now. I'll be making level generation templates with them soon so I can play with them in the game properly and see how they feel.

Thanks for reading!

Fun and Challenges with Procedurally Generated Music

Here's a fun story.

When we were developing the initial prototype for Conway's Inferno during the 2011 Global Game Jam, we actually implemented a system for procedurally generating music for each level. It's still there, so you can check it out if you're interested.

The procedural generation was pretty darn simple and looked something like this:

1. Scan each column of the game grid at a fixed rate. 
2. For each column scanned, count the number of certain objects. For instance, the number of people is recorded in num_people, the number of trees in num_trees, etc. 
3. Once a count is recorded for each object, choose a sound to play from a list of sounds for each object. (i.e. people_sound <- people_sound_list[num_people Mod len])
4. For each type of object found in the column (i.e. count > 0), play the chosen sound. 

The goal was that the player's interactions with the level would actively change the music played by the level. Since we had a different set of sounds for, say, living cells and graves, the tone of the music would change significantly as the player killed all the cells. Meanwhile, environmental objects such as trees and rocks would provide percussion.

So you might notice if you play the new version of the game on iOS that it doesn't have any of the original procedurally generated music. What happened? Well, there were a few issues with the procedural system. First up, the general response from the public:

Not a compliment

Now if you've never heard of Crazy Bus, view the video below at your own peril. Personally, I kinda suspect Crazy Bus is just piping its own game code into the audio output stream or something. So in a way it's also procedurally generated "music", but obviously not the kind you'd ever want to be compared to.

Now, I think Conway's music is definitely better than Crazy Bus's, but we also could have improved it a lot if it weren't for the 48 hour constraint of the Global Game Jam. 

Unfortunately, another issue with the procedurally generated music came from the fact that levels that play well don't always intersect with levels that sound good. For instance, here's a shot of level 2 from the original prototype. 

Broken level 2

It may not be obvious, but this level is actually broken design-wise. The original goal of the level was to teach the player that trees could be set on fire to cause explosions that would reach cells one square away.

In the original version, there was just a simple line of cells to the tree in the center (instead of a T-shape) so the only way to win the level was by setting the center tree on fire. After we modified the level to sound better, the player could win by setting any of the inner cells on fire, which was no different than level one. Whoops! This is a good example of how easy it is to break the design of fragile puzzles if you're also trying to design for good audio.

For a fixed version that actually produced the same music as the broken version, check out the revised level 2 (now level 3) from the iOS version below.

Fixed level 2 (now level 3)

Ultimately, the problems of getting our system to sound good while at the same time playing nice with designing fragile puzzles were too much for our limited development time, so we ultimately scrapped the system in favor of a simple looping track.

While our exact implementation of procedurally generated music wasn't quite up to snuff, it was a pretty fun problem to play around with. For an example of a game that I think does procedurally generated and/or interactive music pretty darn well, check out Everyday Shooter on PSN.

Rich Vreeland's January also does some cool stuff with interactive music generation.

Thanks for reading!

Play TNNS in the bathroom!

I tend to play a lot of games in the bathroom, usually on my phone. In fact, since my free time started hemorrhaging a few years ago, game time and bathroom time have become almost synonymous. I have a friend who thinks it's super gross that I use my phone in the bathroom, but I ignore him because he uses his laptop in the bathroom and that's probably more gross. 

Anyways, my most recent bathroom mainstay (at least since I had to make a mid-year resolution to stop playing Super Hexagon) has been the new pong-like TNNS by Action Button Entertainment and Rbbx Inc. 

So whats the game about? Well remember that one movie where Angelina Jolie teaches some dork how to "bend" bullets by twisting his gun while he shoots? TNNS is like that but actually good.

The heart of the game lies in the very precise control you have over the ball(s) after it hits your paddle. Wiggle your paddle to the left or right, and the ball curves in that direction. Once you've mastered the basics, you can start doing more complex curves to get the ball shooting around obstacles or bouncing directly into prizes. 

The tactile feedback the game provides is some of the best out there. The window of trajectory control after the ball hits the paddle is just large enough to precisely hit targets. The audio is filled with satisfying crunches and pops while the visuals shake and spark with each impact. All these factors combine to give a sense of the game as a precise physical mechanism, rather than just a digital simulation. 

Other than that, here are some things that make TNNS a great bathroom game: 

• Games tend to last less than a minute.
• The levels are procedurally generated to a certain extent, so every game is guaranteed to be different. 
• No concentration required! Let your fingers do the work while you go about your business. 

All in all, TNNS is pretty neat and basically better than just leaving old Dilbert collections next to the toilet.