Breath of the Wild Sequel Teaser Speculation

Nintendo just teased the next Zelda game. So now we get to get to dissect a minute-long video and speculate the heck out of it. I’ve been spending way to much time re-watching it and listening to others’ observations, so I may as well present my findings during this obsession.  Not much has been confirmed. We don’t even have a title yet. However, a lot was squeezed into that teaser. It seems like they intended it to be very cryptic. It takes place in a crypt, there’s gibberish backwards chanting in a game that is safe to assume has actual voice lines, and it makes 14 cuts in about 7 seconds. Below, I’ve presented a few of my theories sorted from most to least likely.

Almost certainly true

The game takes place a few months or years after Breath of the Wild. It is obviously the same Link and Zelda. They do not appear to have aged significantly, but there are a few indicators that at least some time has passed. The biggest is probably Zelda’s haircut. Sure, she could have trimmed her hair immediately after the events of the last game; however, off-screen changes in hairstyle usually imply a time leap. A good, recent example is Avengers Endgame. My guess is that at least a year has passed, but probably no more than five. Either way, this would make Link and Zelda slightly older than they usually appear in games.

The map will be mostly the same. The part near the end of the clip where Hyrule Castle rises up confirms that Hyrule doesn’t look all that different. I opened up Breath of the Wild again just to make sure. That view is the same one from the opening scene in Breath of the Wild just after you leave the Shrine of Resurrection. The castle rising up seems like a callback to the events at the beginning of Breath of the Wild where you activate all the towers, which then rise out of the ground. It might also related to what Ganon does to the castle in Ocarina of Time, or the ascension of the Hylians in Skyward Sword, or the City in the Sky in Twilight Princess. The Zelda team must really like the idea of floating buildings. Whatever the reason, this would be a good excuse for the map to change dramatically enough to be interesting.

Hyrule will have new monsters and enemies that weren’t in Breath of the Wild. The teaser showed rats. Rats are a recurring enemy in the series, but they never appeared in Breath of the Wild. If nothing else, this new game will have rats. Based on the theme, there’s a good chance we’ll see some ReDeads as well. Maybe that black stuff that glows red is also something you can fight. It might just be more Malice, but it looks a bit different. The red actually forms a distinct, glowing outline, while the red in malice looks more like veins.

Likely true

Zelda will play a bigger role in the adventure. Zelda, with her hood and short hair, appears ready to explore the secrets of Hyrule alongside Link. Maybe this teaser is actually the prologue right before Zelda gets trapped by that mummy in the castle again, but it seems weird to advertise a clip with Zelda herself so early on if that was the case. Some possibilities:

  • Link gets trapped this time. You play as Zelda, who must rescue Link. It did seem from the teaser that Link’s hand got possessed by a monster, so maybe he’s not going to be helpful this time.
  • You get the option of playing as either Link or Zelda, or even swapping out at various points in the game. Their screen time was about even.
  • You stay in the same party and work co-cooperatively. The teaser briefly showed Link and Zelda grabbing each other’s hands. This could actually be a significant part of the game, working together as partners in this adventure. Maybe this would just mean switching who leads, or it could even be an opportunity for multiplayer.

Ganon/Ganondorf/Demise is involved once again. The most popular theory is that that zombie is Ganondorf, but there is support to suggest it might be one of the other two. The head jewelry makes him look like Twilight Princess Ganondorf, but Calamity Ganon also had a glowing forehead. The jewelry looks Gerudo, but it isn’t actually the same as what we see in Twilight Princess. The pointed teeth and the shadow look more like Demise, but Demise is more immaterial (his hair is made of fire). Finding a Ganondorf corpse would make more sense, but ultimately Ganon, Ganondorf, and Demise are really just three manifestations of the same dark entity, so it could just be referencing all three. Or all the speculation is totally off, and this is just an especially scary ReDead. It is also possible that, Ganondorf corpse or not, this is just a puppet at this point for whatever entity created (or broke?) this spell.

Maybe true

There will be time travel. The only thing I have to go off this time is the fact that the audio is reversed. This could just be for creepy effect or to hide a message, but it could also suggest that reversing time is part of the gameplay, much like Majora’s Mask, where you manipulated time by playing a song backward.

