(I wrote this article as a Dev Log to my game GateKeepers)

https://singingstranger.itch.io/gatekeepers Play here!

Post-Mortem of Gate Keepers 

Crunch is a pervasive and frighteningly common tool used in our industry. But it is far from being a last minute, must get this game out by yesterday, kind of deal. Crunching, when you have fallen behind schedule and you desperately need to meet a deadline, is not something I am a stranger to from the working world but also from my own projects. 

In Crunch

Summer 2021 I ended up hospitalised and had emergency surgery after spending almost a year in constant crunch. I was working at minimum 12-14 hours a day with very few free days (even taking shabbat off was difficult), studying full time, working a part time job, applying for jobs for post graduation, all while I was making my final project, Facing AND also Sitting Shiva. This was the practical portion for my master thesis equivalent. Those of you who have played it (or even were present at my final presentation) know that the game takes around 45 minutes to complete. It is a first person narrative game. The written thesis part was definitely not easy on me either, I wrote and rewrote a total of hundreds of pages of content, all for a paper that ended up being very short. Months of research, debate, technical error and failure, writing and rewriting, coding my heart out, making 3D assets, designing, redesigning, spending so many hours just trying to make sure that the message of my game and thesis made sense together… I absolutely exhausted myself. 

When I got sick, it was days before the written paper was due. And days after my professor said the written paper was so bad, I should consider adding another year to my studies. I ended up putting the game on hold for a week and taking all the help I could get to just finish the paper. Somehow I managed to fix it, hand it in and then get back to polishing my final game, having two weeks now to finish it and then have my final presentation. There was a catch though: Two days after finishing my paper, I was starting my brand new, shiny full time job. There was an overlap of working and wrapping up my studies. After my final presentation and graduating with the best possible marks (guess my paper was decent), I sat with my friends for some water and cheers and then had a socially distanced BBQ in my back yard with my housemates. Because of my recent surgery, I couldn’t really eat anything much. 

Speaking of jobs. My day job in a small agency where we make a variety of AR/VR apps, software solutions and games, has occasionally resulted in crunch for me or my teammates (often the head of dev). I’ve had some weeks where the project manager would come to me the next week and tell me that I couldn’t work such long hours. Too many 9-10 hour shifts. Crunching was being actively discouraged. After spending a year in eternal crunch, it took me months to adjust. Now, I do my best to come out at exactly 40 hours every week. Shocker: I actually have time and energy to do things after work. Like laundry. Or taking a walk with a friend. Make some private art. 

The transition would have been less abrupt and startling to me if I had not been told by every dev, media outlet and by many professors and other, more experienced students, that crunch is pervasive, frighteningly common and just “how things are done” in our industry. At work I have also encountered a lot of talk of horror stories. That one company where people kept toothbrushes and shower gel in the work bathrooms. The many all-nighters you pulled on that one project ten years ago because of last minute errors and client wishes. We have also encountered our fair share of last minute panic. 

But there is an important difference. We have very competent and good team leaders who do their best to set realistic goals and deadlines. When we have to crunch, when overtime gets out of hand, they turn inward and discuss what they can do to prevent this from happening again. What to do so that we avoid crunch next time entirely. And then they turn to talk to us: Do we need a bigger team? Do we need a few extra days? Would it help if we had more and earlier check-in meetings? The answer is yes to all, and they work with us to find a good balance that doesn’t break the budget. Kudos. 

This active anti-crunch has become more comfortable to me. It has also taught me something important, after now finishing a few projects with strict deadlines on time, or even within half the time budget. Crunch is a symptom of failure. It is most often a failure of management. Not enough resources planned for the right phases of development. Not enough communication of expectations, goals and reasonings for decisions. Not enough availability when questions or even problems arise. Not enough oversight of juniors who are working directly with the database. 

