Visitor 7 - Can I build a game in 3 months?

Welcome to another post in a series of developer logs about the building of the game Visitor. At the beginning of the year I set out with 4 projects, to be worked on for 3 months each. My first was the game Visitor, which has just been an idea in my head for about a year leading up to 2022. It has officially been 3 months, so let's get to the answer:

Can I build a game in 3 months?

No.

But almost, yes.

What do you mean by "game"?

I use the term "game" pretty loosely. To other indie game enthusiasts (and especially solo-game-devs) I don't think I need to qualify how broad the notion of "game" can be. Needless to say, my goal to create a game in 3 months was to create a publishable artifact that was accessible and playable by other people in the world.

At the end of three months, I'd say I'm about 75% done (and of course, they say the last 10% is the last 90%, so in reality, there's still a long way to go). I'll write a bit about the self-imposed limitations I had before we get into the "how far did I get?" section.

Why the time limit?

Why set a time limit of 3 months for a project? Isn't that too rushed? Your projects are probably going to take longer than 3 months?

Those are good questions. I'll start with the last one.

It's all about quantity

As with my journey in learning how to draw and paint, I believe that I have to make a lot of bad stuff, so that I can get gradually less bad, and then eventually be good. I've decided that, for my personality, the best way to execute on the things I want to make in the world (the things I really daydream about, not just small projects) is to build up to them through a series of increasingly more challenging and stimulating projects. There are a few reasons for this:

1. Finished projects give me more motivation and inspiration to continue than unfinished projects.
2. I can avoid deathloops, as Derek Yu puts it so well:
3. Starting small means I know how long certain things take, which help me budget (time) for the more complex things I'd like to make.
4. Quantity over Quality has been discussed numerous times in other blogs, especially in the relating of the parable from the book Art & Fear.

Limited scope creep

A real deadlines means learning what I will have time to make and what I won't. While I'm still learning some processes with game development (exporting is especially brutal), I can more easily shut down ideas.

I'm sure connoisseur's of game development could point out that I'm limiting what my game is capable of being if I don't make time to build X mechanic, or add Y to the story, etc etc. This is likely true, but there are so many things to learn about building games that I'd rather let a game be entirely too simple and lack-luster in order to learn what you learn from completing a game.

Ok, but you didn't finish the game?

You're right, I didn't. More on that in the section below.

Why stop now?

Well, I want to follow through on my project plan, which means Visitor now has to take a back seat to other projects I want to build. If the next project is a total dumpster fire, I'll come back to it, but otherwise, Visitor will be a putter project I come back to when I'm inspired for short bursts. I certainly intend to finish it. If you go back and read the new year's post I link at the beginning of this post, you'll see some hesitancy in the framework I've worked up for myself - but I want to stick to it. The whole point of the 4 projects over three months each was to help me assess how I work. I have no problem with the way I've worked on projects in the past; I just wanted to try something new to see what I learn.

Getting space from a project

Getting space for a project seems like a good idea to me. This might be my way of making myself feel better that I didn't get the project done, but at the very least, similar to painting a painting, you often have to step back or step away for a time and then come back to see what needs work.

What did I learn / have yet to learn?

I've covered a few of these in earlier posts, if you've been following along.

• If you're testing/working on building for hardware (in my case, android), test, test, test on it. Don't just assume that what works in the editor renderer will work on your hardware (seems obvious, but I keep forgetting this, so I'm writing it out again)
• If your Android build is suddenly not working... you may have a renamed file issue. Android is surprisingly difficult and sensitive to how files are named. Beware of this.
• I still can't quite wrap my head around using signals in Godot when I could be using singletons. Either way, I haven't built a large enough game to see the benefits/downsides of either approach.

How far did I get?

This was a screenshot from my first post.

Here's what's left:

• Music and sound
• Configure NPCs to have different behaviours based on their "storyline".
• One strange bug
• Proper end screen/end game state

I'm pleased with how far I got and I'm looking forward to returning to this project. The music I might be able to make from a detached perspective, which might be a nice way of "continuing to work on it" without really working on the project. I do feel at a loss, in some ways. I feel close to being done, and now I'm stopping?

I guess it's all part of the experiment! Keep an eye on the blog to see if I stick to my resolutions.

See ya next time, WT