Unreal Engine has some decent support for automated testing, and my IDE of choice, JetBrains Rider allows you to run the tests from the Unit Tests tab.

My blog runs on GitHub Pages, which uses Jekyll. Usually I just push new posts to GitHub and check them once they’re active on the site, but sometimes it’s nice to be able to preview things locally.

The CommonUI plugin for Unreal Engine has some really useful features. One of them is the notion of activatable widgets, and the activatable widget stack.

Running cheat commands on the server requires a bit of setup, as the cheat manager is not an actor and therefore not replicated.

In the game I’m working on we use the chat window also to enter cheat commands, so I found myself in need of an editable text box with history, as you sometimes need enter the same command repeatedly. Or maybe you just want to spam the chat in the most efficient manner possible.

Setting up a basic chat system in an Unreal Engine multiplayer game is quite easy, as UE takes care of all the networking.

It’s fairly easy to set up a door that opens in Unreal Engine, but having it replicate to all clients in a multiplayer game gets a little trickier. I’d like to show my take on this and explain the issues I’ve encountered.

A spline component in Unreal Engine doesn’t really provide any collision detection, as far as I can tell. You can use the spline to add spline mesh components to an actor and those can in turn have collision, but I ran into a use case where I wanted essentially a spline based volume for detecting overlaps. So, rather than adding spline mesh components to the actor I simply added Box collision components - this gave me the results I wanted.

I’ve been doing some experiments with navigation in Unreal Engine. The navigation system is pretty powerful but does suffer a bit from a lack of documentation so I’m finding myself discovering things by trial and error and reading the underlying source code. I’m describing some of those experiments here primarily for my own benefit but hopefully others may find it useful as well.

In an earlier blog I showed how to create a custom widget for drawing a slice. It has properties for the start angle and arc size, but unlike most numeric properties on widgets they can’t be animated as I left the widget last time. This is easy to fix, though!

I’ve been experimenting with the navigation system in Unreal (see my earlier posts, Click To Move and Visualizing Paths). What could be the best test environment for path finding? A maze, maybe? Anyway, making a randomly generated maze seemed like a fun project so I went ahead and did that.

The UI system in Unreal, UMG, offers a fair number of widgets and allows you to do quite a lot in Blueprints. There may still be times, however, when you need to create custom widgets to fill some gap in the provided feature set, or for performance reasons. In this blog post I will go through the basics of creating a widget with custom rendering - in the near future I will follow up with more advanced issues.

I’m continuing my experiments with the Unreal Engine navigation system, this time around I’m working on visualizing the path the character will follow. In my last blog post I described a component for finding and following paths - in this post I will talk about a component for showing the path.

In this post I want to describe an approach I’ve used for controlling a character in Unreal with a click-to-move scheme. There is a sample with the Unreal Engine that has simple click-to-move, but I want something that gives me more control, allowing me to visualize the path, for example, and to allow integration with a WASD control scheme.

Here are some things I’ve run into lately while working in Unreal Engine, where I’ve spent way too much time tracking down the issue. By writing these down I’m hoping I’ll better remember them in the future, and maybe I can save somebody else time as well.

At work, I’ve had reasons to look into Antlr recently and decided to do some experiments in a stand-alone project to get some experience with it. Antlr is a parser generator - I played with something like that way back when in college, but that was bison and yacc. I’ve also implemented some parsers for our data formats when working on games, usually with straight up C++ or Python code.

The texture atlas in my Vulkan sprite renderer relies on an AreaAllocator class to keep track of areas allocated to the individual atlas textures. I have implemented such a class before, when I was working on EVE Online. This time around I’m building it from the ground up with unit tests, trying to do it in a proper test driven development style.

My Vulkan sprite renderer uses a texture atlas for more efficient rendering of sprite.

For my Vulkan sprite renderer I decided to use FreeType for text rendering.

My sprite renderer needs to support alpha blending, and I’ve opted for a scheme using pre-multiplied alpha. I’m not going as far as pre-multiplying alpha into the textures, but rather performing the multiplication in the fragment shader. As far as the blending stage in the graphics pipeline is concerned, the alpha has been pre-multiplied, however.

I’ve moved all my tests for the Vulkan sprite renderer from Google Test to Catch2.

I really like the concept of test driven development, but I’ve often struggled with applying it to the codebase I’m working in. It’s easy to do simple test projects from scratch with TDD, and I’ve used with success for new projects that go well beyond simple test projects.

When I was working on EVE Online I was accustomed to having a log viewer running at all times, capturing the log output from the EVE client (and the proxy/server when running a local server). We used to have an old program, implemented in Borland Delphi, simply called LogViewer, but then my colleague finally got fed up with it and wrote a new log viewer, dubbed LogLite.

My simple Vulkan sprite renderer doesn’t have a large collection of complicated shaders. In fact, it only has one vertex shader and one fragment shader. Rather than loading the SPIR-V code from files on disk, I’ve opted for embedding them in the executable.

I want to implement my own game engine, using Vulkan for graphics. The primary driver for this is to learn to use Vulkan, but I also want to try some things in the overall architecture and infrastructure of a game engine.

Working with JSON in Go is quite nice. I’m using it as my communication protocol for my exsim project.

I knew when I set out on my exsim project that it was ambitious - mixing three programming languages in one project, two of which were new to me. Elixir is very promising for handling lots of connections, and in general running concurrent tasks making good use of multi-core processors, which is why I found it interesting.

I want to describe my first iteration of exsim, the core server for the large scale simulation I described in my last blog post.

Learning new things is important for every developer. I’ve mentioned  this before, and in the spirit of doing just that, I’ve started a somewhat ambitious project.

My employer laid a bunch off people yesterday. While I still have a job, this makes me really sad. I feel bad for those people that didn’t have a job to go to this morning - some of them have worked here a long time, some of them are good friends, some acquaintances, some I can’t really say I know.

I’ve added search and trim to my expiring records module in Erlang. This started out as an in-memory key/value store, that I then migrated over to using Mnesia and eventually to a replicated Mnesia table.

Earlier this year I started experimenting with the Xmpp protocol, and implemented bots in Python to communicate with an Xmpp server. I’ve now revisited those bots and reimplemented them in Go. I’ve been meaning to learn Go for quite a while, and this seemed like a reasonable first project to tackle.

I’m still working on my expiring records module in Erlang (see here and here for my previous posts on this).

Continuing with my expiring records module (see my previous blog), I’ve now switched it over to using Mnesia, rather than a dictionary object stored in the state of my gen_server instance.

I’m continuing my experiments with Erlang - this time trying out gen_server with a simple key/value store with a twist - the values have an expiration date.

In a previous blog I described a simple echo bot, that echoes back anything you say to it. This time I will talk about a bot that generates traffic for the chat server, that can be used for load-testing both the chat server as well as any chat clients connected to it.

I’ve been digging deeper into my experiments with Erlang and have improved the JSON parser I discussed in a previous blog. The code lives at https://github.com/snorristurluson/erl-simple-json in case you want to take a look.

In a previous blog I started discussing Xmpp and showed how to set up an Xmpp server and connecting to it via Python. In this blog I will dig deeper and show how to implement a simple echo bot.