How creating a Game in a week looks like

This week I took part in the Brackeys Game Jam 2023.2. This has been my first Game Jam (and possibly last, keep reading to know why 👇).

This post tells the story of a week making a game from zero.

This post is not about "my game". I do not mention anything about the gameplay or how I implemented it.

This is the story of how the week went, what challenge I faced, and how I overcame them ✌️

Theme reveal: "Diving Deeper"

A Game Jam usually features a theme on which the game should be based.

The theme is revealed when the Jam starts. This time the theme was "Diving Deeper".

The first phase is brainstorming. I wrote down everything that came to my mind when thinking about "Diving Deeper". Every game genre, mechanic, feature, anything is written down without judgment:

This is the first one of several pages I wrote when brainstorming ideas for the theme "Diving Deeper"

As I was writing notes, some of them sounded immediately interesting. I came back to them and started highlighting all my favorite ideas.

I then went to do something else, leaving some time to process all the ideas.

After a couple of hours, I came back ready to write down a plan.

How to plan a game

This is the most important phase, and also the hardest.

I collected all the ideas that I liked the most. Now I need a plan of execution.

The plan should include everything about the game, as well as all the tasks required to create it.

Since I used Github to host the code, I decided to write the plan as the README.md for the repository

I wrote down all the mechanics, ideas, entities, goals, and their interactions. I then included a list of tasks, listing everything that I needed to do to implement the game.

I marked each feature with the following icons:

• 🎲: Main mechanics
• ⚠️: Attention when implementing
• ✏️: Good to have, not necessary
• 💡: Idea, may be added or not
• ❓: Possible problem to verify

I also marked each "main entity" in the game with `` (formatted as code by Github).

The goal is making sure that the game scope is appropriate for the time: 1 week.

The final list of tasks is the starting point for the implementation. Make sure to write down everything that you foresee will be necessary to do.

This process will help make sure that the scope fits the 1 week time.

Starting the implementation: Core mechanics

The first part of the implementation is all about building the main mechanics.

I made sure to avoid at all costs creating any sprite or asset. The core of the game must be completed before making any art or UI.

This has been the most interesting part of the week: ready for the challenge, exciting ideas, a blank project.

The goal is to verify that the original idea makes sense. You want to get to a working prototype as fast as possible.

Ask yourself: is this feature necessary for the main mechanic to work?

If the answer is no or maybe, then cut it. It will come later on.

Note about code quality

One week is not enough time to polish and refactor all the code.

I made sure from the beginning to organize the code and use the patterns I knew would be necessary later on.

For example, when implementing the enemy AI I opted directly to use State Machines (How to implement a State Machine in Godot).

I knew that the enemy AI would be necessary in any case, so I used directly the most suited pattern to implement it from the beginning.

This will save some refactoring time later on in the week.

Is this going to work?

The first couple of days went by without major issues.

I completed the main mechanics. The game looked solid and with a lot of potential.

However, the first inconsistencies started to come to the surface.

I noticed that "playing" the game was not necessary to complete each level.

The goal of the game was to "reach the end of the dungeon". I implemented some mechanics around power-ups, collecting coins and resources, fighting enemies.

Well, turns out that those were all unnecessary to "reach the end". The game allowed you to just sprint straight to the end, avoiding all the enemies.

I therefore reduced the player speed, but this caused the inverse problem. Now the enemies were too strong to overcome.

New idea: allow the player to become stronger. I therefore added a "leveling system" to allow the player to become faster and more powerful.

This is called "Scope creep".

Spoiler: the final game prototype at the end does not include the leveling system, it was simply too much to implement and polish for a week of work

Many other inconsistencies started to surface. Furthermore, it became evident that the scope of the project was too much for the week 🤦.

Therefore, I reviewed the README document, removing all that I considered not necessary and updating the tasks list.

Unexpected problems

I implemented the game using Godot.

I was familiar with the game engine, and I had also written some articles about it before starting the Jam (with code that I then reused for the project).

There was only one thing that I did not practice enough before starting the Jam: UIs.

When it came time to implement the main menu for the game I ran into a lot of problems. These caused considerable delays in the implementation.

I also opened, resolved, and closed an issue on Godot's Github repository about on problem that I was not able to figure out 👇

Furthermore, the UI looked terrible. I did not have enough experience to move fast with UI development in Godot.

Game art: It takes ages

The second major problem was creating the art for the game (Pixel art specifically).

I initially intended to use an 8x8 resolution for the game. While implementing the game I noticed that 8x8 was too small and I decided to move to 16x16.

Once again, it turns out that making all the art for the game takes a lot of time. In one working session, I managed to create a draft of the tileset and a not-so-good-looking sprite for the player.

I then needed to refine the tileset, add animations to the player, add more than one enemy with animations, creating the art of the UI and all the assets in the game.

Well, this was not going to work.

Sprinting to the end (it happens every time)

The final phase was the most difficult and problematic.

My goal was to ship the game, no matter how simple or unpolished.

I started cutting the majority of the features planned, they were simply too much to fit the time.

Furthermore, I removed some of the mechanics that were conflicting in the game (or simply unnecessary to reach the main goal).

I also reduced the workload for the game art. Things like making the player animations unnecessary, using the same sprite with different colors for the player and enemies, reducing the tileset to only the minimum set of tiles.

Shipping it

In the end, I settled for a simple but functional prototype.

I skipped the last phase of expanding the content (adding more levels, more power-ups, more enemy types).

The game at the end is a simple "proof of concept": 1 level, 1 enemy, 3 collectibles, and not much to "play".

I also did not consider the "shipping" part as something that would take as much time as it did. You need to organize the assets, write a description, upload screenshots, and build the project (never works on the first try).

Final considerations

I did it. The game is available on itch.io.

It is not a playable game. It does not have content, the UI looks terrible, and the gameplay is as simple and unpolished as it gets.

Some final considerations after this week-long experience:

• Solo game development takes time, a lot of time: no matter how hard you try, game development is complex. Working alone on a game takes ages, seriously. Every game that I made in the past took hundreds of hours to make.
• The scope is always too big: I paid a lot of attention while deciding the scope of features, I knew this was one of the most important considerations when planning. Nonetheless, it was still too much. Lesson learned: decide what to create, and then cut it by half or more.
• Not just programming: making a game is the most skill-complete project that exists. Project management, programming, art, music, marketing. Making all of this as a solo developer is a real challenge. While it's doable, it will take ages, both to learn all of these, as well as put them into practice.
• Parkinson's law: a Game Jam is the concrete representation of Parkinson's law. I knew I had a week to complete this project. This pushed me to put more hours into it, fitting the allotted period.

Parkinson's law: the time it takes to complete a project expands to fill its allotted time span, regardless of the amount of work to be done

All in all, making a game is exciting and challenging: more exciting at the beginning, when all its potential, and more challenging at the end (if there even is an "end").

This has been a great experience that I would suggest other people to try. Nonetheless, I think I will not do something like this again.

It takes too much time. Even when the main gameplay is implemented, you still need to think about UI, art, music, content, polishing, fixing bugs.

This is simply too much for a solo developer, considering how difficult is for any game to "stand out" (whatever it means for you, but especially if this involves earning an income).

I suggest you take a look at these videos to get a sense of what game development is about:

• Releasing Our Indie Game
• The Reality Of Game Dev

That's it. Thanks for reading.