Identity Quest?


Language: ActionScript 3.0
Summary: Self Identification and Exploration Puzzle


Identity Quest was a project created in collaboration with four other artists and designers for Global Game Jam 2014. It was created within the 2-day schedule being 100% feature complete and bug free.



Global Game Jam

Compactor Panic

Featured image for Compactor Panic

Language: ActionScript 3.0
Summary: Arcade puzzle platformer


Screenshot for Compactor Panic

Compactor Panic is an ActionScript 3.0 game created for web sponsorship. Blocks of trash drop from the top of the screen and its your job as the player to sort them before the grinder turns on. Earn multipliers to increase your score at a very quick rate. Protect your head. Collect hard hats to take more damage. Collect cash and become the richest player!



Panda Rush


Language: ActionScript 3.0
Summary: Procedurally generated endless runner


Panda Rush is an ActionScript 3.0 game created for web sponsorship. It was created out of a desire to experiment with procedural platformer level creation. I get a bit into the implementation details and reference Spelunky many, many times.


Screenshot of Panda Rush

The levels in Panda Rush are based off of templates created which were created using the Ogmo level editor. After a few dozen of those are created they are broken down into a CSV file that simply represents solid and empty tiles. These files later get used by a LevelManager class to populate the individual cells that make up the endless levels.

As the game is being played a LevelManager class keeps track of the previous, current, and next cells. The LevelManager cycles the cells every time the player crosses from one into the next. Cycling involves removing the cell at the bottom of the stack (previous cell), adding it back to the top (next cell) as an empty cell, choosing a random template, running the proceduralizer which fusses things up based on the current difficulty, running a tilemap cleaner, and finally adding all the enemies into the game. I’ll explain the interesting parts in more detail.


Making a generator like this is extremely rewarding. I used a weighting system not unlike the one in Gomoku. It would scan each tile in a cell and run it through a gauntlet of what are essentially dice rolls based on the tile location. For example, if a tile is surrounded on three sides with the fourth side open there is a big chance that a baby panda (the game’s point pickup) will spawn and almost no chance that a spike trap will spawn. Tiles many spaces away are checks in order to prevent a spike trap from blocking an exit that the player has to jump to, or to make sure that the player is able to jump across a pit.

A great example of template-based procedural generation is Spelunky. There are several write-ups that I’ve used through development of Panda Rush and I’ve provided links at the bottom of the page.

Animation of a Panda Rush Enemy

Once the tiles gets switched up I needed a way to connect all the times together in a way that made sense visually. My tilemap had unique graphics for corners, platforms, inner and outer crevices, etc. Some research revealed an excellent method to handle this problem: bitmasking. Essentially bitmasking involves taking a number and using all the adjacent tiles to flip the bits from 0 to 1 if present.  Angry Fish Studios did an excellent write-up on the subject and I highly recommend implementing something similar if you have the need.


Gomoku AI

Featured Image for Gomoku Board

Language: Java
Summary: Utility-based Artificial Intelligence


Gomoku is a project created using Java and Eclipse. I had been taking an edX course on artificial intelligence at the time so I went ahead and gave it a go. The class was taught by Stuart Russel and Peter Norvig, two very smart people who teach using cartoon robots and video games. Their running example for the entire semester was a game of Pac-Man.


Image of Pacman

Russel and Norvig’s approach to Pac-Man was using a tree search and utility value in order for the AI to pick the best move for its current state. Utility is the score of a game state with all things considered: dots collected, time spent, enemy locations, etc. While the tree search and game state are simple enough to implement, the real difficulty in designing the Pac-Man AI is creating the utility function.

For example, if an action results in a dot being collected, give that state gets +10 utility. If an action results in being boxed in, that state gets  -999 utility. With this arrangement almost no amount of dots will tempt Pac-Man down that path. But what if the last dot is in a dangerous area? The win state could be given +1000 utility to give preference to that even over getting into a deadly spot. Making decisions like these could have negative side-effects and it’s recommended to test every change over a couple dozen runs. Things get even trickier when considering the utility of a situation where Pac-Man looks like he’s going to be boxed in, but later eats a big dot and gets extra points from chewing on the blue ghosts. How aggressively should Pac-Man chase after the fruits? Developers are always looking for more effective utility functions and there are a ton of resources for those interested in making their own.


Gomoku’s AI works is a similar way to Pac-Man. Gomoku is a game in which two players take turns placing their color checker onto a gridded board, two checkers per turn. The first player to get six in a row wins. Using the utility measurement from Russel and Norvig’s approach, the black player attemps to get positive utility while the white player goes for negative. Utility increases based on the length of each tile, which naturally makes the AI try to block enemy chains, add to their own chains, and do both in a single clever move if possible. The AI prefers to create two short chains instead of one long, easily-blockable chain, and will also take a game winning move immediately.

Image of Computer Memory

It’s very simple to get a basic implementation of the AI running in Gomoku as it only takes four things: a game state: a set of available actions, a result function, and a goal test function. The game state is can be anything as long as it can be scored with a utility, and in my case it was a simple 15×15 array with 0 representing no checker, 1 representing black occupation, 2 representing white occupation. The only available action is to place two checkers at any open location. This made alpha-beta pruning necessary since the possibility space is enormous and trying to predict a few moves into the future can be very memory intensive. The result function takes in the current state and an action, then outputs the resulting state with an updated utility. The goal test is just a boolean about whether the state’s game has ended or not.
After these four basic are in place all that’s left to do is loop through all available spaces and test their utility. The method I used was the minimax algorithm with alpha-beta pruning. There are links to both of these below.