Noah and The Quest to Turn on The Light: Coming out of the dark

I’ve been working on something pretty personal for the last month or so.

Before we talk about what I’ve been working on, you’ll need some history. I should also preface this post with the fact that I’m pretty sure I’m not a narcissist, and I’m not trying to fish for attention/pity.

Some history:

I’ve been making games for about 5 years, and sharing them publicly for a bit over 3 years now. I started sharing my work by participating in Ludum Dare, and then eventually Global Game Jam. I got bit hard by the jam bug, and started doing gamedev pretty much exclusively for game jams. I found quite a bit of success within the Ludum Dare community, with my games making it into the top 25 rankings, then into top 10 for many categories. In December of 2014 my game, OMNI, placed 2nd in Innovation and Theme, 6th Overall, and top 100 in all but one category. This was a super exciting time in my life. The amazing feedback from the Ludum Dare community paired with such high rankings was super validating for me as a designer.

But that elation dissipated quickly. During 2015 I was unhappy and incredibly critical of everything I made or conceived, and my work showed it. I quickly stopped showing my projects to others. By early 2016 my self-criticism had led to full-blown creative block.

Noah and The Quest to Turn on The Light is a game about why I think that happened.

When I started designing, I was doing it for me. I wasn’t showing my work to anyone more than close friends or family occasionally. I was in early high school, and just making games for fun as a hobby. That’s the attitude I had when I hit the jam scene. But as I learned more, and my projects started receiving more and more praise, my internal motivation shifted from “because it’s fun and I want to,” to “because it’s nice to receive praise.” External validation had become my primary motivator.

I stopped showing people my work because I didn’t feel it was worth showing off. It wasn’t as good as OMNI, and I was afraid they’d realize it. They’d realize that it was just a fluke, and that I’m not actually that good of a designer. They’d tell me my work was bad. Impostor syndrome paired with my fear of negative feedback kept me from making anything to even receive feedback on.

I started working on this project to explore reliance on external validation and its affect on creators.

I’m done talking about myself now.


Noah and The Quest to Turn on The Light (referred to as just The Light to maintain my sanity moving forward) is a game about a creator’s struggle with external validation, and how that external validation can lead to one being overly self-critical.

In The Light, the player navigates dark worlds solving a series of terminal-based puzzles in order to collect fragments of an image of a lit lightbulb. The fragments are to be deposited on a canvas in the world, in order to light its grey bulb, and illuminate the world.


The player begins in the Gallery, a large room whose walls are adorned with framed pictures of unlit bulbs. Each frame serves as a portal to a unique unlit world. Upon lighting of the world and return to the Gallery, the player will find the bulb in the frame is now lit.

Over time, figures begin to appear in the Gallery. These observers comment on the lit bulbs, positively at first. As these observers increase in frequency, they begin to appear in the unlit worlds, offering encouraging commentary to the player.

Eventually, an observer makes a negative comment.

Criticism floods the Gallery, and the unlit worlds. The Observers present at each terminal to criticise the player as they attempt to progress.


The idea here is that over the course of the game, the player gradually stops solving puzzles for the sake of solving puzzles, and begins solving them in anticipation of the feedback from the Observers. When that validation is replaced by criticism, the player must face the discouragement to continue to progress. How they handle the validation and subsequent criticism is completely up to the player. The Light tries to only provide the environment in which the player must face these things.

So that’s the state of things. I’ll periodically post development updates here, but the most up-to date log will always be Twitter. Feel free to reach out to me there or by email with any thoughts about The Light.

Rainbow, Factorial Algorithms, and You

In mathematics, a factorial represents the product of all the positive integers less than or equal to n. This is written as n!

So, n! = n * n-1 * n-2…

Generally, this operation can be implemented very simply with a recursive function such as:

