Tag: game engine

An Update

Despite lack of blog updates, I am indeed still working on my little game thing. Only, until recently, I’ve mostly been writing the story, and writing about what I’m writing felt like excessive writing that would take away from my, er, writing time. Anyways, recently I picked up the art and programming string of development again, and I have enough to say for another post.

The Godot Escoria plug-in seems to have gotten an overhaul this past year. I’m happy for the devs, but unfortunately for me, the Escoria 3.2 api I was working with got deprecated into the void of githubs past. Most of the documentation got taken down and replaced with the new and improved version of Escoria. Again, great for new people, but it’s a bit of a shock to find a 404 page where docs were before. I had a dig through the Wayback Machine (thank the Internet gods for the Wayback Machine!) to find the docs I needed. The new version of Escoria does look more organized– I’m excited to try it when it’s more production ready.

Speaking of open source things, I’ve started using Krita for all things digital painting. Besides being free, it has this brilliant auto-paint feature (which reminds me of the coloring in TVPaint) that saves probably hours in coloring. Here’s a character art preview– this thoughtful dude is supposed to be sitting in a chair, not hovering in mid-air, but the chair part of this background is still in progress.

On the administrative side of this project, I promised myself I can buy a Nintendo Switch when I finish. So, now there’s incentive to finish in a timely manner, before a new console generation is released.

The Great Potato Bug of 2021

Almost immediately after posting yesterday’s update, in which I wrote, quote, “no major bugs”, I encountered a bug. I was changing up some story points, which included moving a couple assets from one scene to another. I then continued developing, and at some point I realized that my HUD had disappeared from the project. Many print statements later, I discovered that the resource loader was not loading my HUD upon loading any game scene. Turns out the resource loader was getting stuck on a “potato.png” that I referenced in a scene but had since deleted. No potato!

I still can’t find where that potato reference is, but I band-aid fixed it by adding a new potato.png into the requisite folder. My hope is that some day I will find that potato reference and put this bug to bed. This blog post will remind me to do so.

The Game is Afoot

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.