Of course, there can also be technical or other failure. That app that doesn’t get approved and you have two weeks to make a scalable game from scratch. The git that suddenly self destructs and leaves you scrambling two days before the deadline. The junior who has been happily coding away at his first project and accidentally built a very delicate house of cards that gets blown over when the final feature is added less than 24 hours before launch. Oh and the said junior is unavailable and off on a business trip, leaving the team to try and scramble and fix the mess. No, that is not a suspiciously specific scenario, stop asking. 

Framing crunch as failure instead of as something worth being proud about really has changed my perception of the value of my own work. For my final project, the failure is on me. I needed a team or I needed to reduce scope. I was too stubborn and cheap to do either. My budget was literally 100€. My patient, lovely partner helped me with a bunch of 2D textures and character designs. I spent more than my budget on a proof reader for my thesis, since I knew that my professor could and would absolutely fail me or dock my grade if it was not formally flawless. Money well spent. This budget meant though that I needed to reduce scope – and I refused to. In fact, the scope went from about 20 min. game to more than double that during the year. I am an artist. I firmly believe that sometimes, our projects decide for us how long they will be. But scope comes at cost. It costs time or money. If it costs neither, it costs health. 

Whenever I hear a company (or sadly, usually devs) brag about how quick they are and how “our team crunched so hard and we brought the app out on time!”, I have realised it usually translates to “management exploited the workers to save money”. 

I am blessed that my company is against this kind of practice. 

So why am I writing about all this in a post-mortem instead of making this a Culture tagged post? 

Jamming

The worst contenders for encouraged or even enforced crunch that I have ever experienced were not my final project or at work, or any previous of my 10+ seasonal jobs I have held in my life. They have all been game jams. 

It takes time to make a game. It takes longer when you are new at it. It takes longest when you are bright eyed and bushy tailed and barely know what the difference between a public and a [SerializedField] private is. My first ever game jam was a 12 hour jam at university. It went from 6pm to 6am. I’d been to a 24 hour comic day jam before, where I had indeed drawn 24 full pages in shaded ink drawings in about 20 hours and slept three hours on an old couch in the corner. It was one of the best comic projects I ever made. The game jam was… well, it was a failure. I spent five hours getting help from everyone around to figure out how to make a 3D character move and then went home. Here, it was a technical failure. I was too inexperienced to make a game, I lacked technical know-how. Thankfully, it wasn’t graded and I hadn’t expected anything. I just wanted to go, eat some snacks and hang out with my friends. 

The next, to me notable, jams I participated in were three class-internal game jams. They were crunch free. I made Ascending, Home Invader, and The Missing Piece Makes it Right.  One of my favorite games I ever made, one of the more political games I’ve made and a game I quite liked but nobody cared about. Something they all have in common? Had at minimum a week to complete them and they all actually got done and had some level of polish to them. Home Invader in particular is a decently long game. They also all are 2D. Only one of them was made in Unity. They were successes, they were fun and they were still an intense race against the clock. The long deadline had the simple reason that we all were extremely busy, working, studying and having lives. It didn’t make sense to make a crunchy, strict deadline because nobody would be able to do anything. 

But then I left the safe little bubble of my university and got into my first external jam. And it was not just any jam. It was the bpb:game jam 2020: binär und mehr, a federally funded German jam about gender. I was a bit shocked when I applied and got in. But I was in for a very, very difficult 72 hours. The environment was trying to not be competetive, but they announced from the start that there would be an internal ranking. Group work was the default. I had to work through Shabbat, which wasn’t my favorite thing but what are you gonna do, right? 

I found myself in a group that just didn’t really have a good idea – and that was really lacking competency as a group. The individuals were all very talented and bright, but all together, we just struggled hard. Unfortunately I was too timid to really take control, as it was my first foray into the wilderness so to say. But because I could tell that my own ideas were not really finding their space, I ended up making my own game during lunch: Name Age Gender. This is my most reviewed, most viewed game I have ever made. A little purely text based Twine game that I made in an hour because I was frustrated over a failing jam. 

