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

"This has potential": a difficult revelation for both player and developer. It's almost easier when things are a total disaster - you can try again from scratch, armed with new knowledge. When something that's 'finished' has more potential, pushing it further is usually nuanced, as many of the decisions that created it have already been set in stone.

So, given nobody sets out to make a "bad" game, there’s often observable elements of good design in every game, even if they don't feel like they work together in the final product. What could be a more fitting example of a game filled with nuggets of gold, than a game about pirates?

, a 2015 naval combat game with a 61 Metacritic score, in a bundle. I was convinced to play it because it was conceived as a multiplayer successor to Sid Meier's Pirates (

), and had good Steam reviews. I really enjoyed the early game, but soon grew bored of it, which upset me more than other games I'd immediately disliked. I'd optimistically sunk time into it, and I wished it did more with the foundations it laid out. For now, let’s look at those reviews...

Reviews are an excellent way of gaging community consensus - so much so, 

. We can see from the reviews of Windward that players with both positive and negative opinions of the game agree that although it's ship-shape, it lacks depth.

The core gameplay loop is to make money to upgrade your ship's effectiveness in terms of health, arsenal, and crew. You can make money via several disparate systems that all hinge on traversing between ports - there's a commerce system to buy-low and sell-high on a time-sensitive stock market, a quest system that sees you ferry cargo between ports or killing pirate captains, and a territory system that sees you convert ports to your 

 faction in order to unlock them for trade and quests.

To this end, there's an inventory system and a skill tree, which both require you to 

 to hasten your growth; kitchen-sink mechanics that provide a framework for a functional living-world game by encouraging you to emotionally invest in your avatar. You can even style your ship with your favourite insignia and colour. But... why? 

This word cloud implies that players who liked the game found its simplicity relaxing, whereas those who didn't found it boring and repetitive.

In Windward, the journey is very much the destination. It does something that sandboxes often fail at - it actually has a goal, but it inspires the player to discover it without explicit instruction. We're in spoiler territory now: the goal is to kill a series of powerful dragons, for which you must venture to high-skill, contested territories that requires you to have the best equipment. As developer Michael "ArenMook" Lyashenko put it: 

"the farther out you go from the start, the more challenging it will get"

The map in Windward is made of procedurally generated islands contained within an overworld grid. Grid tiles have recommended skill levels, and players are initially required to spawn in a safe, low-skilled area within their faction's territory.

As ever, in order to attain the best equipment, you must become rich. In order to become the most-rich, you're compelled to risk travelling to more dangerous areas, with more reasons and opportunities to engage in combat. The nugget of gold I see glinting here is that you’re naturally coaxed through the game’s difficulty fascias at the perfect pace matching your ambition and interests. Casual players can meander around in safer areas enjoying the idle nature of the game's quest and commerce systems, while bolder players can venture outward seeking excitement through combat. Both routes allow players to re-invest their spoils to unlock more health and combat abilities which enable them to be more effective.

The quest and trade systems encourage players to shuttle between random ports, making the early-game feel like a scheduling puzzle from 

This act of self-correction pays dividends for the developer, as at any given moment, players are surrounded by other players with equal ambitions, meaning whichever difficulty of tiled instance of the world you're in, everybody is having a similar experience. Although mature players are doing more damage, they also have more health, so it’s largely the visuals, density of players, and 

 that's changing. This is what allows the game to remain mechanically lean and accessible to multiple demographics - a great amount of foresight for an open-ended exploration system.

A group of players having just sunk an enemy ship recapture a port

