remembercomic

[remembercomic]

Killer Concept: The Witch

Dead by Daylight has more than its fair share of "witch" type characters as-is between Hag, Artist, and Nurse, but prompted by chat earlier today I thought I'd give a shot to adapting my own OC, the Witch (or witch!Lying), to the context of a video game full of murderous psychopaths that constantly terrorise and torture hapless civilians.

Let's start with the core concept:

A chase Killer with a ranged debuff attack and a connection to the crows that inhabit the Entity's realm.

And with that, the outline of the Witch's lore:

Living in a cabin in the woods on the outskirts of town was just fine for the Witch, giving them just enough privacy to practise their eldritch magics, construct little charms and talismans to forgotten gods, and especially to terrorise the villagers who dared step just a little too far beyond the treeline. But eventually, probably after one too many spooks, or maybe the child that was chased into the river last winter by ravens, or possibly the whole family that went mad after finding their house picked clean by the same three-eyed birds mocking them all the while, the townsfolk got nervous enough to dare. Despite a harrying amount of ravens cackling at them as they made their way, they laid siege to the cabin and set it ablaze. And as the Witch gave one last hearty cackle to terrorise their revolting victims, the Entity stepped in to claim them. Now in the Fog, the Witch is surrounded by crackling flames and watchful black birds, and charged with one solemn duty: Make them fear

First, the ability:

Cursed Flame The Witch can toss a small fireball which flies on an unerring trajectory unaffected by gravity (ie. always in a straight line). If hit by the fireball, healthy survivors become injured, and injured survivors are afflicted with Deep Wound. Has a short wind-up and uses charges, similar to the Nurse's Blink, which need time to recover once expended. A number of add-ons apply status effects to survivors struck by the fireball, including the usual Blindness, Mangled, and Exhausted. Eldritch Wings The Witch is old friends with malevolent black birds, and the Fog is full of them. Like the Dredge, they can teleport to undisturbed crows around the map, with their appearance being heralded by small flames that crescendo as they arrive. Additionally, they can teleport to just shortly behind a visible survivor within their terror radius, appearing in a flurry of black feathers, though this puts the ability on a considerably-longer cooldown compared to the crows.

Second, the perks:

Sinking Sensation: Survivors within your terror radius have any Exhaustion effects slowed by 12/16/20% (eg. the Exhaustion caused by Blood Echo would last 50-54 seconds instead of 45 seconds if spent entirely within your terror radius). Three-Eyed Ravens: Survivors who startle crows within your terror radius have their aura revealed for 6/8/10 seconds. This could be likened to Spies From The Shadows, but the dependence on terror radius makes it more variable, such as being worthless for most stealth killers. Omen of Doom: After hooking a survivor, a random injured or healthy survivor hears your terror radius approaching for the next 6/8/10 seconds. You still emit a terror radius as normal. Any effects applied by your terror radius (eg. Coulrophobia, Overwhelming Presence) also affect the haunted survivor.

The general playstyle is to use surveillance-type perks to monitor the map and teleport between generators using the crows, then when in a chase using the teleport to quickly catch up to a fleeing survivor in a similar fashion to the Singularity's Overclock mechanic.

Their fireball serves to give them ranged potential, but it can't down a survivor by itself (unlike most ranged killers so far) so they still need to get close, such as by using the teleport at the cost of needing to really stick the landing on the subsequent hit or else risk a more protracted chase. Debuff add-ons would give it some hefty versatility as well.

#dead by daylight #game design

[remembercomic]

Competing With The Optimal

In the long history of Minecraft, there is a handful of recurring game design elements that have appeared quite prominently amongst the various mods made for the game. Ore multiplication, item transportation, automated crafting, etc.

Of particular note at this time is that third one: crafting, because as of Java Edition version 1.20.3, the developers at Mojang have added the Crafter. After 12 years since formal release version 1.0, the unmodified version of Minecraft may soon have its own solution for automated crafting.

In terms of its design, the Crafter is a fresh entry in a troublingly-long series of changes made to the game that introduce a solution to a problem that obviates all others. It has exceedingly few drawbacks and occupies only a single space in the cubic grid, rendering any attempts to address the challenge of auto-crafting irrelevant if they don't somehow occupy an even smaller footprint. Its user interface is unique, in that slots can be toggled on or off, preventing them from receiving items whilst still contributing to the composition of crafting recipes. It even spits out the crafted product when triggered, either into the open world to be collected by the player or into an adjacent inventory, including other Crafters.

How then do mod developers compete? How can they reclaim some ground in what has historically been one of the high notes of virtually any mod with a solution?

Well frankly, they can't. Like the Shulker Box and the Elytra, the Crafter is a solution that renders the problem trivial, so the modders need to do something more creative with the solution in a way that complements rather than attempts to exceed it.

For the purposes of the Tricksy Foxes project, there are two blocks that attempt this: The Work Table and the Clockwork Friar.

