What I Learned at Global Game Jam 2019 in Bari

Our game began with the idea of searching for home—not only as a physical shelter, but as a place where the mind can feel in harmony. The player starts in an unfamiliar land whose sounds and inhabitants are difficult to understand. Through exploration and conversation, new languages become familiar and the world gradually becomes clearer.

This was my first Global Game Jam, and it felt different from the competitive hackathons I had attended before.

The best part: it was not a competition

I have always valued competition. It can reveal our limits, push us beyond them, and give a project the energy that makes hard work enjoyable. It was one of the reasons I joined hackathons.

The Global Game Jam, however, is deliberately non-competitive. That made the experience more exciting in several ways.

Knowledge moved between teams

Our sound designer and 2D artist sometimes helped other groups that were missing those skills. I also sat with other teams, partly out of curiosity and partly to offer advice when they were stuck on an implementation detail.

I had rarely seen that happen at competitive hackathons. Without that exchange, an event loses one of its greatest benefits: the technical and human knowledge we take home.

There was no jury to impress

Competitive events often evaluate teams through a five-minute pitch covering the problem, value proposition, business model, competitors, and prototype. The result can feel like trying to invent a start-up in 48 hours, even though a short pitch cannot capture the quality of all the work behind it.

That exercise can be useful if the goal is to develop a business. At a game jam, I mainly want to experiment, express an idea, and build something enjoyable with people who bring different skills. Without a jury, we could focus on creativity rather than the financial ecosystem around a weekend prototype.

The projects were open

The Global Game Jam site made it possible to explore games from around the world. Teams were also encouraged to release their source code, so anyone fascinated by a particular mechanic could study how it had been implemented. That openness reinforced the exchange of knowledge beyond the room itself.

Mistakes worth remembering

Several problems we encountered also appear in ordinary product work. Writing them down makes them easier to recognise next time.

Define the boundaries immediately

The most dangerous mistake is not simply attempting too much; it is investing in secondary details before the team has agreed on the final experience. An animator or environment artist can understandably polish work that later has no place in the playable prototype. The result is last-minute confusion, bottlenecks, discarded work, and a weaker demo.

My advice is to spend the first evening with the whole team, brainstorming with pen and paper. Draw the beginning and end of the smallest complete demo, including the gameplay, setting, required animations, soundtrack length, and other constraints.

That shared picture makes it easier to simplify, expose dependencies, and decide what does not need to be built. It also leaves room to experiment, rest, and enjoy the event.

Our own mistake was planning two levels without agreeing on their size. We ended up with two enormous spaces and had to debate which empty areas to remove and where to add interaction so the experience would not become boring.

Keep comparing progress

After brainstorming, people often retreat into their specialist roles. They stop discussing difficulties and do not surface the simplifications that could still be made. That may happen because strangers feel awkward with one another, or because everyone naturally concentrates on the work they enjoy most.

Walk around. Look at your teammates' progress, show them your own, ask how things are going, and resolve ambiguity while it is still inexpensive.

Sleep

At earlier hackathons I would return home exhausted and feel the effect for the rest of the week. This time I made a rule: sleep. Fatigue is often connected to uncontrolled scope. One well-finished half-level would have delivered the same idea as our two oversized levels, with better quality and more rest for everyone.

Tight constraints create space for the unexpected. They also make it much more likely that you will want to attend the next event.

Try something unfamiliar

At many hackathons I found myself doing exactly the same work I did every day, perhaps to prove my value or to feel immediately useful. This time I chose a technology I had never used before. The final product matters, but the knowledge we bring home can matter even more.

For me, that meant experimenting with Unreal after years of working with Unity. Pair programming helped me learn quickly without blocking the rest of the team.

Closing thoughts

Global Game Jam succeeded at creating an event for play, creativity, and shared learning. The prototype was only one outcome. The more lasting result was a better understanding of scope, collaboration, rest, and the value of trying something new.