It’s not the first time we’ve seen an intersection between economy and 

 and RuneScape have long gated areas behind experience levels and equipment as a means of constraining exploration. Where I think Windward excels is that the world itself changes unpredictably - faction boundaries set by port ownership shift like a 4x or MOBA game (MOBA here meaning 'massively 

 battle arena') while newer recruits train for an exciting front-line war of influence being waged. There's also nothing stopping a player from beelining straight into a flotilla of pirates.

This is a gradual realisation: you're taking part in a distributed, grand strategy game playing out a thousand times simultaneously at a micro scale, a sandbox where the castles can be kicked over. This is impressive considering this kind of multiplayer is difficult to implement, and its contemporaries are found in games as decorated as 

. That each player can create their own unique story within the same world, as opposed to treading the same identical path, gives it a sense of life that makes it easy to share.

Unfortunately, I think this most important explorative aspect of the game is obscured by a myriad of comparatively insignificant and menial mechanics that both steal attention and confuse players long before they can engage with it. As mentioned in the reviews, there's a long 'grind' to progression, that can also be broken unintentionally.

I spent an hour ferrying shipments of wood to-fro for a pittance, before having an idea: to sail straight into enemy territory. Along the way, I had my most awe-inspiring moment in the game - upon entering, a fog-of-war set in, and a huge 

zipped overhead. I also had my most frustrating moment - if you're not of the correct skill level for an area, ports are closed to you, even if they belong to your faction. In other words, there was 

My plan was to clip the outskirts of an AI battle and plunder the rewards. I watched from afar as two humungous frigates doused each other in poisonous explosives and other AoE effects I'd yet to encounter. When they were finished, I hoovered up the salvage: thousands of gold pieces and more experience points than I'd made in hours of standard gameplay. I did this several more times, dying and respawning in the same area with no punishment, before buying a bigger ship and realising that the stakes hadn't meaningfully changed. Believing I had nothing else to do but ogle new item icons with bigger numbers, I signed off.

I gasped as blimps and helicopter ships passed overhead, wondering how and when I would also be able to graduate to the skies

In summary, I felt the overarching problem of Windward was that the developer didn't know what game kind of game to make, so decided to make a bit of all of them. You could make the argument that this is an unfair criticism to levy at a genre of multiplayer games that intentionally eschew endings in favour of creating stories through play.

I'd riposte, though, that each of the mechanics present 

 have their own progression which each peter out, leading you to believe there is a specific point to them that can't be found. A popular community guide describes faction selection, the very first decision a player makes, as something that will "barely impact gameplay", leading me to wonder why it was even there to begin with, and the inclusion of a final boss fight appears to me a compromise similar to 

Minecraft also settled on fighting dragons in their struggle to give players a reason to progress in the game's systems

There are also other mechanics in the game I didn't even mention, such as instanced combat, climates, bribes, and a town 'gossip' system. This melting pot of ideas isn't necessarily improved by adding extra 

 missions. I think the sequel would benefit from "trimming the fat", and deepening mechanics that serve the overarching goal of a narrative conclusion, chiefly:

The first could be achieved by allowing players to set their own destination on a trade quest that pays rewards based on a function of the distance and danger level of the target port (similar to 

). Perhaps rewards from wreckages should be tied to how involved you were in the fight, and fighting itself could emphasize group healing, providing an alternate route to progression for those newer players mostly interested in combat.


The second could be achieved by enforcing a sort of 

 for factions, which would provide newer players with that occasional 'wow' moment of seeing a victory convoy that inspires them to remain connected, and enemies with a stronger reason to make riskier and more penetrative invasions.


Happily, it seems as though the developer is taking their own path to the same outcome, having signalled their intention to create an 

. In doing due dilligence for this article, I reached out to them to ask how they would describe the main goal of the Windward series:

"Windward was never about world domination. It's a sandbox game meant to be played with your friends... Combat was the main part of [the first game], and it will still be like that in [the sequel]. However with [the sequel] I aim to have more depth to everything else, so trading and questing as well. These were pretty barebones in [the first game]. Plus, the story. There was none in [the first game]. There is one in [the sequel]."


When I played Windward again to refresh my memory, there were only 10 other players online. Tasharen Entertainment run an 

 concerning the development of Windward 2, and an ear for community feedback. I'm looking forward to seeing what they do with it.

Digging for design treasure

When doing outreach for the games industry, I'm often asked what the difference is between a 'designer' and a 'coder'. My answer depends on who I'm talking to.

To some, what matters is the degree certificate - if you were trained as an engineer, that is what you are, so you should go and do it. Some might say design is more "creative", whereas engineering is more "logical", or "mathsy".

To others, a design precedes engineering - engineering is the act of fulfilling a design, the 'how' to its 'what' and 'why'. In practice, unless you're acting as a 

 the lines are more blurry; a single person can both design and implement a system, and a self-described designer can consider the engineering process while designing just as a self-described engineer can consider the design process while programming. In agile companies, this relationship is necessarily bi-directional.

But what, then, distinguishes the role of design from engineering? After all, they have different career paths, salary bands and job descriptions. I believe the most important distinction is in the nature of problems presented to each discipline, particularly in their objectivity.

A game should run with as high FPS as possible. Everybody wants that. Given that task, engineer A's solution resulting in 120FPS is objectively better than engineer B's solution of 60FPS, if there are no other side effects to consider such as cost or code clarity.

Designers, on the other hand, work in percentiles and target demographics. They must consider the emotions of potential players when designing a system, and consider that what works for one group mightn't work for another. 

 is simultaneously described as obtuse and underwhelming by some, and the best game of all time by others. In this sense, designers have a greater responsibility to consider who they are trying to please, whereas engineers have a greater and riskier responsibility for the quality of execution based on supposed 'facts' - this is sometimes referred to as 

Generally, designers spend their days considering what adjoining groups problems are worth solving (or, to invert that optimistically, what cohesive opportunities can be taken advantage of to provide a positive experience), and engineers spend their days attempting to find an objectively "best", practical solution for those same things. Engineers carry the burden of upholding a set of objective, culturally sensitive principles that create a significant enough workload to "leave the ideas to designers", e.g. ensuring any given system is 

. This split of responsibilities feeds a complementary cycle of refinement whereby together, each "level" of thought (abstractly, "high" and "low") are hopefully covered.

Over time, these modes of thinking are cemented by experience and productivity boons. Engineers learn patterns in software architecture to streamline their implementations, while designers establish paradigms and build systems of documentation to communicate their ideas to both stakeholders and engineers alike. In a career-long effort to work smarter, not harder, so beckons forth the caricatures of asocial senior engineers with long, grizzled beards, and flat-cap clad lead designers constantly opining.

There are, of course, exceptions to these rules. Whose responsibility is a poor design executed perfectly? Oftentimes, an engineer will have to consider how an incomplete solution may disproportionately affect some users. For example, there is no current implementation of 

 that can be universally regarded as 'correct' - it's an unsolvable problem for which false positives and negatives upset players. As any elective algorithm could be considered to have been 'designed', the implementation is the realisation of a design that mightn't have needed specifying - is an 

 an aspect of design limited to designers?


Given a brief that could originate from anywhere (clients, research, production teams), such as “make a backpack system”, designers and engineers can parallelise their work. One can program a generic backpack system based on items and weights to display using a rudimentary text console, while a designer researches and considers whether the player would prefer items to have realistic weight, which measurement system should be displayed in the front-end, and how the maximum weight should be determined as a factor of other game systems. Both parties influence the scope of the outcome, and specifications are suggestions, unless written by egomaniacs.


The overlap between these terminologies, and the fact that they can't meaningfully exist without each other, is why I 

 prefer to disregard this kind of discussion altogether, and why we have an emerging trend of 'technical designers' and 'technical artists' occupying the space in-between. After all, plumbers don't conform to a binary "pipe schematic designer", or "wrench wielder" - plumbers are plumbers, as on the front page of this website, I'm a "game developer".

The difference between design and engineering

Without pressure, life slows down. In otherwise action-packed video games, puzzles are unmasked as chores waiting idly for you to complete them, which can kill the pacing even if the puzzle in isolation is well-designed. Without pressure, a player mightn’t even pause the game when their doorbell chimes, leaving their character in an existential, 

 limbo while the background music fades and loops. Awkward, if they were supposed to be saving the world.

Pressure is a topmost concept. An active type of challenge, it creates tension, contributes to difficulty, and can produce anxiety and adrenaline. Like salt in a recipe, used well it can mellow out bitterness and enhance sweetness; used poorly it can give you a heart attack or leave you feeling... salty.

In Uncharted, periods of forced downtime see players go from swinging around cliffs and intense firefights to quietly traipsing back-and-forth between dark rooms pushing buttons

Famously, diamonds are created from pressure and time. In video games, however, time-sensitive tasks can be a lazy way of applying pressure. Players crave diverse new experiences, so developers looking to utilise time pressure have had to invent new ways to push players through their hoops.

Let’s consider one of the most pressure-oriented experiences in modern gaming: the 

. Generally, a large group of disparate players enter into a large combat arena that shrinks in size as fighting occurs, with the goal being to eliminate other players to become the last remaining team. In 

, shrinking the play area is a method of ensuring the game will eventually draw to a close should the players hide, get lost, or embrace pacifism. In their own arms-race to capture our attentions, developers have since stacked additional and increasingly complex mechanics on top of this model, resulting in many observable sources of pressure in a given game:

Vampire: The Masquerade Bloodhunt uses irregularly shaped safe zones and clusters of hostile AI to pressure players into rerouting


This means, for a game with guns, the qualities of a good player have as much to do with communication, time management and orienteering as being a sharp-shooter. These pressures translate into requirements like understanding how the server will spawn resources or alter the map, and staying abreast of time and enemy positions – additional strains on players’ cognition that are intensified by each other when they overlap.


One of the most interesting feed-back loops we can exploit here is the 

 of games. If the play area is altered automatically based on players’ actions, then we end up in a situation where players influence the world, which influences the players, which influences the world…

In PvP games, the matchmaking system sets the strongest precedent for pressure – if you’re pitted against seasoned professionals, they’re going to be able to apply pressure to you more effectively than a roster of newbies, regardless of the game's mechanics.

While Deep Rock invokes tired design paradigms like defending moving vehicles and base stations for set periods of time, the need to re-stock in-between combat forces a parallelization of efforts that pressures players into effective teamwork

In PvE games however, we have more control as designers to dictate the game’s events. My favourite example of this is Deep Rock Galactic, a sci-fi game about spelunking dwarves. While mining resources, an AI director spawns waves of mutant bugs to disrupt your progress. It’s a simple concept that works well because the system is context aware – like Left 4 Dead, the game will punish complacency, but reward you with a reprieve if you successfully fight back a wave of enemies. Constantly flitting between modes of mining and fighting keeps you engaged and alert, and provides enough variance to stave off boredom on repeat missions. With the right tuning, AI can give a game a satisfying ebb and flow, up until the player wants to pause the action.

I believe players should be able to pause the action. We should be mindful of boundaries as designers – we’re making something we want people to enjoy, not hold them hostage. A player should be invited to exert themselves, but be provided with an excuse should they fail - they may feel stupid for failing a level in a game with low-pressure, but better for having given a more difficult game “a good go”.

Horror games such as Phasmophobia and Pacify allow you to opt-in to pressure – players willingly submit to entering a scary environment, but can retreat back to the outside of their respective haunted houses (with some checks and balances…)

Both Apex: Legends and Vampire: The Masquerade Bloodhunt provide players with systems to mitigate punishment when under pressure, e.g. consumables that grant immunity to environmental hazards, and the ability to mark and drop equipment for teammates, revive them. Deep Rock Galactic missions, like the treasure rooms in Sea of Thieves, contain a finite number of resources, meaning while there isn't a discrete time limit, the level of risk increases the longer players decide to hold out (just don't lose your hat, Indy!).

