If you create content for the web, then you've probably had some experience with content management systems (CMS). Most sites that receive regular updates will have:

, are together referred to as the 'body', whereas the place someone may go to view the content publicly i.e. 

is referred to as the 'head'. Historically, these have been coupled together in a single software solution for ease-of-use, and there's an entire landscape of website builders and hosting plans that package it all together, vying for your attention.

An emerging category of CMS is the 'headless' one, where there's no 'head' included. 

 - there may be many 'heads'. They generally provide greater freedom at the cost of increased technical complexity - you'll have to create your own data structures, and probably build your front-ends from scratch.

If you're unsure why that might be desirable, keep reading - otherwise, 

As always with web development, the terminology is wishy-washy

If you use any kind of social media, then you already know that the people behind Facebook and Twitter have made decisions about the 'shape' of the content to keep it in-fitting with their vision for the design of their websites.

At a high level, both platforms provide the ability to create 

that may contain text and images published at a specific time. Digging into their discrepancies, Tweets may have characters limits and hashtags, whereas Facebook posts may have specific privacy settings and activities attached to them. If you're looking to start a blog or run a business, then the constraints of each platform will inform their compatibility with you - I use 

 because it suits my desire to create simple pictorial posts with titles, and provides a customizable theme for others to view them.

When we learn a new paradigm in technology, like what a typical 'post' is, we often assume it is the 

 design in the present once it makes sense to us because it is the only one that exists - if you're out having a nice meal, it might occur to you that you could post a photo with a geolocation to Facebook, because you've seen those features used before. It's easy to forget that there are people deciding how this all works, and that they can and 

 experiment over time with what a post actually is. Large platforms strive to provide generic enough features to accommodate as many use cases as they can, but if you were in control, would you want more or less specificity?

For example, somebody selling a used vacuum cleaner on Ebay may be presented with an input field dedicated to describing the item's condition, which will ultimately get its own dedicated space on the listing's webpage. The same post to Facebook may simply see the item's condition tacked onto the end of the post body if the seller even remembers to include it. If you consider that Ebay is not just a 'website', but also an 'app', and that your local Facebook marketplace could also potentially be delivered as a weekly print magazine, then you come to understand that while the context in which the data is presented is important, the driving force of the internet has always been the data itself.

Imagine if you got to decide what that data looked like for your application - if you didn't have to call it a 'post' if that didn't suit you, if you kept a hold of it yourself instead of submitting it to be stored by somebody else. Imagine having that freedom, without having to code it from scratch. This is where a self-hosted, headless CMS like Payload comes in.

Consider how a Facebook marketplace post differs from an Instagram post, and how that forces people to think outside of the box depending on how they're using each

Another example of this could be showtimes for a cinema. Imagine you have both a website and digital signage outside the venue, with both needing to display information about the current films. You could make two 'heads' - one website for the browser, and another kind of view to load onto the digital sign outside. As long as they were both internet-connected, they could both retrieve information from your headless CMS via a REST API e.g. 

It would be plenty of work to build such a system from scratch in a way that would accommodate non-tech-savvy authors, and there's no free out-of-the-box solution available online for this specific use case.

A headless CMS allows a web developer to define what a unit of 'film' data is, and provide authors with a clean interface to publish films to the system.

Dissecting the user interface of the showtimes page from the Picturehouse Cinemas company shows film posts comprise of at least a name, trailer, MPA rating and runtime

 a step further, and allowed authors to control more aspects of the end applications - for example, the style and layouts of websites?

This is the unique selling point of website builders like 

. They define blocks of content, such as text, image galleries, videos etc., and allow authors to create pages made up of any number of these blocks in any order. Each of these blocks may have extra properties dictating their style, such as color and background images, again to be obeyed by the developer of the 'head' applications as they see fit.

This can be achieved in a headless CMS that allows for creating your own data structures. Instead of 'films', the concept of a 'page' could be created, comprised of similar blocks of content. Theoretically, authors could build entire websites of pages and posts with unique combinations of these blocks, so long as the user experience was accommodating.