int factorial(int n) {
    if(n != 1)
       return n*factorial(n-1);

However, this implementation is quite inefficient (plus Rainbow doesn’t really have any concept of functions or recursion). In Rainbow, a more reasonable solution would be to set a new variable, s, to the value of n, then create a loop that subtracts by 1 and sets s to the product of and n, finally breaking the loop when n equals 1. In our pseudo-C representation, it’d look something like:

int factorial(int n) {
    int s = n;
    while(n > 1) {
        s = s * --n;
    return s;

Thanks to labels, lookaheads, and lookbacks, basic logic like this in Rainbow is pretty simple. Here’s a factorial calculator in Rainbow:


This representation isn’t terribly helpful though. Let’s break it down by each hex string, as the RainbowVM would.

0x300101 ;in at 0x00, len at 0x01
0x101100 ;set value of 0x01 to value of 0x00
0x5000F0 ;label with const 0xF0
0xB00001 ;sub 0x00 by const 0x01
0xC01100 ;mul 0x01 by val of 0x00
0x700100 ;lookahead to val of 0x00
0x500001 ;label with const 0x01
0x201101 ;print 0x01
0x000000 ;exit
0x500100 ;label with val of 0x00
0x6000F0 ;lookback to const 0xF0
0x000000 ;exit (unreachable)

The first line, 0x300101, instructs the RainbowVM to take input, put the value of the input starting at 0x00, and the byte length of the input at 0x01. We don’t expect numbers greater than 255 (especially as 6! is 720, which is much higher than our memory cell limitation of 255, and would result in undefined behavior within the RainbowVM), so we only expect the first address, 0x00, to have the value of n. We don’t care about the length of the input, so we put it in 0x01 arbitrarily.

The next line sets address 0x01 to the value of address 0x00. Here, we’re essentially establishing address 0x00 as n, and 0x01 as s.

Next, we set a label with the constant value of 0xF0. Any value would be applicable here, 0xF0 is just an arbitrary constant. This is effectively the start of our loop.

Then, we subtract 0x00, or n, by 1, and multiply 0x01, or s, by 0x00.

Now, we see a great example of simple logic in Rainbow. The line 0x700100 instructs the VM to lookahead until it encounters a label with the value of address 0x00, or n. Immediately following is a label with the value of the constant 1. Were 0x00 to be 1, the VM would begin execution here, printing the value of 0x01, and exiting. However, if the value at 0x00 is not 1, then the VM will continue looking ahead until it reaches 0x500100, which is a label with the value at address 0x00. The instruction following that label is a lookback to our constant 0xF0, which completes our loop.

The last instruction, 0x000000 is unreachable. It’s there simply to make the program 12 instructions long so it makes a nice 3×4 bitmap image.

So, now that we know how the program works, let’s walk through the calculation of 4!.

First, address 0x00 is set to 0x04, and address 0x01 is set to 0x01 (the byte length of the input). Then, address 0x01 is set to the value of 0x00 (4). Next, the value at 0x00 is subtracted by 0x01 and becomes 0x03. Now, the value at address 0x01 (4) is multiplied by the the value at 0x00 (3), and becomes 0x0C (12). The VM now looks ahead until it reaches a label with the value at 0x01 (4). It finds the label 0x500100, and begins execution at the instruction following the label. The VM now looks back until it reaches a label with the value of 0xF0. It finds the label 0x5000F0, and begins execution at the instruction following the label. We’ve completed our first iteration through our loop.

Now, we start again. The instruction following 0x5000F0 dictates that the value at 0x00 (3) be subtracted by 0x01. It becomes 0x02. Then, as before, the value at address 0x01 (12) is multiplied by the value at 0x00 (2), and becomes 0x18 (24). The VM looks ahead for the value at 0x00, and again finds 0x500100 then looks back until 0x5000F0, completing the loop once more.

We’ve reached our final iteration. The value at 0x00 (2) is subtracted by 0x01, and becomes 0x01. The value at 0x01 (24) is multiplied by the value at 0x00 (1) and remains 0x18 (24). Again, the VM looks ahead for the value at 0x01 (1). But, this time it finds 0x500001, a label with a constant value 0x01, first. The instruction following the label, 0x201101, is executed, printing the value at address 0x01 (24), and the program exits.


If you are interested in learning more about Rainbow, check it out on GitHub.

An intimate introduction to the Rainbow programming language

As a child, I had always been one to speculate things about the world around me, crafting beautifully absurd answers to questions I asked in my head. Such as, “How does that tree grow?” The natural answer, of course, is that small people live inside the tree and work all day to pull dirt from the roots and pack it into the end of the branches, growing them outwards. Of course I knew this was not a logical answer, but that knowledge didn’t keep me from imagining I lived in this beautiful reality.

Computers had always been a huge interest of mine as a child. Those mysterious beige boxes were machines of magic, able to take me on a journey to imagined worlds. No part of the experience of computing was overlooked or underimagined by me. Even the desktop was a strange realm that needed explored, and it’s inner workings imagined.

When my father introduced me to my first programming language over a decade ago, my world grew exponentially. He let me look behind the curtain, and had given me the knowledge to bring to life my imagination. With this new tool, Visual Basic, I was able to do anything. I wasted no time, and began creating.

Soon, I learned that the all powerful Visual Basic was not the only way one could program computers. There were, in fact, many other ways one could instruct these wonderful machines. This had my mind racing. I began imagining a vast expanse of programming languages. Much like the men in the tree, these programming languages were impractical and unrealistic creatures of my imagination. But, the more I learned about programming in the real world, the more beautiful these creatures became. They grew with me, and continue to grow, developing and changing just as I do.

Rainbow is one of those languages.

Rainbow is a language in which 6 character, 3 byte hex strings are encoded into pixel data of an image, providing instructions for the Rainbow VM.

Each hex string is referred to as a statement, and each statement is made up of 4 parts. The first part of a statement is the instruction to be executed on the Rainbow VM, and is defined by the first character of each statement. The second part of a statement is one of two 1 byte, 2 character parameters passed to the Rainbow VM with the instruction and is always a memory address. The third part of a statement is a single character switch indicating whether the last part of the statement is a value or memory address. This switch always has the value of either 1 or 0. The last two characters of a statement make up the second 1 byte parameter, a value or memory address depending on the state of the previous switch. If the executing instruction calls for a value as the second parameter, but a memory address is provided, the Rainbow VM will use the value of the cell at the address in execution.

For example: the statement 0xA05031 would execute the instruction at A with the address 0x05 and the value 0x31 as parameters. Additionally, the statement 0xA05131 would execute the instruction at A with the address 0x05 and the value of the cell at address 0x31 as parameters, due to the value/address switch being set to 1.

Here is a simple hello world program in Rainbow: Hello World!

This program is interpreted by the Rainbow VM as the following set of instructions (comments excluded):

0x100048  ;set cell 0x00 to value 0x48 (H)
0x101045  ;set cell 0x01 to value 0x45 (E)
0x10204C  ;set cell 0x02 to value 0x4C (L)
0x10304C  ;set cell 0x03 to value 0x4C (L)
0x10404F  ;set cell 0x04 to value 0x4F (O)
0x105020  ;set cell 0x05 to value 0x20 ( )
0x106057  ;set cell 0x06 to value 0x57 (W)
0x10704F  ;set cell 0x07 to value 0x4F (O)
0x108052  ;set cell 0x08 to value 0x52 (R)
0x10904C  ;set cell 0x09 to value 0x4C (L)
0x10A044  ;set cell 0x0A to value 0x44 (D)
0x10B021  ;set cell 0x0B to value 0x21 (!)
0x20010B  ;print values from cell 0x00 to cell 0x0B 
0x000000  ;exit with status code 0x00


The Rainbow VM currently has a set of 12 instructions, with capacity for a maximum of 16 instructions. These instructions are identified by the first character of each hex string passed to the VM, and are executed on an 256-cell tape with 8-bit memory cells.

For example: 0x10204C would result in the VM executing the command correlated with the character 1, the set instruction, which would set the memory cell at address 0x02 to the value of 0x4C.

The full list of Rainbow VM instructions, as well as more information about the Rainbow VM is available on the Rainbow project on GitHub.

The first Rainbow interpreter was written in C#.NET and was developed for a Computer Science House 24-hour hackathon. It implements all features of the Rainbow VM, and comes with some nice additions like output in hex, decimal, and ASCII. More information about the C# Rainbow interpreter is also available on GitHub.

Below are two more basic programs written in Rainbow:


This program takes an integer as input, calculates the factorial, and then prints the resulting value. As the Rainbow VM only has 1 byte memory cells, the maximum unsigned integer value that can be stored without undefined behavior is 255. This is problematic when doing math such as factorials. The greatest integer this program can calculate the factorial of without undefined behavior is 5.


This program calculates the nth number in the Fibonacci Sequence, then prints the resulting value. As with the factorial calculator, this program is limited to memory cell size, and any number higher than the 13th number in the Fibonacci Sequence will produce undefined behavior.

Soon, I will be writing posts breaking down how exactly each of these programs work.

Games, Projects and Portfolio updated.

It’s drawing close to the end of the year, and with that comes website update season!

Looking back, I’ve done a lot in the last half of this year. I added 6 more games from this year to my games page, including my most recent project for Ludum Dare 34, Psychra.

Additionally, I created a projects page to keep track of non-game projects, many of which I worked on this year, and plan to continue working on in the future.

I also made some changes to my portfolio page to reflect more recent projects.

Thanks to everyone who made 2015 awesome!

Migrating to a new host

Happy holidays!

This week I’ve set out to finally migrate this blog to a new (cheaper) host. With that migration, I’m taking some time to optimize how much space I’m using, and what files are hosted on my server.

So, for the next few days there might be some broken links here and there. If you come across something, please email me right away!

Ludum Dare 27 is a wrap!

For my third time in a row, I participated in Ludum Dare this weekend. I’m going to do a more comprehensive writeup later after I’ve gotten some sleep, but here’s a link to the submission page. Also here’s a link to my profile on the Ludum Dare website where you can find all of my entries.