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!