, but grew tired of keeping it up to date for the sake of features I wasn't using; I wanted something simpler, and I wanted more control over the shape of the data.

Throughout this process, I catalogued my experiences into pros and cons. Payload is new, and still has teething issues, but I'm comfortable saying that it's the best CMS system I've ever used - one I'd never found the time to make for myself. This isn't a sponsored post, but I'll happily evangelize the ethos the makers 

 display through their enthusiastic approach to work and 

The Payload admin panel being used to create achievements for a video game

It's here that Payload is best-in-class - even if the software goes in a direction I end up not liking, there will always be capable snapshots of the framework on NPM; the work has already been done, and open-sourced. Additionally, since self-hosting doesn't preclude a managed solution, there will also be guides and one-click-deploy solutions out there to help take it live. It's not prescriptive, and can be hosted in isolation - depending on your architecture, you can even use the Payload library to call directly into the database, bypassing the need to make HTTP requests to the REST API.

The icing on the cake is that the developers are active on Github, and engage with the community to share knowledge of their own professional, client-oriented development practices from their experience operating as a digital agency.

Although it takes some learning, defining your own data schema means you never have any more features than you need. This allows the admin interface to remain clean and customisable, with a small footprint  - it's not 'overkill' to set up for any given project that needs some dynamic data, and the form libraries being used make for pleasant editing experience.

Payload is written in TypeScript, and the admin panel is made using React. Aside from being popular technologies, aligning yourself with them allows you to share your code between your own Payload configuration, and any of your front-ends. There's little mysticism, which means you've got greater agency if you need to hack your way to a solution (something I needed to do as an early adopter to skirt around some bugs). 

Aside from a few technical issues to be expected with the launch of a new software product, my concerns regarding Payload are largely rooted in time and circumstance.

As with everything, new software is prone to bugs, breaking changes and a lead-time-to-community resulting in an absence of self-service support (via Google). This is emphasized when comparing Payload to 

, its closest contemporary, where the community has been building out plugins for years. With Payload, more complex behaviours are left to you, meaning it's not an all-in-one solution. This necessitates a more technical knowledge, whereas other solutions allow non-technical people to create and maintain websites.

Since release, they've incorporated a few ubiquitous features, such as 'draft' post states, change diff-ing, and hooks for common operations. In regards to feature requests, I'm unsure how far the developers want to go in any specific direction before the system itself would be considered bloated. To spur adoption, Payload may benefit from a clear and communicated public roadmap.

If you change the data schema in a breaking way, Payload cannot reconcile what is already there - e.g. changing the type of a field with data already in the database. Since it's already opinionated about the type of database to use, the system itself may benefit from including some aspects of database management 'for free'.

I've experienced a number of bugs with the admin panel that have resulted in some lost work (data not saving, UI elements relocating about the page, irreconcilable time-outs…).

In general, I think their library could produce more descriptive error messages, and their online documentation could be more thorough.

Having worked as a web developer for years now, I find Payload to be quite refreshing - its versatility lends itself well to more esoteric and interesting projects that require bespoke content models. I work in the games industry, and I could see Payload underpinning everything from patch notes to an in-game store - in fact, 

At the very least, I'll certainly be keeping an optimistic eye on it over the next year, and greedily integrating and subsuming each new feature into this site.

Why I built this website with Payload CMS

I wanted to jazz up the 'pub quiz' format I'd gotten tired of during the Covid lockdowns over the past few years, and reduce the burden on a quiz host - no more messing with Powerpoints! I took inspiration from 

 and the way they present their apps to players: a game client married to a separate  spectator/host control view intended to be livestreamed.

Managing my tasks on Trello, I did lots of play-testing with friends before settling on a winning quiz-show formula. My mission statements were to:

The justification for these goals was primarily that it's not fun to be part of a quiz where you don't feel like you can contribute. Therefore, I wanted the game to feature team-based multiple-choice wagering - options could be written kindly to lead players to a more likely subset of answers (e.g. one obviously wrong, egregious option per-question). I also wanted to create a spectacle whereby hosts could pause for dramatic effect in-between questions and create a narrative from the game's events so far: "Team One have fallen below Team Two this round, who used their hint expertly!". I was essentially reverse-engineering the emotional pillars of the game - fairness, competition and frivolity.