This game will explore a secret history in the games, connecting mysterious organizations like the Sheikah, the Interlopers, and the ancient tribe in Majora’s Mask. This one is a bit of a stretch, because references to other games are usually more Easter eggs than important plot points. While this specific theory might not be exactly confirmed by the teaser, there’s evidence to suggest the game might touch more on these subjects. The connections with Twilight Princess are particularly strong.

  • The weird singing voice sounds a lot like the Twilight Princess warp sound if you speed it up.
  • The Sheikah drawing on the wall shows someone holding a trident. Beast Ganon often wields a trident, but so does Midna when uses the Fused Shadows, which we know is Interloper magic.
  • The style of the Sheikah drawings and language somewhat resembles the patterns on the Fused Shadows with its blocky spirals, symmetry, and obsession with eyes.

  • Who else had a giant, glowing magic hand? Midna.
  • The singing voice sounds like a creepier version of Fi, so that could be yet another connection to another game.
  • The magic around the corpse and hand forms strange glowing symbols, similar to Sheikah technology/magic. However, the symbols are more curved and flow-y than the box-y Sheikah alphabet or the straight-lined constellation patterns in shrines. It is also green instead of blue. Ganon’s magic tends to be red or violet as well as chaotic like fire. This green magic is not only in the middle of the spectrum between the Sheikah blue and the Ganon red, but it is also a compromise between Sheikah order and Ganon chaos.


Well, that turned into a bit of a conspiracy theory. If I missed something let me know. I’m excited to see how off I am on this when we get more details about the game. It’s presented as a Breath of the Wild sequel, but the themes and nature of its development are setting it up as a spiritual sequel to Majora’s Mask, and if any of this speculation is close, an indirect sequel to Twilight Princess. Whatever it ends up being, I’m excited.

Fail to Win Update: Chapter 2 Shenanigans

I’m just writing something quick to let everyone know Fail to Win is being worked on, specifically chapter 2. I can’t say much because of spoilers, but I attached a few screenshots just to show how ridiculous this game is getting. These stages definitely need some work, but the plan for this chapters is pretty solid now. The original plan was to make Fail to Win a short, 1-2 hour game, but the demo ended up being that. Now, the plan is much larger, something you might have a hard time finishing in one sitting. Also, I’ve been making progress on the stage builder. I plan to include that with the game so players can make their own deadly puzzles.

Also, I’ve been gradually updating the chapter 1 demo based on feedback from players. I swapped out/tweaked some puzzles and I clarified some of the instructions. These early challenges are crucial for getting a sense of the weird rules of the game so you are prepared when tackling the larger, interconnected puzzle-box challenges planned for later in the game. The free demo is still downloadable at the same location:

Fail to Win: Chapter 1 released

The first chapter of Fail to Win is now available for free on itch: It’s a ragdoll puzzle game where you progress by dying.

The game now consists of four stages, each with a handful of puzzles. The game should last about 30-60 minutes. Please check it out! Also, you can join our feedback and discussion discord: We’re hoping to turn this into a full game with at least four times as many puzzles, because we have a lot planned.

Fail to Win Update: Demo Coming Soon!

After an awesome Christmas with White Elephant, I’m feeling a lot more confident. If you haven’t played White Elephant, it is a first-person 3D puzzle platformer where you must open an absurdly-wrapped Christmas present in an escape-room-like way. The game was well-received with nearly five-hundred downloads, five-star ratings, and lots of recorded walkthroughs. It was one of the most popular games on Itch this past week. This was an exciting response to a game I threw together in four days. Now that Christmas is over and I expect the excitement of White Elephant to die down, I’ve been turning my attention over to my other project: Fail to Win.

What is it?

Fail to Win is a 3D puzzle platformer where in order to progress, sometimes you have to die. With a respawn point that acts as a teleporter and explosives that can launch your corpse at hard-to-reach locations, you solve a series of puzzles while being led by mysterious fourth-wall-breaking guide.

I actually started making this about a year ago when I was playing with ragdoll physics. It was just a proof of concept, and I had no idea what direction to go with aesthetic or plot. I left it for some smaller projects hoping that when I came back to it, I’d have a bit more popularity and could actually get this game in front of people. It is one of my more ambitious projects, so I want people to actually play this one.

