The Fun Zone
Yes, I am still banging the drum about overly prescriptive game design.
- Behavioural modelling is not game design
- Punishing a player from deviating from your intended behavioural model has real-world parallels and none of them are good
- Punishing a player for not engaging with your game in the way you, the designer intended them to in an environment with no material consequence is absurd
- What constitutes ‘fun’ for somebody might be entirely different from what you as a designer intend
- No I do not intend to play ‘Doom: Eternal’
Look I’m aware that NuDoom and other games with clearly defined and formalised mechanics and loops get a lot of love, but I am so intensely weary of what amounts to a prescriptivist approach to play that has become utterly prevalent in game design over the past couple of decades. NuDoom’s approach of mechanistically enforcing an optimal style of play exactly in line with the designer’s intent (what Hugo Martin referred to as ‘The Fun Zone’) teaches the player by punishing them for deviation, through repetition.
Platformers such as Limbo, Inside and Little Nightmares actively punish the player for not anticipating the designer’s explicit intent in a scene, often forcing a fail state on the player for mistiming moves or simply not interpreting the designer’s ‘tells’ correctly. Call of Duty railroads players through its blockbuster setpieces, as do many other ‘prestige’ games, often having players embody avatars that may make decisions fundamentally at odds with a player’s interpretation of the setting.
The designer’s role in these types of games therefore becomes fundamentally similar to that of a film director, and interaction with the game is reduced to a state of not-quite-passivity, whereby a player’s agency is strictly meted out and parametrised. I feel the prevalence of this approach is fundamentally limiting. It is not a requirement for games to emulate cinema. Game design’s response to ‘ludonarrative dissonance’ has simply been to constrict ludology to fit a given narrative.
I desperately wish there were more games that truly bucked this trend. STALKER will forever remain one of my absolute favourite games of all time due to just going in a wildly different direction which has never been fully replicated, giving the player a fairly standard set of first-person shooter controls, but baking in incredibly rich background mechanics, and giving wide remit on how to tackle almost any given task. I can think of so many games that would benefit from emulating STALKER’s wide-remit approach to player agency, be they immersive sims, traditional CRPGs, first-person shooters, open-world sandboxes etc etc.
Cruelty Squad is another great example of this, giving the player large, entirely nonlinear levels and a set of basic mechanics and more exotic tools with which to interact with their environment. There are no incorrect approaches. Experienced players can finish levels in seconds. This is encouraged, but never actually mandated. Cruelty Squad was developed by a single developer in a free, open-source game engine and has by almost all conceivable metrics been an absolute success.
Hell, Breath Of The Wild is one of the most successful videogames ever.
I think game design thinking just needs to fundamentally trust the player more. That’s really just it.
March 31, 2021
OSR and Negative Space
I wrote a really terrible article last week about my distaste of formalised core loops in game design theory. I was honestly kind of surprised that some folk responded at all, and I had some really good explanations from people far more versed in this sort of thing than I am. That said, my view hasn’t altogether changed, and I still find the idea of tightly structuring and defining what the player can and should do to be infuriatingly narrow.
There are so many examples of entire gaming subcultures based around breaking out of imposed limitations: Speedrunning, boundary-breaking, virtual tourism, pacifist runs are just a prominent few. These are not new developments, and I would argue contribute a houge amount of worth and richness to gaming as a medium. And yet there is a lot of talk in design circles about saving the player from themselves or ensuring they don’t optimise the fun out of a given game, which while no doubt well-intentioned, can feel condescending and paternalistic.
I think part of my newfound distaste for this kind of approach partially stems from my newfound infatuation with the OSR (or, OldSchool Roleplaying/Renaissance) movement, which unlike more conventional pen-and-paper roleplaying, favours mechanical simplicity, and relies on conversation between the players and game-master to arbitrate what is or is not possible or plausible in a session of play.
Games like Knave, Mothership, The Black Hack or Best Left Buried, and modules like The Stygian Library, Deep Carbon Observatory or Lorn Song Of The Bachelor are all hugely imaginative, but share a common design thread of minimalist rulesets that encourage a more freeform and interpretative approach to play that is wildly exciting to me.
This is radically different from looped approaches, which attempt to model player behaviour in predictable and repeatable ways. I also think this is a solid example of what Jennifer Scheurle refers to in her wonderful article about Valheim and use of negative space in game design on Polygon. This, as somebody without much formal design experience under my belt, was absolutely eye-opening. Simplicity of formal mechanics and trust in how the player engages with the game are really at the heart of what I yearn for more of.
I realise I have touched on a lot here without going into detail on any of it, as to do so would take way more time than I have to spare, so I will just instead bullet point a summary of my thoughts:
- Trust in how a player engages with your work is preferable to me over trying to define how they experience it.
- The concept of defining a ‘core loop’ for a game is potentially useful, but often abused.
- OSR is a wonderful movement from a really diverse set of voices that deserves more serious consideration in game design circles.
- OSR mechanics would be staggeringly difficult to interpret into videogames, but perhaps negative space in design is a common thread.
- There are alternatives to established videogame design conventions hugely worth exploring
March 10, 2021
Against Gameplay Loops
The very concept of a ‘gameplay loop’ so fucking miserable and limiting. Conceiving of and designing videogames as pure mechanism is a truly horrible thing.
Just for writing this post, I decided to do a quick Google search for the term “gameplay loop”. Doing so pulls up diagram after miserable diagram, whittling the act of playing a videogame down to repetitive, meaningless chores, typically in the format of:
- Kill Monsters
- Win Gold
- Buy Stuff
- goto 1
The idea is repeated again and again, completely uncritically in game design circles. A videogame, according to conventional wisdom, needs a loop. Admittedly this is an incredibly hard thing to disprove because as a pattern, it can be inferred into almost any game ever, purely through reductive reasoning. The same is true of almost any human activity, and invariably, rendering them as a list of repetitive, mechanical actions will represent absolutely none of the joy or meaning of performing the action itself.
As a design pattern, loops were only formalised back in the mid 2000s. I have tried to find ealier examples than Jaime Griesemer’s infamous ‘30 seconds of fun’ quote, and came up with nothing. And yet they have come to completely dominate conventional thinking about game design, from highly commercial AAA products specifically designed to replicate the conditions of addiction, all the way down to the indie scene.
Here’s the thing though:
Games do not need formal loops to be memorable.
Mechanically-induced compulsion is not necessary in order for a player to experience joy, or sadness, or anger, or happiness.
I don’t really have the necessary know-how or diction to seriously consider alternatives, but Anna Anthropy’s theories on verbs and objects feel like a worthwhile place to start exploring. I have some theories on why the range of expression afforded to a player is a far better touchstone for design. Many of even the best-selling videogames of all time deal with player expressivity in interesting and occasionally radical ways (lookin’ at you, Minecraft). I also haven’t even touched on things like the indie RPG / old-school roleplaying scene and the radical rethinking of mechanics and how players interact with their games there. Maybe I’ll write up something about them next. Talking of which, I’ll close out with this quote from one of my favourite RPG writers Luke Gearing:
March 2, 2021
Where Abundance Lies // Some old devlogs from last year
22/04/2020 Started new Godot project using 1stPersonStarter as base, as there’s some weird-ass magic going on in the developer’s GDScript that fixes all of Godot’s weirdness when it comes to movement and physics. Implemented basic firing logic for character controller. NEXT / TODO: Modularize firing logic by breaking out into separate BulletEmmitter class a-la Miziziziz’s modular weapons code. Then, draw the rest of the fucking owl.
23/04/2020 Broke out firing logic into weapon and emitter nodes for modularity. func fire(): sends signal to BulletEmitter to spawn projectile NEXT / TODO Figure out projectile spawning logic, use global_transform for zeroing projectiles on centre of screen
29/04/2020 Basic firing / projectile logic complete although hacky. Player can now walk, run, climb, jump and shoot. NEXT/TODO: Design some basic test levels and placeholder enemies.
30/04/2020 Started work on new test level - slowed significantly due to me being a goddamn idiot, setting up my hierarchies incorrectly and wondering why my player controller was flipping out (PROTIP: don’t add it as a child node of your geometry meshes). Adjusted bullet speed to try and mimic real-world velocity better. Adjusted walk-speed and jump height to feel a bit more STALKER-like. NEXT/TODO: Continue building out geometry for test level. Basic structures, walls, elevation etc
03/05/2020 Work continues on test level. Tweaked materials and bullet velocity. Investigating using godot-ink for dialogue and quest mechanics. NEXT/TODO: Work out schedule for working on game properly over weekend. Build test level out further. Add godot-ink to project and begin investigating how to implement dialogue
Todo for week beginning 04/05/2020
- Implement interaction logic for player controller (i.e. press e to do thing). Refer to CodeWithTom’s video for example
- Build UI element for displaying dialogue on screen
- Implement basic non-interactive dialogue for dummy NPC
- Install godot-ink into project
- Write basic dialogue tree in Ink
- Investigate how to get Ink dialogue displaying ingame
05/05/2020 Feeling sleepy and uninspired so playing Metroid Prime instead. Inb4 accusations of scope management issues. Fook off m8
10/05/2020 Currently working on switching dev environment over to Linux bc Windows sucks ass. Running with Pop!_OS just now, which is pretty awesome. Fast and stable. Still need to get drivers for graphics monitor working, in progress
Lesson learned: It is absolutely not worth planning huge chunks of work for given days, for I have the planning capacity of a goldfish
“Inb4 accusations of scope management issues. Fook off m8” It turns out I have scope management issues
10/05/2020 Implemented base interaction code using raycast. Current plan is to keep player’s interaction code as simple as possible and store each bit of interaction logic on the class being interacted with (i.e. when NPC senses it is being interacted with, call dialog script)
11/05/2020 Messed around with interaction code some more. Yesterday’s attempt was too simple to be useful, so adding a bit more scope using CodeWithTom’s example. Basic interaction logic finished. Can now hopefully use this to extend into more specialised scripts for dialogue etc
12/05/2020 Not much today, just cleaned up a bit of debug print code as my firing system’s working as intended now. NEXT/TODO: Start work on child classes for interaction nodes. Start real simple and add a print statement for when the child class is interacted with.
13/05/2020 Don’t really have the mental capacity to think about code much tonight. Currently busy writing up a formal design document. Feeling inspired after reading about Splash Damage’s Dirty Bomb design doc
21/05/2020 Unexpected hiatus, but looks like my hard drive is about to crap out, so work is suspended while I move all my shit to a new drive.
23/05/2020 Currently setting up everything to work under Linux. Project imports and runs. Refraining from doing any work on it until new hard drive arrives. Considering setting up Github page for project
26/05/2020 New hard drive arrived. Project ported over to Godot 3.2.1 on Pop_OS. Everything just kinda works. Groovy.
10/06/2020 Funny how being stuck in the middle of both a global pandemic and a huge amount of social upheaval fucks with your productivity. NEXT/TODO: Fuck knows. Black lives matter.
27/07/2020 Started work on weapon modelling. Basic design for sidearm pistol maybe 50% done. NEXT: Complete pistol design - Trigger, greeble, laser sight thingy
28/07/2020 Continued work on sidearm / pistol thing. Some passable visual interest. Still looks like shit but not too bad for two days work on My First Hardsurface NEXT: Refine pistol but don’t overwork. Switch to modelling basic scene props - Rocks, trees, basic architecture etc etc
16/08/2020 Everything is fucked. Every time I spawn a projectile, my character loses collision and falls through the level. GlobalTransform is the culprit. If a collision mesh spawns inside my player’s collision, everything goes borked EDIT: Nope, doesn’t even need to be conflicting collisions. If I use GlobalTransform AT ALL, collision is nulled. What the fuck.
Considering starting from scratch on this. This is absolute bullshit.
Reverted project back to last backup, re-imported weapon and applied transforms. Everything now magically works again and I’m not sure why :thinking::thinking::thinking: :thinking:
18/08/2020 Putting WAL on hold for now. Work done so far is going to be channeled into a much more manageable project that I’m hoping I can get out the door with some concerted effort. Purpose of which to build a much more solid foundation to build WAL out on.
29/08/2020 Manageable is fine, but ambitious is way more appealing. Got some more experiments I want to do here.
28/12/2020 Lots of on-paper doodling of ideas. Designed basis for high-level AI needs / task system. Considering holding off on further dev until Godot 4.0 alphas start to drop, as lots of current issues such as physics implementation, lighting, rendering and GDScript performance will supposedly be addressed. Also may wait to see state of 64-bit coordinate system, as this may make level-streaming and coordinate precision non-issues.
25/01/2020 Considering reworking weapons into less complex raycast system. Very little tangible benefit to wholly projectile-based system that can cause Godot’s collision to completely freak out. Will keep for launcher-style weapons, but raycast = less issues Need to have milestone system for work-towards / focus / motivation. Tackle different parts of game logic etc
February 28, 2021
Where Abundance Lies // Option Paralysis
The ideas I had for Where Abundance Lies initially derived from a series of vivid dreams I once had. I’d been playing a lot of STALKER and Destiny and reading a lot of Nihei at the time. Someone who was myself, or just as likely somebody else, searching vast, lonely ruins for something. Ideas are, of course, the fun part of any creative project that doesn’t happen spontaneously. A game that borrowed liberally from STALKER’s gameplay philosophy set against a backdrop of a posthuman future exploring endless, brutalist ruins succumbing to the encroachment of decay and nature. Fucking excellent. Genius. Going straight to my magnum opus from a dude who’s done sound design for a couple of small indie projects. What could go wrong?
I’d already had some experience working with game engines. I’d poked about in Unity and Unreal some, so felt confident that if I just applied myself and kept reading, I’d be able to figure out at least the basics of developing the sort of game I wanted to make. For some reason I decided to land on Cryengine. I can’t quite remember why, but I think I liked the idea of having a fairly complete first-person shooter template built into the tools. The global illumination was neat. I tried for a bit, but the further I got into trying to work in Cryengine, the less I understood about what I was doing. So after making a pretty embarrassing Youtube video announcing work on the project, I soon realised I was in way over my head, and promptly switched tack.
I’d also been playing about with Godot in my spare time and had become pretty charmed with it. I found that I could actually write a bit of code in GDScript, Godot’s own scripting language, which felt incredibly empowering. I felt strongly that I needed to understand the mechanics that I was using in whatever game I was making. Even though Where Abundance Lies is little more than a demo of simple FPS mechanics as of now, I’m not entirely sure I regret the decision to do so.
So to sum up, I’m currently in a position where my game project is still little more than ideas and experiments, and the more I think about it, the less I feel that was a bad decision. I have a foundation to build on that is all my own. Godot 4.0 releases soon. Maybe I should revisit this whole thing then.
February 28, 2021
Hello World
I set out to make my ‘dream game’ about two years ago. Predictably, I have resolutely failed to do so. I intend to use this blog to gather my thoughts as to why this happened, how I could do better going forward, to be a pinboard for ideas and inspiration, and, hopefully, to have another attempt at doing so. I’ll probably fail again, but I hope, at least, that these failures could be instructive in some way.
February 28, 2021