The next bpb game jam I again participated and this time, I was better prepared. I arrived with a set of 3D assets, some basic scripts and a vision. By the end of day one, I had a concept written out, presented it and found a team of amazing artists who loved the vision. I was the team leader and did a mixture of technical art and programming. It was a great success with a game we were all incredibly proud of: The Quarry. This was the project that convinced me to  seriously pursue game dev as my career. 

But do you know what I ascribe the success to? The fact that I was better prepared and a better manager this time. I took some control where it was needed, I pro-actively organised our team resources, I had brought a bucket full of assets to the table before the timer even began and I made sure that nobody was being over-exerted. It was a few long days, but we did not work through the night even once and I did not encourage anyone to do so. I heard some of the admin team softly discouraging crunch, but in the group chat I still saw plenty of people pulling all nighters to get their projects done. I too found myself humble bragging about staying up till midnight and then waking up at 6 am. But the only way to get this project scope done with less stress would have been more time. 

Why am I talking about these jams? 

Because this jam, the TGD birthday jam, did something I hadn’t really encountered before. 

Crunching was actually specifically forbidden. 

Making the Game

Roguelike

When I saw the topic for this jam, I immediately thought of the amazing indie game “Hades” and knew I wanted to make a roguelike or roguelite game. I have never made one, I had no idea how to make one, but having two weeks deadline meant I could actually use the jam to learn something. This alone made it all worth it to me. I love having an excuse to learn something new, constantly asking questions and eager to go the long way around with a task if it means that someone will sit down and teach me their way of doing it, or if it gives me time budget to try some stuff out. 

So after a nice, calm shabbat, I sat down, started up a tutorial video and got to jamming. I quickly realised that, after almost a year of working as a dev, I could quickly pick up on the logic at play here and decided to just take some of the knowledge for how to build up the UI and then take what I got and run with it. With the learnings of my past few jams, I set up some rules for myself: 

• It doesn’t have to be the greatest thing since sliced bread. It just has to be done. 
• I want it to be a roguelike-ish game.
• I want it to be an abstracted journey about being trans and dealing with medical/social gate keeping.
• I want it to be about how anger and burning bridges/relationships can get you through life, but patience preserves more friendships.
• I want it to be about the necessity of community to thrive. 
• I want it to be a 2D Unity game. 
• I want to work from scratch: no re-using old assets of mine. 
• Done is better than pretty: I don’t intend to work on it after submission, so I am allowed to use occasional bad practices and hardcode some stuff that really shouldn’t be hard coded. 
• I want the protagonist to be a fire elemental. 
• No crunch.

At my day job, I had literally just finished two projects in half the time that was allotted to them, so I felt confident I could do this. I also had just gotten home after being a carer for my ailing mother for a month, so I knew I would have the time but would be a bit emotionally preoccupied. 

I started simple. I had a concept, I drew up the protagonist and started to code. Concept was simple: fire hair that goes glowing blue when you attack and simmers down when you defend. First get the character moving. Then add sprite animations. Then add a simple AoE attack and defence (at this point, both were literally just a circle). Then add an enemy. Write up some UI logic. And then it was time for bed. 

Next day. This Sunday was earmarked just for development. I had breakfast with my roommates and sat down to start working in the early afternoon. Enemies could now take and give damage. One day I will write out an OnCollision Event and it will work without going back and forth 20 times with colliders, triggers and rigidbodies. Today is not that day. I added different enemy movement patterns. After I initially could not figure out a glitch with that code (I swapped a rotation with a position value), I turned it into a feature. Originally I thought I wanted the enemies to be people. But then I turned them into projectiles instead that the people hurled at you. Make it simple: the projectiles spawn in when you hit a trigger. There are four different movement patterns that all differentiate by just a few lines of code. Then came the pickups. Health and time aka “patience”. Or as I called them in-game: tokens. My initial concept was beginning to flesh out. I had the idea that you  walk into a dungeon aka room and there is a character there. This character “attacks” and you have two options. Defeat all the projectiles with attacks – then the character leaves and doesn’t show up to support you in the last screen. Or take the longer, more difficult route of defending and collecting all tokens. Then the character stays. Either way, defeating all enemies or collecting all tokens (which is tracked via a simple list at level loading and then an int is updated every time you defeat an enemy or collect a token) makes the gate disappear and you can proceed. You can never go back unless you fail and have to start over. 