Then, a couple months ago, I got impatient and indirectly returned to it anyway by working on making some Asset Store tools. I’m an Asset Store publisher, currently with five code packages for sale. I hadn’t published any new packages recently, so I figured I could work on programming a stage creator designed around 3D puzzle platformers. I’ve been making a lot of progress, so I started using this stage creator to build stages for Fail to Win.

The demo

The demo currently consists of a single stage with a few simple puzzles, acting as a sort of tutorial. The whole experience lasts about ten minutes. You can download it at

It isn’t quite ready for releasing on Itch, but it is getting close. Expect the demo to make an official appearance some time in January. Recently, another game jammer, Yru2kind, offered to help out with audio. The full demo might just be this single stage with a little extra polish, or I might add a couple other shorts stages that are close to ready, depending on how much time I have.

What’s coming later?

I’d like to make Fail to Win into a full game, but that is up to the response the demo gets. If people like the demo, and I get enough people following the project (Itch follows, YouTube subscriptions, etc.) then I’ll start looking into crowd funding. The full game will likely last a couple hours for the average player, but maybe more depending on how much funding we can get. Development will take about a year to incorporate all the things I currently have planned for it.

Even the demo is currently a work in progress (more of a demo of a demo), but please try it out and send any feedback my way. Thanks!

Puzzle Platformer Stage Creator for Unity

I returned to work on Fail to Win and decided to build myself some better tools. So I started build a stage creator. It is front-facing, so it makes it possible for players to design and save their own puzzles, something I plan to include in the release of Fail to Win. I figured, though, that there isn’t anything quite like this on the Asset Store currently, so once I’m done, I’ll make it available for purchase as a framework for creating 3D puzzle platformers.

All of the above were built using the stage creator. Each stage is a single mesh with no hidden geometry. The stage can be saved as a JSON file and then loaded into the game later. The developer can configure the stage creator to pick what is exposed to the in-game stage creator (list of props, stage size, etc.).

There is still a lot more to come. Currently, I’m working on finishing prop placement and play-testing. If you are a Unity developer, please let me know what you think and what you might like to see in this framework. If you are a gamer, I’m interested in your thoughts on player-generated content and stage creators.

Maze Generation

Mazes are designed to be complex; otherwise, they would not be used to make people lost. However, the techniques for creating mazes can actually be quite straightforward. You can create a complex maze by following a simple algorithm. This makes mazes ideal for diving into procedural content generation, a field of study devoted to building complex structures and art from code with little or no input from humans during the process. This tutorial will not provide any actual code, but rather is designed to be an introduction to maze generation algorithms. Let’s first look at an example algorithm:

  1. Begin with an empty space with no walls.
  2. Divide the space in half with a vertical wall.
  3. Randomly place a single opening in the wall.
  4. Divide each half in half with a horizontal wall.
  5. Place an opening in each wall.
  6. Repeat 2-5 for each new section until the desired level of detail is achieved.

This is an example of a recursive division algorithm. Following this algorithm, we end up with this:

simple subdivision algorithm

There are obvious weaknesses. One is that there are more horizontal walls than vertical walls. This is inevitably the case for any square maze created with this algorithm. The other problem is that it is somewhat predictable. Given a view of the whole maze, you can see an obvious middle point you must reach to get to the other side of the maze. You could find similar points that connect each quadrant of the maze to another quadrant. You can easily find the red, then green, then blue dots that you must pass through to access other parts of the maze. Connecting those and finding any other point in the maze from those is trivial. We could modify the algorithm, but related algorithms will have similar issues. Instead, we need a different model for our mazes, one that will give us flexibility to create all sorts of algorithms.

Graph Theory and Mazes

We need to better define our goal. Let’s say that our ideal maze is a maze where every point in the maze is accessible to every other point in the maze in exactly one way. This means no loops and no inaccessible areas. We can see the recursive division algorithm achieved this, which makes sense. Since we only left one opening between halves at each level of detail, there could only be one path between them. Looking at mazes in this way though, of points connecting to other points, lets us use graph theory. For those not familiar with graph theory, it is a mathematical field of studying graphs, which are structures that have objects, or nodes, connected to each other through edges. If our nodes, for example, are cities, then we might consider the presence of a road between them to be an edge. In our maze example, we can set up various points that we assume will be empty, like a room, and connect them together in various ways.

