My first GameJam

Last year I’ve decided that I want to switch and make games as a full time Indie Developer ?? Besides of prototyping different ideas, one of the starting points for me was Game Jams.

Here I’ll describe my first time participating in Game Jam, and what I get from it.

This will be a longread. The final result can be found here: mozokevgen.itch.io/repair-unit-01.

Preconditions

Working on your own game prototype begins with a passion for the idea and a desire to do as much as possible at once. However, in the process, the excitement subsides and the inner critic wakes up and begins to question every decision you make. Development drags on, you always want to add something more. Not everything works out as planned. Bugs are piling up and routine covers previous enthusiasm.

There is a clear desire to finish and release the project. And this is where Game Jams come to the rescue.

Looking through the calendar at indiegamejams.com and itch.io/jams I came across a jam for beginners. And without thinking for a long time, I took part — itch.io/...ie-game-dev-beginners-003. While I was writing this post, the jam disappeared from itch.io ??

The idea is to do everything yourself. Go through the entire development cycle, make a release, collect feedback and adjust accordingly.

Development

Day 1. Theme of the jam: Robots

Realizing that I had little time, I had a full-time job and I was inexperienced in game development, I had to limit the scope of tasks.

I once had an idea for a post-apocalyptic RPG about robots. The idea remained at the stage of a three-paragraph text description. It's unrealistic to implement an entire RPG in a week, but one of the mechanics was recharging and saving the battery while moving. So why not implement it in isolation at one closed level?

So we have: movement, top-down view, and battery recharging. Next, we need to come up with a goal.

What can a robot do? Move around, scan something, move its manipulators... After several iterations, I came to the keyword "Repair". So what happens if we play as a repair robot?

Next, the setting. I didn't really stick to the previous idea of the post-apocalypse. But I decided to make a small, limited level, somewhere "at the station". This way I could clearly define the gameplay, minimize the size of development, and potential bugs. What kind of station are we in? I decided not to explain, so that there would be a little mystery.

Next question: How exactly are we going to repair?

Abstract thoughts about repair are checking the operation of the device according to the schematic. If any elements do not work, we replace them with the appropriate tools.

Once I had another prototype and there was a mechanic for moving objects from the "inventory" to the "playing field". So why not add a check of the items placed on the field according to the template? And we will get such a primitive repair. Since repairs need to be done with different tools, the robot should have a choice of tools, in addition to the inventory. And here, too, I had to limit myself in order to fit in the development time. So I put aside thoughts of soldering irons, screwdrivers and other wrenches…

All these restrictions began to feel like an additional incentive for creativity. Because you want to make something interesting and worthy in a small volume, and with a minimum of tools. And you want it to be playable and interesting. And for this you have to try harder ??

? After a few iterations, I came up with the following look:

• The robot has an inventory that contains elements/spares. For simplicity, they will only be numbered 1, 2, 3, 4.
• The robot has three tools to choose from. Again, for simplicity, they will be color coded — red, blue, green.
• For repairs, we will have a "field" where you can place elements from the inventory.
• For each device that needs to be repaired, there should be a diagram. It shows in a simplified way which tool should be used to place which element on the field.

? Refused to:

• A detailed list of elements: resistors, transistors, microcircuits, etc.
• The robot has two manipulators. One is for placing elements. The second is for tools.
• Complex schemes built on many elements.

This description was not received immediately. I returned to it several times in the process of designing other parts.

Next, we need to decide what exactly we will repair and how we will move around.

The robot travels around the level, finds non-working devices, finds spare parts and circuits, charges at stations... This seems like a lot for a week of work. So let's just repair the charging stations. And we'll find spare parts and schematics in conditional "boxes".

Several layouts on paper.

Level:

This is where the idea of closed doors and the need to repair them in search of resources came in. Then it turned into the following mechanics: repairing the stations would open the corresponding passages/doors. But only one door and three stations made it to the final.

Repair mini-game:

Implementation starts

So now we need to move on to the implementation in the engine. My choice some time ago settled on defold.com.