The Work Table (planned only days before the Crafter's announcement) serves as a mid-point in the evolution from Crafting Table to Crafter. It has an inventory, it can still be used for crafting, and if triggered can craft its inventory according to a matching recipe. It does not have toggleable slots nor can it dispense its product into an inventory, but it can serve very well as a crafting table with built-in storage or a simple compacter (a form of recipe common in modded and unmodded gameplay). Relative to the Crafter, it's also quite cheap, requiring only humble wood to create.

The Clockwork Friar is almost a step beyond the Crafter, but comes with its own drawbacks in comparison. A programmable automaton, the Friar similarly has an inventory like the Work Table, but can only hold up to 9 items at the most. This informs it of the recipe it is to process and, when triggered, it siphons the ingredients from neighbouring inventories directly instead of needing them piped in. It can also be triggered with a simple interaction, with no inherent need for complex wiring. However, it is twice the size of the Crafter and Work Table, like the Crafter cannot be used for everyday crafting, and like the Work Table cannot deposit its product.

Ultimately, neither of these blocks seeks to directly compete with the Crafter, but rather to serve as useful tools in their own specific use-cases. In the context of Tricksy Foxes, a mod based around automation using behaviour trees, they serve as a means to easily enable the foxes to craft items, an action that would be overwhelmingly complex if it were performed solely inside of the behaviour tree implementation itself.

#game design #tricksy foxes #projects

[remembercomic]

Fundamental Elements of Automation

It can roughly be said that a behaviour tree is only as useful as the sum of its available conditions and actions, to that end when building a behaviour tree system for the purposes of automation it becomes important to consider what actions the player takes most frequently to identify what nodes will be necessary.

Virtually all sandbox games for example include a degree of inventory management. This is to say, not only picking items up from somewhere in the world but also moving them intelligently into a container for long-term storage. Useful conditions in these contexts include the exact type of item that a given item represents (such as a set of wooden planks or a valuable ore), and whether a given container is appropriate to receive it (either because it has been designated as such by the player or because it already contains some amount of the same item).

In Minecraft, the majority of automation falls into this category, a task which is typically addressed through the usage of a great many hopper blocks, which both pick up items that land on top of themselves and transfer them to other containers or hoppers in a predictable and linear fashion. It is then up to the player to properly engineer only the intended items to arrive in the intended containers.

A behaviour tree approach is quite valuable in this context, as it enables a singular agent to take the place of possibly dozens or even hundreds of ticking tile entities with considerably less engineering needed on the part of the player. Instead, they only need to walk through the steps they themselves would take to perform the same task.

Automation seldom ends here, however. There may be occasions where specific player-taken actions are needed, often specifically relating to certain items held in hand. This might range from applying a food item to multiple livestock to initiate breeding, to mining resources (both in the wild and in controlled environments), to attacking hostile agents in the pursuit of certain rewards (aka "drops", after the tendency of such items to "drop" once the entity is slain).

These tasks may be simplistically reduced to repeating them endlessly (in the understanding that the desired context will just happen to occur whilst the loop continues) or performed more conservatively (such as waiting until a sheep's wool has regrown before trying to shear it). This presents a quandary in terms of efficiency: The eternal loop approach will inevitably require fewer behaviour tree nodes, whereas the efficient approach will inevitably require more, hence the efficient tree has higher computing costs. This poses a problem when attempting to maintain a low-impact system, which is difficult to overcome without providing very low-impact and often hyper-specific conditions.

However, despite this challenge, it can be foreseen that the end result remains less severe on a server's resources than the equivalent in a large mechanical system as well as providing opportunities for players to continue playing the game. This is to say that as many of these more complex automation tasks require the player to undertake them, either by writ of how interactions are performed or by their complexity, it becomes increasingly necessary for the player themselves to perform them. This can range from mindless repetition of the same action for hours on end or, even less palatably, from automating the player's control inputs directly (such as by an external auto-clicking application).

But in all this there is an overarching question: Is it fun?

By alleviating the need for large complex systems, reducing much of them down to only a handful at most of behaviour tree-driven programmed agents, are we eliminating part of what the player finds enjoyable in the first place?

Surely the end product is less time-consuming and less prone to error in the event of malfunction or mistake during construction, and for many players the engineering is indeed the entertaining activity. However, there is skill and puzzle to the design of an efficient behaviour tree as well, which can be construed as being different but similar to the original approach.

#projects #tricksy foxes #minecraft #behaviour trees

[remembercomic]

A brief demonstration of one use-case for editable behaviour trees for the purposes of sandbox automation, featuring a fox.

The tree used in this demonstration is 15 nodes in total, which is relatively small. It primarily consists of only two behaviours: retrieving up to 8 fuel whenever its hands are empty and the lamp is on, and cycling through the furnaces giving them 1 fuel each. Otherwise, it waits at its initial position.

The lamp itself only serves as an indicator that enough fuel is present to retrieve, which ensures the fox distributes it evenly. Beyond that, the fox's behaviour tree is entirely responsible for the automation demonstrated.

In this particular implementation, the number of furnaces is entirely arbitrary and the tree can handle as many furnaces as the fox can hold fuel. The only thing that would need to be changed is the contents of the Furnace Array variable, the tree would handle everything else.

Without the fox, this particular automation problem would necessitate dozens of ticking tile entities (in the form of hoppers) and significantly-complex wiring dependent upon discrete knowledge of the game engine.

#tricksy foxes #behaviour trees #minecraft

[remembercomic]

Kerbal Space Program was once afflicted by a bug the fans dubbed the "Deep Space Kraken", whereby if you travelled far enough from the origin of the game's coordinate system, floating point rounding errors would cause your spacecraft's components to become misaligned and/or clip into each other, resulting in the craft falling apart or exploding for no obvious reason.

The bug was later fixed by defining the active spacecraft itself as the origin of the game's coordinate system. In effect, the spacecraft no longer moves; instead, the spacecraft remains stationary and the entire universe moves around it. Owing to how relativity works, to the player this is indistinguishable from the spacecraft moving about within a fixed coordinate system, and it ensures that the body of the craft and its components will always be modelled with maximal precision.

While elegant, this solution introduced a new problem: it was now possible, by doing certain stupid tricks with relativistic velocities, to introduce floating point rounding errors to everything except the active spacecraft. In extreme cases, this could result in the destruction of the entire observable universe.

Some might call this one of those situations where the solution proves to be worse than the problem. I call it a perfect expression of what Kerbal Space Program is truly about.

#kerbal space program

[remembercomic]

I love it when an rpg has a huge potion making system and it’s just 

health potion 

better health potion 

best health potion 

bestest health potion 

fire resist potion (useful in one battle) 

jar of bees

[remembercomic]

Making Magic Feel “Magic”

In many video games, players are gifted with a set of abilities to use as and when they choose. In many cases these are representative of their character’s distinct and often-superhuman capabilities, and in the case of fantasy settings in particular they are frequently magic spells.

However, there’s something to be said for the lack of immersion involved in knowing your character has studied and researched for years, gathered vital reagents in the wilderness, and has uncovered the ancient sigils necessary to produce an arcane fire bolt... and pushing keybind 1 to actually use it.

Immersion is the property of a game that makes the player “feel” like they’re in the game environment doing the things that their character is purported to be doing, rather than simply interacting with game objects and menu screens. It can be a hindrance to necessitate that players go to such lengths, but it is an important facet of player enjoyment, particularly when dealing with things outside of normal life like magic.

Over the course of the last decade, Minecraft in particular has seen an entire genre of mods themed after magical effects.

One of the earliest was Thaumcraft, which notably featured a research system that required players to examine blocks, items, and creatures in their environment to glean points to invest intelligently into a research UI at a research table in order to unlock new tools and devices. Whilst the presentation could be described as immersive and certainly it and the rewards were themed as magical, the ultimate payoff is decidedly less so. Sure you have an item that releases a gout of flame, but that’s really just a texture pack away from being a regular flamethrower, and what’s more it’s identical to what someone you’ve had no interaction at all with has made thirty servers over. This ultimately makes Thaumcraft fall short in the sensation that you’re a mage in seclusion studying the arcane and putting it to use, it’s really more of a coat of paint over a tech tree.

After Thaumcraft came the Witchery mod, though it was sadly short-lived despite numerous innovative gameplay features. Witchery focused on simple devices that could be interconnected, with no research required but with some incentive to play around and experiment to get a better understanding of how different parts worked. Included was the Mystic Branch, a wand-like item that allowed players in the field to draw out directional patterns to produce various magical effects. Ultimately however, the wand was difficult to use and the spells were predefined, so few players invested time into it and those that did mainly resorted to a handful of the available effects in particular.

Then came mods like Psi, Ars Nouveau, and Hexcasting. These mods made a severe shift to the existing framework by focusing on one specific concept: Custom spells. Instead of the hard-coded spell effects of earlier mods, these mods allowed players to create their own through different systems. Ars Nouveau used a single-line linear system of distinct glyphs to create effects, Psi had a visual programming-esque interface to perform logic and calculations for effects, and Hexcasting required the user to draw pre-coded glyphs on the screen to perform mathematical operations on derived variables.

Whilst the addition of personal spell-crafting was a major step forward, the actual execution in these mods was... lacking somewhat. Ars Nouveau was so simple that it was very easy to understand even for novice users, but this meant that many spells ended up looking much alike and more-over this deprived the spells of a lot of their “mystique” as magic. Psi and Hexcasting conversely were very unfriendly to players without some background in programming, with Hexcasting even necessitating that its glyphs (arbitrarily made and hard-coded) be memorised, as its creation screen deprived the user of all outside knowledge in-game. This ultimately made them both too tedious for players to invest in and similarly lacking in mystique.

In summary, whilst strides have been made in better enabling players to “feel” like powerful mages studying and creating new spells on their own, there remain some obstacles to the “sensation” of doing so. I think the addition of manual spell crafting is an important effort, and doing so in a programmatic manner so as to allow spells to be more diverse helps to sell the narrative that you are studying and creating them in your own personal way, but it needs to be conveyed to the player in a less overt fashion whilst paradoxically being as comprehensible for players without programming experience.

To attempt to describe a potential approach that meets these requirements, a common almost-quintessential feature of many magic systems in fiction is that of the magic circle.

The magic circle is, as its name suggests, a circular arrangement of glyphs and imagery connected by drawn lines or additional circles, resulting in a magical effect. The actual logic of such arrangements is usually quite minimal, as it is rarely necessary for the audience to properly comprehend the fine detail of magic in the setting beyond simply that one magic circle arrangement does one thing and another does another different thing.

However, if a system could be described that leads the player to develop their own magic circle arrangements with sufficient programmatic logic to enable them to readily design them to specific ends, I think this would produce the missing immersive property of the previously-described approaches. The benefit of magic circles is that they provide meaningful structure in an unorthodox fashion, preserving some volume of magic mystique, without necessitating memorisation of arbitrary shapes (as any UI to create such arrangements would necessarily need to provide them for placement) or high levels of real-world programming ability.

Moreover, such an arrangement with programming logic embedded could easily be stored as an external object to be shared between players, like wizards sharing research notes, and letting the players actually feel personally involved with the development of magical knowledge in their gameplay.

Of course, this approach is by no means simplistic in implementation. The allure of hard-coded effects in the earliest mods was that you always knew what it would do and it was very easy to implement new effects during development. A programming approach necessitates some form of compiler to convert the user input into an executable program. This was simple enough for Hexcasting and Ars Nouveau with their sequential operation strategy (each provided operation happens one after the other until end), but quickly grows more complicated for Psi or this hypothetical magic circle approach.

#game design #ui design #magic

[remembercomic]

So I got quoted in a book about gaming during the pandemic because of this post...

The epidemic began on September 13, 2005, when Blizzard introduced a new raid called Zul’Gurub into the game as part of a new update. Its end boss, Hakkar, could affect players by using a debuff called Corrupted Blood, a disease that damages players over time, this one specifically doing significant damage. The disease could be passed on between any nearby characters, and would kill characters with lower levels in a few seconds, while higher level characters could keep themselves alive. It would disappear as time passed or when the character died. Due to a programming error, players’ pets and minions carried the disease out of the raid.

Non-player characters could contract the disease but were asymptomatic to it and could spread it to others.[2] At least three of the game’s servers were affected. The difficulty in killing Hakkar may have limited the spread of the disease. Discussion forum posters described seeing hundreds of bodies lying in the streets of the towns and cities. Deaths in World of Warcraft are not permanent, as characters are resurrected shortly afterward.[3] However, dying in such a way is disadvantageous to the player’s character and incurs inconvenience.[4]

During the epidemic, normal gameplay was disrupted. Player responses varied but resembled real-world behaviors. Some characters with healing abilities volunteered their services, some lower-level characters who could not help would direct people away from infected areas, some characters would flee to uninfected areas, and some characters attempted to spread the disease to others.[2] Players in the game reacted to the disease as if there was real risk to their well-being.[5] Blizzard Entertainment attempted to institute a voluntary quarantine to stem the disease, but it failed, as some players didn’t take it seriously, while others took advantage of the pandemonium.[2] Despite certain security measures, players overcame them by giving the disease to summonable pets.[6] Blizzard was forced to fix the problem by instituting hard resets of the servers and applying quick fixes.[3]

The major towns and cities were abandoned by the population as panic set in and players rushed to evacuate to the relative safety of the countryside, leaving urban areas filled to the brim with corpses, and the city streets literally white with the bones of the dead.[7]

#life is bizarre sometimes

[remembercomic]

wow players having to stand in lines for a quest because a relevant npc can only talk to one player at a time. is the funniest image on the planet

#world of warcraft #game design

[remembercomic]

UI Design for Unit Control

In many games possessing of a combat mechanic, players are gifted the benefit of companions to join them in glorious battle and tackle their enemies.

Under most conditions, these companions are governed by an AI system that the player has no involvement in. Typically, this is by way of a conventional methodology such as a behaviour tree or finite-state machine, with the occasional inclusion of utility functions to moderate what special behaviours and/or abilities are best used in different contexts. This is advantageous because it frees the player from having to micro-manage their companions during combat, which is especially valuable during real-time gameplay such as in the Dragon Age or Elder Scrolls franchises or The Outer Worlds.

However, it is the reality of sufficiently-complex gameplay that a one-size-fits-all approach to an AI’s behaviour is rarely going to suit all contexts as and how they develop, thus necessitating the gifting of the player with some degree of command over their bold group of daring adventurers. In the case of The Outer Worlds, players may allocate companions to particular roles (namely to attack aggressively, to follow your lead, or to remain passive unless directly instructed otherwise), though this represents a very limited control and exclusively only affects their behaviour in combat.

This is then further complicated by the real-time aspect, meaning that in an ideal circumstance the player must be able to deliver commands to their companions whilst staring down an oncoming assailant with minimal disruption to their efforts to get out of the way.

In the case of the Various Oddities project, the gameplay conditions are as follows:

Players may optionally have multiple companions at any given time, up to a maximum limit determined by server configuration settings

Players experience the world in a first-person real-time context

Players may engage with the world in combat, construction, management, and destruction modes, and can switch between such tasks freely without interruption

This immediately poses a substantial problem: With so many possible contexts, companions must be able to provide useful functions in as many as possible in order to be worth recruiting, and hence the player must at all times be capable of commanding them to conduct any of several dozen different tasks (28 and climbing at time of writing).

Additionally, because multiple tasks exist for combat scenarios (guarding targets, positions, or the player, attacking, ceasing fire against one target or all, etc.), the tasks must be navigable quickly and reliably with minimal error even under tense hostile situations.

Hence, we are presented with a question of how to present the player with so many options without overwhelming them in moments where they the least available time to parse them.

It becomes quickly clear that the first priority is to minimise the options the player is presented with at any given time. By identifying what the player is most likely looking at when they begin the process of giving a command, we can narrow down the list of options they are likely to be looking for. A player looking at a large rock in their path is, for instance, unlikely to be in need of the attack command (depending on what you define “attacking” as, at least) but may be interested in the guarding-position or mining commands.

However, there may still be an unwieldy set of options after this initial culling. And if we are to presume a combat situation, the player will want to use as few keys as possible to select the option they want, hence ideally we want to be as close to one keypress as we can be. The result of this is that even a handful of options may nonetheless prove too slow to peruse, and further culling is needed.

Given that we can identify a set of general contexts to associate different commands with, such as combat vs construction, we can generate categories of options and present the player with the highest-priority option of each category with at least one viable option. This swiftly reduces the amount of searching the player has to do to, at most, the number of categories and the order in which they are presented. If the player is pointing at a hostile enemy unit, for instance, we can safely presume that they are most likely to be looking for the attack command, and present that as early as possible to them in the set of options.

Given that gameplay is as diverse as described, our presumptions may not hold true and will, more likely than not, ultimately fail some players in a great many occasions. To that end, it is beneficial to present all viable options in each category, so that they may take their time to be precise if necessary.

Development in Various Oddities ultimately settled on a mid-keypress and scroll wheel approach to the command process.

Once the player depressed the bound key, the system identified what they were looking at (either an entity or a position, with further qualifications made per-command) and culled the available options accordingly, without pausing the game or opening a menu screen that would potentially paralyse them mid-combat. All information was presented via an on-screen overlay instead to minimise disruption to real-time gameplay.

The player was then free to use their scroll wheel to navigate between the top-priority options of all categories with at least one (attack for combat, go-to for motion, etc). Then, after a short and configurable period, were locked in to the category they had selected and able to choose from further more-contextual options.

Once the player had found their desired command, releasing the bound key transmitted it to the server for execution. All without ever preventing them from moving or exercising their agency in almost any way.

#ui design

[remembercomic]

Despite not using this blog since 2019, I’ve actually been doing a lot of interesting development work across a few different projects. I usually post those to Twitter, but under the current circumstances it’s likely that anything I post there will be lost in short order, so I’m going to try and post little diatribes of my work here from now!

[remembercomic]

The Gods Behind The Curtain

In many roleplaying games, players have the option to pledge their service to a fictional deity in exchange for boons and guidance. In the case of tabletop games, the role of the deity in question is typically handled by the game master, who observes the noted personality, ideals, and influence of the god and acts their role as expected.

However, in video games it tends to be that the god serves as little more than a set of effects and values and then may occasionally spit out some pre-planned declarations and questlines. This makes the gods much less mysterious, as players can expect them to act the same way each playthrough even with multiple players representing the same god.

To that end, I’m going to pose the question of how to implement deities with regular properties whilst preserving the mystique of an unseen ultra-powerful entity whose opinion you must consistently worry about.

Step one: They need to be invisible.

Though players can occasionally contact their respective gods, under normal circumstances they never actually see them and almost never speak to them directly at length. They’re unseen and unheard, with even the most divine of classes such as clerics and paladins getting only the occasional message from them.

Keeping the gods outside of player’s sight helps to hide their motivations and viewpoints, as long as they retain the vital values that setting and lore requires. It also greatly assists us by reducing the necessary complexity of their AI.

Step two: They need to have personality.

Whenever a player chooses a god, they have some expectation of how that god will behave and respond to their actions. This means that whatever system is used to represent the gods, it has to be reliable and consistent.

However, if we choose to keep the gods hidden and their direct influence with players minimal, they don’t actually need to be very thorough. We can seed them with specific known values (alignment, domains of belief, gripes, etc.) to give them reliable outputs in those matters, but everything else can be nearly random.

The final implementation of this system can be a number of different possible architectures. The most obvious is the neural network, which we can generate from a genetic algorithm using the seed variables as the genes.

As long as the vital questions give reliable answers, the players will naturally ascribe meaning even to the random answers regardless if there isn’t any intentional meaning actually present. A god of water needs to reliably respond appropriately to water contexts, but everything else can be arbitrary.

Step three: They need to seem to care.

Whilst actual miracle events could be made to randomly occur, like a momentary buff or incident of seeming divine intervention, with enough hidden information it’s possible that the influence of a player’s god could simply be inferred rather than evidenced. However, if players don’t think the gods are intervening at all, then their association with their god will seem meaningless.

Therefore, on the grounds that the gods are actually a seeded random output, it’s best to make their influence equally random and let the players attempt to draw connections. A meaningless “Miracle” status effect for instance will prompt players to question what it affected and, more importantly, what they need to do to provoke its appearance.

Additionally, in the case of player classes most directly tied to their chosen deity, such as clerics and paladins, the gods could be made to “whisper” to them in vague terms. The occasional on-screen message, devoid of context but describing the god’s view of some arbitrary matter, would be enough to prompt the player to reconsider their present course of action in order to better appease their god, under the assumption that doing so will improve their likelihood of miracles and their performance in gameplay.

Again, nothing actually needs to change, only the player’s perception of their relationship to their chosen god. If the player receives a message from the divine that sounds disapproving, they will most likely decide against whatever they are currently doing, even if they can’t necessarily identify why it would be bad or even what the god is specifically referring to. The messages themselves can be extremely limited in tone, only 2-3 are needed.

If players believe that their god is watching them and that they can and do make actual interventions into gameplay, then the god themselves doesn’t actually have to materially intervene at all.

Conclusion: A god is what the player imagines a god is.

The ultimate goal of this approach is to minimise the actual complexity of gods by hiding them from direct view and giving the players just enough interaction with them to allow them to infer their personalities and ideals. As long as the players believe that their behaviour reflects on them to the gods, and that the gods will then choose to intervene on their behalf, they will naturally conclude that whatever information they have on the gods is representative of their influence on their standing.

In many ways, this reflects how religious faith actually functions in the real world, as adherents draw connections to random events and outcomes to make their own conclusions as to their standing amongst the faithful under their chosen theology. We are therefore taking advantage of the human nature to see patterns in random noise to fool players into perceiving a highly-complex system of AI behind the scenes where there isn’t one.

#game design #mechanic design

[remembercomic]

The Internal Conflict of Post-Release AI

In the course of implementing more complex and intelligent agents for Various Oddities, a recent Minecraft mod project, I’ve had to contemplate how to create more complicated behaviours using the preexisting task system of the source game.

However, when developing special time-sensitive attacks and particularly with boss creatures, this runs into the problem that I need to create an AI system that functions fundamentally differently and often against the AI system of the source game.

Task systems are one of the fairly common styles of AI in procedural games. They consist of a list of usually-simple behaviours rated by priority, from which the server picks randomly each game tick. In the case of Minecraft, these behaviours include a check for contextual validity and whether they can be performed concurrently with other behaviours (and which ones). This is a relatively straight-forward way of simulating decision-making through a sort of organised chaos, but it is very odious when trying to craft long-term or complex decision making.

Conversely, the behaviour of most video game bosses tends to follow one of two primary styles: The behaviour tree and the action sequence.

Of the two, action sequences are by far the eldest and easiest to implement. The agent retains an internal record of its current position in a sequence and continues to perform the behaviour at that point until it is completed, moving on to the next in the line. This isn’t quite what we might imagine as “AI”, as it functionally breaks down an incrementing value operating a state engine, but it has greatly informed the classical view of how a boss battle performs. These sequences only happen in exacting order so there is little need to check validity each game tick, making them very low-intensity for early generations of CPU, but it didn’t take very long for players to nail down the attack patterns and render the bosses trivial.

Behaviour trees began to come into fashion with the release of games like Halo: Combat Evolved, and consist of a branching set of behaviours with individual conditions and results. A given branch of the “tree” has similar types of behaviour which differentiate based on their conditions, allowing the agent to select a behaviour most appropriate for the current context. This style also allows the agent to conduct its business without concern for the random changes in routine seen in task systems, whilst still being able to change things up when necessary (unlike the action sequences).

A third form of rudimentary AI has been popularised by the hulking and deadly boss monsters of many games: that of the ability pool.

Since boss monsters are frequently encountered in isolated areas (frequently termed the “boss arena”) and almost always only individually, they don’t need to worry about much in the way of navigation or interaction. Where a group of soldiers may need to give the appearance of collaboration and clever contextual thinking (since they are re-used throughout different levels), a boss only needs to worry about itself in its pre-designed area.

Consequently, the AI of bosses (particularly in massively-multiplayer online games, or MMOs) tends towards being substantially simpler than most agents. The distinction between them, in terms of gameplay, is that they are usually more deadly, more resilient to player attacks, and have one or more unusual abilities. These abilities might be a ground stomp that sends players around them flying, or the creation of a large fireball, or even the spawning of minion creatures it then proceeds to care precious little about.

Since Various Oddities is in particular heavily inspired by RPGs, this system made especial sense to imitate. Each necessitating creature was given a handler variable with a list of possible special abilities, held in a map linking them to integers representing their current cooldown (the time before the ability becomes usable again). The handler also contained a global cooldown value, to ensure a minimum amount of time between uses of special abilities, to give the player time to breathe between them.

Each game tick, the cooldown of all abilities are decremented towards zero. Whenever the current ability in use ends or is otherwise disrupted, the handler isolates all usable abilities, which can be used in the current context, and picks the one with the highest priority value to begin enacting next.

The result of this system is that the boss will choose its most dangerous ability applicable for the given moment in battle, which is not dissimilar from how the player themselves manages their abilities in many modern RPGs.

The difficulty in implementing any such system like this however is interfacing it with the preexisting task system, necessitating the addition of several function overrides that links the AI system subordinately to the handler variable.

In an ideal world, this would be handled simply through a function call to validate which AI style a given agent should use, such as using a task system while out of combat to using a more complex system when engaging the player. In earlier versions of Minecraft, this was feasible as the move to a task system progressed gradually throughout the agent types (with zombie pigmen being a notable exception to the task system, but having since been included in it), but support for this has since been removed.

In theory, the bulk of behaviours produced by Minecraft’s task system could be meaningfully replicated through a behaviour tree with a random input variable inserted into the contextual validity checks, but I am not in a position to rewire the entire game and so instead must be content with overriding half of it to meet my needs. Such is the life of a modder.

#game design #various oddities

[remembercomic]

Designing a Boss

It is standard practice for most video games to contain one or more “boss” encounters, be they in the form of a difficult AI opponent to play against in a rigorously-defined game setting or in the form of an imposing creature in the game-world itself to slay. Popular examples are the military commander of the enemy army, the rampaging monster in the nearby forest that blocks passage to the next village, and the grunt with the unusually-large weapon, though by no means is this an exhaustive selection of archetypes and boss encounters may not include a singular creature (or, in the case of puzzle challenges, a creature at all).

In the particular case of the YogDwarves!! project, the incorporated boss is that of the Uberwidren, which ostensibly is counterpart to Minecraft’s existing boss creature, the Wither. YogDwarves!! maintains that the Wither is simply the result of an incomplete or improper attempt to summon the Uberwidren, and that, as with common video game logic, the correct methodology produces a far more challenging and rewarding enemy. As YogDwarves!! is designed with amorphous groups of modifications in mind, this poses an interesting challenge in incorporating it and retaining its challenge, which can be likened to the development of expansions or add-ons to final products. If a boss is to retain its challenge despite contemporary or future additions and alterations to a game, how can we account for these changes?

First, let’s start with the standard toolkit for boss difficulty: Health, Damage, and Speed.

Health

Health (aka health points, hit points, vitality, etc.) roughly represents how much of a beating a creature can take before it finally falls over, and boss creatures typically have two or more times the health of a normal enemy unit. If the grunt soldier has only 20 health points to deplete, the military commander might have anywhere from 50 to 100 or more. Ultimately, adding health points to a boss creature serves to increase the grind associated with it, and over time as a game expands and develops enemy units tend to garner more and more health points.

This growth can reach absurd levels, such as in the case of World of Warcraft where we see the following progression:

Level 25 Hogger (12,000 health)

Level 35 Lord Vyletongue (~16,000 health)

Level 40 Archaedas (~22,000 health)

Level 51 Lord Aurius Rivendare (~32,000 health)

Level 69 Talon King Ikiss (~79,000 health)

Level 82 King Ymiron (~194,000 health)

The Lich King marks a notable alteration here, as its health varies based on the number of players actively fighting it (ranging from 10 to 25). If we wish to incorporate multiplayer into a game with a boss, this makes a useful tool in adjusting difficulty of a boss to match the scale of the assault against it, as a single individual player may only do so much against it in a given moment.

For the purposes of the Uberwidren, whose extant counterpart the Wither has 300 health, let’s say that it has 400 health + 100 per player nearby (meaning its health in a given encounter will range from 500 in a solo engagement to within the region of 2,900 with a typical full server).

Damage

Damage defines how much of a player’s own health the boss can deplete in a given action. This does not need to be a literal numerical exchange, for example a boss in a card game may force the player to discard cards from their hand (thus reducing the number of available options the player has) or remove cards from the field to prevent the player from using them. As the majority of games feature some form of health, we’ll treat damage in this context as defining how much of it we can drain for the purposes of this article.

The capacity to deal damage varies considerably on its format. One boss may blast an area on the ground with a missile every few dozen seconds, causing substantial damage to anyone unfortunate enough to be in the way, whilst another may constantly pepper players with many low-damage bullets from a machine gun. Additionally, we need to consider ranged combat versus melee, and also whether a given attack can hit multiple players or only a single targeted unit.

If we are designing for a single-player encounter, we can think of ranged combat and melee as being staged and ignore that final concern. In this archetype, the boss will shift between the two styles, usually switching to one or the other based on its remaining health or according to regular intervals.

If instead we are designing for a multiplayer encounter, we need to take into account that players will be assaulting the boss with both styles interchangeably. This means that in the case of a two-man encounter, one player may rush in to draw the attention of the boss with melee attacks whilst the other stays at range either healing his comrade or firing projectiles at the distracted boss. If our boss can only attack one unit at a time, the ranged player has little to be concerned about. Additionally, if our boss can only attack in melee, without a suitable ranged response, then the typical style of attack will be reduced purely to a comparison of threat ranges between player(s) and boss.

Taking an example from another popular MMO, Guild Wars 2 contains the Tequatl the Sunless boss, a large undead dragon-type creature. Befitting its size, Tequatl focuses significantly on area-of-effect attacks, many of which bestow deleterious status effects on targets, and though it lacks any attacks that could be outright defined as ranged it does have attacks which can affect targets at a considerable distance and from different directions. Its wide arsenal of abilities makes it a challenging opponent both solo and in groups.

Looking back to our Uberwidren case study, the basic Wither contains both a ranged and melee attack which it may use simultaneously. Its three heads fire frequently explosive charges at up to three targets whilst contact with its main body inflicts considerable damage, and both attacks may impart a deleterious status effect. This should be fairly suitable for the Uberwidren, but let’s up things a notch by giving it a regular melee attack of slashing claws that eat through players’ armour (thus giving it an additional means by which to damage the “health” of the player: item durability).

Speed

Speed refers to the movement of the boss versus the player, but we may also consider it to be the degree of difficulty with which the player must contend with to actually deal damage to the boss. A fast-moving and small boss for example is much harder to hit than a lumbering and slow one, regardless of how much or little health and damage it may be capable of dishing out. We can therefore more precisely describe this aspect of a boss encounter as its maneuverability.

In some games, given a selection of bosses, speed will quite often be the common delineating factor. You might find an early boss is slow and lumbering, whilst a later boss is nimble and quick (typically pausing to goad the player in regular intervals before getting a few rounds to the face for it). Exactly how the selection breaks down in this fashion depends additionally on the speed of the player, as faster enemies are more likely to appear (and pose a challenge) against a slower player. Faster enemies are also more challenging versus a group of opponents, as slower boss creatures quickly become focus points for coordinated artillery-style assaults against multiple opponents.

The simplest means by which to improve speed is to give the boss access to a form of transport that the player does not, at least does not often have access to. This can mean teleportation, or water transit, or much more commonly flight. Both extant boss creatures of Minecraft (the Wither and the Enderdragon) are able to fly, making their very agile against the grounded player. Meanwhile, the flightless-but-teleporting Enderman monster quickly puts the player on the defensive by regularly altering the direction of attack against the player who is limited to attacking one direction at a time.

Let’s take as our example here Kessler of inFAMOUS, who uses beam-style ranged attacks coupled with frequent short-range teleportation, keeping out of reach of a melee-focused opponent. He also occasionally takes advantage of the one-target-at-a-time nature of many of the character’s attacks with an illusory group of himself.

For the Uberwidren, retaining the flight of the Wither seems a must, but the Wither has an additional trick up its sleeve in the form of environmental destruction. A player may seek to limit the Wither’s speed by encasing it in blocks, but the Wither is capable of breaking almost any block (the sole exception being the impenetrable bedrock that contains the world) with its movement, thereby making any possible shelter the player might seek universally permeable.

This concludes our look at the conventional means of adding a boss to a game, but certain elements must be additionally taken into consideration for a game that is expected to change over time due to the addition of further content.

Alterations made by additional content will vary considerably based on the type of game and exact content added, but certain patterns persist across most games that receive such expansion. By investigating these patterns we can make some reasonable estimation of what our boss will need to be able to respond to.

Assuming a typical combat-oriented game, the following elements can be expected to increase over time as new content is added:

Player damage output

The standard addition within an expansion is new items, typically including new weapons. This is understandable, as it makes a player feel as though they have reached a new plateau of ability after completing the expansion’s content and is often also a necessity (given the health creep noted above). In order to challenge more powerful foes, more powerful weapons are often needed.

This means that a boss included in the initial product may become overshadowed by new weaponry and lose its challenge. The most obvious counter to this effect would be to limit the maximum amount of damage a given attack may incur upon the boss, but this has the substantial downside of making more powerful weapons worthless beyond a point, degrading the player’s agency and devaluing the effort necessary to obtain the item.

A function seen commonly in more powerful enemies in Dungeons & Dragons is that of damage resistance, wherein a value is subtracted from all incoming damage (save that which comes from certain sources, in some cases). As we cannot be sure where damage will eventually cap, a percentage subtraction would seem the better option. If the boss always takes only 80% of the damage normally incurred by a given weapon, then new weapons will still always matter but the challenge will be retained.

Should the damage reach more absurd levels later however, a flat cap or scaling damage reduction would be necessary.

Continuing with our Uberwidren study, we’ll say that the boss takes only 60% damage from all sources and include a boolean to cap the damage at a meaningful but still manageable value.

Player damage resistance

Whether it be due to improved armour or a larger health pool or even due to less straight-forward routes such as targeted resistance items (not unlike the damage reduction described above), players can be expected to become hardier as a game develops over time, and this is especially the case with games that are further developed and expanded after initial release.

Whilst the difference may be minimal with the first or second expansion, the divide between low level players and high level players (assuming a leveling system is in place, alternatively simple playtime to garner better gear may be the dividing factor) will usually grow and change over time. This makes it more difficult for a boss with a known and static damage output to assault them in response, eventually leading to a sitting-duck scenario in which the boss cannot defeat the players, who can therefore take their time defeating the boss without challenge.

The resolution to this could be to ignore such defenses, by enabling the boss to deal damage directly to the health of the player, perhaps as a percentage of their maximum health, without regard to their armament. Whilst this would certainly eliminate the problem of increasing defense, it also makes armour worthless against the boss at all stages of play, returning us to the loss of agency described above.

An alternative would be to allow the armour to affect the damage as normal, but to additionally increase damage incurred by the armour from the boss (that is, the boss’ attacks deteriorate the armour rapidly) and apply status effects to reduce the benefit of conventional physical damage resistances.

For our Uberwidren, we’ll say that its melee claw attacks (where armour will matter most) rapidly damage armour worn by targets, and apply a damage-over-time status effect to targets at all ranges.

Greater magic

“Magic” here is a vague term used to describe non-weapon and non-armour benefits applied to a player. Commonly in regard to magical settings, this includes potion effects and magical spell protections, in the case of more technological settings it could be as simple as health restoration via medkits and such.

As players advance, they can be expected to gain access to more potent and versatile magic effects like these. The benefit of medkits can be limited simply by the damage alterations described above, but benefits such as regenerating health and damage resistance are more difficult to plan for, and depend greatly upon the context.

For the context of the Uberwidren, Minecraft has some notable archetypes represented in its potion effects. Fire resistance, regeneration, water breathing, speed, and the like are all implementations of well-understand “magic” effects. The severity of these effects, though significantly limited in the released product, are still significant enough to make a difference in gameplay. Also available in Minecraft are item enchantments (another popular archetypical “magic” effect), which increase the damage output and resistance of players.

The Uberwidren can respond to the latter case well enough using our previously-discussed methods, but status effects are a more hazy area. We could simply negate them or use stronger inverted effects (respond to regeneration with poison, speed with slowness, strength with weakness, etc.), but the more innovative solution will often prove the most effective in the long term.

I therefore propose a “boonsteal” ability, negating active positive effects on targeted players and applying them instead directly to the Uberwidren. This means that the time taken by the player to create the effect is not wasted, but that they must think more strategically in how to apply them when facing this boss. A player that runs into battle against the creature with several powerful potion effects may find themselves at a disadvantage compared to a player than did not use potions at all.

This concludes my treatise on developing boss creatures, with particular attention to retaining difficulty over a length post-release development. We’ve managed to design a boss for Minecraft that is difficult at all levels of play, without reducing player agency, and can hold its own even in the very varied and powerful realm of modded play.

#game design

[remembercomic]

Squad vs Battalion

Give an ideal scenario wherein each individual unit is equally possessing of a high level of intelligence, there are some significant differences between the behaviours of a small four-man squad and a much larger military force, such as a 2000-man battalion which bear noting.

The fundamental difference boils down to communication. With a larger force, different teams and groups are able to signal others for supplies, to conduct strategic maneuvers, and to request medical attention. A squad has none of these properties, instead relying on the abilities of each member to perform more or less the same duties. An army has a medical corps, an engineering corps, etc. whereas a fire team has a medic, an engineer, etc.

This means that it should, essentially, be possible to form a squad from a single candidate of each army corps to form a well-rounded group able to handle most small situations. The actual problem is much deeper however.

Historical military strategy using hundreds or thousands of units is an extremely nuanced and changing environment. Most formation strategies, such as bounding overwatch, feint, etc. rely on the motion and inherent bulk of a large force and are thus highly improbable with much smaller groups.

Battalions are also, as a consequence of their scale, more suited to open terrain, such as fields and broad city streets, whereas squads are more suited to tight confines where a single unit can suppress an entire corridor and where cover from enemy fire is ample. A soldier in a squad will contain a constant search for suitable cover from known enemy units, leading them to progress in a much more calculated and methodical pattern than a battalion unit would be expected to.

The difference in environments and the distinct separation in available levels of support and communication thereby lead me to conclude that squad AI will always prove to be less intelligent than that used in battalions. However, there is one potential avenue of innovation which may yet prove this wrong.

Battalions must be intelligent in order to detect and respond to the inherently chaotic situations that unfold in open warfare. As squads possess far fewer units, each is therefore substantially more valuable, and must be able to respond to the actions of the enemy units in more rapid style. This of course has little concern in the scenario of an AI vs AI conflict, but human players are far more difficult to predict. Simply put, AI act as expected, but players are idiots.

The distinguishing element for squad AI therefore should logically boil down to its ability to learn and evolve over time, especially within singular encounters. Being able to accordingly alter their behaviour over time and based directly on experience with and observation of the enemy would enable the squad AI to respond to the actions of a handful of players. This could involve the use overlapped heat maps of detected player movements to identify likely encounter zones, as well as overlapped damage heat maps to identify areas most likely to come under fire. Genetic algorithms to improve response behaviours over multiple encounters and neural networks to improve from individual encounters, as well as to allow different units in the squad to behave differently (thereby making them harder for the players to predict), could also come into play.

#group ai

[remembercomic]

Dwarven Buildings pt.2

In order to cater to the wide variety of potential structures, the EntityDwarfBuild class must be capable of meeting the needs of as many interactions as possible.

The fundamental unifying factors between all structures are variables such as whether they can be owned by one or more individuals, their capacity, their boundaries, rotation around the central position (where the marker entity is placed), etc.

These variables must be accounted for and made available directly through the EntityDwarfBuild class, particularly to enable the entity to illustrate and use the data itself, such as to recognise whether the structure in question has been completed as part of the construction phase.

Currently, development is focusing on the DwarfStructureHouse class as a baseline example of structure requirements. Houses can possess multiple owners (aka occupants), and a number of interior sleeping locations, depending upon their capacity.

When a dwarf begins the behaviour of going to sleep, they retrieve the entity of their house (if they have one) and from it the co-ordinates that they should travel to before going to sleep. If a dwarf does not have a house (either because they have not searched for one yet or because their existing house has been destroyed or entered new ownership), they scan the vicinity for houses lacking an owner (or which have not yet reached capacity) and assign it as their own (informing the EntityDwarfBuild accordingly). When the dwarf dies, they must also endeavour to inform their house of this so that new occupants may move in.

Once the primary functionality of a building is completed, the final requirement is the construction. The internal boundaries of a building must be cleared of unnecessary blocks and then replaced with a more appropriate structure, according to a pre-written schematic. This necessitates the creation of the BuildSchematic class, which houses a list of keys referencing different blocks and a 3D matrix that defines which blocks exist in which position.

The EntityDwarfBuild class contains a globally-viewable value determining its status in the construction process, beginning at -2. When an idle dwarf with the Miner profession detects a nearby building in such a status, they will move to the next identified block that needs removing and mine it out. Once all such blocks are removed, from ceiling to foundation, the building shifts to status -1. At this stage, nearby idle Builder profession dwarves target the building and retrieve what block is next needed according to the BuildSchematic of the intended structure. If they have the block in their inventory, they place it precisely where it is needed and the building naturally progresses to the next block, from foundation to ceiling, before reaching status 0, signifying that it is complete.

As an additional functionality, all DwarfStructure classes contain a onBuildFinish() method which is called by EntityDwarfBuild as it reaches status 0 and which defaults to no action. If overriden by a specific class, such as DwarfStructureRoad, special behaviours can be undertaken at the advent of a building’s completion. In the case of DwarfStructureRoad, this is done to erase the now-unnecessary building marker (as roads have no special function).

#projects #yogdwarves #buildings

[remembercomic]

Dwarven Buildings

In order to support more complex AI tasks and to enable the expansive structure and organisation necessitated by a civilisational hierarchy, it became necessary to allow the dwarves to easily and readily locate and identify buildings of a variety of different kinds. Quartermasters needed to be able to locate inventories, miners needed to be able to locate dig sites, and all dwarves needed to be able to locate a comfortable dwelling to sleep away the night in.

In most systems, this would be handled by having a centralised kingdom data structure to catalogue all structures in the system and provide a hook for different dwarves to discern where they needed to go. However, the YogDwarves!! structure requires that no such central structure exist, instead relying on the AI of the individual dwarf entities. This required the addition of a versatile entity to serve as a marker or waypoint for the dwarf AI tasks to scan for and retrieve the needed data from.

Similar to the dwarves themselves, the building marker (EntityDwarfBuild) served predominantly as a container, being itself incredibly shallow. Each marker contained a DwarfStructure object which held the more pertinent data. The markers displayed their clan affiliation and their type as determined by the internal DwarfStructure object (or “Empty lot” if the object is null). Each marker also contained a variable defining the three-dimensional boundaries of the building itself, enabling calculation of entities within its borders as well as the prevention of overlapping structures. The latter will prove especially useful once the markers graduate to actual build sites with physical objects.

In the first stream, building development was concentrated on the addition of DwarfStructureHouse and its incorporation into the existing EntityAIDwarfSleep task to enable the dwarves to find a home (either a previously-identified dwelling or an unoccupied one). This required that the DwarfStructureHouse object contain an identification value of its registered owner in order to properly identify whether a given structure was owned by a given named dwarf, with special consideration given to the possibility of a building being destroyed or reallocated and therefore the dwarf owner being unknowingly evicted.

To that end, EntityDwarf was given a number of new methods (void setHome(Vec3), Vec3 getHome(), void clearHome(), and boolean hasHome()) related specifically to a Vec3 variable representing the location of their home. EntityAIDwarfSleep also saw substantial revision to enable the dwarf to retain their capability to fall asleep anywhere if they were unable to locate or navigate their home but otherwise to navigate to an appropriate dwelling. DwarfStructureHouse was given an ownerName String variable to identify their assigned dwarf (though consideration was also given to houses being reserved for players in the future) as well as an array of methods to manage this value.

Ultimately the stream concluded with the dwarf Markus Stonewater successfully identifying an unoccupied house and allocating it to themselves, as well as both entities retaining knowledge of one another across game sessions, and navigating to it appropriately at night.

The structure was kept deliberately simplified for purposes of programming during the livestream session, only allowing for a single occupant and having no regard for where they sleep within the boundaries of the structure. Further development will allow for a variable number of possible occupants and the inclusion of locations to fall asleep, as well as the autonomous creation of new houses for clanless dwarves (who are the only profession capable of doing so, as part of their solitary nature).

#projects #yogdwarves