Aesthetics of trash
I was always a fan of trash stuff. People who know me in person are very aware that I will at some point praise some bizarre, low budget creation of any sort of medium in a true, heartfelt way – latest public evidence of this is when I freaked out finding out that Eric Barone (@concernedape, of Stardew Valley fame) was 50% of 17 Colorful Feathers, which is my go-to reference for “no, you don’t understand, I really do enjoy some pretty weird stuff” in music talks.
Also, I’m Brazilian. Which means there’s no way I’ll go through life without acquiring a certain appreciation for gambiarras. As coders, we are (rightfully so) trained to avoid that. But I’m guessing because of my taste for the grotesque I can’t help but having fond memories of some nasty code I’ve either seen or written myself, like that time when I passed data on a hover text parameter, or added a “case 2.5:” on a switch statement out of urgent time constraints (and because lazy).
It all started when Matt Thorston posted the source code for the Player Controller in Celeste. Many people, me included, wondered if it was maybe a tad too big, given your average “best practices”. In my case it came mostly from being a full time coder on Free to Play projects in the recent years: you have to think about people who may parachute into your codebase years after the original coders have left. Sure, you might end up taking extra care in projects that prove to be short-lived, but that is way, way better than eons old shit code that is the main money maker for a big company and some poor devil has to add new features to.
However, as everything on the internet, people took it from “oh, this is unusual, why did you take this approach?” to “I’m an expert, this is total shit, that’s why [completely unrelated thing] happens, you suck“. Alas, people tend to forget that shipped, working code is the best type of code.
A small twitter exchange in that thread made me set up the jam as a joke – including the rule of mandatory open sourcing, “so everyone who learns from it can never get an actual coding job“.
But the more I thought about it, the more interesting it became to me. Code aesthetics is not something that is often talked about, and even though we all wished we were writing stunning code all the time, it’s not always possible. So the idea of trash aesthetics + code sounded interesting enough for me to actually spend some time making a game in a single class. The worst way possible, obviously.
The jam ended up showing on an itch.io newsletter, which rendered some participants. And I have to admit it, I felt like it was already a success when this popped in the submission feed on the first day:
There were 16 entries in total, and I’m really thankful for everyone that took part in it. There were games with twitch streams during development; a simple, but moddable networked card game; pretty charming entries with nice code, and even one doing the “multiple games in a single class” modifier!
I really enjoy the fact that all of those were made, but I do have a few favorites. I really liked Shape Dodger, because Rachid seems to be just starting out, and I’m really glad for giving a little push for him to make a new game. Stealing Wallets pretty much embodies the whole trash aesthetic that I love. But at the end of the day, my favorite ends up being Crowdsurfing on Chicks – having that aspect present in a bunch of things I made over the years, I obviously have a soft spot for games that intertwine gameplay and social commentary.
I kept thinking about the concept of making a whole game in a single monobehaviour. There’s way too much stuff packed in Unity for the whole “single structure” thing to be a real challenge; it’s more an eyesore than anything else. If you look at almost all of the Unity entries, they just do the sensible thing and control groups of things in their “game” class. But doing the sensible thing is no fun. I needed something grimier.
Unity is moving into a new era with the new Job and Entity Component Systems, and Mike Acton is now on board and pushing for a data-oriented, optimized future. So this would be my chance to say goodbye to sprinkling components everywhere in the crappiest way possible.
What if I made a monobehaviour that would be put in all the objects? The exact same code chimera in all objects, unfolding its functionality based on… a type dropdown somewhere? How nasty would it end up? Was there any way this could actually be clean code somehow?
I started by splitting every default Unity function in switch statements, and creating methods stubs to fill them up later. Fortunately, it didn’t take long before noticing that I was overthinking it: there were more methods and variables than I really needed.
That’s when I realized: if everything is the same thing, everything can be anything! The only thing that separates one functionality from the other with the way I was building the code was… a type dropdown somewhere. This meant changing this value at runtime would change the way the object behaves.
That’s the glitch mechanic: in the further levels, there’s a chance that, upon a ball collision, a random block starts behaving like either a ball or a paddle. That opens up different gameplay possibilities and adds a bit of spice to the game. But the reason why it’s interesting to me is because it comes from the very structure that was supposed to only have faults.
The other interesting anecdote is that this is by far my most polished jam game on the audio-visual aspect. Heck, I spent 80% of the jam’s timespan screwing around with Shader Forge, ChipTone and mostly running errands and doing grown up stuff.
All of the grimy code and the fact that it doesn’t scale at all on the long term have zero impact on the player’s perspective. That’s something a lot of coders forget about. And that’s why Celeste’s player movement code can’t be any better than it is: it’s shipped, bug-free, played and loved by a bunch of people in multiple platforms.
Here’s something way more shameful than the code I wrote: I’ve been so neck deep on the kind of work I do every day that, on the very specific moment that I proposed a 1 Class Jam, I honestly simply forgot “classes” are not present in every language – even though I started programming in C (I did add a rule about structs to cover my ass about this later on).
There were lots of people asking about the specific rules, because they didn’t want to “cheat” and make it easier. But the whole thing is not really about making it hard, or even making it challenging necessarily. It’s more about having a sandbox for people to react to the whole “single code unit” concept: do they reduce scope? Do they write unreadable code? Do they pick a specific challenge within those constraints? Do they simply go for a non-OO language?
And that’s the interesting thing about trash: it’s only possible when the methods become accessible. When I was a kid, there was a quite active trash movie scene in Rio, and it produced some wonderfully shitty gems. That was only possible because your average home PC became able to run a pirate copy of After Effects. There’s also the fact that these things are made out of sheer will, against all odds, which is why I’m a long time fan of Wakaliwood movies.
That’s the point where we’re at with games now: you might not be able to make a living out of your creations, but you sure as hell are more able to make them than ever before.
I’ve encouraged people to start developing games. I’ve organized events and made sure people’s games were front and center in them. But I had never put together a game jam before. And here’s the interesting aspect that I never thought about: there’s a bunch of games that exist right now that maybe wouldn’t if I hadn’t joked about this thing. Maybe they would, at some other time, in some other way, but brains are pretty much serendipity-driven mechanisms. Ideas pop out at a given time, space, context, and might not appear in that specific way in any other.
As Alejandro Jodorowsky recently said:
Every artistic gesture can be the seed of a new world.