204 lines
11 KiB
Markdown
204 lines
11 KiB
Markdown
{% extends "../../../layouts/post.html" %}
|
|
|
|
{% block article %}
|
|
|
|
## Preface
|
|
I'm an indie game dev that has an interest in making tools that I think would improve my life as a game developer in the hopes that it can help others. I'm not an expert in any of the topics that this article covers. I have no formal education in game engine development or architecture, systems programming, or anything else. I went to university for Computer Science with a specialization in game design & development when I was in my early 20s and the only thing I learned is that there are better ways to spend tens of thousands of dollars.
|
|
|
|
Everything in this article is drawn directly from my experiences working in game development.
|
|
|
|
## Theseus' Shield
|
|
In the context of game design and development, object oriented data modeling can feel intuitive. Players, NPCs, and Enemies can all derive from a common "Creature" class which handle things like health and damage. Weapons, armor, and consumables can derive from a common Item class which handle inventory management.
|
|
|
|
Thinking exclusively in terms of hierarchal, nested patterns can come at a cost: software brittleness and inflexible design. Let's use our base `Item` class as an example.
|
|
|
|
```cs
|
|
abstract class Item {
|
|
public string Name { get; protected set; }
|
|
}
|
|
|
|
abstract class Weapon: Item {
|
|
public float Damage { get; protected set; }
|
|
public float Range { get; protected set; }
|
|
}
|
|
|
|
abstract class Armor: Item {
|
|
public float Defense { get; protected set; }
|
|
}
|
|
|
|
class Sword: Weapon {}
|
|
class Bow: Weapon {}
|
|
|
|
class Helmet: Armor {}
|
|
class Shield: Armor {}
|
|
```
|
|
|
|
In the above scenario, we have [three layers of inheritance](https://wiki.c2.com/?MaxThreeLayersOfInheritance). We can imagine that `Item` handles behaviors like item management such as being added or removed from an inventory and highly generic item behavior. `Weapon` would then be responsible for an item which is capable of dealing damage at any range. We can expect that the specifics of its attack behavior would be implemented by a subclass. Similarly for `Armor`, this would handle generic damage interactions such as common mitigation or avoidance calculations while leaving specific implementation details to its subclasses.
|
|
|
|
Seasoned game devs, disciplined object-oriented programmers, and existing ECS developers can likely already see what comes next: a new requirement.
|
|
|
|
How do we add a Spiked Shield item -- one which derives the behaviors of `Weapon` and `Armor`? If we were using a language which supports multiple inheritance this could potentially be a nonissue: except that multiple inheritance is often [purposefully missing](https://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem) in many languages. We could decide that the item belongs more to one class than the other and just duplicate the missing behavior but these types of decisions often introduce unforeseen complexity: will the damage algorithm need to do a specific type check for `SpikedShield`? What about the equipment screen? And of course, what happens when we need to implement a damaging potion?
|
|
|
|
Perhaps the most appropriate solution for this case would be to forgo the inheritance pattern in favor of [composition](https://en.wikipedia.org/wiki/Composition_over_inheritance). In C#, this could be achieved with interfaces and default implementations.
|
|
|
|
```cs
|
|
interface ICollectable {
|
|
void Take();
|
|
void Remove();
|
|
}
|
|
|
|
interface IDamaging {
|
|
// by default, we'll just pass the damage directly to
|
|
// the damage handler
|
|
void ApplyDamage(IDamageable damageable, float value) {
|
|
damageable.ReceiveDamage(this, value);
|
|
}
|
|
}
|
|
|
|
interface IDamageable {
|
|
void ReceiveDamage(IDamaging source, float value);
|
|
}
|
|
|
|
class SpikedShield: ICollectable, IDamaging, IDamageable {}
|
|
```
|
|
|
|
We can use this approach to refactor our existing items and systems to derive/override only the behaviors they use. The respective systems for these interfaces now only need to check for the existence of these interfaces in order to act on them.
|
|
|
|
Engines like Unity and Godot use variations of the [Entity-Component (EC)](https://gameprogrammingpatterns.com/component.html) pattern (similar to but distinct from Entity-Component-System (ECS)). These patterns favor composition over inheritance by allowing developers to isolate behaviors into discrete components that can be applied to entities. In the Spiked Shield example, a developer could make a "Damage Source" and "Damage Target" component and add both to the item. In essence, this is the same as the interface-based approach.
|
|
|
|
Unfortunately, these patterns suffer issues that are much more difficult to solve.
|
|
|
|
## In the event of my demise
|
|
Due to the nature of video games, important events may need to be handled at any moment. For example, a player may've dealt a fatal blow to a boss enemy on the same frame that they received fatal damage. In which order should this damage be processed? Depending on the handling order, this is likely the difference between clearing a potentially difficult boss battle and needing to do it again.
|
|
|
|
In my experience, this would likely be handled by a traditional event system where the order is difficult to predict. This isn't to make the claim that syncronous event systems are *unpredictable*, but ensuring that a given event will be handled in a way that is predictable to the designer/developer without additional abstractions is difficult.
|
|
|
|
It's often useful to explicitly define the processing order of certain interactions and events. To solve this problem, we could implement a priority [event queue](https://gameprogrammingpatterns.com/event-queue.html).
|
|
|
|
```cs
|
|
public class DamageEventArgs : EventArgs {
|
|
public readonly IDamaging Source;
|
|
public readonly IDamageable Target;
|
|
public readonly float Value;
|
|
}
|
|
|
|
// this is more of a dispatcher, but that's
|
|
// an unnecessary implementation detail.
|
|
// in a real scenario where other systems would be reading
|
|
// these events too, this would subscribe to a Mediator object
|
|
class DamageEvent {
|
|
// only one of these should exist and should be globally
|
|
// accessible so we make it a singleton
|
|
private static DamageEvent instance = new Instance();
|
|
public static DamageEvent Instance => instance;
|
|
|
|
private PriorityQueue<DamageEventArgs, int> queue = new();
|
|
|
|
private void Raise(DamageEventArgs args) {
|
|
// before enqueuing, determine the priority
|
|
// based on the object dealing damage
|
|
var priority = args.Source switch {
|
|
Player => 2,
|
|
Enemy => 1,
|
|
_ => 0
|
|
};
|
|
|
|
queue.Enqueue(args, priority);
|
|
}
|
|
|
|
// we'll dispatch events with the trick rate
|
|
// so they're all handled at the same time
|
|
private void OnTick(float deltaTime) {
|
|
// for simplicity we'll dequeue everything each frame
|
|
// and pass it to the damage handler
|
|
while(queue.TryDequeue(out var e, out int priority)) {
|
|
e.Source.ApplyDamage(e.Target, e.Value);
|
|
}
|
|
}
|
|
}
|
|
|
|
// bossEnemy's damage should be processed after player's damage
|
|
// if they're raised during the same frame
|
|
DamageEvent.Raise(new DamageEventArgs(bossEnemy, player, 10));
|
|
DamageEvent.Raise(new DamageEventArgs(player, bossEnemy, 10));
|
|
|
|
```
|
|
|
|
There's a lot of issues with this code that I'm going to pretend were deliberate decisions for brevity. The point of this example is to show that we can ingest events and sort them arbitrarily based on the requirements of the game. We've made a step in the right direction by identifying a need to explicitly order these events. Even if this implementation isn't ideal, it properly encodes the requirements of the design (ie. player damage should be processed before all other types).
|
|
|
|
There is still a timing issue with this approach however. Events can be raised at any point: before, during, or after `DamageEvent` queue has already done its work for the frame. If `bossEnemy` raises its damage event before `DamageEvent` processes its queue but `player` raises their event after, we still have the original issue.
|
|
|
|
Depending on the engine and implementation, there may be a few options for solving this. Rather than using `OnTick`, the damage can be handled in `OnLateTick` which runs after all `OnTick` systems have been processed (Unity's version of these methods are `Update` and `LateUpdate`). In Unity the `DamageEvent` singleton script could have its order explicitly modified in the settings or with the `DefaultExecutionOrder` attribute. In Godot, this would likely be resolved by moving the `DamageEvent` node lower in the tree since nodes are processed from top to bottom while resolving children first.
|
|
|
|
An alternative solution would be to identify the behavior which raises code events and isolate it into its own singleton. Doing this would allow it to easily be ordered before the damage handling system.
|
|
|
|
## Reading game state
|
|
Managing a game state as it grows in size and complexity is *difficult*. It's not uncommon for a game to have dozens, hundreds, or thousands of active entities at a time. In many cases, it makes sense to decouple separate-but-related behaviors into their own systems to make them easier to manage.
|
|
|
|
One such separation would be game logic and UI. Rather than directly coupling the player's health to the UI representation of the player's health, it makes sense to have them communicate via some type of messaging system. An event seems like a natural fit.
|
|
|
|
```cs
|
|
public class HealthChangedArgs : EventArgs {
|
|
public readonly float PreviousValue;
|
|
public readonly float CurrentValue;
|
|
}
|
|
|
|
class Healthbar : UIElement {
|
|
private float _currentHealth;
|
|
private float currentHealth {
|
|
get => _currentHealth;
|
|
set {
|
|
if (value != _currentHealth) {
|
|
_currentHealth = value;
|
|
Redraw();
|
|
}
|
|
}
|
|
}
|
|
|
|
protected void OnInitialize() {
|
|
// register to the player spawn event
|
|
PlayerSpawnEvent.Register(OnPlayerSpawned);
|
|
}
|
|
|
|
private void OnPlayerSpawned(object sender, Player player) {
|
|
// subscribe specifically to that player's events
|
|
player.health.Register(OnHealthChanged);
|
|
}
|
|
|
|
private void OnHealthChanged(object sender, HealthChangedArgs args) {
|
|
currentHealth = args.CurrentValue;
|
|
}
|
|
}
|
|
```
|
|
|
|
This should work fine but it's unfortunate it needs to manage subscriptions to two events in order to get the updates it needs. We could circumvent this by making health updates dispatched globally but that wold come at the cost of checking *every* health update just to find the player. This solution would work, however, if every entity with health had a healthbar.
|
|
|
|
global variable, then array
|
|
|
|
use examples of multiplayer, then enemies with health bars
|
|
|
|
## Enter ECS
|
|
ECS solves many of the problems presented by object oriented programming patterns but it's still in its infancy.
|
|
|
|
## Issues with ECS
|
|
Mental modeling is hard. Complex queries are hard. ECS is hard.
|
|
|
|
## A Solution?
|
|
something something game state as a database, expressive querying
|
|
|
|
## Going forward
|
|
continued evolution of ecs which can broadly respond to specific use cases and needs
|
|
|
|
### What I'm looking for
|
|
* constructive feedback and discussion about the general direction i'm putting forward
|
|
* potential implementations and data structures that allow ecs to perform as outlined
|
|
* potential pitfalls that ecs may not be able to answer
|
|
|
|
### Not on topic but will still accept
|
|
* improvements and specific optimizations to my prototype
|
|
|
|
### What I'm not looking for
|
|
* criticisms about my specific prototype implementation
|
|
|
|
|
|
{% endblock article %}
|