How can a game be a foot?

I’ve been meaning to publish a point’n’click adventure game for a while now, and the stars have aligned this year so that I have time to work on one. This here blog is to encourage me to finish what I’ve started, plus maybe help any other netizen with similar aspirations, so they don’t have to retread the steps I have taken.

I’m at the point now where I’ve settled on a game engine, and I’ve just started writing the thing. The game idea is based on a drawing I made a couple years ago combined with what’s currently going on with the COVID situation. I’ve got an outline of where I want it to go and a bunch of sketches, though I imagine it will change along the way.

Starting the programming part wasn’t easy. My initial thought: start from scratch with SDL. This is not a good idea. Building a game engine from scratch is a great learning experience, but it’ll take you, a single programmer, years of weekends before getting to the story part of your game. So, I needed a pre-built game engine. I started off looking at Unity, as I have some past experience with the software. The major benefit of Unity to me was documentation. If there’s a thing you want to implement, chances are some random person on the Internet has had the same idea and has asked a question on the forums about it. The docs are pretty extensive, and C# ranks high as my favorite programming language.

Why I decided not to go with Unity? One, the programming is bloated for what I’m trying to make. Unity felt like overkill for a 2D adventure game, and with great flexibility comes a lot of features I don’t want to deal with. Two, unless I buy the pro version, I get that Unity splash screen. My budget is roughly $0, so no pro version. And I don’t like the splash screen.

So I turned to opensource engines, which are awesome but can also be iffy. Documentation can be spotty, but I can forgive that for the price tag. First I checked out Adventure Game Studio, which I had experimented with a few years ago. Back then, I had found it outdated and limiting in terms of capabilities, and now… it still is. Next was Ren’py, an engine built for visual novel games. It’s great, but only if you want to make a visual novel. The Python-based language is super easy to figure out, but the moment you try to add the point and click elements, you start fighting the engine.

I finally settled on Godot, which is an opensource game engine that reminds me of Unity in that it tries to cover almost any type of game. The scripting language, Gdscript, is easy to learn, and there’s a Godot adventure game framework called Escoria that has all the major features I want. Escoria was originally released for an older version of Godot, and it was only recently that the contributors updated things for more recent versions. The main downside is documentation. There’s a sample game that helps get you started, but I’ve had to search out a couple features that are available in the framwork but not mentioned online. A few elements are also broken/buggy, namely the verb menu it comes with, but the bugs are largely fixable after some code deciphering. The selling point of Escoria for me is the scripting language. It is beautifully simple and thought out.

And that’s where I am now. So far no major roadblocks with Godot or Escoria, but I’ll see as things come up.