This week will be the last before I get a 2-week break from school. In that period I'll be doing plenty work on the engine powering this RPG as well as art and oooother things.

Wanted to share some info about it.

Gunner Engine

A (very) tiny game engine for having and making fun

I've spent the past few months pouring research and work into this. It's mainly based on the Raylib framework and focuses on making it easy to just create. I've faced many issues over the past 2 or so years with Godot Engine I am tackling with this.

Engines shouldn't be so large, they shouldn't be monolithic. They've made it easier to make games, which is good, but they've also frustrated us. Many times we have to work against what the developer thought was right for them, but isn't right for the user. The creators often don't battle test it themselves and become unaware of these limitations brought up by users, and I am one of them.

I've tried to take advantage of the open source nature of Godot to try to do something about this predicament, but such a large and often cumbersome to initially understand C++ codebase only invited more frustration. My PRs were also largely ignored for being considered frivolous or because developers were more willing to keep their software bug-compatible. I couldn't stand it longer and decided to focus full time on this important piece of the puzzle that is Conflict deFuse.

Inspired by the philosophy behind Raylib, understanding the internals of Gunner Engine doesn't take long, as it's a straightforward C99 codebase concerned with only providing the kinds of things I wanted. It doesn't have an editor, and some tools are still under development, but akin to how Godot's editor is made with Godot, so will be Gunner's. Even better, you'll be able to edit that very editor at runtime.

How? I decided to go all in on hot reloading all the things (where applicable, of course.) such as textures, shaders, and most important of all, C code.

Godot wasn't built with hot-reloading in mind and trying to edit your game's code at runtime may prove dangerous in certain instances. Reloading assets is also hardly instantaneous in the editor and hardly even works at runtime. The engine's philosophy is like an assembly line, things sure move fast but it's all strict and cumbersome to swap things out for unless they're meant for it. My engine's philosophy is like putting together a toy. You keep working on it until it does what it should.

By utilizing Tiny C Compiler as a library, code is compiled before startup and then run. Best of all, true to its name, it's a very quick process and never has to be done again unless code was changed, it simply grabs what it compiled last time after every startup. If you change a file, it simply compiles that one file and links everything back again to keep on running. Any errors or warnings are reported to you to prevent compiling broken code. It should just work instead of being some kind of afterthought.

What about assets? Often with C code you are expected to play around with pointers, this obviously invites many dangerous procedures when it comes to the makeup of your game. However, the engine was built with passing handles instead of pointers, letting it take care of the dirty work and letting you simply keep track of indices to those assets in your game code. Not only is it easier to catch any issues (you'll know where and what!), it runs faster as everything is packed together in memory, easy for the computer to access again and again. Letting the engine keep track of assets also means offloading the job of hot-reloading entirely to it, making any asset a breeze to continuously iterate upon.

There is still plenty to figure out and build but the hardest step has been taken: committing to not only creating a new game engine, but a game that necessitates it at the same time. Developing a engine without a game is a fool's errand.

Conflict deFuse is not a big game. The demo is 2 floors with many odd sights and faces to meet, as well as enemy designs inspired by books and urban legends. The final game is around 4 with even more to find. It could've been built with Godot and I did wish to build it with Godot, as that's the engine I've used for many recent titles such as the ENA: Decimation Journey demo. However, as you saw, my frustration reached a breaking point and now I put in the extra work to make it fun to work on this game.

The game's own commitment to its artstyle is also part of this necessity for something custom-built. Godot's rendering systems appear quite full of features to anyone who's seen their fair share of Unreal Engine 4 titles, but don't mistake it for flexibility; it has anything but. Shaders use a flavor of GLSL with preset entry points for each of the usual steps of building a triangle, plus a cumbersome light function that doesn't even play nicely with some of the render settings you can add onto the shader. Custom blending isn't even implemented and there aren't many modes to work with. My PRs were meant to tackle only small oddities within shaders but alas, all left to build dust in their GitHub repository.

Gunner Engine speaks to everyone like me because this problem I faced is a non-issue with it. The engine is quick to build (I plan for it to be really quick eventually!), and exposes full GLSL. Of course it doesn't have all the conveniences Godot has, but if you're using Gunner you're not here for them. You're here to setup a specific blending mode from the Playstation 1 so your fade to black looks sicker.

It's a combination I wished to see and decided to make real: something that handles what you don't want to and lets you handle what you want to. There are not many like it, maybe Renderware or even whatever utterly sick thing they use at Tomorrow Corporation. A game is like a toy, and I pity the state we find ourselves in where making a toy has to be so cumbersome. With all the things we have today now though, it doesn't have to be this way! The engine should be what you want it to be, tools that do more than the sum of their parts.

Gunner Engine's source code will be available alongside Conflict deFuse once it releases, and you'll be able to look, prod and happily make something of your own with them. I've decided to forgo the usual kind of open source licensing for everything that isn't assets (which will use CC BY-NC-SA 4.0) and just use GNU All-permissive instead. Take it and do something with it! Everyone should be able to create.

I'll share soon more peeks and thoughts about development. Thank you for reading and have a wonderful new week, and a great day.