The problem of scope under tight time constraints

I had an idea, make a simple game using the ‘standard’ Unity approach then remake the same game with Bolt and again with ECS. I wanted to really see the practical differences, the strengths and weaknesses of each approach. I knew it would have to be a very small scale project to keep things simple so I went with the classic Flappy Bird. Immediately starting the first version of the project I began to run into the same conundrum that I always run into when doing small-scale projects or gamejams, how much do I invest into foundational architecture and keeping things generic versus just getting shit done.

The Game Jam dilemma

This is a problem that I’ve never really took the time to nail down. I also think deep-down sometimes I claim to make decisions that may not be perfect with the excuse of time constraints (when the reality is that I may not actually know what the perfect solution is, or just too lazy). There’s also the lingering knowledge that “if i would have done it this way, then it would have worked out better” but the reality is that you’ll never know because you typically never go back and make that change and the game’s scope is small enough that is ultimately doesn’t matter.

So I had a new idea, I’ll make the game as if I’m under gamejam conditions but keep track of all the shortcuts, crossroads and architectural decisions I’ve made that are suspect. Afterwards, I will expand the game and see what decisions were the right call and what screwed me later in development. I can also go back and perhaps do things different just to compare which way was faster.

Here’s an example of some of the notes I took:

As always, here’s the source.

 

Leave a Reply

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