In that vein, pressure needn’t be limited to time; it boils down to coaxing the player into giving a 

 in exchange for a reward. Applying pressure to an inherently uninteresting mechanic is an unjust punishment that will only cause frustration.

Punishment is a divergent topic, but it’s useful to understand that for pressure to work, you may also need a consequence for failure. Good games exist delicately, neither too-hard nor too-easy, but with no challenge, there’s (arguably) no reward.

Even a mechanically bereft, linear game invites the player to challenge themselves mentally – to engross themselves in it so far as to complete it, failure being to quit.

A casual mobile puzzle game like Crayon Physics still presents a challenge, but there's no real pressure to succeed by design, and little punishment to match; it's relaxing, and ergo has the right level of pressure to succeed in its goals.

Take the trend of 'parkour' platforming levels in games like Minecraft and Roblox, made simply using in-game editors: the higher you climb, the more pressure you feel to not plummet to your death. It's a concept that needs little explaining because it maps 1:1 with the real world, is more interesting the more times you 

fail on the way to success, and more frustrating the more times you become stuck on a difficult jump (could you provide more checkpoints and alternate routes?).

Some games reel back player progress, while others alter the world permanently to remind the player of their mistakes. In some games, a lack of punishment is the reward: “I didn’t fail, so I get to move on to the next level”. 