Our definition of an ideal maze lets us do something interesting with our graph. If there is only one path to any node from any other node, we could use any node as the root node of a tree. Trees are a special type of graph, and a lot of algorithms have been invented for building and traversing tree structures.

Because mazes are random though, we do not know what the tree will look like until we generate it. This is okay. If we imagine our maze as a tree, we can traverse it to “discover” what that tree looks like, even if that is not determined until the traversal. There are two popular types of tree traversal/generation algorithms worth describing, and they each produce a very different kind of maze. After their description, I included another algorithm that is a sort of combination of the two.

Depth-First Search

Depth-first search (DFS) is a simple tree traversal algorithm that works the way it sounds. First, keep going deeper in the tree until you can’t go any further. Then back up and try another branch. More specifically, the process is as follows:

  1. Start at the root node, which can be arbitrarily chosen. Mark it as visited, and set it as the active node.
  2. Do the following:
    • If there are no unvisited children of the active node:
      • If the active node is the root, you are done.
      • Else, the parent of the active node becomes the new active node.
    • Else:
      • Pick a child, mark it as visited, and set it as active.
  3. Repeat Step 2.

Since we are using this for maze generation, this requires a few tweaks. To implement this, I used a 2D array, where a 0 represents empty space and a 1 represents a wall. For example:

1  1  1  1  1  1  1
1  0  0  0  1  0  1
1  1  1  0  1  0  1
1  0  1  0  0  0  1
1  0  1  1  1  0  1
1  0  0  0  0  0  1
1  1  1  1  1  1  1

The bold zeroes are our nodes. A zero between two nodes means the nodes are connected. A 1 means they are not connected, and there is instead a wall. We can begin with a map entirely filled with ones. Whenever we change a node to a zero, it means we have visited it. If we go back to thinking about this maze as a tree, then each node can have up to four children, one in each cardinal direction. This is not always the case, though, since sometimes, moving in a direction means leaving the edge of the maze or connecting to an already-visited node, creating a loop. If there is no direction to possibly connect to, then we back up to the previous node. Here is how we carved out the above maze. Red is the active node. Blue shows the possible next move. Orange is the path created so far.

Normally, DFS would have a consistent yet arbitrary way of selecting the next node in the path. For a maze, though, it is better to choose randomly. Whenever there are multiple blue paths, one is chosen completely at random. Note that at steps 5 and 10, there were no options for possible moves. In these situations, we back up until there are possible moves. We can keep track of the path using a stack. With each move, add something about the move, such as coordinates, on the top of the stack. When backtracking, take the top coordinates off the stack and set that as the active node. When we arrive back at the root node (which we know we did if the stack of moves is empty), and there are no possible moves, we know we are done. Following this, I created a maze that looks like this:

This does not have the same problem as recursive subdivision. There are no obvious ways to divide this maze in half. However, if you try following a path, you will notice that you are not actually faced with many choices when navigating this maze. There are a few dead ends, but most of the maze is just a couple long, winding paths. This might be preferred in many situations, but not always, so it is worth exploring other algorithms.

Simplified Prim’s Algorithm

Prim’s algorithm is in many ways opposite of DFS. It is breadth-first, so we will be looking very shallowly at a lot of paths before moving deeper. It is usually used for finding minimum spanning trees, or a tree with the fewest/shortest edges. The result is an optimal path that connects everything together. The algorithm looks something like this:

  1. Start at the root node, which can be arbitrarily chosen. Add it to the tree.
  2. Of all the edges that connect the tree to an unvisited node, choose the one with the smallest edge weight.
  3. Repeat until all nodes are visited.

For our purposes in making a maze, we can simplify this by removing all concept of edge weight. We don’t want to find an optimal solution; that would be a very boring maze. Instead, we will choose the edge randomly. Imagine maintaining a list of possible next moves. Every time you visit a new node, you can add another move to its adjacent unvisited nodes to the list. However, unlike DFS, the next move is selected from the entire list, not just the ones from the last visited node.


While this maze is also random, it is significantly different in appearance to a DFS maze. The modified Prim’s algorithm creates a maze with lots of dead ends, but very short paths. While this fixes the problem mentioned about DFS, it takes it to another extreme. There are so many dead ends that none of them go very far. You aren’t likely to be fooled by a dozen nearby dead ends that don’t even turn a corner.

