GDEX, GDC, and the Importance of Networking

The most crucial tool for anyone trying to get a job in the games industry is their network. As a games student, networking is especially important, as you have little to no industry experience to pad your resume. More often than not, the only way to land that first games job is through someone you know in the games industry. Although there are many ways to make industry connections, there’s really nothing that builds your professional network faster than games conferences.

This past weekend I had the opportunity to show my current passion project at the Game Developers Expo (GDEX) in Columbus, Ohio. This is the second major games expo I’ve attended, after going to the Game Developers Conference (GDC) in San Francisco, California earlier this year. In this post, I’ll be comparing and contrasting the experiences of attending a games conference, and showing a project at an expo.

I’d like to first acknowledge some differences between GDEX and GDC. GDEX is a locally organized event that showcases regional game developers, and is open to the general public. Attendance at GDEX is generally in the thousands, making it a small to mid-sized event. GDC is an industry organized event aimed mainly at professional development and networking, and has attendance in the tens of thousands. Although the expo floor is open to the general public for part of the conference, tickets are fairly heavily sought after, and are also somewhat prohibitively expensive. As a result, the average attendee at GDC is generally more industry-oriented than the average attendee at GDEX.

GDC, being the largest conference in the games industry, and my first ever conference, was quite daunting. However, all the networking I managed to do on and off the expo floor was astonishing. I handed out and received many business cards, had lots of awesome lunches, and made many connections I was able to follow up on after the conference, keeping in touch throughout the rest of the year. Those connections have, and will, come in especially handy when it comes to moving my career forward. One big constant at GDC (as well as many other industry conferences) is the parties. These events, while fun, are also huge for networking opportunities, as they provide an opportunity to converse in a more casual setting. However, many of these events are also fairly exclusive, and being a first time GDCer, it felt like I was often out of the loop. Luckily, those connections I made at the last GDC will come in handy for keeping me in the know on further networking opportunities.

GDEX was a lot smaller than GDC, but that’s not to say the networking was any less impactful. I should include a disclaimer about GDEX: as I wrote in my last post, one of the most helpful things for me when it came to networking at GDC was the connections I already had established via my involvement in various online communities. I am lucky enough that GDEX is organized by the local game developers group in my home city of Columbus, so I was on a first name basis with not only the organizers, but many of the other developers exhibiting that weekend. Having this network coming into the expo opened many opportunities for me that I would not have otherwise had. This just highlights how incredibly important networking really is in our industry.

Showing a game at an expo is a lot different from attending an expo. For one, I found myself locked to my booth nearly the whole weekend. As much as I wanted to peruse the expo floor and talk with other developers, I just didn’t have the time to, with a near constant stream of attendees at my booth. But, that doesn’t mean I didn’t find a way to network. Although GDEX had a lower percentage of industry-oriented attendees when compared to GDC, there still were many professionals in attendance. As an exhibitor, these professionals found their way to me, and I was able to show them directly what I was working on. I was able to exchange cards with many people who were clearly interested in my work, and I even made a couple contacts that could aide in getting my game into other showcases. As a whole, I’d say that due to the smaller and more intimate nature of GDEX, although I made less new contacts overall, the connections I made were deeper and more meaningful than those made at GDC. Additionally, I was able to catch up with local developer friends, and show them what I’ve been working on. I even ran into a friend whom I had last seen at GDC!

The two experiences, although different, have many similarities, as well as many individual perks. GDC was great for blanket networking, and building my network very rapidly, which provides a great entry point for deeper networking outside the expo, and at the next conference. Showing my game at GDEX allowed me to make more intimate connections, as I was able to spend more time showing my work to–and talking one on one with–professionals in the industry, especially those who will be able to directly advance my career or at least my game. I believe that attending as many local conferences and expos as possible do nothing but good for your career, as they at least provide practice for GDC, and might even yield connections that will have great impact on your career moving forward.


Note: This is a lightly edited duplicate of a blog post I wrote for the RIT Interactive Games and Media student blog. If you’d like to read the original, you can find it here.

Big changes and betas

After the last update, I started working in a prototype of  The Light, returned to university, and pitched the idea at a couple game dev meetups. After getting back to school, progress on the game stagnated, but I kept talking about it. Every time I talked about it at a meetup, someone would ask how I planned to end it. I didn’t have an answer. This wasn’t something that worried me too much, as I figured I would come to how I wanted the game to end eventually.

After putting the game on the back burner to focus on school for a bit, I came back to it and realized there were a lot of things wrong with the prototype. For one, the transition between canvases and the dark worlds wasn’t very intuitive, and it seemed to break the flow of the game. The idea had originally been that the dark worlds and puzzles were just content to keep the player engaged and interested in the game, but they were ultimately distracting. Additionally, I the mechanics of the dark worlds had started distracting me as well. I spent more time iterating on mechanics in the dark worlds than I spent working on the parts of the game that really mattered to the narrative. In fact, those parts were largely unimplemented.

wing1-smol

So, I pivoted. I dropped the dark worlds and instead moved their simple terminal based puzzles to the canvases in the gallery. Observers still stand next to completed pieces and pass judgement on them as the player progresses, and the player still works to unlock wings of the gallery by solving puzzles. The game became a uniform experience that takes place in one room. I also developed a narrative arch for the experience.