This is yet another thing that needs balancing – imagine if a battle royale booted you straight back to the main menu without fanfare after winning a game.

In Terry Cavanagh's Roblox level 'Climb the Giant Man Obby', the player, driven by the mystery of what lies at the top, is invited to scale an obstacle course shaped like a giant character with carefully timed jumps

The need to expunge pressure is apparent when considering that wildly successful games with 

. High-pressure, while fun, can lead to fatigue, and limit repeat sessions. A rollercoaster going at a constant slow speed would be boring, but a rollercoaster going at a constant high speed would be nauseating. Thinking of this as a tool as opposed to a caveat means we can plan content roll-out and opportune breaks in the action. The Warhammer series does this to great effect, expecting you to only complete one or two campaigns per session and returning you to a peaceful and ubiquitous social hub in-between, the prevailing tea-breaks between cliff-hanger endings.

An e-sports team celebrate a tournament win


If you find yourself frustrated at a section in an otherwise enjoyable game, identify sources and amounts of pressure and consider whether the experience would be improved by adding or removing them, changing their complexity, or allowing the player a level of control.

It might be the key to shifting your feelings from "ugh, it's finally over", to "whew, that was satisfying".

The role pressure plays in game design

Certainly, anyone who has ever imagined a new system of play, or an improvement to an existing one, could style themselves as a game designer. In the effort of putting my thoughts somewhere safe, I’ve been ruminating on what design means to me as a mechanical process. Empathy is an oft touted, yet muddlingly vague concept: “Put yourself in the player’s shoes in order to make a good game” – not untrue, but not very discrete or practicable advice. Rotes of advice such as this can easily become a box-ticking exercise during iteration if you don’t understand what you’re gaining by following it.

