iTroubled is a game where you play as Maurice Moss (The IT Crowd), running around the office fixing issues. Pick up an item, deliver it to the appropriate problem and score the most before the time runs out.

Play the game

GitHub Itch.io Global Game Jam 2020

Two friends and I developed it in 48 hours for the Global Game Jam 2020, which theme was “Repair”. We used GDevelop as the engine and not a single line of code. It won 2^nd place from popular judge in the venue where we participated (University of Malta’s Institute of Digital Games).

Myself and my teammates Renan Lopes and Jeanluc Zammit.

The key to get second place by popular vote in the venue was fun and simplicity. In the continuation of this post, I will share some of what we did to achieve that.

We had a well-mixed team

The configuration of the team will define what it can produce (mobile, console, computer, card, board games, etc.). Our team was a mix of development, game engine, arts and music skills, plus a shared interest for arcade/casual games.

A good team is cross-functional. Team members can be developers, designers, writers, musicians, artists, or others. Of course, the player won’t care for the team configuration as long as the game delivers a good experience.

There was no bad idea - execution is what counts

In our game, you fix fire with a fire extinguisher and virus with a floppy disk (which is ok). However, “internet down” is a broken wifi symbol (on a desktop, really?), fixed with an “Internet Explorer” item (????). Whatever ¯\_(ツ)_/¯

Never reject ideas, focus on creating fun.

Working with what we had

We had no experience with fashion engines like Unity, Unreal or Godot in our team.

I knew a bit about GDevelop. It was easy for the rest of the team to get its gist. Since it is block-oriented, the !Coding GameJam diversifier came as a bonus (see a sample screen below).

I already had some animations for Moss that I made for another project; they gave us a head start for graphics:

K.I.S.S.: Keep it simple, stupid

We went with a casual style where one could play a quick round without commitment to extra levels or a steep learning curve.

The winning criteria was straightforward: score the most within the timebox (45 seconds).

As the dealine approached, we started to give up style concerns to prioritise having something playable. This is the reason why the sprites of the floppy disk, the Internet Explorer and the coffee cup look shit a bit antialiased and off the rest of the graphics. We got some usable stuff from google images, resized them and did minor to no retouches.

These (“properly drawn” sprites) look much sharper than these: (slapdash solutions).

Also, the game controls were ridiculously simple: arrows only

Always think “Can I achieve it with less?".

Taking care of body and mind

Rest, go home for a shower, eat, take breaks. Contribute to a well functioning mind. Burn yourself out and stress will kick in, taking the focus and the fun away (then you’d rather chill at home instead of waste a weekend).

We took breaks for lunch, dinner, as well as small ones for coffe. They were good opportunities to get creative, come up with ideas and bond.

Gathering feedback as soon as possible

The theme “Repair” was announced on Friday at 18:00. The deadline for submission was Sunday at 18:00 and we wanted to have something playable around 24 hours before that. By Saturday late evening we had a single game screen with minimal graphics, two “playable problems” (fire and broken computer), and raw score counters.

With this version, we managed to get feedback from other jammers that helped to narrow our focus moving forward.

Planing to ensure something playable

A mediocre playable game is more fun than a beautiful unplayable one.

Saturday 23:00 we stopped all we were doing, to came up with a plan to deliver a good experience within our time limitation:

1. We set a internal deadline (16:00) before the actual dedadline (18:00), to play safe.
2. We wrote on sticky notes all the features that were missing.
3. Discussing as a team, we sorted these remaining features from most to least valuable (considering value = fun)
4. We idenitified milestones along this roadmap of features. They were:
   • Gameplay: A bare minimal version that people could have some fun playing.
   • Full game: A presenable version with and end-to-end experience (intro, game, final screen, missing animations and a “coffee power-up”).
   • Internet: A 3^rd problem for Moss to fix (internet down) and make the game more rich.
   • Music: Backgroud music for improved atmosphere.

Staying mindful of time

For each feature (sticky note) to start, we discussed what approach to take considering the time remaining. When we reached the last one, the music, we were very close to the end and composing something was out of question, but Jeanluc had a tune by himself that with some tweaks became loopable.

At the end, we managed to deploy at 16:24 (24 minutes past our internal deadline, 01:36h ahead the main one).

Fun was the ultimate goal (beyond developing a game)

After the submissions deadline, there was the “Arcade” time (a “show-and-tell” of the games built in the venue, for jammers and visitors to play). We used the remaining time to organised a mini-tournament in our game station:

Some findings from the “tournament station” experiment:

• The end screen did not show an overall score and it was not a problem. People would just sum up subtotals (fire + virus + wifi solved).
• People were queueing to play: apparently, having short rounds made it easy to wait for one’s turn on the game.
• The players' competitiveness became a game element: people were challenging each other’s scores and proudly writing a stick note themselves when beating it.