The pivotal moment for the player is given the option to seal back off a wing after they have entered it, blocking observers from entering and passing their harsh judgement. If the player sealed the wing, they are presented with two options upon completing the wing: open the door, or exit the game (exit remains an option regardless of the state of the door). The player has the option to allow the observers to return and pass whatever judgement they may, or just exit the game satisfied that they completed the puzzles.

After making these changes to my design, I prepared another prototype for a local meetup and held the first playtest. I also collected emails for a closed alpha group. Over the past month, I’ve been working with the alpha group through to get a build ready for the Game Developer’s Expo (GDEX). The game has really come a long way from it’s inception nearly 5 months ago.

This past weekend, at GDEX, I ran the first public build of Noah and The Quest to Turn on The Light Beta. (More on that soon!)

During the beta, this blog will see more updates with insights into development on the project, so be sure to keep up to date!

 

Game Jams 101

Earlier this year a peer and great friend of mine, Joshua Landman, wrote an awesome blog post on passion projects. I absolutely agree with him in that working on projects outside of class-assigned work is incredibly important as a games student. Not only do personal projects look great to employers, they also provide the opportunity to experiment and develop your skills. But, taking on a long-term passion project is daunting, and there’s many barriers to starting. What do I want to make? Where can I find a team? What skills can I bring to the team? Game jams provide the answer to all of the above.

What is a game jam?

If a long-term passion project is a marathon, game jams are the 100m dash. Game jams are events in which game designers, developers, musicians, and artists work together or alone to develop a game based on a theme in a short span of time. The game jam ecosystem is incredibly diverse, but most jams follow this rough format:

  1. Participants get together either in person or online (depending on the jam), and spend some time getting to know each other.
  2. At a pre-announced time, a theme for the game jam is announced. Games made for the jam should revolve around the theme in some way. Upon announcement of the theme, the jam officially begins.
  3. Participants break out into teams and begin brainstorming ideas. Sometimes participants come in pre-formed teams, or prefer to work alone. However, larger in-person game jams, like Global Game Jam, encourage collaboration and making new friends at the jam.
  4. Participants begin to work on their games. During the brainstorming phase, teams generally work out the strengths and weaknesses of each member, and tailor their roles to match.
  5. The length of a game jam can vary greatly, with some as short as 1 hour, and some as long as a month or more. But generally, jams run the duration of a weekend. As the jam’s deadline draws nearer, teams begin to wrap up their games, and submit them to the jam’s website.
  6. If the jam took place in-person, there will generally be time for teams to show off their game, and get feedback from the rest of the participants. If the jam took place online, there will often be some way for participants to rate and provide feedback on other games. Participants take time playing other games from the jam and provide feedback on them.

Why would anyone want to put themselves through that?

Game jams are generally fast, and pretty high-octane. But, they’re also incredibly fun, great for levelling up your skills, and provide invaluable networking opportunities. The limited time-frame forces participants to work quickly, solve problems quickly, and think outside the box. It’s great having a week to muse over that bug in your game you just can’t quite fix. But, when you’ve got 10 hours to the deadline and you just can’t figure it out, you and your team might have to come up with a creative way to integrate the issue into your game. “It’s not a bug, it’s a feature!” is a common expression heard at jam sites.

Jams are also low risk. Participants are able (and encouraged) to break the mold and experiment in terms of design. If your project goes sour, you’ve really only lost a weekend, and you’ve probably at least learned a whole lot of what not to do. Due to this low risk factor, participants may also choose to try something new, like a new game engine, or a whole new specialty, like taking a sound/music role for the first time. Again, if your game doesn’t succeed, you’ve still succeeded in learning more than you can in a weekend anywhere else.

If your game does go well (and it will!), you’ll have a really cool prototype of a design to start with when you start that long-term passion project! Plus, you’ll already have a team that’s just as engaged with and in love with the project as you are. Many incredibly successful commercial games have come out of game jams. Surgeon Simulator, and Johann Sebastian Joust, are just two examples out of hundreds.

Finally, the connections you make at jams will follow you throughout the industry for life. At Global Game Jam, I jammed with somone who ended up a peer and great friend of mine in RIT’s game design program. This year at GDC, I was able to meet up with former teammates, as well as community members of various online game jams who recognized each other by their projects. These meetups opened opportunities for further networking opportunities, and made a massive conference like GDC feel a little smaller and more welcoming.

How do I get involved?

There are many game jams going on all the time. For online jams, the only barrier to entry is signing up on the jam’s website.Ludum Dare is by far the largest online game jam, with thousands of individual developers and teams participating every few months (that’s right, Ludum Dare is a quarterly event)! Websites like itch.io, Game Jolt and Indie Game Jams also provide great aggregation of many of the jams going on at any time.

In-person jams are a little less frequent (although many online jams may have physical meetups during the jam). The largest in-person jam by far is Global Game Jam, which runs yearly in January. This event takes place in physical meetup locations across the world, with all teams working on projects focused around the same theme in the same weekend. Check the GGJ site for a site near you!

The only way to get involved is to get started! So, go register for a jam that sounds appealing to you, clear your weekend, and put together a rad development playlist. Happy jamming!


Note: This is a lightly edited duplicate of a blog post I wrote for the RIT Interactive Games and Media student blog. If you’d like to read the original, you can find it here.

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.

fading

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.

opiniongood

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.

observers

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:

factorial

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:

factorial

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.

fib

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!