Combination of the two

Both maze algorithms have weaknesses, so I figured a combination of the two ideas would create a better balance. For this algorithm, like our simplified Prim’s algorithm, we maintain a list of edges, but we tend to stick to the same path a little longer like in DFS. Do this by defining some maximum number of moves before a jump, such as 5. Now, when we pick an edge, we then do DFS for only 5 moves before quitting and picking another edge like in Prim’s. For simplicity, it may not be necessary to maintain a stack of move history like in DFS. Instead, you could simply say that if you get stuck, switch back to the Prim’s algorithm instead of DFS, and start working elsewhere.

  1. Start at an arbitrary root node. Add it to the tree.
  2. Add this nodes edges to a list of possible edges to choose from.
  3. Choose one of the edges to connect to. Add its edges to the list of edges. Also replace lastEdges with its edges.
  4. Do the following MaxMovesBeforeJump times or until lastEdges is empty:
    • Choose one edge from lastEdges and connect to it.
    • Replace lastEdges with just the edges available from the last move.
  5. Repeat 3 and 4 until there are no edges left.

After experimenting with different values for the maximum number of moves before a jump, I was able to get different mazes on the range of qualities we see from the DFS and Prim’s algorithm extremes.

2 step combo algorithm
2 steps max before jump

5 step combo algorithm
5 steps max before jump

10 step combo algorithm
10 steps max before jump


These algorithms form the basis for most maze generation, and they can be adapted in many ways. While these examples acted on a 2D array to produce a square maze as is most common, the graph theory behind the algorithms does not require these kinds of limitations. It can easily be adapted to 3 or more dimensions (I actually created a 4D maze one time). You could even build a maze from other types of graphs, such as a maze with hexagon nodes. I would have posted my implementation code, but it is too long for this post, and it is for sale on the Unity Asset Store in a package called Maze Creator. The package also allows the creation of maze templates, a tool for greater design flexibility outside the scope of this article. If anyone is doing anything cool with mazes or have any questions/suggestions, I’d love to hear about it!

3-Handed Laser Shuffle

I recently competed in a game jam on The requirements were a 128×128 resolution, four colors, one weekend, and a theme of “break out.” So I made this. The controls take some getting used to. It’s intentionally a bit awkward, and requires some practice switching among three controls with only two hands. WASD controls the red laser. TFGH controls the green laser. The arrow keys control blue. Try to destroy the matching blocks before they get too close. Every 100 blocks cleared gives you a power-up that you can use with SPACE. This pauses block movement for a few seconds.

3-Handed Laser Shuffle won first place in the Mini Jam, among 20 entries. Try it out!

Creating a Circuit in Unity

During a recent game jam, my team made a game called Elevator Circuit. The game is now available on for free on Itch: The objective is to complete a circuit by moving elevators holding circuit segments, aligning them into a complete path. It currently has five short puzzles with more to come. My biggest role in the project was to program the circuit system.

The idea was that any segment without a path to a generator would be red. A segment with a path from one side, but not a path from the other is yellow. When there is a path to a battery from both sides, current can actually pass through the segment, it turns green. I used Procedural Lightning to indicate that the connectors of two segments are close enough to be connected (It happens even when the two segments are not connected to a battery, but we needed some kind of feedback).

My first (failed) attempt

I made a script for each connector that checked for other connectors to enter and exit its trigger area. It then registered the segment of the other connector to current segment. The connector then told the segment to update its material by recursively checking its neighboring segments, and then its neighbor’s neighbors, until it either dead-ends, loops , or reaches a battery. All the segments along that path would update their materials accordingly. I soon ran into all sorts of race conditions and edge cases. The lightning would correctly connect segments, but the colors of the segments would be wrong half the time. So, I scrapped that and tried something new.

Working from the battery to the segment.

Since there would only ever be a handful of segments in any stage, it would not be too expensive to check for changes every frame. I kept what I had before with each connector registering other segments to its own segments, but instead of updating the materials only during a connection change, the battery would “pulse” every frame. Going recursively to each connected segment from the battery, it would mark the visited segments as “connected” either from the left or right, depending on where the pulse came from. The segments would then all update their materials accordingly, the frame would render, and then the connections would reset for the next pulse.