, but found that if all teams went all-in on an incorrect answer, the game would end without getting to see all the questions, meaning it'd be hard to predict - I didn't want people to commit an hour of their time, to attending a quiz only to leave disappointed. So, I experimented with the idea of wagering being additive - you could win money, but not lose any. There, I encountered the issue that players doubling their money exponentially would win by several million pounds over the course of a 20 question quiz.

Eventually, I decided that each round, each team would receive a limited pot of money to wager with - any money not spent would disappear, any spent on incorrect answers would be deducted from their final score, and any spent on correct answers would be added to their final score. In addition to meeting my criteria, the benefit of this format was that there could be a deterministic maximum potential score - 50k per question over 20 questions means theoretically you can win a nice round £1 million.

The final rule-set explained to players in a modal dialog

I embellished this with additional UX and quality-of-life features that were borne of testing my own game hundreds of times, and friends chiming in with their own ideas: a hint system to 50/50 the answers, a chat system to enable teams to communicate outside of VoIP, a countdown timer to constrain the length of the session, a quiz designer (wizard) to tune variables such as quantities of money and the questions themselves, an achievement system to still reward 'losers', a notification system to allow hosts to send players text messages, and, of course, an emote system so hosts could see real-time feedback from players.


Each of these features are microcosms of the same features in larger online games, which is my wheelhouse. Each one presents a different set of challenges - thanks to the scope of this project, I could simply reload, test, see what was wrong, and then fix it: "Now that I have a chat system, what happens if I send too many messages? Ok, I probably need to create a FIFO system and limit it in order to prevent the client from crashing". I acted as my own QA, doing bug-driven development.

 as the underlying technology as, piggybacking off HTTP/IP, they support frequently sending/receiving messages from clients without needing to establish new connections or guarantee a response like 

. This meant I could host a resilient, authoritative server, and create a custom marshalling library (I chose JSON for simplicity), in order to re-use the same stack for other, similar projects, with the only thing changing being the specific message schema and set of handler functions relevant to each.

A high-level overview of the message processing solution - the main perk being that the server and player entities can be swapped, as clients use the same library to rate limit and register handlers to messages originating from the server

The biggest problem to solve was ensuring that people could join the quiz easily. Matchmaking and managing teams is generally the driest and most important topic of online games, since it's the player's first introduction to the game and an unpleasant experience can lead to a higher bounce-rate and burden on organizers. I managed to create a system whereby players could create a team, or play solo - solo players are simply part of their own team, which is marked as solo, to create consistency in the model.

The team structure and ample buttons allow for late joiners and team-switches, which again prioritizes the host's workload by giving players the option of self-service

After an initial handshake with the server, a client is assigned an ID to cache so that they can refresh their page without breaking the link to their player object. Security for the host view is done via obscurity (extra connection parameters), which worked for my purpose. All clients are sent the game state when it changes, if the change pertains to them, and they are only given what they are allowed to see. With the time I had, I failed to create a system whereby players would initially receive the whole state, and then only receive diffs to that state, meaning payloads are larger than they need to be. Nonetheless, this allowed me to massively simplify the code that updated the DOM, and meant that I could forego relying on an SPA technology like ReactJS.

Since not all elements of the UI will actually be modified every time the game state is received by the client, this is a surprisingly performant, if brittle, solution

I hosted the mini-lithic app on the same DigitalOcean droplet as my website. I containerized it using 

, which is accessed indirectly through an Nginx proxy-pass. This means it can use the 

 protocol, while keeping a consistent URL structure with the rest of the site.

 players to the app and, based on the game state, simulate messages. I found that, once I had implemented a sensible rate limiting solution, and kicked clients that provided unexpected input, a single server on paltry virtualized hardware could cope with up to 200 players before experiencing visible latency, which satisfied me.

