Category: Gamedev

July 30, 2023 / / Devlog

Despite our best intentions, our programs will likely crash at one point or another. If this has happened on your own machine then you have your debugger at hand, but if it has happened on a user’s device this becomes more problematic.

A solution for this is crash reporting: a crash dump which is sent to you for debugging, as well as any relevant log files.

June 4, 2022 / / Gamedev

No matter what game we are making, robust logging is essential. It is an essential tool for the developer (and for more technical players), assisting both during development and after a game is release.

My custom C++ engine, Genesis, has had a logging from the earliest days, but it has received some upgrades recently to make it easier to use. I thought it might be helpful to other developers to write an article about the considerations which go into writing such a system, as well as share some code snippets.

August 18, 2021 / / Gamedev

With holidays and birthday season out of the way, it’s time to let you know what’s been happening in HEXTERMINATE land.

Engine upgrades

Linux support & Proton

Being stuck on holiday with a laptop that only runs Linux Mint, I thought I’d try to get the game running on it, as the majority of the code was meant to be portable anyway.

That was the theory.

In practice, it required quite a substantial amount of work to get the game compiling, nevermind actually running. Right now it does run and it is playable, although there are some graphical artefacts and sound doesn’t work. However, this led to some interesting discoveries which will affect everyone, leading to better performance and fewer memory issues.

Currently, native Linux support is scheduled for Build 19 (so, not this one but the one after), but the many fixes that have been done to the engine will likely allow the game to be run through Proton in Build 18, rather than just displaying a black screen.

June 19, 2021 / / Gamedev

A new User Interface

It is one of those things which are inevitable in software development: mistakes are often obvious in hindsight.

If we go back several years, I decided that writing my own User Interface library was a good idea. This was a valuable experiment in a number of ways, providing valuable insight into the complexity of such a system: how do I bring fonts in? How does input need to be implemented in a multilayered system? What about popups? How difficult can it be to get the text in a text box wrapping correctly?

If I was just making an engine for fun and experience, that decision would have been fine. However, since I was actually trying to ship a game with it, that was a mistake. This mistake was further compounded by a reluctance to upgrade the UI system to allow for dynamic reloading, which meant that building and tweaking interfaces was very time consuming.

However, with HEXTERMINATE staying in development for the foreseeable future, there will be a substantial amount of UI work that will have to be done. For my sanity, I’ve decided to finally bite the bullet and layer a more advanced system on top of the current UI, allowing me to modify new UI elements on the fly and store the design as a JSON file.

May 6, 2021 / / Gamedev

With HEXTERMINATE having been out for a while and the bulk of the issues resolved, it is time to talk about what will happen to the game in the long term.

Although the game is has been released, development will be carrying on for a long time to come: HEXTERMINATE is one of my two hobby projects and one that has an ever-growing list of things I’d like to do.

Before we go any further, let me just make one thing clear: these will all be free updates and available to anyone who has bought the game.

So, lets have a look at the backlog for a broad overview of where development time is going.

Engine updates

The engine HEXTERMINATE uses is homegrown and was started a very, very long time ago (a cursory look shows the first copyright notice in it dating back to 2014, but the first files were probably created in 2006 or so). Over the years it has been updated as necessary and chunks have been rewritten to allow for easier development.

One of the systems that needs some love is the renderer. Although sufficient for what the game currently does, it is quite primitive and had large chunks of OpenGL boilerplate code which is completely unnecessary nowadays. Previously using OpenGL 2 and relying on extensions, the engine has now been updated to use OpenGL 3.3. This is unlikely to cause any issues to anyone who has bought the game, as most cards this side of 2010 will support it, while considerably simplifying any work which touches the rendering system.

These first updates will be available in the upcoming release, Build 16.