I’ve spent a few years now developing services to support online games, and one thing that’s struck me through innumerable playtests is how features are disappeared and resurfaced. The rationale behind these decisions tends to eventually click, but it’s not immediately apparent from the outside looking in just why this happens.

When I have an idea, I often enter that magical state of ‘flow’ where my stream of consciousness leads me to make many small decisions in my head, in the span of a few minutes. I realise I often do it while in the shower or out walking – I’m typing this article on my phone in the corner of a pastry shop.

When it comes to games, I’ll imagine myself as the player, moving through the world. It only exists in that way for me; I 

 the player. I’ll keep going until I find something that doesn’t work – a frustration or a roadblock. Like that 

, where an algorithm imagines a couple together enough times to figure out how compatible they are. That’s really where it starts.

I had an idea for a short-play online game where one invisible player would try to sneak to the other side of a task-filled room, while another player with a gun stalked around trying to find and shoot them. I liked the idea because it meshed the mischievous and social elements of Among Us and old Garry’s Mod levels.

It also helped that the idea was set in a single room. By literally constraining the design space to a Portal-esque test chamber, I could reason with the problems more concretely. Many online games with more ambition invite more questions haphazardly shuffled under the category of “later”, and I wanted to “fail-fast”.

We’re good at finding problems with things. As human beings, we’re always seeking to minimise our own discomfort, and therefore it’s quite easy to determine what’s not-fun about something. When designing an online game, you can use this quirk of nature to balance a design and arrive at a place where it’s fun for all parties. By asking cyclically: “how does this affect Team A?” and “how does that then affect Team B?”, you can make a more informed guess about an idea's longevity.

Take the game idea above – I imagine myself as the invisible player, nervous about the situation, immediately sprinting to the victory area. The hunter is surprised and upset to have been taken off-guard. It’s unfair, so the first concrete feature is to put a gate on the victory area – perhaps the sneaker needs to pull a lever which will be visible to the hunter.

Iterating now, I’m imagining myself as the hunter. There is a single lever in the room. I have no other point of reference. I stand patiently by the lever with my gun cocked. The sneaker sees no way forward and quits the game, and I’ve figured out I need a way of misleading the hunter – perhaps I need two levers. I take a bite of my sausage roll and begin walking.

This process repeats until I have a full, satisfying chronology, in which I’ve invited every silly idea that didn’t upset either player to manifest its presence in the game world. The hunter has a minute to move props around the room – traffic cones that tip over if bumped into, a pool of paint to leave footprints if stepped in, a pot plant to set off the sneaker’s allergies. The sneaker creeps to the back of the room and picks up a ball to throw and knock something over – a distraction! They dash to the first lever, then the second, bullets whizzing by their ear as they make it across the finish line. GGs are shared – it was a close call; they’ll get you next time.