I started with a minimal structure for switching screens. To do this, I used this extension https://defold.com/assets/monarch/. I also connected the library for processing inputs https://defold.com/assets/defoldinput/.

I made a start screen with a start button. And put together a simple scene with movement. Added a charging station for interaction.

There should be a screenshot of a gray button on a black screen, a blue circle and a yellow square. But I didn't take it, so I'm just describing it ??

It's time to think about graphics. I won't have time to draw everything myself, so I need to find free assets that will suit me. And that's where these materials came in https://kenney.nl/assets.

I built a primitive level with movement:

At this stage, we have:

• Start menu with a start button.
• One scene with a level.
• On the level there is a room with walls and one corridor.
• A robot that can be controlled with WASD. The robot does not move at a constant speed, but has an acceleration of 100 dt, dt is the time since the last frame. The maximum speed is 400 dt.
• The robot has a battery charge. Just a number from 0 to 10. As you move, the charge decreases. For every 2 seconds of movement, the charge decreases by one.
• There is a charging station in the room. It can be working or not.
• The robot interacts with the station by approaching it.
• If the station is working, the robot starts charging. Every 2 seconds, the charge increases by one.
• If the station is not working, a screen with the corresponding mini-game is called up.

In the mini-game, we select a tool and move the elements:

On the left is the field where you want to place the parts. In the center is an inventory with parts and a choice of tools (red, green, blue). On the right is a diagram that you need to repeat when placing elements on the field.

The repair mini-game still consists of gray squares on a black background. While searching for sci-fi assets, I came across a great pixel art https://opengameart.org/content/190-pixel-art-assets-sci-fi-forest. From the very beginning I wanted to have such graphics. And I thought that Kenney's assets would be temporary. But there is nothing more permanent than temporary solutions :) The new assets are less bright and have a mystery vibe.

So for the repair mini-game, I’ve started to assemble the scene in a slightly different style.

Background:

From several different images, I assembled a robot for a mini-game and a charging station that needs to be repaired. I've given up on any animations for now.

These assets also went through several iterations until they got the current look. At the beginning, all the objects and the background looked very noisy and hard to see. So I also reduced the saturation of the background. On the contrary, I increased the saturation of the objects on the stage and made an additional outline.

Here you could find a GIF of the mini-game: https://twitter.com/mozokevgen/status/1642210819143266304

Next, I reassembled the main character - I took the existing one as a shape, but "painted" it in accordance with the new pixel art assets.

The mini-game turned out to be quite simple. To make the whole demo a challenge, I decided to place the first charging stations far enough apart. And to repair the second station, you still need to pick up the spare parts from the box next to it. So a full charge should be enough to drive to the box and from there straight to the charging station.

Then I wanted to give the player several paths and confuse him a bit. So we have two corridors and several boxes. Here I also decided to lure the player a little bit. Two boxes are placed not far from each other. As you approach one, you will see the other. But if you try to collect two at once, the battery charge is not enough. So you have to collect the boxes separately.

I also added a door that opens after the second charging station is repaired and makes it possible to move between rooms.

This is what part of the level looks like:

It was day 3 or 4.

It was time to add audio. While I have enough experience in programming, and I've tried to work with graphics before, I was far from digital audio. So Kenney and its assets https://www.kenney.nl/assets/category:Audio came in handy again. From them it was possible to collect the sounds of driving, clicks, hitting the wall, charging, etc.

Do you remember that mystery vibe? I still need a background soundtrack for it. This is where https://gdc.sonniss.com/ came in handy. By searching for "sci-fi" and "mystery", I found several tracks that, when played simultaneously, combine into an ambient soundtrack in the background.

But the tracks have too high a bitrate, Defold has a 16bit limit and a sampling rate of 44'100. And one of the tracks had a not very pleasant and rather loud "squeak". It was too distracting for background music. So, remembering what I had heard about Audacity, I went to figure out how to fix it. This is where I got a glimpse into the world of audio work, and I felt like I was debugging the sound ??

