Gameplay Programmer
DrekLike
Technology
-
Visual Studio (2015)
-
C++
-
GLSL (OpenGL)
-
-
Photoshop
​
Genre Single player, Procedurally Generated, Turn Based, Roguelike RPG
​
Platform PC
​
Development Time 2 Months
Table of Contents
Game Summary
The game is a turn based RPG roguelike with some advanced systems. Particularly in that there are NPCs with different behaviors/AI, different types of items, factions, and so on, all mostly set up from XML. Behaviors/AI are mostly controlled from XML, but if want a new type of behavior, then it requires some code to be made as well, same can be said for the "Features" which are basically interactable objects in the world that the player can interact with. The game also uses a very basic state machine set up.
If you plan to play the game, then please read the controls, there are a lot, and they differ between states.
Controls
There are various states in the game, and each one has different controls. If interested in what the controls for the game are, please click the button below.
Other Notes About the Game
Consistent tile and entity types:
-
Representations of items, npcs, or tiles are represented by a character and an assigned color.
-
'@' - represents the player.
-
'_' - represents an air tile.
-
'#' - represents a stone tile.
-
'~' - if blue represents water, if red represents lava
-
Its kind of hard to see, but if an item is on a tile, and no npcs are on that tile, then the tile underneath will be partially visible. If its npc, you will not be able to see the tile underneath.
-
All items and NPCs have their colors and associated chars assigned in XML.
Slight graphical issue in the sprite sheet of letters: The lower case characters are one off. So if Dwarves are assigned to 'd' then in game they will actually have the char 'e'.
​
NOTE: Lower and Uppercasing DOES MATTER in the xml files.
Dungeon & Entity Customization through XML
Summarized Bullet points:
-
Data that can be defined or loaded from XML
-
NPCs
-
Some of the Behaviors for this type of NPC
-
-
Items
-
Features (Interactable Objects in the world)
-
Map Creation Variant
-
-
For a more in depth break down, click the button below.
​
In order to make it easy to edit or add in new Items, NPCs, Features (such as Doors), and Maps, I set up the game to read certain amounts of information from XML. This also makes it easy to customize what sorts of behaviors my NPCs use as I just define the behaviors they are allowed to use. The behaviors themselves require more custom per each one, but I can easily define and edit the behavior's internal stats from XML as well.
For more information about how to set up or mess with the individual types of entities or map generators in the game, please click the button below.
​
This is a screen shot of the XML code used with the armor presently in the game.
This is the XML code for the potions presently in the game.
This is the XML for a Feature; aka the Wooden Door.
This is a screen shot of the XML code used with the armor presently in the game.
Self Registering Generators
Summarized Bullet Points:
-
Map Generators, and Behavior Generators self register to a list.
-
List is only in one .hpp, meaning only need to include one .hpp file to get access to all of the Generators of this type.
-
Really easy to add more self Registering Generators of that type. Just requires a registration name, and a couple of Functions of a particular defined input and output.
-
This structure requires that the intended generators have a way to spawn themselves through their registration, given data.
​
In order to make it to where I only ever needed to include just one .hpp file to have access to all of the behaviors and map generator types, I had to make code that self registers all of the generators for those variants. This slims down how many included files I need access to in order to access a given variable, and requires taking advantage of class inheritance.
The idea is I would, when I want a new Behavior, create a new class that inherits from Behavior, and also has a static const BehaviorGenerator tied to it that has pointers to a couple of functions as well as a const char for the class name. The Behavior Generator's constructor then takes that information and registers it to a list at start up, which then enables it to be called and grabbed from one centralized list and thus only one include file necessary to get it.
​
Generator, MapGenerator, and CastleGenerator header files.
Fundamental Code Snippets for the Self Registering Generators concept.
Registering Entity Factories from XML
Summarized Bullet Points:
-
Easy to create separate factories for each entity type. Just need:
-
An Entity Factory Constructor that takes and reads off data from an XML node the way wanted.
-
An easy to read Entity Template class.
-
​
Registering Entity Factories for the items, npcs, and so on, is made easy thanks to XML. The first step is to create a constructor that takes in an XMLNode of with the correct name, and then reads off the data as intended for that factory type. All of the data read should be copied onto an Entity Template that the Entity Factory holds onto. After the data is finished being read, its time to verify that the Factory has a valid and unique name. If it does, then added it to a data holder of your choosing (vectors, arrays, maps, etc.). I chose to store off the Factories as name and value pairs, plus have a separate array of the factory names.
NPCFactory and EnvironmentalProcessData header file.
NPCFactory CPP File
NPC Behavior System
-
Thanks to both the Self Registering Generator system and the Entity Factory system, it is easy to create custom code for NPC Behaviors.
-
The NPC Behaviors use the Self Registering Generator method to define some particular AI Behaviors (such as Wander, Patrol, Chase, etc.), and are created via XMLNodes passed to it during the NPCFactory reading process.
-
The original copies are held onto by the NPCFactory, and then copied onto an NPC whenever said NPC is spawned.
-
This allows for both having a well defined parameter for what each behavior does, but a level of customization that allows for each NPC type to be different.
-
-
NPCs determine which one to run by first testing which one has the highest running score. Then afterwards it goes and starts running that behavior.
​
Behavior Header File
Wander Header File