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 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. 

Fun with Procedural Lock and Key Puzzles

Hi!

Something I've been experimenting with recently for Jungle.com is throwing in some procedurally generated lock and key puzzles. Since I've played around with these before, mostly in the context of my research, and Jungle.com already has both locks and keys for other purposes, I figured they might add a nice bit of spice to the generated levels.

The basic idea with generating locked doors is pretty simple and fits nicely on top of the existing level generator. For context, this is what the generator did prior to adding locks:

1. Generate the complete arrangement of objects for the level (I might post about this process separately) 
2. Randomly choose rooms for the start and end of the level (sufficiently far apart to keep things interesting).
3. Pick a semi-arbitrary path between the start and end of the level. This will be the "guaranteed path" for completing the level, although other paths are highly likely to exist. 
4. Forcibly carve openings between rooms on the "guaranteed path". 

Now to add locked door puzzles, I just add a few extra steps to this process:

1. Choose how many locks to add to the level based on a "lock density" parameter that I can control for each level. 
2. For each lock to generate, choose a random node on the guaranteed path (that hasn't yet been chosen) to generate the lock. Place a bunch of immovable walls and locked doors in between the chosen node and the next node on the path to add the locks. 
3. For each lock generated, spawn a new key somewhere on the guaranteed path before the locked node. 
4. I don't do this yet, but it might also be fun to generate locked doors between rooms that don't lie on the guaranteed path, just to see what happens. 

And we're done! With locked doors active, you might end up with rooms that look kind of like this:

The walls and locked doors are placeholder art right now

Now, since almost everything can be destroyed in Jungle.com, keys included, you might wonder what I do to prevent the player from blowing everything up and getting kinda stuck. The answer is, well, "not much."

Even the code says "too bad"

The design philosophy for Jungle.com so far has been "Offer enough solutions so the player would have to work pretty hard to get completely stuck". It's seemed to work pretty well so far, so hopefully it works okay here as well. I'll be relying on ample play-testing to make sure there aren't any serious snafus.

Anyways, after implementing all this junk I tried playing a few levels set to 100% lock density (so every room on the guaranteed path is separated by a locked door). It seemed pretty interesting. I definitely had to plan my motion through the levels a little bit more, but I could also see it getting kind of annoying if I make locks too frequent. Also, what's this...

Darn you acid spider enemy! How dare you destroy my carefully generated lock and key puzzles! Haha, the fun thing is that getting past that spider unharmed might actually be more of a hassle than just finding a key and unlocking one of the other doors.

Of course I'm leaving that in.

Okay Bye!

Hello

Hi! My name is Alec Thomson, I'm trying to become a game designer and this is my new blog.

I've made a bunch of games in the past, sometimes as a student and sometimes as a researcher at the former Singapore-MIT GAMBIT Game Lab (now known as the MIT Game Lab), which can all be found at my website.

Most recently, I've released a free puzzle game for iOS called Conway's Inferno. Conway's Inferno is a game about goofing around with a cellular automata to cause the extinction of a species. It's totally available here, so feel free to download it and (hopefully) have some fun.

One of the later levels of Conway's Inferno

Meanwhile, the game I'm currently working on is a procedurally generated stealthy puzzle game called Jungle.com. Jungle.com is a game about robbing a major online retailer by ordering tools from that same retailer to help you out. It's still in development, so check out this gameplay video for an idea of how it plays.

At my day job, I'm a Masters student at MIT in the Computer Science department. My research is on developing designer targeted tools for creating procedurally generated puzzles. Right now, I'm creating tools the look kind of like this.

The Puzzledice puzzle editor

Anyways, this is actually the third time I've tried to start up a regular blog (don't look for the others), so hopefully I can keep it going this time. I'm going to try to keep posts short but frequent and mostly about my projects or other things I think are cool.

Okay bye!