If you follow Daniele on twitter you may have already seen some spritesheets for the Fiery Pit enemies and his concepts (and if not it seems a good excuse to start) and I have started adding them to the game.
Enemies, or more generally “interactive objects” are of course one of the most important and complex parts of a game, even at the level of the game engine, and their implementation can vary a lot depending on your goal. At code level you have several possible ways to implement objects and several different angles to tackle at the same time, leading to some interesting choices. For this article I would like to focus on one of the first choice you have to make when designing your “Entity System“: will it be Object Oriented or Data Driven?
Object Oriented, in this context, means that every enemy is an instance of a different class. Specifically there is a base class, probably abstract, from where different entity classes will inherit, creating a hierarchy. Each time the game creates an object (let’s call them enemies for easy of use, even if really everything can be an object) it will create a new instance of a specific class. This specific class will contain everything needed to define the enemy: its statistics, its game world attributes, its Artificial Intelligence routines etc.
Data Driven means having a single generic container class for your enemies. When the game creates an enemy it creates this “generic” enemy and then loads its details from a Blueprint. Even its behavior is dynamically defined at run time, loading it from a script or assigning it depending on the Blueprint.
Let’s use a simple game like Pacman as an example. During the development of your own Pacman clone (which, by the way, is a very good exercise if you are just starting out game development) you may choose to follow either approach:
- For Object Oriented you can implement an “Entity” class and then derive five other classes: one for Pacman, whose AI consists of following the user inputs, and four for the ghosts, each with its own behavior (did you know that all four ghosts had a specific one?) and spritesheet. Maybe even creating a “Ghost” intermediate class that for example can manage the behavior of blue/vulnerable ghosts.
- For Data Driven you will have only one “Entity” class and have an external file that define the sprite to use for each entity and its behavior (it can be as simple as an ID, like “player” and “ghost”).
It is a bit like defining the behavior of an object at compile-time or at run-time.
In recent times, especially with the rise of indie-friendly Game Engines that with every release further blur the line with Integrated Development Environments, the dominant paradigm has been the Data Driven one. Data Driven and scripting enable fast development cycles and place in the hands of designers (which often, especially in big companies, are not programmers) and modders a lot of power and flexibility: anyone with the right tool or a text editor can modify or even add entities, possibly without having to restart the game to test the changes. Talking about procedural generation, using Blueprints means also the possibility to generate variation of an entity quite easily.
If your game is more focused and you don’t need a system able to scale to dozens of different types of entities, however, Object Oriented can still be a winning approach. It is usually easier, faster and more straightforward to write you Entity System directly in code, and all the benefits from the Data Driven methodology can be recreated with modern, and even not-so-modern, programming techniques: Nethack is a massive game and every entity is defined inside the source code, using C.
Regarding Wizards’ Duel I have followed the Data Driven approach, in the hope that it will be easier later on to fine-tune the enemies to our liking and even offer the possibility to create your own.
Thanks for reading.