With this logic, there are two possible main outcomes: a faster playthrough where you burn bridges and a slower one where you keep supporters. 

On the coding side: I ended up making a script that carries between scenes that called RelevantDataRL. It is literally just a bunch of static public fields like total health, total time and which characters were scared away and which stayed. 

Ludonarratology

Record scratch – wait a minute. What exactly is the story I am telling? 

At this point, I took a break, went away from my desk and had some ice cream while I contemplated my design. Ludology and narrative are often discussed in the context of dissonance: when you are trying to say one thing but your game is telling another story through the mechanics and set dressing. So I always try to keep myself cognizant of what I am trying to say, fully aware that the story my audience will receive and the story I was trying to tell are two different things. 

So what was I trying to tell? 

I wanted to talk about gender. The topic was wrath. A lot of my anger around gender comes when I encounter people who refuse to believe or tolerate me. Especially if they give me some nonsense about how they know better what my gender is. I am too young to know what is right or wrong. I am rude for expecting basic decency. And I really “like” those who try to argue with me about biological sex without even understanding that biologically, sex is not just one factor but an accumulation of factors. Medically and biologically, our best bet of knowing what someone is, is to ask them. 

Gate keeping is a concept that goes beyond just gender stuff. Someone might make a definition up in their head and try to exclude you in your hobby (“real knitters use wool and wooden needles and have callouses on their fingers, you casual”), your profession (“real devs live off of coffee, energy drinks and 2 hours of sleep, you casual”) or really anything. Even words can be gate kept (“you can’t call yourself bi if you date someone of the opposite sex, you hetero”). It is bad enough when people try to exclude you and you just deal with the stress. It becomes a big issue when they succeed in excluding you. This is a big point of failure and overcoming gatekeeping is extremely difficult. The exact circumstances are essential for navigating out of the situation. 

You can brute force your way through by getting loud, complaining up the chain of command, intimidating… Sometimes you find or pay people to back you up. Often with enough time, persistence and patience you can also get through to someone and get them to let you in/through. 

Brute forcing your way through leaves people hurt. Sometimes people who didn’t really want to gate keep you in the first place. But not everyone will be persuaded with time and patience. Besides, you only have so much time to get things recognised/processed/done. Your life is finite, your patience is too. I am not sure how to adequately reflect the fact that sometimes, it is the better choice to brute force your way through. Sometimes you really just cannot wait. Some people cannot be educated because they genuinely don’t want to be. Some people just hate me and everything I stand for because I am how I am and live how I live. I cannot set myself on fire to keep others warm and I cannot pour from an empty vessel – if I burn myself out under constant pressure, assault and abuse, there won’t be much left of me. I cannot crunch my way through life, or I will pay with my health. 

And frankly, some people don’t deserve the time of day. 

So what is my story saying?

I don’t know what my story is telling you, unless you tell me of course. But my hope was to reward both paths in their own way. If you brute force it, people run away and you have less support, but you get through quicker. If you take it slow with patience, people show up for you down the road, giving emotional support. It doesn’t really count in the fact that some people are impossible to please but I hope that it does give a grim but accurate depiction of the choice we have to make. Burn a bridge or mend it? 

Ultimately, you can play this game and win it in a minute. It’s not that deep. But maybe it is. 

Bugs

Oh the bugs. Oh lord, the bugs. I went to bed on Sunday, telling myself all that was missing was some polishing. It was the minimal viable product as was and I did not want to add more levels. I touched it for an hour here or there during the week, hunting down the endless  array of bugs, finally deciding to make a tutorial. Now, a wise person once told me that if you don’t design from the start with the tutorial in mind and make the tutorial early, it will be rushed. They are still right. One of the nice things of not being allowed to crunch though was that, when I couldn’t figure out how to make the tutorial, I could step away for a day and then come back. I did in the meantime make some particle effects, wrote some music and edited the attack and defence. 