Whether or not this idea would be a hit lies in its execution, and to some degree, the state of the world. What matters for now is that I have a flexible idea, a core loop can’t be immediately broken, and I’ve stepped through the scenario enough times to identify patterns of repeating elements.

In this case, I can draw a distinction between static objects that can be interacted with, and placeable objects that move, make noise, and potentially produce visual effects. I can continue to elaborate on these two lists, constantly re-sorting them in my head as a function of how fun I think they are for both parties, and how much hassle they’d be to prototype. I’ll pick three at the top of each list to form part of my ‘vertical slice’ and invent a shorthand lexicon for them – my 

. Building a mental framework like this helps you to prototype and iterate quickly, in addition to explaining your idea to bemused friends and colleagues.

I briefly consider if the lists are mutually exclusive to the hunter and the sneaker, or if both parties should be able to interact with both types – perhaps when both levers are pressed, the gate opens for a finite amount of time before closing and resetting them, meaning a keen hunter can sabotage the sneaker’s progress. Is that going too far?

Contrary to most advice, I think it’s important to let your mind wander into the future when ideating. Seeing all the ideas meld together into a blurry picture of the ‘final product’ can be useful in avoiding decisions that would render parts of it unrealizable. It’s painful to have a great idea mid-way through a project, and decide it isn’t feasible because it wasn’t included in the plan from the get-go. It’s equally as painful to ‘finish’ something, only to have somebody point out a glaring flaw in retrospect. In the idea above, having followed a particular line of thinking far enough, I can begin to judge the idea on its principles: the hunter relies heavily on sound (and ergo headphones), making it immediately less accessible to specific demographics of players who may have disabilities, or simply prefer to play unbridled on their television. Will it be possible to pivot?

I like to think of it likes waves on a shore. At night, when the tide’s out, you can see everything left as it was at the end of the day – a big collection of rocks and shells tumbled over each other, the lauded ‘final product’. Then, when the next day starts proper, the waves come and wash all the smaller things away, leaving behind the heaviest and stalwart ones.

It’s important to have a vision of how things will look at the end, otherwise, you can end up with a mess of bolted on features from iterating without a clear direction. How will matchmaking work? Will Twitch viewers be able to mess with the game? Will I ever want to make an object that is both interactable and placeable? Can I think of a catchy name? If you ask these questions now to get an idea, and then pull back, let them wash away, you can focus on what’s important. Everything else? “It’s been thought about, yeah”. My key goes into the lock on my front door, and I’m ready to write it all down and sketch the level onto grid paper.

Game design, among many things, is about the interplay between systems that evoke feelings. The space between is crucial – they can’t be considered in isolation.

For example, once you think you’ve hewn some maxims about, say, 

, you must consider them together for a specific design to see if there are exceptions to the rules. If you believe game should challenge you by becoming more difficult, and should include elements of randomness for variety, given a target audience of e-sports fans, will a very difficult game of chance frustrate players seeking to improve their skills? It all falls apart and lends credence to the importance of actual – not imaginary, playtesting.

Many of the ideas I had in my head, the ones that survived the initial culling, will still need to be tested with other people. Many will be discarded before then, and if enough are without replacement, then the whole idea will be too. Because this is such a quick process, this kind of conclusion is less disappointing than it is informative, given some ideas may be revived in more appropriate context later on. Singular mechanics may act as the seeds for other brand-new ideas in the future.

Recall that this whole process is in the effort of empathising with the player. A poor design is unsatisfactory, as it will always be uncovered by players – you can’t sneak a broken idea past a million critics. The most empathetic thing you can do for a player is to never ask them to trade their time for an experience you know is wrought with frustration, irrespective of the graphics or marketing budget. With an analytical mindset, and a desire ask “why?”, “why does this work so well and how can I prioritise it?”, “why doesn’t this work and can I change it until it does, or will the idea be improved by removing it?”, you can follow your own cyclical path to something truly worthwhile.

A thousand little playtests in your head

During this training course, I learned about the statistics and stigma surrounding mental health, encompassing different kinds of mental illness, under what circumstances and mental models a person may suffer from ill mental health, and what I can personally do to spot signs of distress in others and help guide them towards a solution.

Mental Health Aware Training

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.

Blog

Technological tattle, design documents, and miscellaneous musings written during various projects