A firsthand account of a non-programmer's experience at the GI Jam

Thursday, October 18, 2018

We sent AC Atienza to the GI Jam, Fall 2018. This is their firsthand account.


"GI Game Jam as someone who knows absolutely nothing about programming and also went alone" - AC Atienza

I went to my first game jam this past weekend! Overall it was a really good, fun experience. I went to the Jam alone and before I started I knew absolutely nothing about programming.

I formed my team of people by shouting, "Who needs a team?" and taking in the first 3-4 people who looked at me. We got together and it turns out that I was the only non-programmer, but also the only artist - so my role was pretty much set from the start.

The game we decided to make was a roguelike where you left a "time trail" in your wake and could go back in time to solve puzzles or attack enemies in your "trail", etc.

As a non-programmer I submitted my image assets to the discord, while another member uploaded them to Unity and pushed my stuff to the Github. Thanks to a team of programmers around me, I could hyperfocus on art and designing a game implicitly through my choice of assets.

But you care about seeing what I learned! So here's five lessons I learned, particularly geared toward people who (like me) don't consider themselves a "programmer":


1. Make ugly placeholders of everything first, then polish later on

For example: I spent a few hours one of the nights making a glacier/giant ice cube pile that never made it into the final demo of the game because it just wasn't really needed anywhere. Sure, I can post it somewhere else, but it was kind of sad seeing so many assets essentially go to waste.

2. Really detail out what's actually being programmed into the game and what stuff is feasible

At a game jam you don't have time to mess around with massively experimental things that may never come to completion or even randomly just get cut without

3. Be prepared for a pseudo competitive nature at the Jam

Make a conscious choice whether or not you'll get into the competitiveness of the Jam. That way you don't get waffly feelings about feeling inferior throughout the weekend.

4. There's a lot of fun and learning that comes from doing things fast instead of doing things properly

I loved seeing what I was capable of doing within the span of a few hours. Turns out you can actually accomplish a lot when you have tiny deadlines! This is particularly with regards to drawing. Sure, I didn't make the best pieces I've ever done, but the fact is I got them *finished* -- and that's more than I can say for a lot of my more ambitious projects that got me nowhere and taught me little except how to feel stuck.

5. You can thrive in a group of randomly-chosen members as long as someone takes the lead

It seems like the individual relationships between people scales inversely with the amount of leadership required by any one person, anecdotally. It was very interesting seeing firsthand that you don't need to be personal friends with people in order to produce something substantial together - especially when there's independent parts that can be developed separately. Of course, cohesion can be somewhat of an issue, but if there's even one person who can be a liaison between departments things work out surprisingly well.


What about game dev knowledge?

I also learned about game development as a whole this weekend. I came to appreciate what programmers have to deal with on a minute and large scale. I came to understand what code debt is firsthand, as well as the frustrating nature of merge conflicts.

For artists: try to limit your colour palette or stylistic choices when doing videogame art. Cohesiveness is more important than necessarily looking great in a vacuum.

I also had a good experience seeing what other people have to deal with in departments other than my own. While the specific problems vary it seems there's universal issues that everyone has to deal with. For example, all of us had to deal with the sadness of assembling something that was amazing but useless in the context of the project.

This leads me to another lesson, maybe the biggest one:

What makes something "polished" depends on the gap between what a game does and what it wants to do. The smaller the gap, the more polished the game.

Ultimately, what matters for a good game, good art, good anything, is not a vague concept of how "good" your output is in a self-imposed vacuum; What matters is how much of your goal you fulfill.

Therefore, the biggest takeaway from my game jam, that I want to carry into my "regular" life, is that the relationship between goal and output is very often more important than the "raw" output alone.

...

Seriously! It perhaps sounds obvious to hear, but actually applying that is harder than it seems. I guess kind of like how boxing has different weight classes, you really need to figure out your own weight class and operate in there instead of comparing yourself to the heaviest of the heavies.