In order to prevent connections being closed by the server, I implemented a simple ping-pong system. Much later, I realised that I had a 

 - each client might have their own, slightly different understanding of the current time, meaning I couldn't rely on each client to manage their own timer for each question. I solved this by bundling the server's current time with each heartbeat, so the client could figure out their average latency to the server and adjust accordingly - this interpolation seemed to work really well, which was satisfying to see!

I pitched the idea to my producer (and eventual co-host) Dan Jones, and  people engagement manager Chloe Sinclair - they loved the idea, and I was super grateful for their enthusiasm. I also recruited the talented Miles Rodyakin as a graphics designer, as there was suddenly a deadline and ergo motivation to polish and put the whole thing into production.


This also meant I got to engage in a bit of marketing, communicating about the project in a newsletter and creating some assets to share:

The stakes were pretty low, but I was nervous nonetheless. There was a single input bug on-the-day, but otherwise it went smoothly with a real cohort of ~30 players. I created a survey to ask for feedback, which received positive reviews and some feature requests. Having also provided a 

 from the session in order to understand how they responded to each question.

 from this quiz show which questions were difficult and which were easy

An online quiz game

There are now a huge number of user reviews in Steam, but the only place to view them is the store front, which is geared towards consumers. However, Steam's APIs can be used to access all reviews for a given product at once, and more. This tool provides a clean interface to this data set with a greater level of control.

It is intended to answer a number of interesting and useful questions such as:

A community manager may use it to find dedicated users worth helping and rewarding. A designer may use it to isolate high quality feedback. A product analyst may use it evaluate success (retention, sentiment) over time.

To this end, visualisations are provided to aid exploration, and the data itself can be exported.

The web requests are funnelled through a CORS proxy that I host on Heroku, and the data itself is stored in your browser's memory. This isn't terribly efficient, but it cuts costs and ensures that indies with < 50,000 reviews can access the most up-to-date information about their games. If it were to ever suffer from success in terms of performance or rate-limiting, I'd have to write some back-end services with extra caching and their own data stores.


I created a feedback form for the site and posted the link on Reddit, where it briefly hit the front-page. I've been overwhelmed with positive responses and useful suggestions as I continue to support the tool, and have implemented quality-of-life features such as a dark mode, more graceful error handling and further filtering options. My favourite so far has been a filter that uses some RegEx magic to  find reviews that contain ASCII art.


I hope that it sits alongside its influences of SteamDB and SteamSpy as an alternative method of exploring data. Steam's API itself seems to be in a state of flux, and I will likely have to continue to program around certain obstacles like incorrectly labelled or missing data, and aberrant failing requests.

A free games analytics tool

‘, I led a team of 3 to create an experimental website that allowed players to leave short notes representing their favourite in-game memories on an interactive map of the game world in real-time. My idea was intended to inspire the kinds of community-driven marketing experiences we could create in the future, learn more about other departments supporting the games, and try new technologies. As a result, I also acquired time from members of customer support, legal, data, creative services and community management, who were each able to shape the resulting product and become invested in its success.

The website was promoted by the RuneFest Twitter account and mobile application during the event, which garnered a low yield of high-quality user-generated content with positive sentiment. This engagement was enough to fill both maps spatially over time, and was manageable in terms of moderation. Despite providing users with free-text input, only a few people tried to act negatively. The system was shut down gracefully the following Monday, after sharing with members of staff in order to receive feedback – an overall success!

The map was a “living” experience – new notes, once approved, appeared instantly to all connected clients using 

. I wrote the WebSocket server in TypeScript and deployed it through AWS, while co-ordinating the design (

) and creation of an administrative portal and public front-end with some colleagues. This involved learning how to secure WebSocket connections (

) and build bespoke communication protocols (JSON-based RPC) for them. It also involved creating a JWT-based account system for moderators, and database design in Redis to ensure easy indexing, separation of concerns, and the ability to audit moderator actions.

Due to the necessarily quick turnaround, we responded to feature-creep by scoping down the finished product in favour of necessary additions. The biggest challenge was identifying anonymous users and discouraging them from acting maliciously, which required risk analyses. I was pleased when a small number of users were ultimately rate-limited when attempting to spam the system, and manually banned while failing to perform an XSS injection.

