There was another game jam week at my studio, Doborog! These regular game jams are my favorite job perk.
Our studio game jams are whatever we make of it. The five days are self-directed. We can build a game, work on a side quest for an existing Doborog project, or learn a new development skill, just so long as what we do enriches ourselves and/or the company in some way. Erik, our creative director, argues enriching ourselves benefits the studio, because we have a more talented workforce.
At the jam kickoff, we’re expected to discuss an idea or two about how we’ll use the time. I pitched two ideas…
The first was a productivity game, because I’m always thinking about ways to make a to-do list fun. We use a service called Asana to organize our studio’s tasks. My idea was to design a turn-based RPG that connected to Asana, so actions like fighting and magic could be powered by checking off items in Asana. Erik worried a hastily made game prototype could accidentally screw-up our Asana board, which would be a net negative result for a game jam. Scratch that idea off the list!
The second was a game to test out a broad design concept that’s been rattling around in my head. Many narrative game genres, such as visual novels or Choose Your Own Adventures, use what I call a “stop-and-go” rhythm of interactivity. The player stops interacting to read pre-written text, then gets to interact by making a single choice. Compare that to most non-narrative-focused games, which give players an on-screen character to move any direction they like at anytime via a gamepad. Constant interactivity! Players love that! Some narrative game genres adapted to this by giving the player a constantly moveable character, like the narrative platformer Night in the Woods, or most point-and-click adventure games.
I had an idea for a different rhythm of agency. Lately, I’ve been thinking about the homemade marble run my dad built for my sister Holly and I when we were kids. We used to love putting a marble at the top of the run and watching it bounce off nails, wooden blocks, and spinners my dad hammered to the wooden board. It was fun to watch the consequences of our actions play out in surprising ways, like putting in too many marbles and watching them all get stuck in the funnel then leaving to watch TV.
So my experimental concept was: What about a game where you make a bunch of choices at the beginning, then sit back and watch them all play out? You wouldn’t have a herky-jerky, “stop-and-go” rhythm of interactivity. At first, you would go, go, go, then you would stop and watch all those marbles bounce through the run. I pitched it to the company as a puzzle game set on a space station, where you had to come up with the safety procedure to save as many lives as possible during an attack. Since we’re developing a space exploration game right now, this felt like the setting to explore for the jam. Erik thought so, too.
Normally, I do a lot of planning for a game project. I write a game design doc, draw UI screens, and do research. It’s my training as a writer coming to the forefront. If you don’t outline your project, and know how it ends, you risk getting to the middle of the story and being stumped. This happened in my earliest attempts at screenwriting, before I knew how to outline properly. But I’ve noticed Erik has a different approach to game design. He feels it out as he goes. He builds a spaceship to see how it feels to operate one. Then he builds a gateway and sees how it feels to teleport across the galaxy. The game’s core loop isn’t the immediate focus, though he knows he needs to get there eventually. The pre-conceived idea for the loop might change based on what feels best!
So I figured, as long as I was experimenting, I might as well try developing Erik’s way. He’s a more experienced game programmer. I might learn something from his approach. I would feel out the project, rather than create the core loop and work outward from there.
This would be my first time using GDevelop to complete a game project, rather than Unity. I was excited, but a little nervous. If GDevelop turned out to have hidden complexities that stumped me, I would come away from the week empty handed. I really wanted to make something that resembled a complete game, as I had with the first two jams.
I began by doing some research. What are safety protocols used in real emergency situations? What are things you should never do? I translated real life specifics into space stuff to create my list of protocols. Next, I tackled the branches for each chosen protocol. I wrote the outcome text in Ink, my reliable scripting language for games with branching dialogue. I used it all the time for Adventure Snack. As I was writing, I thought about how one protocol might affect the next. If the player didn’t charge the escape pods, for example, then that needed to be acknowledged when the player tried to launch the escape pods. Some protocols were very simple to branch, but others had seven or eight branches depending on choices made before. It got pretty complex, but I was able to feel it out, more or less. Sometimes I had to revisit a protocol I’d already written to add another branch to it, but I had a good handle on it overall.
When I created a new project in GDevelop, I started with the aesthetic. I wanted the game to have a classic shareware feel, so I made buttons, backgrounds, and color choices based on 16-bit Mac games. Happy with the look, I made a simple title screen as a test, titling the game Space Station Self-Destruct Simulator (SSSDS 🐍). Everything worked as expected. Very easy to put together.
The introduction screen drew text from the Ink file. I knew GDevelop had an extension to connect with Ink, but I needed to test it. Ink integration worked reasonably well, but I wouldn’t call it plug-and-play. I referred to the extension’s documentation a lot to get the hang of the logic. Some aspects of the integration I cheesed to make work. I know it wasn’t optimal code, but ultimately, it did what it was supposed to do. As I understand it, setting up Ink with Unity is a chore. I’d estimate I got 80% of the way to fully making it work in GDevelop? A layup, not a slam dunk.
The next screen was the ordering of the protocols. I wanted to make something similar to Motion Picture to see if it’d be easier in GDevelop to make a bunch of drag and drop game objects that lock into slots. No question, GDevelop was easier than Unity. There was no code to make an object draggable in GDevelop, just a single box to press. The logic for what to do if the player dropped the object in the wrong place was written in English, not secret math speak. I can’t understand more than half my code for Motion Picture, but I completely understand my code for SSSDS. Almost all the code is on a single screen, the Event Sheet, where the left side are the IF statements and the right side are the THEN actions.
I did run into one problem though. I noticed that the draggable object could be dropped onto an object of the same type and they would stack! Gasp! That’s not the behavior I wanted. The object was supposed to snap back to the previous spot rather than stack. How unseemly! The problem was GDevelop’s logic. In GDevelop, all the objects are grouped together as a type. So if I write, “IF you drop the Protocol Block onto Home Space, THEN make Quack sound,” it’ll totally get that. Anytime a Protocol Block is dragged onto a Home Space, it’ll quack like a duck anticipating fancy bread at the pond. But if I write, “IF you drop Protocol Block onto Protocol Block, THEN make Quack sound,” it won’t work, because it’s like, “How can Protocol Block drop onto Protocol Block? How do you drop something onto itself? You’re so weird, Geoffrey!” This was the nut I had most difficulty cracking.
But I figured out a solution! I made it so when you picked up a Protocol Block, it created an invisible “shield” object over every other Protocol Block. Then I said it couldn’t land on the shield. That worked! It was a tricky problem, but I was pumped my fist like the kid in that ancient meme when it worked.
The last screen was the results screen. I was able to get GDevelop to draw out the correct scenes from the Ink file decently well, but I did have trouble reading the variables in the Ink file. I found it easier to just re-create them in engine and do more of the gameplay logic stuff there, and use the Ink file more as a text database with some branching. For future projects, I might experiment with Yarn Spinner, which is natively integrated with GDevelop and is similar to Ink.
One of my favorite additions to this screen was adding some goofy UI elements. Originally, the screen was going to be text only, but I was inspired to add a color light that says whether what happened was good or bad, a battery meter to show how charged the escape pods got, and a running counter of living crew. The visual elements brought the experience to life for me. Even if you were glancing the text, hearing the negative tone and seeing the red light again and again told the story of your choices. Your marble left the run and rolled under the sofa. It felt right.
The feedback I got on the project was overall positive. Unlike my first game jam, which got no comments from the team when I posted it on Slack, this one inspired several colleagues to try it and post their results screens. Our marketing lead Josh posted a video about the game on Doborog’s TikTok with highlights from my co-workers projects. (I’m the only one who finished a game. Many of my co-workers experimented using new tools for art, coding and music composition.) Gwen said it showed a leap forward for me as a solo designer. And thank you to reader Elly for trying to play the game on iPad (which didn’t work due to the screen resolution) and on mobile (which surprisingly kinda worked). Even though the game was not designed for mobile, Elly still enjoyed the design.
💥 Play Space Station Self-Destruct Simulator here! 💥
Overall, I’m very happy with how SSSDS came out – and the design process as a whole. Feeling out the design piece by piece led to good choices, particularly the UI and visual elements. On a large scale project, I would do more prep, but the approach worked well for me to execute a small prototype or jam.
Coding is about solving tricky logic challenges. But I never felt overwhelmed by my lack of development experience on this project, which was regularly the case with Unity. There were frustrating bits, sure, but I found clever solutions and made it work. I never felt like I was going to self-destruct.
🎲 Your Turn: What project are you currently working on? What’s your biggest challenge with it? Have you thought of any creative solutions? I’d love to know! Reply to this email or leave a comment by slammin’ the orange button below.