Realms of Ancardia (Weekly Update 1)

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:

PassTime(1.Year() + 7.Months() + 3.Days() + 12.Hours());

Settlement inhabitants milling around

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:

    public enum Reputation
    {
        Honored,
        Respected,
        Liked,
        Neutral,
        Disliked,
        Hated,
        Outlawed
    }

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:

• NPC interaction (e.g. greetings, prices, dialogue options)
• Legal effects (e.g. bounties, guard hostility, arrest)
• 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.