After shutting it down and removing the data, I used Python and a Jupyter Notebook to explore the data, producing a report.

Each domain expert I spoke with was able to provide insight into potential issues or opportunities I had never considered:

An ARG for a game convention

 and a complementary moderation layer similar to social-media-management tools like 

; I’d found myself getting into small rituals finding entertaining online-content, and wanted to automate and share the outcome instead of spamming my friends with links. My favourite candidate idea was a combination of games analytics and dramatic irony: ridiculous Steam reviews.

Having played around with Steam’s review API in the past, I did some sketching for a potential system

The architectural diagram for the project, with Heroku as the worker host and Firebase as the front-end host


I started with a scraper that spitballed some criteria and used 


Initially, the criteria was to find games with an active playerbase, and negative reviews left by people who’d spent more than ten times the amount of hours as the average reviewer. I wanted to see personas evolve around these reviewers - why do they spend so much time playing something they so detest?

With a mechanism to retrieve game data, I iterated over 

reviews for that game – the console output was enough to slow the request time to below Steam’s 4-per-second rate-limit.

I decided to use Firebase since it is free and quick to set up. Lastly, I could nest these calls in some loops to get data from the most popular games of the last two weeks – games meeting my criteria would be processed, and reviews of those games meeting my criteria would be pushed into the data store.

I converted the above Node project into a 

 project – in this way, calls could be made via a CORS-proxy in the browser, simplifying the process of scraping to the point that it could be done on my mobile phone in my down-time as opposed to in a terminal. This was my first time using Vue, and I found it to be quite intuitive – component driven frameworks marry well with simple interfaces.

 – again, free and easy. It takes a random review off the queue (weighted against recently posted games), formats the post, includes an image from Steam, logs it and then posts it to the 

, who are a fantastic catalogue-community of open-source bot developers. Thanks to a small nudge from their Twitter account, I was able to start picking up followers, and could therefore ask them what they’d like to see – I ran a poll to determine a post cadence of 4.5 hours.

After seeing some unsavoury things make it into my system, I added a profanity filter from NPM.

After seeing reviews get posted for the same game multiple times in a row (thanks 

…), I made sure the worker would re-roll a few times if the review it picked matched any of the recent games in order to ensure diverse content.

When Halloween came around, I used the “pinned” feature in my worker to prioritise reviews that had been moderated as “pinned” first, essentially creating a sandboxed queue I could fill exclusively with horror games.

I’ve since been adding features to the moderation client, and tuning the criteria to ensure that moderating these funny, perplexing game reviews continues to be fun for me.

In regards to the reviews themselves, while myself and others find them funny, I also think they are valuable – running them through word-clouds for each game, they expose trends. For living-games, most appear to complain about monetisation, or abandonment. For single-player games, most complain about bugs. The data may be helpful in exposing addictive behaviours in digital-media, and providing developers with intensified feedback from those with a deep investment in their products.


Since this project was somewhat slapdash, there are aspects I’d like to improve:


Creating a Twitter bot for game reviews

I took part in the Ludum Dare Game Jam 44 with the theme "

