Some weeks are great, some less so. Week 4 was a bit sluggish and annoying due to a large number of bugs suddenly plaguing development. But most were slain. Hooray!
Bugs, bugs, bugs
No idea where they came from but I lost a lot of time (well, at least for some of them) getting them under control:
In week 3 one of my optimizations introduced a memory leak that took me 3/4s of a day to fix.
My underlying TBRLAPI originally was designed for games based on the Curses API (well, my re-implementation of it). Realms of Ancardia is more and more moving away from the initial Curses-based approach towards a purely graphical implementation. This caused some friction with rendering and update issues. The underlying architecture of TBRLAPI still puts the Curses-approach too much into the forefront and the less it is needed the more I feel I have to introduce workarounds to get my Curses approach out of the way. I do not yet have a good idea on how to fix the architecture but something needs to happen since a number of update and rendering bugs this week were caused by the unholy combination of the formerly dominant Curses approach and the now evolving pure tile based and graphical approach. Birth pains of an API…
A Rider update wrecked my gut behavior. And while I love version control (and am fine with git generally) I really think that the git command line interface is one of the worst designs ever. Arcane, full of weird special cases (at least it feels to me like that), etc. It probably all makes sense if you manage a project with the size of the Linux kernel but I still feel that the git interface is just lousy for the majority of software development projects it is being used in. The wrong system won the VCS war in my book. Or at least someone should have taken the time to make git a lot more understandable for 95% of the cases. I lost half a day getting git to forget about files it suddenly started tracking and I still don’t know why this happened. What a lousy way to spend time…
There were some rendering issues where “dirt” is cached somewhere.
Character generation started
It finally feels like the game needs some flesh. So we need to start generating an actual character. I have started working on a primitive character generation screen which will be beautified once the various components of character generation are stable enough. For now it is ugly as hell. But it’s there.
On the main screen you can select the general generation mode (totally random or based on the name of the world and the character are the only two options righr now but a lot more will follow), generate a random world name (later you will be able to enter it yourself but we do not yet have code for text input), a character name (same challenge, but if you have selected a race and a gender then the internal race- and gender-specific name generators are utilized), select race and gender and prioritize talent categories.
The latter is the first major deviation from ADOM: Where in ADOM you have a ton of classes in Realms of Ancardia you can give different priorities to ten areas of expertise (see below for more details).
Each category has up to five levels of expertise (plus “untrained”). If you have at least some expertise you gain attribute bonusses during character generation, skill costs change (for the better the more excpertise you have) and you eventually will get other benefits (like free feats or special abilities).
We also are going to add back the professions from ADOM although they will have somewhat different rules and basically just are prioritized talent category sets. So in the end they will be useful to speed up character generation but you also have the option to kind of “cook” your own profession.
Here are some screenshots from the current state (most beautification still is missing… we just want to get ground by adding content on our race to an alpha release in… months… years… who knows 😉 ):
The main character generation screen so far (work in progress)
The ancestry selection screen
The gender selection screen
The talent priority selection screen
There is still a lot of work to be done but this IMHO is starting to look decent in a certain old school way I really enjoy.
Talent category system
I have implemented the talent category system. The following ten talent categories exist (taken from the source code):
The general scope is much wider than in ADOM because eventually Realms of Ancardia will allow for a lot of activities besides dungeon crawling and monster killing – like building trade empires, raising armies and more.
Skill system
An initial draft for the skill system has been implemented (but the individual skill functionalities are going to be added over time). Here is the skill list from the source code together with the attributed talent categories (see above):
Skills are ranked and run from 0+ to 40 and more. Usually they will be in the 0-20 range for normal adventures and might rise above 20 for experienced or highly specialized characters. The following abstract ranks are used (again taken from the source):
I revised the name generators to create a lot more ADOM-like names. I’m a lot happier with the results and now tens of thousands of beings can have unique names.
I added special algorithms for shopkeeper names, ratling trader names and dragon names.
I added dragon personalities tried to unique dragon titles for special dragons.
Added faith points as a new attribute. While ADOM used power points for priests and wizards, Realms of Ancardia will differentiate between power points (used for arcane magic) and faith points (used for miracles).
Renamed talents to feats.
We debugged an annoying memory leak.
Krys enhanced many tiles making them subtly more beautiful and also added more monster tiles.
Some bugs were fixed related to combat and actions.
Total size of the codebase after this week
28,022 LOC in 440 files for the actual Realms of Ancardia game
21,635 LOC in 369 files in my own underlying TBRLAPI framework library supporting my most recent roguelike games
plus extra external configuration files, images, tilemaps, audio files, etc.
Week 3 was a bit slow because I was away with family & friends on a five day vacation trip to the wonderful isle of Borkum. I’m still happy with the progress I managed. All in all Realms of Ancardia is shaping up nicely, considering that we probably need at least 12-18 more months for an early alpha release. Let’s look at what was accomplished.
My personal goal for week 3 was to work on the graphics framework of the game and introduce lots of new UI elements plus a dynamic layout composition system for UI elements. But before I could tackle that I had to clean up issues left unsolved during week 2:
Refactoring of movement system finished
I failed to finish the (un)planned refactoring of the movement system during week 2 and thus had to continue working on this. Major subsystems now have been fixed or integrated:
There are now time-based actor lists that control who acts when. And what happens on the sidelines.
There is now a standard way for switching maps back and forth including PC positioning.
The internal main loop has been greatly simplified.
The way to calculate time spent has been standardized.
The movement system has been fully standardized.
About 50+ bugs related to his system created in week 2 have been fixed.
UI component set implemented
Currently we still use an underlying Curses implementation of my own for the text on the screen. Eventually I want to be able to use a smart configurable component library to place elements as needed. This week I implemented the framework for a library that allows various layout managers, nested elements and scaling. Neato!
At this point I really feel happy with the decision to use MonoGame as the foundation for my framework. It is stable, clean and has few areas of weirdness (keyboard handling being one – but we’ll see about that later). And so far it seems to be extremely efficient for rendering which makes me very happy,
Also the APIs are elegant to use. All around bliss and for me a much better experience than with Unity or GameMaker (although GameMaker had a certain charm – but in the end it was a convoluted puzzle box with strange bugs… so I will continue to please my NIH syndrome and move forward building my own game engine 😉 ).
Option selection UI added
Already now the player is faced with options (although peculiar due to testing purposes – like “which group of commoners in a settlement should I attack?”). So far we had no UI for this. During this week I added a nice component framework setup (see above) and a dialog for option selection was the first use case.
I am quite happy with the results (although we still need to work on visual decorations). This is the code sample:
The code above creates this kind of dialog on the screen:
Obviously this needs a lot of graphical sugar and we already have ideas we want to explore. The following is a very early sample design and once Krys and I finalize the actual UI design I’ll integrate the design into the code:
(please ignore the typos – rapid prototyping here 😉 )
Tooltips
I have implemented the basic framework for tooltips. Tooltips will get lots of more detail and visual enhancements over the next weeks and months but now there is a rock solid foundation that allows arbitrarily complex and detailed tooltips. This will help us make the game a lot more accessible than ADOM ever was.
Here is a sample screenshot of a (yet unstyled demo) tooltip:
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:
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).
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.
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.
This post marks the first post in hopefully a long series. I intend to report each weeks additions and changes to Realms of Ancardia. To let you know where we are going. And to have a diary for myself. I hope you enjoy it as much as I do. Feel free to ask questions or comments – you might be able to influence the directions we take 😉 Worked well for ADOM, maybe it can do its magic once more.
The last couple of days I had been struck down by a nasty cold (thanks to my daughter who got a very mild version and offloaded the nasty stuff to me 😉 ). Thus work on RoA has been a bit slower than usual.
Still quite a bit of stuff got implemented during the past seven days.
Alpha transparency for settlement lights
First of all I fixed a problem with alpha transparency handling in my underlying graphics framework (Realms of Ancardia: Eternal Strife is built using C# and MonoGame) that ruined the look of our settlement lights by night. Now they are nice, cozy and beautiful (in a certain dark and grim way):
Ancardian Calendar added
Realms of Ancardia now uses the actual Ancardian calendar with all of its special months and days.
Also movement now costs time (but that amount of time still needs to be affected by terrain and actions) and we display a trivial textual calendar info on the right hand side (this will eventually be replaced by something more graphically & beautiful):
Sunrise and sundown
Settlement colors now change dynamically when the sun goes down or rises again. Also lights in buildings are turned on and off in a kind of randomized manner to simulate the habits and professions of the inhabitants. Naturally sundown is tinted with a slight orange while sunrise uses cool shades of blue. As they should. Tiny details? Important details? No. But these details create the idea of a living and breathing world full of details. And that’s where we are heading.
Enjoy a full night in Ancardia in some remote settlement:
Fluent interface for the passage of time
I added a simple fluent interface so that I can easily specify the passage of time in accordance with the special rules of the Ancardian calendar in my code:
Now inhabitants of settlements move on the streets. Not much functionality yet but it’s a first step:
Implemented trade route system (mostly)
Ancardia actually has a vast number of settlements placed on the world map, typically 100+, ranging in city from small hamlets and villages to towns, cities and metropolises.
Side note: City-state like structures are the largest form of organization in Ancardia. It seems that ChAoS has prevented larger forms of rulership from forming. So there are no kingdoms larger than a single metropolis.
Between all these type of settlements naturally a lot of trade is happening. Well, at least between some. Settlements aligned with good e.g. won’t trade with settlements aligned with evil. And the type of government (did I mention we have 21 types of government for our settlements), the dominant population, the size of the settlement, whether it is a sea and/or river port and other things influence how capable the settlement is of trading with others.
I just added the initial generation of the trade network. Right now it is only kept as a data structure in the background. The following excerpt might get you a glimpse of its structure:
Land mass (Continent) with 46105 tiles:
178 dungeons, 82 settlements, 20 ports of call
Settlement data:
Erlthel (417 inhabitants), Village, TribalConfederation, Chaotic Good: 0/0 land trade partners (7 range), 0 sea trade partners.
Celgwynriel (2137 inhabitants), Town, FreeCity, Chaotic Neutral: 0/4 land trade partners (50 range), 0 sea trade partners.
Indorwyn (364 inhabitants), Village, Golemocracy, Chaotic Good: 0/1 land trade partners (10 range), 0 sea trade partners.
Red Stone (7919 inhabitants), City, NecrocracyTyrant, Lawful Evil: 3/3 land trade partners (420 range), 0 sea trade partners.
New Woodhaven (79 inhabitants), Hamlet, Magocracy, Neutral: 0/1 land trade partners (50 range), 0 sea trade partners.
Rockland (24017 inhabitants), Metropolis, Theocracy, Chaotic Good: 0/14 land trade partners (65 range), 0 sea trade partners.
White Water (24337 inhabitants), Metropolis, MerchantOligarchy, Chaotic Good: 0/43 land trade partners (150 range), 0 sea trade partners.
Green Hill (8682 inhabitants), City, MilitaryCommandery, Chaotic Good: 0/4 land trade partners (37 range), 0 sea trade partners.
River Bridgeville (7381 inhabitants), City, Magocracy, Neutral: 7/7 land trade partners (375 range), 0 sea trade partners.
Mirthaswen (278 inhabitants), Village, MeritocraticTrialocracy, Neutral: 0/2 land trade partners (16 range), 0 sea trade partners.
River Fieldhaven (77 inhabitants), Hamlet, Golemocracy, Neutral Evil: 0/1 land trade partners (8 range), 0 sea trade partners.
Calthasael (2202 inhabitants), Town, LotteryDemocracy, Chaotic Good: 0/4 land trade partners (25 range), 0 sea trade partners.
Green Rockburg (6937 inhabitants), City, TribalConfederation, Neutral Good: 4/7 land trade partners (56 range), 0 sea trade partners.
Brookton (6620 inhabitants), City, Theotechnocracy, Lawful Neutral: 25/28 land trade partners (375 range), 0 sea trade partners.
New Brook (6004 inhabitants), City, TribalConfederation, Lawful Evil: 7/7 land trade partners (90 range), 0 sea trade partners.
West Field (8608 inhabitants), City, NecrocracyCouncil, Lawful Evil: 2/2 land trade partners (480 range), 0 sea trade partners.
Huegelstadt (8035 inhabitants), City, Dreamocracy, Lawful Neutral: 7/7 land trade partners (75 range), 0 sea trade partners.
...
The debugging output shows the name of the settlement, the number of inhabitants, the type of settlement, the type of government, the alignment of the settlement and then the trade partners (land trade has a maximum range per settlement based on the capabilities of the settlement). You can’t see dominant populations in that outlook but the names of the settlements might hint at elves or dwarves in a few cases (Realms of Ancardia has race-specific name generators).
Why all this? On one hand trade influences the wealth of settlements which in turn determines which wares the player character might be able to purchase at which price points. On the other hand later on the trade network will spawn caravans and trade ships as world map encounters. You will be able to travel with those traders (usually more safely than alone but maybe at a cost), you will be able to attack caravans and ships (piracy, yay!) and you even will be able to affect the fortune of a settlement if you manage to block their trade routes. Which might destabilize government and eventually could allow you to take over the settlement. If you find that more interesting that dungeon crawling that is…
Right now there still are some bugs in the code and the trade routes are not correctly determined.I’m still working on this but my A* implementation currently has some trouble with the wrapping nature of the world map. Land trade routes already worked (better than above where too many are listed as zero) but sea trade routes have ever been broken. I’m working on this and it seems my changes to the sea trade route problems also partially broke land trade routes once more… *sigh*
Implemented infrastructure for beings and items
One of the things I always find most complicated is to find the right mix of detail and abstraction when handling special abilities, skills, talents and all that.
In my game ADOM many things are hard-coded special cases and data structures are overly generic and flat. So the typical data structure contains several dozen of properties but only needs a handful of them.
In Ultimate ADOM we took the opposite approach. I was fascinated by Caves of Qud and how Brian Bucklew and Jason Grinblat had managed to build a mind-boggingly flexible system for items and abilities. Brian kindly allowed me to have a look at the Caves of Qud code to understand how their system worked. For a while I became totally enarmored with entity component systems (the underlying technology) but my first real implementation in Ultimate ADOM probably suffered a little from my inexperience with ECS: It was overly complex and performance was problematic in some cases. Nonetheless the system was incredibly flexible and all the promise of Caves of Qud also materialized in the underlying engine of Ultimate ADOM. Sadly we ran out of money before we also were able to materialize the power of the engine as pure and simple fun in the game (at least to the extend we had planned). In summary my gut told me that my next game would use a simpler approach.
For Realms of Ancardia I have for now decided to try the following approach:
Beings (monsters, the PC, other NPCs) either can be simple or complex beings. Both are characterized by set of capabilities.
Simple beings consist of a hard-coded set of capabilities that basically are unchangeable (except for temporary effects from spells, magical items, etc.). Most things for simple beings are simulated (e.g. an orc has no real equipment but just predefined combat values). This basically is the approach used for most ADOM monsters before I started to partially introduce inventories for monsters in ADOM (something that never was fully completed due to inherent code complexities).
Complex beings are reserved for the player character and very important NPCs. They have an inventory (both equipped items and whatever they carry in the backpack), skills, talents and traits. All the factors can modify the set of capabilities and have complex potential interactions.
Skills have levels and simulate learned things (like athletics, pocketpicking, stealth, and many other things). They can modify capabilities and might activate special means of interactions.
Talents are special abilities (like ambidexterity, talent with wilderness skills, luck at finding certain things, etc.). Like skills they can modify capabilities and might activate special means of interactions.
Traits are special modifiers (like undead, magic resistance, …). Again they can provide modifiers to capabilities and might activate special means of interactions.
The difference between talents and traits mostly is one of semantics and how and where they will be displayed, selected and changed. Skills differ in that they can have levels.
This week I implemented an initial infrastructure for all of this. Almost all details are missing (there are not yet any items, skills, talents or traits, etc.) but for now a solid infrastructure exists and I have managed to get a feeling if the defined code architecture will be able to handle the special cases I have in mind.
Later on another special category of powers will be added (similar to skills but limited to the player character due to his very special nature in Realms of Ancardia – I will elaborate on this in some later post).
Implemented infrastructure for encounters
Realms of Ancardia breaks with a few classical assumptions of roguelike games which is why I sometimes like to call it the most unroguelike roguelike. Eventually I will blog about this in more detail but let’s just say for now that at any given map position the game does not just memorize a monster (or the player) but full-blown (and potentially very complex) encounters. And one position even can hold more than one encounter. Encounters can be a lot more than just a single monster or a group of monsters… imagine anything like a monster, a full-blown ambush, a riddle, a treasure chest, the entrance to something else, a horde of monsters waiting for, some interesting NPC or even a group of interesting NPCs, a story sequence, etc. pp. Encounters also can be moving or static. Therefor a different system than my standard “one being per position system” had to be implemented. Which happened this week.
Encounters have a lot of detail connected to them:
name and description (all texts in Realms of Ancardia have been prepared for internationalization)
Position
Movement rules (if any)
Encounter radius (an encounter will be initiated once you enter its radius… this makes for interesting new challenges in dungeons; also tactical movement gets a new dimension)
possible interactions for passive encounters
and encounter-specific code describing what happens in detail (from spawning a battleground upon iniating the encounter and placing all foes to simulating a large shop or whatever you can think of)
Also encounters are categorized as one or more of four categories that happen in sequence (because there can be more than one potential encounter per sequence – imagine e.g. ten different citizens on a space, one just walking around, another waiting to pick your pocket, a group of four house wives available to chat about rumors, one disguised assassin planning an attack and two adventures that are looking for a job – just as an example). We currently have the following encounter categories:
Reactive encounters: Happen automatically in phase 1. Can’t avoid them. E.g. traps or meta encounters that prepare something else.
Combat encounters: Monsters and all kinds of enemies. Try to evade them or fight them. I’m still wondering whether to combine groups of enemies in one big fight or have you fight them sequentially. Probably the latter for the first version to simplify setup but we will see.
Active encounters: Encounters that engage you. A ratling trying to sell you something, a dying adventurer seeking help, etc.
Passive encounters: These ones only provide interaction options.
All of these can be combined and mixed for a very lively environment.
Actual encounters still need to be added. There currently is but one simple demo encounter representing a crowd of people in a settlement. More details on this once I implement it in its full-blown glory.
Implemented combat encounter map architecture
As mentioned elsewhere Realms of Ancardia is not unimodal. The game often will switch between modes, e.g. the surface world map mode, the settlement mode, the dungeon mode or the encounter (battle) mode. When a battle occurs you zoom into the current map and face your opponents. Until either side is dead, has surrended or fled.
I have prepared the infrastructure for this and now am ready to add actual encounters and battles. But there still is a lot of work to be done before we have a fun and detailed combat system.
Started work on actual encounters
I started implementing the first type of encounter – which directly probably is one of the most complex and convoluted scenarios I can imagine: A “settlement inhabitants encounter” generically representing the people walking through the streets and filling them with live by randomly created a subset of settlement encounters that change after a certain interval.
Tons of interesting questions arise from this and week 2 and the next update probably will mostly focus on topics surrounding this.
Implemented a framework for settlement event propagation
Let’s just say: When something happens people should have a chance to know. Weekly update #2 next week will explain this in more detail because I’m working on this right now. The summary would be: It’s a relatively simple architectural element that creates tons of fun interactions and adds a whole new level of vividness to settlements. More on this in the next update…
Implemented a reputation system
The player will have a reputation in each settlement (and reputations might spread based on trade routes and other factors like extreme notoriety).
We use the following base range of reputations possible:
These reputations are derived from your reputation score measured against a dynamic scale based on settlement parameters.
Additionally I have defined 29 different crime types that can result from your actions in a settlement (eventually – right now I am just working on the general infrastructure, the actual gameplay is not yet there). Whenever a crime is committed this modifies your reputation score roughly like this:
by settlement size (it’s easier to get away with things in larger more anonymous settlements)
by government type (each of the 21 government forms has different proprities regarding the 29 crime types)
by dominant population (e.g. dwarves have different opinions towards certain crimes than orces)
by settlement alignment (lawful good settlements definitely regard crimes different than chaotic evil societies)
The player can build up a crime record and might suffer its consequences – good and bad. The consequences fall into a variety of categories:
Access to services (shops, healers, temples, training, quests)
Social influence (e.g. followers, leadership offers, cults)
Quest and faction effects (e.g. hidden quests unlocked or blocked)
Settlement behavior (e.g. being banned, celebrated, executed)
The general infrastructure for this has been setup details. But details still need to be implemented.
Personally I always loved the “every action has a consequence” moniker of Fable and I finally feel that I am heading into the right direction with my game design with this approach.
Implemented a justice system
Where there is crime there must be punishment. As a consequence I have implement a justice system that takes a number of parameters like settlement type, dominant population, government type and alignment of the settlement and based on that defines punishments for each of our 29 types of crimes.
Justice rarely is absolutely neutral though. Thus your reputation in a settlement might affect the punishment for better or worse if you are caught.
Side note for a minor but nice detail: One form of punishment is branding. Not only does that reduce charisma and appearance, but it also lowers your base reputation when you come to a new non-evil settlement making it progressively harder to be accepted.
UI text colors now are configurable
So far most colors for the UI were hard-coded. For the tiles, features and encounters we have been using a mapping file for a while now. Therefor I now also integrated the UI color definitions into this file to make the UI more easily adaptable:
################################################################
#
# Meta colors for the UI.
#
################################################################
# Top text bar in the main screen.
ACP_MainMenuTitleBarForegroundColor : %8B4513
ACP_MainMenuTitleBarBackgroundColor : %ebd5b3
# Colors for the command line on the main screen
ACP_MainMenuCommandBracketColor : %FFFFFF
ACP_MainMenuCommandKeyColor : %FFFF00
ACP_MainMenuCommandTextColor : %AAAAAA
ACP_MainMenuCommandBackgroundColor : %000000AA
# Colors for the statistics area on the right hand side of the screen.
ACP_InGameStatisticsSidebarForegroundColor : %8B4513
ACP_InGameStatisticsSidebarBackgroundColor : %ebd5b3
ACP_InGameStatisticsSidebarMessageIndidatorForegroundColor : %ff0000
# Colors for the temporary popup.
ACP_StatusMessagePopUpAreaForegroundColor : %ffffff
ACP_StatusMessagePopUpAreaBackgroundColor : %000000aa
Later on more color details probably will be added as needed. ACP by the way is the shortcut for “Ancardian Color Palette” 🙂 Nice invention of Krys.
Miscellaneous minor changes and fixes
Now correctly reset day/night settings when leaving a settlement.
Added new translations for the calendar information (special days, weeks and months; did I mentioned that Realms of Ancardia is prepared to be fully translated? I’m just adding English for now and probably will add German as my native language at some point – the rest then will be left to the community).
Also the commands shown on the main title screen now can be translated.
Added a “wait” command that, well, waits.
Added a “special rules hook” for individual items.
Started work on a basic interaction system.
Added more rules for deriving settlement alignments from government types (Realms of Ancardia utilizes a total of 21 government types for settlements and uses the nine-fold D&D allignment system along the axis of lawful-neutral-chaotic and good-neutral-evil).
Defines a set of 29 relevant crimes that will affect your reputation in settlements. Which will have consequences like bounties and the full weight of the settlement-specific judicial law system. If there are laws that is…
Funny oversight: I had forgotten about dark elves because so far I worked on the surface world. Dark elves now are back.
Beings now have alignments and alignments can be changed (no consequences yet though).
Added a simple framework for gaining reputation by performing good deeds.
Krys improved our font.
Krys optimized many tiles and colors for the game screen.
Krys is working on enhancing the main screen image (animation, yay!).
Krys has painted beautiful frames for an animated calendar view of the Ancardian calendar. Now I just need to get around to implement it.
Total size of the codebase after this week
18.856 LOC in 289 files for the actual Realms of Ancardia game
18.686 LOC in 297 files in my own underlying TBRLAPI framework library supporting my most recent roguelike games
plus extra external configuration files, images, tilemaps, audio files, etc.
A long time ago I tried to learn the C programming language and used my fascination for procedural generation as a foundation: I had played Hack, Rogue and Nethack and was absolutely in love with how these games managed to create random worlds. Being a young programmer I had no idea how this worked and in the pre-internet days information was pretty hard to come by. So I set out on my own and the results after a couple of years of relentless work was ADOM – Ancient Domains of Mystery, nowadays called one of the five foundational roguelike games and a true classic (let’s put modesty aside for a second). It still today sells well on Steam and in October 2025 will again be under my full control – which is something I have been waiting for for quite some time.
After ADOM I began dreaming of JADE (Java-based Ancient Domains Engine), a sequel to ADOM with a much bigger scope. The scope was meant to be far greater than ADOM – a whole world to explore full of cities and dungeons and tons of other fun stuff. More modern, more flexible, more of everything. Sadly real life caught up with me (I founded a company called QuinScape, now renamed Dataciders QuinScape, I got my Ph. D., I married, etc.) and I did no longer have the time to work on a new game with as much vigor as was needed to get anywhere. Thus JADE lingered and eventually disappeared… for a brief resurrection when I worked on it under the name of “ADOM II”. But all this led nowhere and eventually JADE faded away. Nowadays Oracle has messed up Java so much that I wouldn’t even want to touch the source code again.
Then followed a time of greatness when ADOM was resurrected with an Indiegogo crowdfunding campaign where during 90 days a surprising amount of love and support was poured over us and we came to the point of being able to give ADOM an overhaul adding tile graphics (thanks to the amazingly talented Krys Dycha), amazing sound (kudos to the wonderful Lucas Dieguez), a modern UI thanks to NotEye and the ingenious Zeno and a much more modern, efficient and stable foundation thanks to my relentless and brilliant friend Jochen Terstiege. All this culminated in the amazingly successful 2015 Steam release of ADOM.
Afterwards it became more silent once more as real life (and our growing company) demanded a lot of attention.
During Roguelike Celebration 2017 we announced the next step on our road: Ultimate ADOM. As the name humbly suggests our (MY) ambition was endless and Ultimate ADOM really was meant to become the absolute perfect ADOM experience. I had huge plans for it, we gathered a lot of funding (actually hundreds of thousands of Euros), incorporated as a company, built a team and started working on Ultimate ADOM which finally released to Steam in August 2021. I still think it is a decent game but we failed to achieve our ambition – for too many reasons to recount here and now. This might be a topic for a post mortem around 2028 or so… factually we ran out of money long before we were able to implement everything we had planned.
While the financial loss was big, the emotional loss was bigger. We had to close down the company and the team and live with what we had accomplished. Ultimate ADOM is a decent game but its name created expectations that we could not fulfull right away with the first release (or the first couple of release). I had failed to see that the gaming world in 21st century was far different from the time when the original ADOM was created and we were not really prepared to handle the community reaction we had initiated with the name, the announcements and everything. But this is over.
(and if you are angry about having invested $15 or so and not gotten the game you have dreamed of I can ensure you my own loss is more than 10,000 times that amount… not counting time and emotions which weigh even more heavily than the money involved)
After Ultimate ADOM failed to become what we dreamed of I retreated into a dark and remote hole to lick my wounds and recover. I had lost the energy to think about ADOM or games and was deeply frustrated.
And this was all I knew for a long time as far as my game design days were concerned. Basically I buried all these dreams.
In 2023/2024 I sold most of my shares in the company I created with two friends, gave up being CEO and moved to a part time consultant role in order to have a lot more time for my family (now being a proud father) and my hobbies.
Suddenly I was free. And still my inner game design flame remained gone. I even lost my fun at programming after retiring from the life of a CEO of a company group with by then about 650 employees. This was a first for me since I always had been programming since I got my C64 in those days of yore.
But there was so much family fun to be had, so many books to read, so many games to play, so many movies to watch that I never felt bored or truly missed programming. It was more a sense of surprise that I could live without programming after I had been programming for more than 40 years almost constantly.
Finally six weeks ago this again changed. I started talking to my good friend Krys (the amazing artist that created the tiles, the website and many mood images for ADOM and Ultimate ADOM). We talked about doing old school games and I started telling him about a game prototype I had written a couple of years ago as a kind of sequel to JADE. Taking the learnings from ADOM, JADE and Ultimate ADOM and once more trying my hand at “my perfect game”. And suddenly things clicked.
I felt the urge to restart work on this game, Krys agreed to work on graphics for it and the past 6-8 weeks we have been busy on making this game slowly come to life).
Do not mistake me – I am not going to announce or promise anything… I have learned my lessons. And maybe this game never will be finished. And even if it will be finished I am 100% sure the first alpha (with very little meat) is at least 12-18 months away. And the full game surely will take 5-10 years to build because I can’t quench my ambitions.
We will see where this leads… or if it leads anywhere at all. But right now I am full of joy working on the game frantically in every second not taken up by family, friends and other commitments. During the past couple of weeks I noticed that so many features get added in such a short amount of time that I need to track this in some way. Being old-school the best I could think of was a weekly blog entry giving insights into what is happening. If nobody cares that’s fine and the blog will serve as just my personal diary for the development of the game. And if someone becomes interested in the game this would be so much better. But it is not required. We are free to do what we want and that’s the great thing about it. For the first time since I started writing the first lines of code for ADOM I am truly and absolutely free to do whatever I want and I finally can write a game without being distracted too much by real life, budget restrictions, publisher plans, marketing requirements or even community opinions. I simply can work on “my perfect game”. If it ever is finished this is great, if not the journey already is extreme fun.
So enough words for today… soon you will read various tidbits of something that has the working title
Realms of Ancardia: Eternal Strife
(and while this is a game set in the world of ADOM it is not ADOM III, Ultimate Ultimate ADOM or even a sequel to ADOM… it’s a new fresh game in the world of Ancardia… kind of starting at the end of ADOM and even more ambitious and grandiose than ADOM… but only with things I want in MY game)
Read ya soon… Axes high till then!
P.S.: Want some teasers? Here we go. All bound to change a lot but it’s what we have so far…
The current title screen… still lots of work in progress and obviously old-school.
Exploring the world. Needs tons of adjustment – it’s demo level right now. But we have a huge world to explore, hundreds of settlements with complex organizational structures already are being generated, dungeons are available… and about one-million features still need to be added before you can seriously play this.
More world exploring…
Visiting a settlement. 99% of the actual gameplay for settlements is still missing, but there will be governments, rulers (you might want to serve or ursurp), lots of special buildings (temples, magical academies, shops, markets, zombie slave markets, golem factories, you have it), varied law systems, a commerce system, the opportunity to build or buy houses and… and… and… said million things still missing 😉
As the actual gameplay potentially will span centuries I am right now having fun implementing algorithms that model the consistent change and growth of the world around the player… so that a city still is somewhat recognizable as the humble small town it started as like 90 years ago. Lots of fluff I’m doing right now but it is immensely joyful.
I will talk about this and other things in future posts.
Um dir ein optimales Erlebnis zu bieten, verwenden wir Technologien wie Cookies, um Geräteinformationen zu speichern und/oder darauf zuzugreifen. Wenn du diesen Technologien zustimmst, können wir Daten wie das Surfverhalten oder eindeutige IDs auf dieser Website verarbeiten. Wenn du deine Zustimmung nicht erteilst oder zurückziehst, können bestimmte Merkmale und Funktionen beeinträchtigt werden.
Funktional
Always active
Die technische Speicherung oder der Zugang ist unbedingt erforderlich für den rechtmäßigen Zweck, die Nutzung eines bestimmten Dienstes zu ermöglichen, der vom Teilnehmer oder Nutzer ausdrücklich gewünscht wird, oder für den alleinigen Zweck, die Übertragung einer Nachricht über ein elektronisches Kommunikationsnetz durchzuführen.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistiken
The technical storage or access that is used exclusively for statistical purposes.Die technische Speicherung oder der Zugriff, der ausschließlich zu anonymen statistischen Zwecken verwendet wird. Ohne eine Vorladung, die freiwillige Zustimmung deines Internetdienstanbieters oder zusätzliche Aufzeichnungen von Dritten können die zu diesem Zweck gespeicherten oder abgerufenen Informationen allein in der Regel nicht dazu verwendet werden, dich zu identifizieren.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
