I tried to make a project for the GMTK Game Jam 2024 where the theme was Built To Scale. By the end of the third day, only the basic framework was finished. The stuff engines normally provides (I think): Tilesets, Visualisation, Saving, … No actual game logic.

The original idea was to have a Tactics game where you fight enemies of differing scale. First facing small enemies, where multiple enemies can stand on one tile, and escalate to huge enemies taking op large amount of tiles.

Movement, elevation and LoS (Line of Sight) would have been important, aka The Terrain. Playing within a city where movement is influenced by house blocks. You could hide in streets where LoS is blocked by the surrounding houses. Enemies have vision cones and would only attack units it can see. Functionally, it would be fighting in a maze, but you can climb on buildings. I wanted several movement skills like a grapplehook. I wanted big enemies to have weak spots that you’d have to get into position for.

Another important feature would be Speed and Turn Order. Big enemies take long to charge their turn. A Wait button would allow a player character to delay their turn until just after when an enemy acts, allowing hit and run tactics.

What went wrong ?

1) Reinventing the Wheel

Well, as I mentioned, I started for zero. I only had a week of practise in with pygame itself. Despite telling myself I’d look for existing open source projects to base myself on, I still ended up just writing everything from scratch.

I wrote a big data managing class, Tile and TileSet.

I… might have overengineered it a bit. (Note: The 4th day of the jam was spend on making this code completely independend and making this uml diagram. It is now saved seperately for future use.) Also, there is a decent chance code like this already existed somewhere. It has to.

Not only that, a lot more also already exists. Pygame alone already has a set of example projects that you can use as a jumping off point! https://www.pygame.org/docs/ref/examples.html

And you know what makes it worse ? I explicitly said I was going to use these. I knew they existed, I knew this problem would occur. Yet I ran straight into it.

2) Planning and Prioritizing

I also didn’t really plan out what should be made. I spend so much time on making saves work while there is nothing to save ! As you can see in the uml diagram, i did infact implement multiple ways to save certain data.

Another thing I did was trying to fully make all classes as I think they should be in their final state. E.g. I implemented Status Effects and how they would work be saved etc… without actually having any units that could do anything in the game.

I should’ve first made some basic units that could do really basic stuff before I started implementing all the more complicated stuff. Especially since status effects are really not that important to what I wanted in the game.

Maybe some positives ?

I did learn quite a bit. I had quite a bit of fun figuring out how to draw the field and the units. In the screenshot below you’ll see how it looks.

You are able to select tiles and see in the sidebar the info of that tile. The actual field is larger then what you see onscreen. This is one of the reasons you’ll see selection and subset appear in TileSet. With iterate_subset i was easily able to draw only what is shown. And while I never got to it, selection would have allowed me to draw e.g. spell effects. (I wanted the mage to have a big straightline beam attack.)

It’s… not a lot in the end. But hey, there’s always a next time.

Takeaways

• Spend more time looking for existing code and modules. Don’t reinvent the wheel.
• Actually make a plan. Prioritize !
• First implement very basics, then expand.