. This was my first LDJ with a partner – we conceptualised together, and then split responsibilities squarely between programming (Unity, C#) and art. I took advantage of a loaned 

, a dusty old microphone and a whiteboard to design a rhythm fighting game where you are a kaiju monster – a legend in human history being repeatedly attacked. In the down-time between eras, you are given a chance to trade your ever-diminishing health for stronger combos, in a desperate bid to continue surviving…

Every game jam, I try to do something outside of my comfort zone – this time, although we both contributed to all aspects, I was in charge of UI/UX, art and sound assets. It was a reasonably UI heavy game, designed to be plugged chock-full of 

 to add characters, battles and moves. This data-driven approach was inspired by our experience of working with content developers in-industry.

We designed it together, and decided on a hybridisation of the typical rhythm-game formula - instead of hitting buttons on-beat, you had to queue your attack patterns, meaning longer combos for better attacks were higher risk-reward.

jam – we didn’t win any categories, but we produced something that felt polished that we were proud of, and thanks to some charmingly constructive feedback on our submission by members of the LDJ community, we were able to pin-point exactly where it needed improvement: chiefly, the core mechanics were not conveyed well enough to the player, and it could have benefited from some clearer tutorialisation.

Designing a rhythm game for Ludum Dare

I created a series of shaders in GLSL for use with OpenGL in C++ to demonstrate core concepts of vertex, fragment and geometry (tesselation) shading. I also used interpolation between textures, and lightmaps and conditional evaluation to provide transparency.

I gained experience writing shaders, including implementing lighting algorithms (diffuse, specular, phong) to manipulate scene objects in a 3D simulation.

Vertex shader to scale model down with conditional evaluation (for transparency)

Two textures are interpolated between, and positions manipulated

Fragment shader to fade away according to texture lightmap

Geometry shader to make each vertex of the cube split into smaller cubes, with random movement

Tessellation control shader for deformation, with real-time lighting

Tessellation control and evaluation shaders to add detail and smash model

Tessellation and dynamic lighting shaders

I took part in the Ludum Dare Game Jam 38 with the theme 

. This was the first LDJ I completed on my own, and my idea was to create a micro-management puzzle game where you play a lighthouse-keeper in space informing ships sending distress signals from upcoming hazards – flitting between them to give them new information as to what to do next to stay safe.

I managed to model some simple assets in Blender, and create a scale of difficulty for the distress types. Ultimately, the game was too hard, however it had a functional loop, and it was fun to be both the artist and programmer on the same project. I ran out of time to do some things I wanted to do, so I think prioritising functionality over appearance early on is a better strategy for future jams.

Designing a puzzle game for Ludum Dare

This took about 5 months of sporadic work to complete, and was written in C++ for Windows machines. It was comprised of a number of subsystems written to industry standards, some of which leveraging middleware, and all drawing from a wealth of theory.

The final gamut of subsystems included resource-management, 3D graphics, 2D physics, file I/O, audio, human-interface, profiling, and an events system to tie them together. You can find an explanation of each below.


After demonstrating of the capabilities of the engine, I went on to add a gameplay subsystem to utilise it, producing a game called ‘Sinball’, an amalgam between a 

Ultimately, I delivered a fully functioning and reasonably polished experience that was a lot of fun to play. The experience tested me on almost all of the skills I had learned during my course , and pushed me to find comfort in architecting complicated systems to unfamiliar archetypes – a long-haul divide-and-conquer with a rich reward at the end.

I had a play around in Unity and came up with the concept for a pinball game where the stage was built from tiles, with the Molyneux-esque twist being that 

, and the idea of aping them seemed both fun and achievable given the deadline. I could already visualise the data format, and I figured it would be more interesting to have to tweak the physics middleware past its out-of-the-box settings to mimic the elasticity and restitution of a pinball.

“Don’t reinvent the wheel” – Every programmer, at least once

‘Middleware’ is ready-made solutions libraries. Without some dependency management jazz like 

 to help me, it was a brute-force exercise in downloading the right 

 files from websites that look like they’d prefer to be left alone (just follow their tutorials).

Gah, I hadn’t expected setting up pathing and versioning for 

 files in Visual Studio would be so finicky! I ended up with some per-build (debug/release) config and a littered resources folder that, despite working, I’m still scared to touch to this day.

I opted to use the in-house graphics library we’d been developing alongside our studies, which relied on OpenGL, supported any regular old shaders and textures, and, pivotally, could be extended to read 

 to design my stage. For physics, since Pinball is typically restricted to two-dimensions by a glass plate, I used the lightweight and well-documented 

, as it was one of the few free options with sensible requirements, capable of spatial sound. Lastly, for Xbox controller support, I used Microsoft’s 

The most atomic unit of a game engine is an ‘entity’. There are some common features of entities that are worth encapsulating for access across subsystems. Mine ended up storing their position in the ‘game world’ as a tuple inside of a 

, along with pointers to extra metadata per-system, such as 

 (their position in the simulation), and 

 (their shaders, textures, mesh). They also had some basic toggles, such as 

. Thus, creating a custom Entity, such as a pinball, was as simple as bootstrapping its own fields, and ergo defining how it should look and act inside of its constructor.

Critical to any game engine is efficient use of memory. Using contiguously malloc’d memory that was strictly indexed necessitated overriding the 

 operator for many managed entities that would end up being spawned and re-used (e.g. game entities such as tiles).

 that held stores of segmented sizes. Each 

 of their states and pointers (free/allocated). These structs came in handy for clarity, and while I was hesitant while writing it, the resulting files were very simple.

Given more time, I would have liked to have also pre-loaded a manifest of static assets – as it stands, the engine hangs on first-load. Nonetheless, manage resources in this way increased the frame-rate drastically, and meant I didn’t have to worry about defragmentation. It also made the process of debugging easier, as snapshots of memory were more orderly.

The final step function ran inside a while loop in 

bool Core::Step()
{
	graphics.Update();
	humanInterface.Update();
	gameplay.Update();

	if (!gameplay.IsPaused() && !gameplay.IsFinished())
	{
		physics.Update();
	}

	if (!gameplay.IsFinished())
	{
		audio.Update();
		profiling.Update();

		eventManager->RemoveFinishedEvents();
	}

	return !(gameplay.IsFinished() || graphics.IsFinished());
}

As you can see, nuances regarding exiting the program aside, each subsystem gets its own turn to update itself, reacting to and potentially creating new events.

In order for each subsystem to function interactively in the game loop, they each needed an abstract way of informing the others of changes. They all stored a reference to a global list of game entities, but needed something to act as a communication channel. To confound the problem, some entities implemented various listeners like 

, inspired by the ‘components’ or ‘nodes’ in other popular game engines – the scope of these functions would be different.

So, using OOP, I created a hierarchy comprising of an 

 objects, whose payloads could be optionally extended by each sub-type and tagged for delivery to a particular other. Extending an abstract 

 class, each system would automatically consume events from the queue intended for it during their 

 step, and circumstantially produce new events for the queue. These events were mapped to internal handler functions using lambdas. Entities themselves could also implement optional interfaces exposing handling methods for certain scenarios, and in them, also produce new events.

It is worth noting that the process of development here was very iterative – I started by seeing if I could press the 

 key, make something somewhere respond by shouting a message to the console, and then built from there

To expound, take the case of the pinball hitting a wall. The physics system would poll its middleware to detect a collision, and then call a handler on the pinball entity:

if (collisionDetected) // Simplified!
{
	Collider * c = dynamic_cast(entityA);
	if (c != nullptr)
	{
		c->OnCollisionStart(entityB);
	}
}

Inside of its handler, it would, among other things, register a 

void PinballEntity::OnCollisionStart(Entity * e)
{
	eventManager->AddEvent(new PlaySoundEvent("./Resources/Audio/collide-wall.wav",
		gameObject->x, gameObject->y));
}

 system as the sole recipient. On the other side, the event would be handled in the audio system by mapping to a function, and acted on in the super call to 

Audio::Audio(EventManager * eventManager) :
	Subsystem("Audio", Event::AUDIO, eventManager)
{
	eventMap[Event::AUDIO_PLAY_SOUND] = [this](Event * e) { HandlePlaySoundEvent(e); };
}

This was a streamlined process very similar to 

, which meant the limitations of the engine’s communication were furthermore only defined by how many different handlers of event types there were. A key-press inside the human-interface system created an 

 that the gameplay system transmuted into a 

 for the physics system to process, etc. Although it relied on the game-loop to operate in a logical order (as it is not multi-threaded), it allowed each subsystem to remain decoupled from the implementation detail of the others.

 graphics. I’d have gotten pretty poor feedback, I’m sure, but the simulation still functions fine without a window. Indeed, it did for a time while I was fleshing things out. I had to set the timestep in such a way that it 

, and balance the number of calculation passes against it (too many -> too slow, too few -> too unpredictable).

Aside from digging through header files, it also took some time to figure out the relative scale between the physics-representation of space and the graphical representation of space. A red-herring, I originally set the force coefficient so disproportionally low that it appeared as though it wasn’t working at all; it took my friend determinedly leaning on the keys for a solid 5 minutes as a pink box eked its way off my platform to convince me otherwise.

I also came across a disparity between the angle of rotation of an object between the physics and graphics systems – one was using radians, and one was not, resulting in some weird spinning cubes. If you’re interested, the the 

I ended up using a small library called 

 to load my meshes. I used the z-axis and some textured quads acting as backgrounds to create a parallax effect. The heavy-lifting here was accomplished in 

Everyone likes to kick-back with a controller now and then. There’s something about adding different kinds of input that gives me a real science-y vibe; I’m only ever a few pints away from adding 

 interface with some more ambiguous types of inputs – ‘up’, ‘enter’, ‘primary’, ‘secondary’. This helped glue the 

 implementations together, and meant I could map multiple redundant keys (e.g. 

, ↑) together for flexibility. The actual system itself polls each connected controller every update, checking for connection/disconnection, and to see if a button had been pressed. I programmed a state map for each input, so it was possible to determine if something had been ‘held’ versus ‘pressed’, and thanks to the aforementioned event payloads analogue input was simply a matter of sending along the extent at which it had been pushed in each direction between 0 and 1, to be used as a multiplier against the pinball’s movement-speed.

Surprisingly, this was my favourite to implement. I enjoy 

, and deciding how to represent the game world felt just like one. There’s no real right-or-wrong here. Some people use in-memory database-dumps (like 

), others use more standard interchange formats (like JSON, YML), and some just use an ASCII file and call it dot-whatever-they-like. Guess which one I chose?

My level files ended up taking the form of a space-delimited array of integers. The first two represented the dimensions of the level. The rest were the stage itself, numbers corresponding to different children of 

. Typing it out using carriage returns actually helped visualise the stage.

. Given more time, it may have been wiser to incorporate the tiles into a 

 function in order to save log output when…

Decidedly the least sexy, but nevertheless important, profiling is a means to measure the performance of a program. Timing the update steps of each subsystem, and keeping a track of the frame-rate seemed to be the most valuable metrics, as they indicated the metaphorical horse-power of my engine.

In a similar vein, I also implemented a basic static logger that supported levels, prefixes and timestamps (like browser dev-tools). This helped during debugging, as each module knew its own name, and I could create a clearer picture of a sequence of actions quicker than trawling over a stack-trace or stepping through breakpoints.

In the end, I decided to allow toggling the profiler on/off at run-time, with mechanisms to enable/disable logging to both the console and local filesystem. Ironically, spewing so many messages to the console actually hampered the performance of the program, creating a self-defeating cycle, so I have some further investigation to do there. I forgot to set it to false by default for release, with the moral to that story being that nothing is ever 100% done, no matter how much time you spend perfecting it.

Often overlooked, there’s a lot more nuance to audio implementation than meets the eye. It’s like shopping for a washing machine – how many kg capacity are you after? How many modes do you need? What rpm spin-speed? Energy rating? Warranty? Monthly maintenance add-on?

On the surface, I wanted to play some sounds, so I downloaded a license free pinball SFX pack. To my horror, when pressing play I was greeted with a cacophony of undulating, grating explosions. I’d programmed the sound event to trigger every collision, but with the ball rolling across a flat surface, it was technically colliding every frame. I fixed this by adding a state to represent the ball either touching a surface or not, and an audio timeout, but I fear I may never be the same. It may be wise to implement some sort of max-polyphony.

Another challenge was music. Different to SFX, background tracks provide great ambience at the cost of much higher file size – therefore, it’s better to stream them in. I had to add functionality to loop them, and support muting all sounds just-in-case.

With a proof-of-concept of the engine’s core functionality, I set about the most rewarding leg of the journey. Having been building towards one specific game, I already had a strong foundation – an untextured ball on an untextured, simple stage, being moved by the keyboard.

Blog

Technological tattle and design documents written during various projects