Cannibal Killers from Outer Space

Does anyone else have a problem with starting projects and not finishing them? The vibe I get is that a lot of game devs do. I like building the first batch of systems, rapid prototyping and seeing things appear from nothing, but polishing things up and making my systems clear and understandable for an audience? BORING Obviously it's an important part of any major production, but it's the point at which my eyes start snapping onto other new and exciting things.

Over the Christmas break, I got to indulge this love of rapid prototyping. Over my holiday I went to visit family, and so didn't spent more than a couple of hours a day tinkering with this, by which time I was usually quite drunk. It was a callback to my days at college making stuff like the parkour system, where it was all learning, building janky and cludgy implementations, and everything being a stupid joke. Here's how it all turned out!

Getting Started

Cannibal Killers from Outer Space originally started as something completely different, I discovered a UI library called Clay, which I thought I might try using to make a point and click game about sailing around the ocean in the 1700's, buying and selling goods for the East India Trading Company. This idea fell flat when I could not get the library to work with C++ on my laptop.

Bugger.

Well that's rather put a damper on the fun project I was going to do over the holidays. What now? Well I did talk about trying to rebuild my interaction system in Godot as a way of learning that engine, which seems like a good idea. The plan is as follows:

1: Basic first person movement
2: Line trace based interaction system
3: Reactive UI for input prompting
4: Interactive object class

I had never used Godot before this point. I'd opened it a few times, and got bored within five minutes because I didn't actually have a project to work on. So I spent most of this project just getting a feel for the editor and figuring out how to do basic things like place objects and edit code.

I started off with a combination of youtube tutorials and documentation, but neither of them could really account for the fact that I was going into this project with the wrong architectural mental model. I'll cover that more in the "what went wrong" section, but in the meantime lets have a quick look at Godot's editor.

Godot is really lightweight. Like astonishingly lightweight given what it can do, and how easy it is to use. It works on a system a bit like Unity's (or at least my memory of Unity) where you have scenes, which are made up of a collection of nodes. Nodes can be 3D, 2D, or "Control" nodes. Control nodes are largely UI components as far as I can tell, where 2D and 3D are for sprite and mesh work (among other things) respectively.

Scripts are then attached to each of the nodes in a scene to make them Do Stuff. Scripts are written in GDScript, and scenes can be added into other scenes. For instance, in the screenshot above, the "player" scene (fig. 2) is then added into the "world" scene (fig. 1). This is basically how "objects" work in Godot. While inheritance and object oriented design (of some kind) seem to be possible, I didn't really get to that point on this project, and would want to spend some more time with the documentation before I made any design decisions regarding it.

What went well

The first couple of days of this project pretty much went off without a hitch. I found Godot incredibly fun and easy to use at first. Getting a prototype level and basic character controller set up was quick and easy, and I had a lot of fun taking photos of my arm to use as interaction prompts and the mouse cursor. It's important to remember, this was supposed to just be a fun project where I make something silly.

While it's not my first choice for a game programming language, I think GdScript being a bit python-esque and a bit typescript adjacent made it easy for me to pick up, and easy to guess at what a function might be called. If I couldn't guess it on my first or second go (or figure it out from the list that the in-built script editor suggested) the documentation was easy to navigate and understand.

Being able to quickly and easily switch between the script editor, the 3d editor, and the 2d editor made rapidly cobbling something together on my little framework laptop a lot more fun and less stressful than it would have likely been in another engine. With these tools at my disposal, it took me about three hours to get a scene with some cubes, a player moving around, and some UI elements on screen.

What went not so well

This, much like the original goals for the project, can be nicely broken up into a small list:

1: Not following "getting started" guides
2: Not making a second plan
3: NPC Navigation

1: Not following "Getting Started" guides
So the first of these issues is most certainly the least of them but throwing myself face first into Godot, and not bothering to follow along with a proper tutorial project, was the largest factor (aside from The Alcohol) in my tackling problems by trying to make them fit my existing systemic model, rather than trying to understand Godot's systemic model. I put up my hands and say that I most likely would have got more done, and got it done at a higher quality, if I'd realised this sooner.

2: Not making a second plan
Secondly, by the end of Christmas day I had finished my initial todo list, and so just started throwing things in as they occured to me, instead of making a list of silly ideas. This lead to a particularly rough stage of "development" where I had three or four different features in the game which were either half working, or not working at all, and I just kept jumping between them.

This is a cautionary tale in feature creep and the importance of making some kind of plan in game development. I find that if I don't have a proper plan set up before I start implementing features, the designer brain gets wayyy ahead of developer brain and things start to fall apart a tad. Of course, better this happen on a stupid project like this than in a real world production environment, but even so I think it bogged down even this dumb game. Had I not made this mistake I might have been able to turn this into a little high score based arcadey shooter, rather than whatever it is now.

3: NPC Navigation
Finally, one of the features I tried to implement during this post-todo list period of chaos was NPC pathfinding for the capsule characters you shoot at. The idea was simple, they either pick a random point in an area, or ping the player's location, and start moving to that position. I got this working after a couple of hours of documentation reading.

What's the problem, then?

Well, at some point I refactored something, somewhere, and it stopped working. I delayed releasing this writeup to try and troubleshoot this. Everything looked like it should be in place, but the stubborn little dudes just would not move anymore. I still have no idea why this happened, but I cannot for the life of me figure it out, and I cannot delay this any longer. I'm really disappointed about this because I was super proud of myself when I got them working, and the only changes I made were to offload some of the calculations so they weren't taking place every frame for every NPC in the game. Alas, it wasn't to be.

What's next?

Short section, but I'm currently developing a fixed camera sci-fi horror game in Unreal Engine, so what's next is a lot of work on that. I'll write a post about that when I've got a demo out and you can wishlist it/play it on Steam.

At some point I also want to try and rebuild this project (or something similar to it) in the Cryengine as a similar learning experience, though perhaps implementing what I learned this time around. Finally, I've been meaning to dig out some of my old prototypes and systems mechanics and just build them and throw them on itch.io. I keep putting it off for stupid reasons, but hopefully I'll get around to doing that sometime this year.

Conclusion

What emerged at the other end of all of this is a "game" where you walk around a collection of grey buildings in the fog popping pale grey capsules like balloons with a poorly modelled gun. It has no sound, and a surprising amount of the user interface is made of photos of my arm.

There's a lot more I could say about this project, but I honestly don't think it's really worth it. I spent a total of perhaps 25 - 30 hours on this project, and I was kind of drunk for a lot of those. It was not, to put it lightly, an ideal production environment. It was a surprisingly good learning environment, and most importantly it was a lot of fun.

I want to make something else with Godot at some point, but I definitely need to spend more time with it and get a better sense for it's system architecture as I go. However, I think that will be easier next time around thanks to this experience.

On a more personal note, I think my biggest issue in this project was the part of my brain that I'm going to start calling The Scheming Advisor. The Scheming Advisor is the designer part of my brain which whispers features to me which sound just about easy enough to implement without considering much else.

The Scheming Advisor is very skilled at coming up with cool ideas, but is only truly useful when tempered both by the other half of the designer brain and the developer brain who actually has to do the work. In this case, The Scheming Advisor got free while the designer brain and the developer brain were napping nearby.

Never trust The Scheming Advisor.

See the project!