Social Sessions
The first mobile game from my game company, Hester Games, on Google Play and the App Store.
A Psycho-therapy themed puzzle game. Be the therapist you always knew you could be and try to make all your patients happy at once by manipulating their feelings and relationships! One of the challenges of this game was coming up with a way to programmatically tell if a randomly generated level is possible to beat. Many level configurations are impossible. I used a node-traversal algorithm to determine if and how a level could be beaten, and how many steps it would take. Check out the game's development blog here. |  |
Below are a small subset of early-stage game prototypes I've done in my spare time.
Wallpaper Game
Click to play (Unity webplayer)
This game is somewhere between a side scroller and a first person shooter. You simultaneously control a "3D player" and a "2D player". The 3D player is whose eyes you see the world through, and control with typical FPS controls (while holding right-click). The 2D player is a flat, stick figure that can be moved around on the walls, floor, and ceiling, interacting with the other flat objects, like crates, buttons, etc.
I had this idea in my head for a while before I made the game. I liked the idea that there could be ways that the 3D player could help the 2D player, maybe by moving obstacles, or standing on buttons. Currently, there isn't much interaction, except that you have to keep walking around to see where your 2D player is going, but I intend to add more mechanics that rely on 2D/3D player cooperation. Challenges and solutions: My brain has major stretch marks from this game. The initialization of the level was an interesting problem in itself. How does the level know where the 2D player should move to when he's going from a corner tile on one wall, to the corner tile on the floor? A simple translation would put him under the floor. My solution was the make an initialization process in which each tile stored information about the tiles around it, remembering which tile one would go to if one pressed "up" or "down" while on it. Then there was the challenge of putting objects on those tiles. There is no collision checking in the game, so how do you tell your player not to move onto a tile if something is already there? So I made each tile also remember which object it currently contains. If the player tries to move onto a tile, it first checks if there is already something on it. An inherent problem with controlling the 2D character was to figure out how to orient the player when he was on a floor or ceiling. Obviously, if he's on a wall, then his head is pointing up, and pressing "up" makes him walk that way. But once he's on the floor, which way should the player be oriented? At first, I just chose an arbitrary orientation for the tiles on the floor and ceiling, and when you stepped from wall to floor, you'd just have to change which button you were pressing to move in a straight line. But when I watched people play this way, they often started walking the wrong way because they wanted to keep pressing "down", even once they'd crossed from wall to floor. But the other option would be to keep the same orientation across corners. But then this would cause a player to become upside-down if he walked from one wall, down, down, down, across the floor, and onto the next wall. The hybrid solution, and current implementation, is that you keep your last orientation from the wall when you move onto a floor or ceiling, but then orient "up" when you get back to any wall. If anyone has any better ideas, I'm open to hearing them. ;) Pushing crates over corners was a tough problem. Like I said before, tiles have their own orientation, and objects match that orientation. So, if you push "up" toward a crate, and the crate goes onto the ceiling, that's fine. But if you push "up" against a crate that is on the other side of the corner (like, going from wall to ceiling), then the crate and tile might have a different orientation. So you press "up", but sending that "up" command to the crate might send it in the wrong direction. So instead of sending the same direction command to both the crate and the player, instead the player does a "find second neighbor" tile, which returns the location he would be in if he walked two steps forward. Then the crate is set to this location. Designing levels has been the final challenge. It's hard enough to wrap one's head around solving the puzzles, it's even harder to figure out good puzzles! Drawing them out on graph paper works alright, but often when I translate them into the game the configuration has some unforeseen strange results. Where to go from here?: Mostly it needs more levels and more interaction between the two "characters". The whole idea was that the 3D player and the 2D player work together to solve the puzzles, but right now it's mostly just the 2D player moving around. I envision tiles or blocks that are movable only by the 3D player, lasers that can be reflected, and doors that can be opened, all only by the 3D player. View code on GitHub |   |
***
Foam Game
Click to play (Unity webplayer)
This is a side-scrolling platformer with all its basic traits, with the twist of being able to "foam". You're basically a shaving cream can that can explode at will and create a big cloud of foam. You can then click anywhere on that foam to re-materialize yourself at that location, sometimes allowing you to squeeze through tight spaces, etc.
The possibilities for level designs have been fun. The "foaming" aspect seems fairly original, but simple, so it makes for some unique puzzle possibilities. Challenges and solutions: The "foaming" mechanic was difficult. I first had the idea of being a deflated balloon, and you could inflate yourself at will. But creating that proved difficult. It had to expand outward in an open space, and expand farther through confined space (like a tube). I went with the approach of creating a grid of possible points, checking to make sure those points weren't being blocked by anything, and then creating tiny circles at those points until a certain amount of circles had been created. This gave more the appearance of foam than of a balloon, I ended up liking that better, so I changed the entire game premise. Another difficult problem is with "foaming" when near a crate. When you foam, the foam looks for obstacles. This is fine for if a crate is sitting still, but if the crate is still in motion (you've pushed it recently or dropped it), then the foam tries to create itself around it, and weird physics-y things happen. View code on GitHub |   |
Building in Reverse
Click to play (Unity webplayer)
This is a simple concept in which you watch a building fall apart. Then, once it's fallen to pieces, you have to try to choose a piece of the rubble that you think came from a high place in the original structure. The structure then reverses itself and shows you a final score of how well you did.
This game was fun to create because it's always fun to watch physics pull apart a tower of blocks. Challenges and solutions: The destruction and subsequent reversal of the blocks turned out to be extremely easy to script. Each step, the transform information of every single block is recorded into an array. When you begin the rewind, you just turn off the blocks' physics objects, and "play" back their recorded transforms (every nth frame to move a little faster). View code on GitHub |   |
Asteroids Game:
Click to play (Unity webplayer)
Simple Asteroids clone.
|  |
Building and Mining Game
A puzzle game in which you have to build the right structures to allow you to mine down into the ground to collect more resources, to in turn build more structures! All the while, also searching for gems, with the ultimate goal of building a tower high enough to place the gem on top of to display for all the world to see!
|  |