visual explanation of circuits


Here is the script that goes on the individual connectors:

using UnityEngine;

public class CircuitConnector : MonoBehaviour {

    public bool isLeft;
    CircuitSegment segment;

    private void Awake()
        //Expect CircuitSegment script to be on parent.
        segment = transform.parent.GetComponent();

    //Make a connection
    private void OnTriggerEnter(Collider other)
        CircuitConnector otherCon = other.GetComponent();
        if (otherCon != null && otherCon != this)
            //Register connection to segment
            if (isLeft)
                segment.leftSegment = otherCon.segment;
                segment.rightSegment = otherCon.segment;
            //Code for anything else to do during a
            //connection, like instantiate lightning

    //Lose connection
    private void OnTriggerExit(Collider other)
        CircuitConnector otherCon = other.GetComponent();
        if (otherCon != null && otherCon != this)
            //Unregister segment
            if (isLeft && segment.leftSegment == otherCon.segment)
                segment.leftSegment = null;
            if (!isLeft && segment.rightSegment == otherCon.segment)
                segment.rightSegment = null;

This gets attached to the individual connectors, labeled A and B in the diagram, although in the code, I refer to “left” and “right”.  They must handle collisions with other connectors to register connections, so each connector object will need this script, a rigidbody for collisions (it can be kinematic), and a trigger collider for its range for connection.

And here is the script that goes on the circuit segment:

using System.Collections.Generic;
using UnityEngine;
using UnityEngine.Events;

public class CircuitSegment : MonoBehaviour {

    public CircuitSegment leftSegment;
    public CircuitSegment rightSegment;
    private List meshesToPaint;

    //Usually only one of these in the scene at a time
    public bool hasBattery;

    //I used a red, yellow, and green material
    public Material deadMaterial;
    public Material oneWayMaterial;
    public Material poweredMaterial;

    //Optional event for receiving/losing power,
    //like opening and closing a door
    public UnityEvent powerEvent;
    public UnityEvent losePowerEvent;

    //Resets every frame, set by pulses
    private bool leftPowered = false;
    private bool rightPowered = false;

    //Does not reset, decided after pulsing finishes
    private bool powered = false;

    //only true during a pulse for checking
    //for loops
    private bool pulsing;

    private void Awake()
        //Register all the meshes I want to paint.
        //I tagged all of them with "Wire"
        meshesToPaint = new List();
        foreach (Transform child in transform)
            if (child.tag == "Wire")

    public void Update()
        //Handle events for gaining and losing power.
        if (!powered && leftPowered && rightPowered)
            powered = true;
        else if (powered && !(leftPowered && rightPowered))
            powered = false;

        //Reset power
        leftPowered = false;
        rightPowered = false;

    //Don't pulse until everything is reset from Update()
    private void LateUpdate()
        //Only segments with batteries start a pulse
        if (hasBattery)
            if (leftSegment != null)
            if (rightSegment != null)

    //Recursive function for deciding connections to batteries
    public void Pulse(CircuitSegment from)
        //If a segment has already been visited in a pulse, it
        //must have looped.
        if (!pulsing)
            pulsing = true;
            if (from == leftSegment && from == rightSegment)
                //Handle edge case of a circuit with only two segments
                leftPowered = true;
                rightPowered = true;
            else if (from == leftSegment)
                leftPowered = true;
                if (rightSegment != null)
            else if (from == rightSegment)
                rightPowered = true;
                if (leftSegment != null)
        pulsing = false;

