Game Design, Free to Play and Mobile Games

5 Lessons learned from our Hackathon project

I consider myself a big fan of Game Jams. I attended many of them during the last few years and tried different roles – from the solo developer, to work in a pair or just as a member of a bigger team. I always found it very refreshing to work on something new, unique, something that will be presented to the audience or other attendees.

The final visual of our Hackathon game

So when the company hackathon was announced, there were no doubts and with a few workmates, we created a team – two Unity programmers, a level designer, and a game designer. What was different from the usual Game Jams was the theme. It was announced a few weeks before the beginning of the hackathon, so we had time to think about it. The theme was Tower Defense.

A hackathon is a design sprint-like event; often, in which computer programmers and others involved in software development, including graphic designers, interface designers, project managers, domain experts, and others collaborate intensively on software projects. The goal of a hackathon is to create functioning software or hardware by the end of the event.

https://en.wikipedia.org/wiki/Hackathon

Of course, our internal hackathon in a free-to-play company has different rules than usual game jams, which I attended before. A most major difference is the expected result – the goal is to create a f2p game and publish it. We had a full 4 days on it. As this is wasn’t an easy task, I decided to write this article as a summary of points, which stuck in my head and I consider them as worthy experiences to remember and share.

1. Hackathon ≠ Game Jam

I don’t want to talk about the atmosphere or organizational differences between these two kinds of events. I will stay in the scope of the goal and the final game.

For me, the Game Jam’s projects were always about pure fun and I always focused on gameplay and experience. I rely on the fact, that I will present my game to the audience and players, we will talk about and have collective fun from playing. This approach often forgives missing menus, tutorials, or special hacks required to run the game.

On the opposite side, players who download your game from the store are usually not aware of the fact that it’s created during hackathon. They expecting a full game, and you have to fight for the player’s attention with all games on the platform’s store. They will not read manuals or close their eyes to bugs or placeholders.

I like to think about the differences in terms “vertical slice” (for hackathons) vs “horizontal slice” (for game jams).

2. Design part vs development part

As in real development, doing these two activities simultaneously isn’t easy and can easily end unproductive. But limited time frame requires finding the right balance between them.

In our case, we started with simple brainstorming a few days before hackathon’s start. Of course, we did basic research and we played several tower defense games on Play Store. We discussed a lot of ideas until we were able to identify, what the unique point of our game should be and how we will implement it.

An evening before I prepared a basic GDD, describing basic terms, principles, and screens. This helped us in communication and we were able to see the whole game at least in text form. The important part of the preparation phase was also to agree on the data structure of the game’s definitions. We used Google Sheets as storage for all numbers and relevant information. Later, this helped us to experiment with individual game aspects independently from our programmers.

3. “It will not work” phase

I experienced this phase almost on every Game Jam. After a positive beginning, you do a significant part of your work and start to doubt. The problem is, that you can see the original design in action, but in very rough form. And it’s not only about visual representation and game juice. You are starting to notice problems in a basic concept, controls, maybe some features not make sense anymore. You start realizing, how much work has to be done until the full release and how little time you have. It’s where you can start to be a little pessimistic.

My recommendation here is to not change your core design dramatically. You are in the phase when you have to continue and try to experiment with balance, content and follow your original vision. This phase is often necessary. And in this case, it’s better to meet it rather sooner than later. You have still a lot of time to work. So don’t worry about the “It will not work” phase. From this point, it will be just better.

4. Be prepared for cutting

Cutting of features or content will happen. It’s fact. Your time is limited and you need to have a complex working game at the end of the hackathon. You will need to do several decisions about what will be in the game and whatnot. Problem is, when the complexity and dependency level of your features is so high, that cutting one thing will break something else. Or even worse, the original idea will disappear.

It’s the reason, why prioritization should be a part of the original GDD. Have a clear picture of what is necessary and what will be nice to have. If you will not have time for creating a proper tutorial, the late game feature will be worthless for players who will not understand the very basics of your game.

5. Opportunity to learn

One of the big advantages of hackathons and game jams is the opportunity to learn something new. If it’s technology, design approach, or teamwork. Time restriction is beneficial in this case. You will not have time to procrastinate or wait until better conditions.

But it’s important and has realistic expectations. Without proper experience level, you will hardly be able to compete in the market (in my case I overrated my graphic skills). Game development itself is complicated even if you know what to do. It’s better to have some basics in tools like Unity or Git and in the game development process. After then you will be able to focus fully on your learning goal and enjoy cooperation with your teammates.

I bet we are a only team with custom merch

The result – Zombie City Escape TD

I don’t write about the game itself. So I can recommend you to go and try it yourself. Go to Zombie City Escape TD Google Play page and have fun!

Another beautiful level created by one of my workmate
Zombie City Escape TD

1 Comment

  1. Adam Debop

    Very Nice hackathon recap.

Leave a Reply

Your email address will not be published. Required fields are marked *

© 2022 Deep in Games

Theme by Anders NorenUp ↑