The title is a bit of a lie, and I’m sorry for that.
I actually started about a month ago. I lamented at our annual New Year’s Eve party that I’d have quite liked to make a video game and had just never gotten around to it. My wife told me that I should. I’m not sure how serious she was, but I spent most of New Year’s Day considering it and eventually decided to go for it.
Choosing a Game Engine
My first consideration was what tools to use in making my game. I briefly considered using my main skill set as a web dev and making a game in a webpage using something like Pixijs, but quickly decided that I didn’t really want to have to build an entire rendering engine and all the tools to edit the UI from scratch. I probably could do it – I’ve built something similar before – but I’m not convinced I’d do a great job of it, and it’s not really the part I’m interested in. Nor do I want to deal with hosting and load balancing and all that shenanigans. If I wanted to do that, I could start moving over to devops in my current job. No, if I’d started down that route, I would probably have lost interest already and considered the whole process a failure.
So I looked at what engines are popular right now. The two which I’ve seen mentioned a lot are Unity and Godot. I remembered there being some uproar about Unity and a runtime fee (even though it did get cancelled) and decided that I didn’t want to have to deal with that sort of thing, so I opted for Godot.
Getting Started
Downloading the Godot editor and getting it to run was easy, even as a Linux user. I suspect it’d be even easier as a Windows user. I took one look at GDScript and thoroughly hated that it’s an indent-scoped language, so opted to use C# with VSCode as my editor instead. What can I say? I like my curly braces and type safety. Fortunately, there’s a comprehensive guide to using C# with Godot in their documentation.
Following the tutorials was also straightforward. I started at about lunch time and had a working 2D game within a couple of hours. It’s a simple game, but it’s quite fun, and it gave me a good foundation how the Godot editor works.
I chose not to do the 3D game tutorial. I had a look at it, but decided that it’s not something I need right now. The game I have in mind might well benefit from 3D, but doesn’t have to be 3D.
So far, so good.
Beginning My Game
With the tutorial under my belt, making my own game should be easy, right?
Right?
Maybe it would be if I’d not had a specific type of game in mind. But I knew this even before I started. It’s part of why I put off starting until my wife’s comment prompted me to consider it. The type of game I want to make is a cross between XCOM (a strategy game with tactical combat) and Pathfinder 2E (a tabletop RPG with loads of options and a focus on tactical combat made by Paizo). This type of game has lots of different systems interacting with each other and is going to be a massive challenge to make.
I’ll go into more depth about my early thoughts about gameplay in another post, but for now it will suffice to say that I have jumped into the deep end of the game development pool.
I decided to start with something relatively simple – a way to generate random characters that are at least partially optimised and display that to the player.
Being new to the Godot editor, this took me quite a while to do.
I initially tackled displaying characters.
My aim is to eventually have something like XCOM 2’s Armory screen, where you can view your list of soldiers in a table format with a summary of useful information.
Making a Table of Characters
It turns out that tables aren’t actually all that easy to make in Godot, so it was several hours of fiddling around with controls before I settled on using HBoxContainers and VBoxContainers (the ‘H’ and ‘V’ standing for ‘Horizontal’ and ‘Vertical’). These handy containers automatically organise child controls within either horizontally or vertically. This is extremely useful for making sure each row in the ‘table’ is spaced out correctly.
After a lot of fiddling around, I ended up with an AdventurerList as the container for the table, and a CharacterSummaryButton for each row. There is a term in web development – “div soup” – the concept that everything is just a whole bunch of <div> html components within other <div> components when better components exist and should be used. I feel like my table solution here is the Godot equivalent with VBoxContainers (represented as a box with three horizontal lines going down) and HBoxContainers (a box with three vertical lines going across).
Still, it works, and a hacky solution is better than no solution at the moment.
After a few hours of playing around and creating some test data, I ended up with this wonderful screen.
It displayed whatever characters I put into it (randomly made using PF2’s character creation system). It scrolled if there were more characters than could fit on the screen. Fantastic. Job done.
Well… ok, I’ll concede that maybe there’s still some work to be done on it…
Yey Khemi!