https://twitter.com/mozokevgen/status/1642896550513836035

In result: https://soundcloud.com/velias-1/sets/repair-unit-01-background/s-wY8oFqouGx4

Let's continue with the level design. I placed the third charging station as far away as possible in another part of the level. To repair it, you need to collect spare parts and a circuit from two "treaky" boxes. I spent some time testing the distances between all the objects in the level and changing the shapes of the corridors between them. I wasn't satisfied with the complexity yet.

When I was thinking about the gameplay, I spent more time on the repair mini-game and thought about making it the "main mode". But now I realized that most of the game time is spent on moving around, making a route, and calculating the battery reserve. So the repair turned out to be a secondary mechanic.

The first working prototype took 5 days to complete. At this stage, we can move around, interact with charging stations, and repair them.

I wanted this little story to look complete. So after the third charging station, I added a "scenario hook" that should give a boost to imagination and thoughts on the topic: "What is happening here and what will happen next."

Release & Feedback

I've bundled an HTML5 project so that anyone could run it on anything.

It was quite easy to upload a game to itch.io. The process is quite straightforward and clear.

I’ve sent it to my friends to play.

And then the feedback began…

First of all, nothing is clear :)) What to do, where to go, and what's the point of all this?

So I added some hints and text messages to the level. But who reads them? So I added visual elements to draw attention to the key.

The next wish was mobile controls. I was testing everything from my laptop, and most people started to open it from their phones) So I hastily added mobile controls. It was good that the connected earlier input library had a module for a virtual joystick.

Another wish expressed by the majority was to reduce the complexity. Some people couldn't even get to the second charging station, which I thought was not too difficult…

I resisted this wish at first. Because this part of the game was designed to be difficult. So at first I increased the battery charge speed so that players wouldn't have to wait long between attempts to complete a level.

But a thought crept in: perhaps those who play at the jam will get the impression that the game is simply broken. So I added a mode switch to the first screen of the menu. In simple mode, the battery charge is increased by 20%. What I didn't do was add a hint in the game itself that it was possible to switch to this mode ?? And then, during the voting, I received comments that people could not complete the game.

The list of comments was longer than these three points, for which I am grateful. I was glad that my friends took this demo seriously and everyone did some analysis of what was missing.

Over the past day and a half, I've made additional improvements, and it would be a bit of a stretch to call it "polishing.":

• I added a simple stopwatch that counts how long it took to complete the entire level. The time is displayed at the end and on the menu screen. During subsequent passages, the stopwatch is displayed at the top of the screen. I suppose this can motivate you to go through it again to improve your time.
• I added time saving, so now you can go back and replay the game. Instead of playing only continuously.
• Added a primitive vignette on the edges of the screen.
• Partially finalized the interface elements.
• Added some minimal animations.

As a result, we have:

The game was made on time. Submitted to the Game Jam list.

Then we just wait for the results. And also playing a lot of projects from other developers. And then the Impostor syndrome kicks in, because some of the projects were really, really good. For example, my personal favorite https://unpseudototalementnormal.itch.io/head-switch.

After the voting stage, my game took 21st place. I wasn't completely satisfied with the result, but it was pretty good for the first time ??

As a conclusion:

It was a very interesting and rewarding experience. As a result, I went through the full development cycle and released my first demo for my first Game Jam.

I also haven't had so much fun just programming for a long time!

What was good:

• A small project scope.
• More restrictions - more creativity.
• Take pieces of old ideas.
• Hold playtests among friends before the deadline.

What was bad:

• I didn't spend enough time on pen-and-paper.
• Need to test all main mechanics before going for the art.
• Not enough hints for the player.
• Less text, more showing.
• An estimate of what the player's time is spent on and what will be the main mechanic.
• I need more experience in using tools (game engine, graphics, audio).
• Take screenshots in the process to add them to the blog to dilute the solid canvas of text.

P.S.: during last year I've participated in three more Game Jams. I'll describe my experience in next articles.