After week 1 went really well the focus of week 2 was to get an initial encounter and encounter battle map up and working. While doing that I tried to finish many loose ends in the Realms of Ancardia engine.
Encounter handling implemented
While I’m probably going to add tons of stuffs during further development a pretty strong combat encounter framework is now in place and work. Let me explain with our first example: Because I had lots of fun during the setup of the system to toy with our settlement generation system (which we needed because the surface world in the game is huge and contains hundreds of settlements ranging from small hamlets to huge metropolisses (is that a word?)) I decided that the first test case for a combat encounter would be attacking citizens (because why not – nobody said that Realms of Ancardia is against game for heroes only 😉 )
To be able to attack citizens the following things were on my implementation plan:
- Citizens needed to walk around the city. CHECK. We already finished this last week.
- Citizen encounters needed to be variable. For that I set up a so-called ReactiveEncounter on each street tile. Reactive encounters are activated as soon as the player character enters the given position. My SettlementInhabitantsEncounter has the sole task to monitor the flow of citizens (selecting crowd volumne and a dependent number of random settlement encounters chosen from a large table [well, the table will be eventually large, right now there is exactly one entry – an encounter with simple commoners]). CHECK. The SettlementInhabitantsEncounter also was finished last week. Now the fun started.
- I had to set up an actual encounter:
- Encounters in Realm of Ancardia are modal (while e.g. in ADOM you only could encounter single monsters per tile). An encounter in RoA can be anything from a single monster, a trap, a text, a feeling or an army lying in ambush (and everything in between).
- An encounter needed a way to define beings and the options it entails.
- The encounter with commoners is a passive encounter (meaning: the citizens ignore you unless you interact with them). So I needed to implement an encounter lifecycle (which now has four stages for four basic types of encounters). Passive encounters are phase four (phase 1 are reactive encounters, phase 2 are combat encounters, phase 3 are active encounters [that activate automatically] and phase 4 are passive encounters).
- I also added that failing to solve an encounter in phase x can stop you from reaching encounters in phase (x + 1). So if e.g. there is a treasure encounter that is guarded by a dragon combat encounter you won’t be able to reach the treasure until you solve the dragon combat encounter (which most often probably means killing your opposition).
- Encounter handling raised interesting detail questions:
- If you encounter e.g. 8 commoners, attack them and kill 3 of them – what happens to the rest (answer: I implemented an encounter state management that keeps a tally of the opposition).
- Initiating encounters can have recriminations. E.g. attacking commoners in the city will flag you for committing a crime (Assault).
- Here new ideas spawned:
- First of all I needed an API to add reactions and workflows to encounters. The basic framework now is there and as first examples I implemented OnDeath and OnAttack handlers.
- Now that crimes were accounted for (affecting your reputation and activating the underlying criminal justice system) the unsolved question was: How does the settlement react to crimes?
- So I came up with the idea for settlement events that could be posted to the settlement and would propagate from there throughout the settlement (or at least parts of it).
- So I added a means for posting settlement events, the first being a CrimeOccurred settlement event.
- After that was done I pondered event propagation and for Realms of Ancardia this is rather easy:
- There are small settlements with scattered homes. Here I implemented a circular propagation where after each time frame the event spreads further outwards from its origin.
- In larger settlements events actually spread following the streets.
- It becomes interesting whenever an event reaches a special building (the non-boring buildings in settlements). Special buildings consume these events and react to them. So if e.g. a CrimeOccurred event reaches a CityWatchStation special building, this in return might spawn a city watch patrol that heads for the location of the crime. And eventually reaches it. When it reaches a raging combat encounter the guards actually might join. If you finish the fight before they reach you, they will track you (at least for a while).
- Then it dawned on me that there could be more interesting mechanisms than just spreading events:
- Realms of Ancardia has 21 government types (some of the more interesting being the Magocracy (being ruled by wizards), NecrocracyCouncil (a group of undead ruling the city), NecrocracyTyrant (a single undead ruler) or Theotechnocracy (being ruled by an actual [demi]god living in that settlement). It would make a lot of sense for these government forms to create different reactions to events:
- A magocracy might react by casting spells at you (while you are still fighting in a totally different encounter) to punish you. Maybe with a little delay because they need to agree on a course of action first. And if they take too long they might summon some demons or elementals or blink dogs (depending on their alignment) to hunt you.
- An undead tyrant might immediately summon undead from the ground that join the battle (and in general: if the crime is severe enough).
- An undead council might summon a lot more undead that a single tyrant – but maybe they again need longer to react because they will have a discussion first.
- A (demi)god ruling the settlement might send (un)holy guardians to the battle site… or whisk you away immediately… depending on his domains, power level, etc. If you are particularly dangerous to the settlement the (demi)god might even decide to appear and handle the issue by trying to cause divine massacre.
- And so on and so forth. Even the more mundane government forms will have different troups, reaction times and so on and their disposal.
- And we are just talking about violent crimes here.
- So I implemented a SettlementEventPropagator pattern which depends on the type of goverment of the settlement and implements different strategies to react to events.
- Realms of Ancardia has 21 government types (some of the more interesting being the Magocracy (being ruled by wizards), NecrocracyCouncil (a group of undead ruling the city), NecrocracyTyrant (a single undead ruler) or Theotechnocracy (being ruled by an actual [demi]god living in that settlement). It would make a lot of sense for these government forms to create different reactions to events:
- But back to the beginning: To attack citizens you need the option to do so. There is no “moving into enemies to initiate attacks” in the normal movement mode of Realms of Ancardia because each position in theory can hold an infinite number of encounters. And you can move through them (usually) for reasons I maybe will explain in some other post (if anyone cares). So I needed a system to offer variable options for interactions to the player (depending on the specific encounters). So I implemented a means for passive encounters to return a list of potential interactions.
- Then I needed code to group these interactions (e.g. if there are ten different encounters you might be able to attack this in the first step is consolidated under a single “Attack” interaction and only when you choose that you get the list of ten potential targets to select the right one (and I’m still pondering if starting a fight on a settlement position immediately should draw all beings into that fight).
- Interaction options needed lots of details:
- Texts (all translated naturally).
- Checks to see if they are available NOW (e.g. a ‘c’hat option should not pop up if the player is deaf).
- Why BTW prompted a new sidetrek because I had not yet any states (like deaf, asleep, paralyzed, …) to beings.
- And when I added state I also needed to add state arithmetics because state (like attribute scores and other data) is accumulated across innate values, equipment, skills, talents and other factors.
- I had to add dynamic binding and unbinding of keyboard commands to represent the shortcuts to the interactions.
- I needed grouping, sorting and filtering of options.
- I had to create a simple initial dialog system to present sublists and select them.
And then this lead to…
Refactored the movement system
And I am still working on it and foresee another day or two of work with this. Previously most movement was faked – now there are the outlines of a complex movement routine which caused me more trouble than expect due to having to cope (depending on map type) either with abstract encounters or specific beings on a map.
C# generics are no little part of the challenges and I will continue to work on the movement system next week. Right now there are still broken code pieces and various bugs. But as they say: TANSTAAFL.
Combat encounter implementation started
This is one of the core components of the future game and as such probably will see fiddling and extensions over years to come while we add more and more detail. The basic idea is that once a combat is initiated you zoom into a combat map defined by the encounter type and environment (e.g. for fights in a settlement a map is derived from the surrounding streets and buildings). The enemies are placed on that map and a turn-based combat ensues.
The basics for this have been implemented although tons of details still are missing (inventory handling, other items, special effects, lots of details for the combat system and so on).
Here’s the video of the very first battle in Realms of Ancardia filmed:
There is a ton of stuff that needs improvement but I’m actually pretty proud of a number of things that already work in the background (like automated encounter roster management on the right side, automated crime management in the background, automated setup of various rules for executing the encounter and more).
All this needs a lot of fleshing out over the months and years to come but it’s a great start.
UI Details
Various small things happened, like the message log having a gradual fade out:
The sections to the right now have headlines:
Beings structured
Beings are the central data structure for any living, unliving or undead things (basically anything that kind of lives) in Realms of Ancardia. I wrestled for a long while on how to design them:
- In ADOM all monsters are pretty primitive flat data structures full of special cases. And inventories have somehow been grafted onto that in a Frankenstein like architecture. Not really recommended anymore.
- In Ultimate ADOM every being had (almost) the same structure and complexity. Mind-boggling complexity (remember amputating and grafting limbs as a feature?). Not really recommended anymore.
- In Grog the player data structure and the monster data structure uses the same interface. But for monsters the underlying implementation is very very simple (almost ADOM-like, just better designed). Only for the player there are the special cases about inventories and stuff (Grog being very simple there actually is not much). Felt good and I still like it but it does not seem to do the planned complexity of Realms of Ancardia justice…
- For Realms of Ancardia I for now differentiate three levels of detail:
- Simple beings – basically just hard-coded statistics blocks like in ADOM (e.g. most animals and almost all standard monsters will use this)
- Complex beings – basically almost everything in data that the player character also has (items, skills, talents, …). Reserved for henchmen, (some) rulers of settlements and very important NPCs.
- Player Character (even more statistical details like number of moves, reputation in each settlement, etc.). Only for the player character.
Map tile meta data structured
For map tiles a lot of meta data exists:
- Can the tile be accessed by any being?
- What is the movement cost for moving to that tile?
- Does it require special abilities to access?
- What is it’s description?
- Can it be damaged?
- How much damage does it take to destroy the tile?
- If the tile is destroyed what happens then? (and what is the replacement?)
- etc.
While I’m not yet finished yet I have implemented the generic infrastructure for handling this meta data for our various map types (surface world map, settlement map, dungeon map, settlement encounter map so far).
Rumor system added
I have added the outline of a rumor system to the game. It needs more dynamic components for the future but I will fiddle with those aspects once I have implemented a dynamic quest generator at some point and various interactive story lines are in the game. For now these rumors can be part of a chat with other beings running through the game.
Actor system
Realms of Ancardia uses a pattern I first made up for JADE: Actors. Actor in this context is the term for something that happens at a specific point in time. The interface currently looks like this:
public interface IActor : IStorable, IUnique
{
long GetActionPointInTime();
void Act(IRNG rng);
void ActAgainAfter(long time);
}All actors are managed in lists (one for beings/encounters per map, one for global events that take place at some point in the future).
I added a lot of infrastructure to make all beings actors, to find the next actor that is going to act, etc. This is the backbone of all interactivity in Realms of Ancardia and thus a pretty important architectural step.
Related to the encounter system the actor system is what makes all enemies / non-player characters in an encounter move, fight, flee, etc.
Goal system added
All beings in the game have an agenda and act accordingly to it (see actors above). To manifest a specific agenda each being has one or more goals (like flee, move randomly, kill enemy, …). When a being actor is allowed to act it uses the current goal to determine the specific course of action.
Goals are managed in a stack and can invalidate due to circumstances. Then the next lower goal becomes the current goal until no real agenda is left (coursing beings to just wander randomly until attacked, etc.).
Wilderness encounter architecture added
One of those sudden and unexpected sidetreks. Krys needed material for drawing monster tiles so I spent some time creating an architecture for our wilderness encounter system (which I wanted to tackle next anyways next week so that wilderness travel starts getting exciting).
I now have finished the general architecture for encounter tables and encounter setup and also defined a lot of stubs for specific encounters.
Talking now is possible
The basic infrastructure has been implemented and you can talk to normal people. The rumor system has been integrated. More architecture is needed for complex conversations but that’s future work.
Miscellaneous minor changes and fixes
- I ported over the racial attribute modifiers from ADOM (with minimal changes).
- The right hand sidebar now has dynamic categories and category headlines for better readability.
- Encounter flags have been added for greater customization.
- I have designed some parts of what I call “the saga system”. The idea here is that a number of complex storylines will run in the background, altering the world and potentially affecting the player. I have outlined the first such saga called “Rolf’s Saga”. The gist is that the storylines will mostly just require code of low to medium complexity and still create the impression of “huge things happening” (and not just impressions) thus making the world a lot more lively.
- I had to do a major refactoring of my internal architecture both for maps and for beings/encounters the reason being that Realms of Ancardia has to levels of interaction: encounters (abstract high level) and beings (usually combat). This has a lot of technical advantages during implementation and hopefully also will feel nice (although it is not quite roguelike). As I started implementing the first type of combat encounter during this week suddenly all the infrastructure for actual beings needed to come to life and that required a number of changes that cost me about 1,5 days of design and implementation time. But now everything feels right 🙂 Important groundwork.
- Refactoring of the time system to be more fine-grained. While last week we still worked with systems we now use ticks. One second has 1000 ticks. This gives us great leeway in determining the costs of actions (especially in combat) and the initiative order.
- Committed crimes now are reported in the message log.
- The right hand side statistics bar now shows some player statistics.
- Added gender, race and name to the PC (currently purely random).
- Added a name generator for being names (including shopkeepers and dragons as special cases).
- Added infrastructure for enemies.
- Krys has added a lot of stuff on the graphics but I was too busy to integrate it yet:
- Animated main title image (it’s gorgeous)
- Ideas for beautifying settlement encounter map tiles
- A bold version of our font (I still need to see if and where we will be using this)
Total size of the codebase after this week
- 24,516 LOC in 398 files for the actual Realms of Ancardia game
- 19,012 LOC in 303 files in my own underlying TBRLAPI framework library supporting my most recent roguelike games
- plus extra external configuration files, images, tilemaps, audio files, etc.