    public void UpdateMat() {
        Material mat;
        if (hasBattery)
            //Batteries work a little different. Never red.
            if (leftSegment != null && leftSegment.leftPowered && 
                rightSegment != null && rightSegment.rightPowered)
                mat = poweredMaterial;
                mat = oneWayMaterial;
            if (leftPowered && rightPowered)
               mat = poweredMaterial;
            else if (leftPowered || rightPowered)
                mat = oneWayMaterial;
                mat = deadMaterial;

        //Apply the material to every assigned mesh
        foreach (var rend in meshesToPaint)
            rend.material = mat;

This gets attached to the entire segment object. Normally this would be the parent of the connectors, although it technically does not have to be with how I set up the code. Add the segment to both connectors through the inspector, and then mark one of them as left (it doesn’t matter which one). You will also need to assign to the segments the materials you want to paint onto the wires. Any children of the segment with the tag “Wire” will be painted those materials, so be sure to set up that tag.

Mark any segment as having a battery in the inspector, and that segment will now supply power and initiate the pulses. Now, if you have some object you want a complete circuit to trigger, like opening and closing a door, make a new script with two public methods such as Open() and Close(). On the segment that powers the object, you can assign those methods in the inspector through the Power Event and Lose Power Event.

Ten Super Helpful Unity Assets

As I’ve been working on Nebula Gladiator VRFly Around and Zap Aliens,  and Fail to Win, I’ve relied heavily on the Unity Asset Store. It is a great way to avoid reinventing to wheel. Unity itself all the basic tools you need (physics, animation, etc.), but to get a good starting point for your game, it is pretty much essential to add some packages from the Asset Store. Many of the packages cost a small amount (I have five packages ranging between 5 and 20 dollars), but many are free as well. Anyway, I’ve played around with a lot of Unity packages and found a few to be particularly useful. I’ve limited this list to just code and effect packages, since those tend to be more generally applicable.

1. Ragdoll and Transition to Mecanim

This is what I’m using for the ragdoll transitions in Fail to Win. In a 3D game where your avatar can get hurt (which is almost all of them), using ragdolls is a lot easier than creating death animations. It also tends to respond better to forces than pre-set animations. This tool by BzSoft, makes it even easier by automatically turning a character into a ragdoll when, for example, you fall from a really high ledge. Then, when things calm down, the avatar get back onto his or her feet. Also, it’s free.

2. Procedural Lightning

I am using this to do the zapping part of Fly Around and Zap Aliens. I used to have a simpler procedural lightning effect, but this looks way better. It has a surprising amount of configuration, so if you need anything that even somewhat resembles lightning or sparks, you can probably use this. Despite that, it is super easy to set up. It only costs $9.

3. Log Viewer

This solved a frustrating problem. I tested everything in the Editor, and it worked great. Then I made a build and deployed it to my phone. I opened it up to find the game broken. I could dig around and find the log file, but finding problems that way takes more time, and you may have to dig through a lot more. I then added this to my project and could open the log from my phone with a simple circle swipe gesture. It looks like the Unity console. It also displays the frame rate, memory usage, and other stats. This could be super useful for collecting information from beta testers. This package is free.

4. ProBuilder

So, I’m not much of an artist, and even if I was, I wouldn’t want to go into Blender or Maya and design a level just to test a simple idea. So I spent a lot of time carefully aligning primitives (mostly cubes) into rooms. The Standard Assets Prototyping package helped a little, but it still lacked the kind of control I needed. ProBuilder is a free package that lets you model directly withing the Editor. Granted, it would not be ideal for anything as complex as character design, but it is fantastic for level design.

5. FinalIK

This is the priciest package I’ve listed so far as $90, but if your game involves a lot running around and climbing on stuff, this may make your animations look a thousand times better. I got tired of having floating feet when walking on slopes, so I was really excited to finally have a way to fit my animations seamlessly to the stage just like in AAA games. This package does a lot more than stick feet to floors. Climbing, opening doors, pressing buttons, and pretty much anything else that involves animation and an avatar’s surrounding are going to look a lot better with FinalIK. I’m even using it in Fly Around and Zap Aliens, although I had to be sure to turn it off every time you become a ragdoll; otherwise, weird stuff happens.

6. Mesh Slicer

Another BzSoft package that makes it easy to create a more fun game. It lets you cut a mesh along a plane, or even along the path of a knife (or sword). It is a super satisfying effect in VR. That’s why I added it to Nebula Gladiator VR. A VR sword isn’t going to meet any resistance except maybe when a family member or roommate walks through the living room at the wrong time and gets hit with a controller, so a VR sword should cut cleanly through anything it hits. It got even better when I wrote a simple script that forces the pieces to fly away from each other after being cut.

7. Head Look Controller

I’m amazed this package still works, since it hasn’t been updated since 2010. It is free, and simply makes people look at stuff. There may be some other similar packages that do the same thing and are more up to date, but most of the time, this package should be all you need. It is super easy to set up and is another subtle effect that really makes a game look so much better.

8. MK Glow

It is a nice-looking glow effect that can be added either to individual objects or to a whole scene. I’m probably going to add it to Fly Around and Zap Aliens soon. I’ve played around with it before, and it is really easy to set up. They even have a free version. The upgraded version is only $10, and offers some extra control, but the free version is already super useful.

9. Unity Particle Pack

This is a Unity Essentials pack, so there’s a good chance you have already been using it, but I had to list it here because of how useful it is. I am using its explosions in Fail to Win, but a lot of its more subtle effects like dust and sparks can add the right kind of detail to a game. Most games are going to have a good reason to use at least one of those effects.

10. Post Processing Stack

Another Unity Essentials package, but worth mentioning. When used right, this could help make your game look less like an obvious computer rendering and more like a cinematic masterpiece. I discovered it doesn’t work so well on mobile, but on other platforms, it helps give the finishing touches.

A Final Note

Many of these tools were things I discovered when I was noticing details in my games that made them seem like ugly amateur indie games instead of modern quality masterpieces. Thank you to all the creators of these tools. The asset store is a fantastic resource. I’ve both sold and purchased tools on the asset store, and the system is great. I, of course, haven’t tried everything on the asset store (there are thousands!), so I’m curious if any of my Unity gamedev readers here have used a Unity package they consider a must-have. If so, please share in the comments below.

Fly Around and Zap Aliens Beta

I recently released a game on the Google Play store called Fly Around and Zap Aliens. It is currently in an open beta, so you are welcome to try it out, although I plan change some things in future. You can download it here:


This game actually started back in high school. I had previously made a simple space game in Flash where you and another player orbit a planet, trying to knock each other out of orbit. When I was learning Unity, I thought I would try making a 3D version of the same game. However, I quickly ran into some serious design issues:

  • There’s a lot more space in three dimensions. Traveling from one side of the planet to the other felt like it took way too long, and it was hard to tell how fast you were going until you crashed into something, unable to slow down fast enough.
  • Your field of view is limited, since you are following a spaceship instead of getting a full view of the arena. This made the pull of gravity really confusing. Since there is no up or down in space, the pull of the planet onto the ship just made uncomfortable controls.
  • Multiplayer would be trickier than simply sharing a keyboard with a friend.
  • Boundaries are unclear. In 2D, it was simply the edge of the screen. In 3D, I needed a way to box players in and still have them experience the openness of space.

So I made an entirely new game with a similar-looking stage. There is still a planet in the center, and you still control a spaceship, but now you are defending the planet from aliens. You zap them instead of knocking them backward. There is no real gravity from the planet, but you still fly around it. I originally had a force-field for boundaries, but my force-field effect looked awful. The game was pretty much playable, though. I never could settle on a name. I then took a two-year break from game development and forgot all about it. More recently, I was looking through my old projects and re-discovered it. I had learned a lot since made it (it’s been about five years now), so I decided to start fixing it up.

The Game Now

I chose to port it to mobile because of the availability of tilt controls. Really, a platform like the Nintendo Switch would be more ideal, since it has a little more graphics power than a mobile phone while stile having the same tilt control, but Android is an easier platform to begin publishing for. The Asset Store has come a long way since I started this project, so I was able to make things look a lot nicer, but the game works in pretty much the same way. I did, however, change the boundaries, using a portal instead of a force-field. If you fly too far away from the planet, a portal appears, taking you to the opposite side of the planet, flying toward it instead of away from it. I released it recently to the Play Store, but it still has a few problems. For example, it is possible to dodge the portal and keep flying away. Most people I show the game are initially confused by the controls. It doesn’t take long to get used to them, though. Also, the end screen is kind of boring. I hope to fix these things and more. Still unable to choose a name, I chose the most concise way I could explain it.

The Plan

Between now and the full release, I plan to add the following:

  • Appearance tweaks (Already swapped out the spaceship models; just need to publish that change).
  • Fix the problem of dodging the portal and venturing into the void of space.
  • Add a leader board
  • Have the aliens come in waves instead of a steadily increasing rate.
  • A tutorial
  • Optimizations and device support (If you try the beta, and it does not work on your phone, let me know!)
  • An iOS port

These updates will come gradually as I make them, leading up to the official release. Please try it out and let me know what you think!