As a personal project, I wanted to try implementing a networked inventory in Unreal Engine 4, and compare how the built-in variable replication compares with an RPC approach (with respect to network activity) when the inventory gets large.

So, I created two ActorComponent-derived classes in C++: ReplicationInventoryComponent and RPCBasedInventoryComponent. To make them as interchangeable and easy to use as possible, both of them implement a Blueprint-callable interface: IInventoryInterface.

ReplicationInventoryComponent internally uses an array of structs, with a map of item names to array positions for fast access (which gets rebuilt using RepNotify so it’s always up to date). RPCBasedInventoryComponent uses a private Inventory class, which just uses a map of item names to quantities.

See the related blog post for full details on the performance comparison, but surprisingly, in this case, replication used far less memory bandwidth than RPCs, even for inventories with thousands of components.

During my time at King, I was tasked with adding some additional particle effects to make clear to the player when their Companion is affected by certain actions. With the help of some very talented artists, I implemented a basic version by creating a new class to move any UI element from some position A to another position B. I composed the movements using a queue data structure, so the visual effects would play one after another.

However, after internal playtesting, the designers for the feature felt that the implementation was too sluggish - all other visual effects on the board would not trigger until the queue was empty. So, I looked into some timer-based approaches, but the timing assumptions were resulting in some unintended behaviour.

Finally, I settled on a version that used callbacks, manually triggering each effect once the previous one finished, which avoided interrupting the flow of any other visual effects on the board. The end result (shown below), while a little less flexible than the queue approach, works well and is in the game today!

Chesskell is a full type-level model of Chess (in Haskell’s type system), bundled with a Haskell-embedded Domain Specific Language for interfacing with that type-level model. A Chess game, expressed in Chesskell, will only compile games of Chess that do not break the FIDE Laws of Chess - so if you describe a game that contains a mistake, then your description will not compile.

Although this project started off as my third-year dissertation, it grew into a research paper which my supervisor and I submitted to the Haskell Symposium 2021. Once accepted, I presented this research at the symposium, to a group of very friendly Haskell enthusiasts!