The end of the beginning

Introduction

As we’ve never managed to properly introduce ourselves, let’s briefly touch upon that. We are Phocatech, a team of two:

• Sleepy — the leader of the team, she pushes us forward, especially when it comes to releasing, jamming, etc.
• Ironic — yours truly, the one who thinks too much and makes games for the sake of it.

There’s also a part-time member, Tired. He’ll be a character in the story too.

With that out of the way, let’s talk about the subject of the story.

Project Overview

Our first game Crane Attack is an arcade game inspired by the classic Stack Attack series from the old Siemens phones of early 2000s. Well, saying “our” is a bit of a misstatement, as this game is technically the first fully-featured solo project of Sleepy. I contributed here and there, but if we exclude rambling and nudging, the involvement is small and mostly consists of testing. Though I will still write “we” for the most part of the article. Team spirit, yada yada.

The game took about half a year to develop, from the idea to publishing on Itch.io. The plan was to release the game in three to four months. As usual, a lot of things did not go according to plan. But hey, it works and we’ve got a lot of experience.

The game is built with Godot 4.3 and is available on Windows, Linux, Android and Web.

The Easy Part

We settled on using Godot 4 right from the get go, as we both had done some testing and learning with the engine. It’s open-source and Linux is a first-class citizen here, and these points are important for us. The engine helped immensely to build a working prototype fast. Later down the production cycle it was also quite comfortable for designing the GUI.

While Sleepy liked the product, I kept bashing my head on things that can not or should not be made my way, but require bending to the logic of the engine. I’m not a programmer, but I have been doing my fair share of coding for the last decade and I like an elegant solution. But Godot’s structure is more about… well, structure, then the clever tricks.

It’s hard to get the exact time frame, but I think we had a mostly working game after only a month of development. We are talking about one month’s work of one new developer. Therefore I feel like that’s a fast start and a motivating one for the newcomers.

Nonetheless you might consider asking a question: if you made the game in a month, what did you spent the next five on? At this point the story gets to the maddening depths of debugging.

The Universe of situations

Turns out there are a lot of possible positions of boxes in relation to other boxes and a moving player-controlled fox. Needless to say, we failed to foresee a fair share of these. Who could have imagined, that the fox would be so attached to the box it’s pushing, so that trying to move the other way would also slide the box across the fox to the new destination? That if you’re fast enough you can run from under the box that killed you before the score appears? Or that jumping at precise moments could let you phase through the box? Neither of us.

Understanding the reasons for these types of behavior was not trivial. The game was written with Godot’s logic of scenes (somewhat similar to OOPs classes), where each box was effectively an object with it’s own code and logic. Which looks great on paper, until the relationships between these objects starts to let you lock one of the boxes in space, merge several boxes into one or on the contrary clone one box into two (the mystery turned out to be the plot of the movie Prestige).

While professional programmers might attribute our hardships to lackluster architecture or simply a skill issue (both valid), I still think that making it in a simpler algorithmic way with a matrix of boxes in a two dimensional array would have saved a ton of time and simplified it all. It’s not a secure networking app to care about encapsulation, not an industrial system to require unearthly levels of structure and not really a diverse game to require much inheritance.

However even with all these coding reasons the game was mostly done in three months.

Live with the mistakes

It’s hard to say that it’s over. There’s always another idea to try, another option to implement, another eye-candy to draw. Adding the second character with unique mechanics seemed like a great idea and was done in a span of two weeks. But then came the requirement to add a character select screen, to write additional texts, to hunt new bugs. Everything comes at a price which sometimes is very hard to predict.

Not all errors will be found. You have to live with that. Some bugs are known, but fixing them requires a rewrite. You have to come to terms with that. Acceptance takes time, so here goes another month.

The Compromise

Meanwhile you care about every single thing… until you don’t. One day you wake up to find, that you just want to put it out and keep on with your life. Here comes the time to fight your way through all the little things postponed to implement a shiny new feature. You have to find the compromise and sometimes cut stuff.

Tired was tasked with making a trailer for the game. It should have been a part of the initial release. Instead his job would force him to keep delaying the trailer. Tired failed to assert the delay, Sleepy decided to wait for the trailer, I failed to see the problem. So another month was spent.

To a brighter future

Now the game is out and it’s a relief. We like what it turned out to be and are glad it’s done. And we’ve got a lot of experience. To sum up, I’d list these main lessons:

• Think beforehand — making a strong logical foundation for the game and for the code is crucial to having easier time later down the line. We used the physical toy blocks to discuss the possible interactions for the next game and it helped immensely.
• Finish before expanding — try to finish every aspect of the feature before moving to a new one. Especially if the new one was not part of your initial plan.
• Cut if needed — if something takes too much time and effort it might be worth evaluating, whether it’s even worth the hassle.

It’s all cheesy and such lists have been done to death. I’ve probably seen these points before. Did it help us? Kind of. We’ve managed to escape enough pitfalls to finish the game and that’s an achievement in my book. So I hope it could help you. Or at least I would read this in ten years and cringe.

Oh, and we are already working on a new similar game. More so we’ve already made great progress and great mistakes. Feel free to come again and read about our misadventures. I also respond to the comments (hint hint).

Regards,

Ironic

P.S. Teaser from the debugging process of a new game: