Ok, so the 3D thing turned out to be a bit of a dead end. It was great in concept but it turned out to be creating a few more issues than I could see from early on in the process.

I’ve reverted and I’ve been back to working on the 2D sprite-based version of the game engine.

One of the struggles I’ve been having is getting my head around the “game” aspect of the engine. It’s all well and good to start coding a cool game engine and adding all the tools and toggles and in-game economics of a virtual grocery store and such, but at the end of the day this is a game: obstacles, progression, purpose are all key in that idea.

I guess I could say that I got a bit diverted on how I could make it work and then hit a bit of a wall around why it should work at all.

I’ve not been coding much. In fact, in the last year I’ve probably only put maybe fifty hours into the game dev work. The life of a sole developer on an indie game, I suppose: motivation comes and goes, and lacking a real deadline what is there to do.

All this is to say that in order to get back into the rhythm of writing code and progressing the development of the game itself I have needed to go back to that big question: why.

Why does the game need to do such and such?

Why?

So I went through my project board and added a bunch of tasks around adding game-specific components to my game engine. That is to say, if I add game aspects to the world, it suddenly is less about how they work and more about coding the tools that a player might need to play the game: to overcome obstacles, to open doors, to progress the story.

If all this sounds obvious, it is actually very much not.

It’s like getting really good at generating a crossword grid, but then realizing that you need to also write some clues and answers to fill it all in.

The game is obvious in one’s head. But until the gamer emerges and starts building the fun into the engine, there is no answer to that big old question of why.

That’s what’s next.