It still was the second Sunday before I finally had the idea to put Sunflower in the game. She is your girlfriend and she gives you support and love. Her level is green and friendly. The idea with the letter came around the same time. You got a letter, now you must go on your journey to your appointment. Oh how about it’s your letter that you have an appointment to get a hormone prescription? I thought that was nifty. So the game begins, you’re on the letter, your girlfriend introduces you to the mechanics. After a lot of trial and error, I decided  to just have her give you love and take down the gate. You can leave that first area without touching a single collectable. Your partner should not gate keep you, after all. 

From that, I also finally added a few important scenes: a game over and a won game screen. When you take too much damage, your girlfriend comforts you. Your fire has gone out. You need to recharge and start over. Narrative wise, this means you dealt with so much crap from people, you completely abandoned the process. Thankfully it’s a game. You can play however often you like and just try again and again. 

At this point the healing items were broken so I spent too long fixing them again. 

Now there was also the won game scene, where you are back home but with a little Rx bag. Implied prescription of hormones, yay! Finally, once you have won the game, you can also play again. 

Funny enough, despite the timer being one of the first things I implemented in the code, it was the last thing that I put in at the end scene. 

Go through it all and then playtest it half a dozen times until I just couldn’t stand to look at it or hear it anymore. I made a build, played it twice in itch.io and then submitted it. 

Retrospect 

In Lieu of Crunch

All in all, I spent maybe 30 hours making the game in total, in active development time. From idea to submission. That is about as much time as I’d invested in weekend game jams too. But this time, I was very relaxed through the entire process (well, except that one time when I thought I deleted my character controller script by accident). I could function, work, have a life and discuss the game as I made it with my friends and colleagues. I learned a lot in these 30 hours and I had a fun time. I did not have more time than these 30 hours (currently writing this log during my lunch hour at work) so the scope was juuuust right. 

I did not need to race the clock. In fact, I finished five days before deadline. But that is not a bad thing, or a sign that the deadline was too loose, or the scope too small. I think that a project finished a few days before deadline is a success. It is a project that has time to be actually tested, put through QA and get feedback on. A project that was reasonably scoped and accurately estimated. There was no exploitation, just a fun challenge. I still made a multi-leveled roguelike game with some narrative depth in two weeks. Is it very basic? Oh yeah. Is the fighting mechanic not great? Jupp. But those are issues coming from inexperience and deliberate scope decisions. I was considering adding some more sophisticated fighting mechanics, but I decided to save that for the next jam. 

So what would I change? 

Bettering

I wish I had more experience with making cool fighting mechanics, so I will take all my learnings from this one and carry them over to the next jam. 

I personally cannot stand the art direction I chose for the jam. I think it’s ugly. But I went with it anyway because it is interesting and very different than my usual style. I don’t really go for this kind of style often and I don’t intend to use it again any time soon. This was a good challenge but if I had to do it again, I’d probably go for something like pixel art or a more clean, cartoony style. 

I could actually increase the scope a little bit next time. Perhaps more animations could be fun. I will be faster next time since I will already know how to build the system and can focus on learning new other things, as well as adding more visual polish. 

Yeah, that’s… kind of it. 

My conclusion is that this was a great, fun jam and I really enjoyed it. It challenged me technically, artistically and design wise. It made me think about my own feelings and challenges and encouraged me to reflect on how I interact with the world around me as a creator, an artist and as a trans person. 

If I had been tempted to crunch, I probably would have and I would have suffered for it, as well as the game. Crunching would have not given anything to the project, it would have only subtracted. 

I doubt anyone will bother reading this monster of a post. But if you did: thank you for your time. Thank you for reading my rambles. It was a lot about crunch culture.