Rookfall takes place on an empty chess board in rook purgatory. Place a rook on any available tile, and swipe in a direction to move it as far as possible. Traversing a tile will have it fall into the abyss. Drop all tiles to complete the level. Check it out at:

rookfall.com


Grab Rookfall on Android, iOS, or Amazon for free, or pay a buck for the full version. This was my first venture into the professional realm, and quite the adventure it was. Below is a little ditty on how Rookfall came to be. 


How the rook got it's own game.
 

Near the end of my senior year at University I knew that to stand out among my peers, I needed an edge. I needed to publish a game, but life gave me a few contraints. The game needed to be made in a few months, with very little money and no artist. Over 6 months later my classmate Ronald M. Burgess and I released Rookfall and Rookfall Free for Android, iOS, and Amazon.

 
Machinarium's greenhouse puzzles

Machinarium's greenhouse puzzles

 

Machinarium doesn't explain it's mini games at all. There's the hint book that shows the answers but the folks at Amanita Design like to let the player figure things out, and that's the way it should be. The greenhouse puzzles were the most challenging to initially understand, and equally so to solve. The puzzle stretches out some vestigial part of the brain that quivers under the pressure of these puzzles. I showed Ron the mini game and decided it would be a good idea to explore. Prototyping began, but it needed more mechanics to make it our own.

 
SLIDE, the prototype

SLIDE, the prototype

 

Among them were bumpers, teleport pads, wormholes, bridges, bombs, double squares, traveling over edges, NPCs, and countless others. Ron and I were considering the puzzles be placed on cubes. The player would rotate the cube for one very large and hard to fathom puzzle. Yet after much deliberation, the humble wall stood as the additional mechanic that dynamically added to the gameplay. There are spaces you can and can't go, and walls between them.

A little code.

public void AutoGenerate(){
    GetComponent<LevelCreation> ().createLevel ();
    while (count < cutoff) {
        GetComponent<GameScript> ().resetField ();
        GetComponent<LevelGenerator> ().RandomizeLevel ();
        if (!GetComponent<LevelCreation> ().checkDup (GetComponent<LevelCreation> ().makeLevel ())) {
            GetComponent<Solvability> ().Solve ();
            if (GetComponent<Solvability> ().solutions > 0) {
                GetComponent<LevelCreation> ().saveLevel ();
                count++;
            }
        }
    }
}

Now to make hundreds of puzzles! Instead of creating each level by hand, we needed a level generator. I had taken an algorithms class the semester before, so I was excited to test my chops. First task was to create a level randomizer. Take a blank puzzle board, randomly select a random number of spaces and walls, turn them red. To prevent unsolvable levels, check if any open spaces are surrounded by closed spaces/walls on all sides. If so, clear it out. Check if the level already exists. If it doesn't, run it through the solving algorithm.

void Traverse(GameObject source){
    source.GetComponent<SquareScript> ().currentState = SquareScript.State.Filled;
    moves.Add (source);
    for (int i = 0; i < 4; i++) {
        if (checkPath (source, GetComponent<GameScript> ().directions[i])) {
            switch (i) {
            case 0:
                moveRight (source);
                break;
            case 1:
                moveLeft (source);
                break;
            case 2:
                moveUp (source);
                break;
            case 3:
                moveDown (source);
                break;
            }
        }
    }
    if (checkWin ()) {
        solutions++;
        startPoint = moves [0];
    }
    if (moves.Count > 1) {
        REVERSETHRUSTERS (moves [moves.Count - 2], moves [moves.Count - 1]);
    } else {
        source.GetComponent<SquareScript> ().currentState = SquareScript.State.Clear;
        moves.Remove (source);
    }
}

Perform a recursive postorder traversal on every root, i.e. open space, in the puzzle. If the traversal completes the puzzle, increment a "number of solutions" variable, and return the number when finished. If the number of solutions is greater than zero, write it to an XML and you've got yourself a puzzle. We would try to use that number to determine how difficult a puzzle is, but it turns out the number of solutions isn't always indicative of difficulty, and several factors make the level generator less time saving than we thought.

 
The puzzle editor, in all it's glory

The puzzle editor, in all it's glory

 

With the ability to crank out levels, a level editor was the next logical step. This was by and large my favorite part of this project. With it, we could generate, review, save, delete, play, randomize, modify, solve, and create custom levels. However, the level generator did not consistently create quality, interesting levels that would make it into the game. Lots of the duds had solutions far too obvious, too numerous, too similar to other puzzles, or with uninteresting layouts. I would create and solve around 1500 levels before the final 300 were chosen. Around 30 of those were entirely custom made.

What could have been.

 
The lightning rod aesthetic

The lightning rod aesthetic

 

On to aesthetics. A rook in purgatory did not come until about 3 months after development started as I was lying in bed with my face in the pillow. We went through many (too many) different aesthetics over the course of the project, and began asset creation for several. The most notable was what we called the lightning rod aesthetic. The idea was a top down shot of a mad scientist's rooftop filled with lightning rods. The player would begin the puzzle by striking a rod with lightning, which would crackle and glow with ambient light. Swipe in a direction and the lightning would channel to other nodes.

Zombie torso 

Zombie torso 

Lightning rod side view

Lightning rod side view

When all available lightning rods were lit and the puzzle completed, the rooftop would open up to reveal a monster strapped to a table. The monster would be random, mixed and matched. The head of a werewolf and body of a zombie etc. A fellow student Txema Palacio created this lovely art, but had to leave the project due to time constraints. We decided the monster mash was a bit cheesy, and the lightning rods were not properly discernible from a top down angle. Other aesthetics included a Japanese rock garden, a mine field, and a dog scooting its butt on the carpet.

Put it together.

 
The first complete version

The first complete version

 

Rook's Gambit was the original title of the game, then Titanfall 2 came out and lodged itself in my subconscious. Back then the tiles were thicker and the UI was 3D. There were several optimization problems, especially with the level select scene. Loading in the specific XML when the player pressed the puzzle dimension (5x5, 6x6, 7x7) would cause a 1.4 second delay, worse in older phones. To avoid this, we decided to create a preload scene prior to the title scene where all 3 XMLs and the music would load unnoticed.

 
The final product

The final product

 

Here we have the final product. 2D black and white UI. Tutorial. Credits. Mute music button. Seamless scene transitions. A new progression system. Every 5 completed levels, the appearance of the rook or one of it's tiles changes. We began to sell the paid version in November 2016 at $3, then provided an update and price drop to $1 along with the free version in December 2016.


Post Mortem
 

This project cost Ron and I a total of $225, and over 6 months of work. I'll tell you we haven't made that money back..... yet. Without money to advertise, an appealing aesthetic, or immediately recognizable gameplay we didn't stand much of a chance in the sea of apps. We relied on review mining, word of mouth, and getting picked up by aggregation sites. But that is far from saying this project was a defeat, failure, or waste of time. We knew going in we had little chance of breaking even, that wasn't the reason why I did it. I wanted to learn. My mantra:

"Create an original game. Publish it."

Working with one other designer meant we butt heads often. Learning give and take, and how to compromise was invaluable. Making student projects was one thing, but the act of finalizing all aspects of a game, every minute decision, and driving it to completion was a much different task. Having the core gameplay functional is less than 10% of the total work required, and post release is still a full-time endeavor. Motivation on a large project is critical, and different for every individual. Aligning those motivations may be the key to creating a great game.