This week work simply continues on a variety of topics.
And one big change: For now we probably will switch to roughly monthly updates instead of weekly because there is so much work yet to be done in the background of our framework and custom engine that I fear that weekly updates will simply feel to irrelevant. Be assured this does not mean that work slows down… it just gets more focussed on things that matter.
As soon as I feel that update posts get too long and extensive we’ll again return to a somewhat shorter time frame between updates.
Started mouse integration
So far the game has been mostly usable via keyboard only (except for tooltips). I have started the work to extend my framework so that mouse clicks can be used everywhere. Contrary to my initial estimate it takes far more effort to extend my framework with this feature than I had expected. Therefore this story will continue for a while as I add more and more mouse support.
Sadly some early architectural decisions that worked splendidly with a keyboard-only game now return to bite me and I yet have to find smart ways to get the ensuing trouble under control. But eventually Realms of Ancardia hopefully will be completely and easily playable by mouse. Stay tuned!
Color scheme improvements
We have changed the color scheme to feel a bit more consistent and darker.
Before:
After:
(yeah, my bad – I forgot to take a “before” image and thus had to use an older screenshot that also lacks the border lines – sorry for that)
Entering settlements
Work on this feature continues. Still not completed but evolving and lots of general framework features come out of this that will speed up the process a lot for other encounters in the game:
Miscellaneous minor changes and additions
Tooltips now show up after a short delay. This feels a lot more natural. Also delays can be individualized per tooltip type (e.g. button explanations might show up after 500-1.000ms while map tooltips explaining map features already show up after 300ms).
Internal color handling has been refactored. The number of color definitions we used started getting out of hand. About 50% have been scrapped and the naming now is a lot more consistent. This is somewhat important to (some) players because it is possible to change the color scheme(s) by modifying an external configuration file.
Total size of the codebase after this week
39,595 LOC in 655 files for the actual Realms of Ancardia game
28,656 LOC in 460 files in my own underlying TBRLAPI framework library supporting my most recent roguelike games
plus extra external configuration files, images, tilemaps, audio files, etc.
We use YouTrack to manage ideas and bugs that pop up. The listings are by no means complete – it’s more of a “don’t eventually forget to fix this bug / add that amazing feature” pipeline that gives a little structure to our development process without turning it into a managed project 😉
Vacation time is over (sadly) which means that we return full throttle to working on Realms of Ancardia. I needed a day or two to remember all the things I forgot during the past couple weeks (so much for my literate codind skills 😉 and I again was sidetracked by weird mini project I felt compelled to complete (after getting addicted to the Vampire Diaries I felt the need to write my own vampire TTTRP – 104 pages later it’s no at Lulu for layout 🙂 ).
If you care here’s front and back of the rulebook containing 104 pages in novella format with compact rules for nice Vampyr sessions…
Now I am finally looking forward to adding actual fun gameplay to Realms of Ancardia – pardon the distractions 😉
Message log and command popup added
We have replaced the continuous message log to the lower right with a context specific popup. We feel that the extra “pop” is a good change to indicate that something important is going on compared to long text logs where it is easy to lose sight of important status changes. What do you think?
Also we now have a popup that shows commands that are available depending on the current context:
Implementation of settlement gate procedure started
Entering a settlement is a small detail – but it has many intricacies. Depending on the organization of the settlement there might be (guarded) gates, guards might raise taxes, random events could occur, you might gather helpful information about the settlement before actually starting to move through it (which can be useful – some settlements might be very dangerous or could affect your health, sanity or whatever).
This week I started the implementation of the procedure for entering a settlement but I probably will need another week to finish it due to the amount of detail to be covered and some lose ends from earlier weeks (e.g. attributing precise number of guards to the individual gates) in order to present a tangible challenge at the gate.
Here we go with a preliminary screenshot – the UI still needs some polish:
Scene graph implementation
Realms of Ancardia uses content-based scene graphs. Note that this is different from the common understanding of scenes and scene graphs in many programming languages where these termins describe graphical nodes and the graphical composition of a view.
In Realms of Ancardia a scene graph is a logical content structure that describe how a specific scene might work out.
Scenes can be highly variable:
entering a settlement
visiting a shop
talking to a stranger
examining a weird altar in a dungeon
etc.
Logically Realms of Ancardia uses a graph of connected scenes. Scenes can lead into each other (e.g. the generic Gate of Settlement scene might lead into the Negotiate Taxes with the Guards scene or the Pick a Fight scene or … whatever).
Scenes have graphical elements (e.g. images or videos to make them more tangible), text elements (e.g. the impression of a city you get when moving towards its gate) and interactive elements (how you respond to the scene).
This week I finished both the implementation of the architecture and the data structure for these scenes as well as of the graphical scene handler that takes an arbitrary scene graph and navigates the player through it, altering the game state, executing consequences, etc.
The screenshot above already is using the scene graph mechanism underneath.
Portraits
Krys did an amazing amount of working on devising a system for building individual portraits:
The individual parts are configurable and you can colorize each element:
Miscellaneous minor changes and additions
The spacing for the in-game stats has been adjusted slightly to use the available white space more reasonably:
Internal mechanisms for adding missing translations have been improved.
Fixed an integer overflow bug in internal random number generation.
Total size of the codebase after this week
39,413 LOC in 651 files for the actual Realms of Ancardia game
27,357 LOC in 451 files in my own underlying TBRLAPI framework library supporting my most recent roguelike games
plus extra external configuration files, images, tilemaps, audio files, etc.
We use YouTrack to manage ideas and bugs that pop up. The listings are by no means complete – it’s more of a “don’t eventually forget to fix this bug / add that amazing feature” pipeline that gives a little structure to our development process without turning it into a managed project 😉
Since it’s vacation time only some little stuff got done. Also I was a bit distracted by working on my TTRPG “Mythen & Monster” which we tend to play every couple of months. 278 pages of player handbook are finished so far, about 50 more to go. And I started my fifth (or sixth or seventh?) attempt at writing a Gamma World TTRP clone suited to my tastes… but all that’s leisurely passtime during vacations and soon Realms of Ancardia will be back to full speed 🙂 After the next brief interrupt of about 10 days… expect development update around the 27th of August when holiday season “finally” is over 😉
Screenshot functionality added
You now can take screenshots from within the game:
F10 takes a screenshot of the whole screen.
Shift + F10 takes a screenshot without controls and tooltips.
Screenshots are saved as a PNG to the desktop for easy consumption.
Improved texts for settlements
Work on actual gameplay has started. First thing was to rework the endlessly long texts for settlements we had so far to install a “gate routine”. When you encounter a settlement there are basically two options depending on wether a settlement is walled or not.
If it is not walled you just can enter and might encounter guards or a lonely sheriff while wandering around. Easy times.
If it is walled you can try to sneak in (success will depend on your skills, alertness of the guards, moats and many other factors) or use the official entry via a gate. At the gate you might have random encounters, hear rumors and be tithed.
Tithes are an interesting thing… because they can bery very variable. Lawful/good settlements, free cities etc. just might let you in without any barrier. Merchant-rules cities, feudal settlements and others might demand a small monetary tithe but other governments might be VERY different. E.g. dreamocracies might demand one of your dreams (e.g. some experience points), undead necromancers might request a bit of your life force and religiously ruled settlements an oath of fealty or sacrifices to their religions (with all kinds of potential alignment implications).
Which leads to…
Random tithe generation system implemented
The highly variable nature of tithes has been implemented in form of a small procedural generator that takes settlement size, alignment, dominant population and form of government and derives the type and height of tithe that might be requested at the gates. Joyful times… now you can be taxed in a roguelike 🙂 And new enemy unlocked: The Ancardian Tax Office 🙂
Miscellaneous minor changes and additions
The background color of the game screen now is manually configurable.
Total size of the codebase after this week
38,503 LOC in 634 files for the actual Realms of Ancardia game
27,005 LOC in 447 files in my own underlying TBRLAPI framework library supporting my most recent roguelike games
plus extra external configuration files, images, tilemaps, audio files, etc.
We use YouTrack to manage ideas and bugs that pop up. The listings are by no means complete – it’s more of a “don’t eventually forget to fix this bug / add that amazing feature” pipeline that gives a little structure to our development process without turning it into a managed project 😉
Back from vacation #1 (of 2) during this summer vacation season. As our flight back from the Seychelles door to door took about 32.5 hours (instead of the planned) and was accompanied by tons of stress due to total incompetence and stupidity of both Etihad and Abu Dhabi airport management we are still recovering. Work on Realms of Ancardia thus restarted more slowly than I had hoped. Still some stuff got done.
Map memory implemented
Before we could start working on actual combat and encounters we finally had to clean up some areas yet untouched. Combat eventually will require nice animations for attack, damage, etc. Before we can implement those we need to cement the architecture of how knowledge about the environment is retained. An important aspect of that is map memory (e.g. what does the player character remember of map areas he currently can’t see).
This is functionality that needs to be contained in the underlying TBRLAPI (my generic framework for all current and future roguelike games I build). Therefor I had to implement map memory and I needed a map memory that was meant to allow variants (e.g. total map knowledge all the time versus limited/growing map knowledge).
There the first thing added this week was a map memory management infrastructure.
Line of sight implemented
After implementing map memory the next important step was to finally add a “line of sight” architecture that allows for various use cases:
You can see everything.
You can see for a certain distance and map elements can block sight or not (the binary simple case).
You can see for a certain distance and map elements have different levels of sight blockage (e.g. plains barely block sight range, forest and hills quite a bit, mountains a lot depending on height).
All three use cases have been implemented and for now Realms of Ancardia useses the binary use case. But this will change soon to have more differentiated sight cases.
Here’s a brief video of the current unpolished state:
Cheat mode implemented
As the game becomes more and more complex we a more and more in need of a cheat mode to speed things up during testing. Therefor we implemented a cheat mode this week. It’s actually ported over from Ultimate ADOM and consists of a neat command line interface with smart auto-completion that can be infinitely extended with commands.
Here’s a brief video showing the initial version (more meaningful commands soon to come):
Tile style experiments
We wrestled with the question of how to evolve our art style for the tiles. After quite a few discussions (also on Reddit) we decided to go with our current art style (right side) and evolve it – it seems to be more distinct and also seems to create more emotions in people with its raw old school power:
3D Globe for the world map
We added a 3D viualization for the surface world map. While we love the style we sadly had to discover that using it causes motion sickness and headaches – therefor we will put it on the backburner for now, work on improvements and hopefully eventually integrate it into the game as a permanent feature.
Here’s a brief demo:
Miscellaneous minor changes and additions
A bug in the player movement code was fixed that caused weird player sprite flickering during movement.
The RoA engine now has nicer error handling when mappings are missing for tiles (which happens quite often these days when we add dozens of new beings, items, …). The engine now not only complains about problems with an exception but the exception also directly contains template code with sensible default mappings that I can copy over with one simple copy & paste operation so that adding stuff is more easy than ever.
Various optimizations and bug fixed have been added.
Total size of the codebase after this week
37,574 LOC in 629 files for the actual Realms of Ancardia game
26,947 LOC in 447 files in my own underlying TBRLAPI framework library supporting my most recent roguelike games
plus extra external configuration files, images, tilemaps, audio files, etc.
We use YouTrack to manage ideas and bugs that pop up. The listings are by no means complete – it’s more of a “don’t eventually forget to fix this bug / add that amazing feature” pipeline that gives a little structure to our development process without turning it into a managed project 😉
It’s vacation time… so for the next couple of weeks things will slow down quite a bit. My current goal is to start having something that resembles a game… e.g. something that allows you to do a few things.
But I expect serious work on the game to commence starting with the update #9 on the 6th of August. In the meantime we enjoy paradise and regroup creative energies…
A little work still got done before vacation time started though:
Settlements are a big focus in Realms of Ancardia and I want them to feel extremely detailed and vivid. Thus the first activity opportunities will focus on settlements. Since we need to test the combat system this will probably bring you into contact with local law enforcement. Which brings me to the primary focus this week:
Law enforcement generation
Realms of Ancardia already has a framework for crime and punishment. But so far I did not spent any time thinking about the makeup of local law enforcement in settlements.
This could be anything from a single old sheriff in some hurthling hamlet to a legion of undead guards led by death knight generals in a dark metropolis ruled by an undead necromancer (and lots of other setups inbetween).
I devised a complex system to determine the types of beings used in settlement watches and militia, determine their training level, morale, composition and equipment quality. All this factors in settlement sizes, dominant races, alignment and naturally government types.
As a side effect more than 50 new monster types were added (although the stats still need to be worked out).
Total size of the codebase after this week
37,361 LOC in 625 files for the actual Realms of Ancardia game
24,280 LOC in 408 files in my own underlying TBRLAPI framework library supporting my most recent roguelike games
plus extra external configuration files, images, tilemaps, audio files, etc.
We use YouTrack to manage ideas and bugs that pop up. The listings are by no means complete – it’s more of a “don’t eventually forget to fix this bug / add that amazing feature” pipeline that gives a little structure to our development process without turning it into a managed project 😉
This week was focussed on finally getting a little game ready to be played. For many things it’s still too early but a lot of basics needed to be finished and/or improved.
Soon vacation time starts and during the summer holiday I probably will work a lot less (if at all) on the game. So weekly updates 8, 9 and 10 probably will be much shorter – if they happen at all (or they will happen later). Should there be a brief period of silence, fret not – regular updates will return.
Random talent category selection improved
If you select random talent category selection during character creation the game now tries to create a variety of more sensible builds for the character. There are certain primary talent categories (arcane, combat, thievery and religion) and all the others are marked as secondary. In most cases the game will try to distribute the available talent points to a limited number of categories. It also ensures that (in most cased) one or more of them are selected from primary categories.
Skill selection implemented
Random skill selection was implemented. To achieve this a lot of things had to be done:
Skills had to be associated with talent categories (e.g. grouping all knowledge skills, all combat skills, etc.). Currently we have a total of 80 skills in 10 talent categories.
An experience cost system had to be implemented mapping initial skill points to levels.
Weapon types had to be mapped to combat skills.
Lots of layout issues were wrestled.
Skill selection tries to be smart:
Each category has some primary (more important) skills that are handled preferentially.
Available weapons and armor are taken into account to select the most useful combat skills.
Generic skill points from the ‘Skills’ category are distributed on more important skills.
Skills now are distributed across three tabs (yet unstyled):
Combat skills
Primary skills
Secondary skills
Started work on the extended combat system
If you look at the combat statistics for Realms of Ancardia in their current state you will notice more values than in ADOM:
DV: Dodge (or defense) value. I can’t decide on naming. This number needs to be surpassed by the attack roll in order to hit a being.
PV: Protection value. The amount of damage absorbed by armor, tough skin, magic or whatever whenever a being is hit by a damaging attack.
#P: The number of parries per combat turn. Each time an attack hits the defender gets a chance to parry the blow for as long as he still has parry attempts available. Note that you can’t parry blows from attackers two size categories larger than the defender. Usually weapons grant one parry attempt (rapiers grant two). High weapon skills can modify this.
PB: The parry bonus. A bonus to the roll to deflect an attack. If the parry roll is equal to or greater than the attack roll is blocked.
#B: The number of block attempts per turn. These are granted by shields but rules-wise work like parries. Small shields grant one block attempt per turn, medium shields grant two and large shields grant three.
BB: The block bonus. Larger shields grant higher bonusses. As well as high shield skills, magic, talents, etc.
H: Hit points. You are dead when they drop to zero.
P: Power points. Energy used to charge arcane spells.
F: Faith points. Like power points. But for miracles. Godly magic is intended to be quite different from arcane magic in Realms of Ancardia.
Damage indicator added
We now have a nicely pulsing frame for the screen when the PC gets damaged. The frame gets thicker and thicker the more wounded the PC becomes. And the rate of pulsing increases as damage gets more serious.
Item statistics in the inventory
I spent way more time than I had planned or expected on displaying items in the inventory. Realms of Ancardia is pretty close to ADOM in the amount of statistics structurally (and has even more details like damage types, different but cumulative damage ratings and some other details) and it took quite a while to get the display of item statistics into a somewhat decent form. Here is a sample:
Equipment view
Backpack view: Here more work is open (e.g. item stacking, grouping, …)
The bad thing is that I will have to completely refactor this because I noticed too late that the current approach prevents me from using that data in messages. Doh!
There are also some details to be fixed (e.g. the coloring with the weapon damage entry). And graphical glitz will eventually be added. Also more statistics (like e.g. seeing the full combat values for the stuff you equipped, etc.)
Character creation modifier infrastructure
I created infrastructure in order to allow subtle and less subtle character (or game state) modifications during character generation. Currently this is being used for
handling hurthling special starting conditions
ensuring that mist elves have all-mithril equipment
very religious characters have guaranteed blessed equipment
In the future the same infrastructure will be used to e.g. handle special starting conditions due to date circumstances and other factors.
Time wasted on sucky Apple Silicon support
Apple really fucks up many great projects with its Apple Silicon move. Despite Apple Silicon being great. But so many good libraries simple don’t work because the hard-pressed communities spending their time, love and energy on these projects seem to be stretched too far by Apple Silicon requirements.
Our project was hit by the fact that LibVLC (at least to my knowledge) does not have any working support for arm64. At least I couldn’t get it to run after spending many hours trying to get this fixed.
As a consequence of my switch to Apple Silicon for the Apple version of Realms of Ancardia we no longer can play videos. Which sucks.
This caused me to switch to SkiaSharp as my new framework for video display. For now this seems to work (fingers crossed).
And Death rejoices…
Character generation is (mostly) complete
Except for some minor details (beautification, more starting equipment, saving defaults) character generation now is complete. It has (for now) four modes (random/deterministic world, random/deterministic player character) and you can select race, gender and talent priorities. Specific skills and starting equipment are selected by the game. Also the character generation screen has become a lot more interactive and smarter…
Character generation screen for an aspiring dwarven hero
Miscellaneous minor changes and additions
The skills tab on the ‘i’nformation dialog was split into “Combat skills”, “Primary skills” and “Secondary skills” as we ran out of room trying to put everything into one tab.
The keys 0-5 now can be used to instantly alter talent category levels during character generation.
We now have functionality for string input (e.g. names).
The inventory and back now show more detailed item descriptions.
Fixed various small bugs.
Added a number of missing translations.
Krys designed tons of great graphical enhancements and detail improvements and I yet need to find the time to add them all. Our issue tracker (see below) is filled with them. For now we have decided to add a little more gameplay to see how certain things will work and stabilize before doing a grand graphical update development sprint (probably: several sprints).
Total size of the codebase after this week
36,186 LOC in 615 files for the actual Realms of Ancardia game
24,280 LOC in 408 files in my own underlying TBRLAPI framework library supporting my most recent roguelike games
plus extra external configuration files, images, tilemaps, audio files, etc.
We use YouTrack to manage ideas and bugs that pop up. The listings are by no means complete – it’s more of a “don’t eventually forget to fix this bug / add that amazing feature” pipeline that gives a little structure to our development process without turning it into a managed project 😉
This update is one day early – simply because tomorrow is Creator’s Day and on Creator’s Day there shall be no work 😉
This week saw major architectural changes. It started off with deleting lots of code I had created during the past weeks (and during several months when I started a first draft of this game a couple of years ago). This brings the one major change in week 6:
Curses foundation removed
When I originally started to work on Realms of Ancardia I had planned to create an ASCII-only game. Because it was meant to be a great passtime for me, I have no graphical talent, I had no artist available to help me (nor the resources to hire one) and I just wanted to move as fast as possible. And nothing beats ASCII-based graphics in that regard.
A couple of years passed, the project lingered and was almost forgotten and my good friend Krys was available and willing to enter the project.
Suddenly there was the option to find a unique yet old-school graphical representation for the game, taking all our learnings from working on ADOM and Ultimate ADOM and trying to do something even better.
And here we are working on a (hopefully) wonderful game with awesome old-school pixel graphics.
Therefore piece by piece the initial Curses implementation became more and more useless. As I already had implemented a new lean UI component architecture in order to show tooltips the decision has been made to extend this to cover all graphical aspects of the game.
Thus this week I ripped out my Curses implementation and replaced it step by step with my graphical component framework. Since the initial framework was designed to always use Curses this required quite a bit of fiddling. On the other hand it helps resolve a lot of weird ideosyncracies that had popped up when mixing the Curses implementation with the new graphical component framework.
This resulted in ripping out code, deleting unused stuff and more. But it makes the game cleaner and leaner which is great because I really try very had to fight technical debt as early as possible (having learned from ADOM what it means if you hit technical debt that has its origin in weird decisions that are 20 years old).
The result is this new look for the map screens where the changes are most notable. Naturally we will evolve the UI a lot over the next months as things grow:
Note that the ugly text are to the lower right will disappear. It’s just there due to the straight port but needs to be changed.
Miscellaneous minor changes and additions
There are now extensive mappings of talent category priorities to resulting professions.
The game window now has a decent title.
The game window now shows the number of frames per second. At some future point this will be disabled (or configurable) but for now during early development it’s an important indicator for our engine performance.
The full screen mode works again. It broke at some point during the past couple of weeks and fixing it required some refactoring but not it’s finer than ever.
Total size of the codebase after this week
34,006 LOC in 593 files for the actual Realms of Ancardia game
23,552 LOC in 399 files in my own underlying TBRLAPI framework library supporting my most recent roguelike games
plus extra external configuration files, images, tilemaps, audio files, etc.
Lots of graphical details have been added in week 5. And work on character generation continues. It starts to feel like something almost complete. Overall the graphical fidelity has gone up another notch (while retaining the old school charm we are aiming for) and this will drive more changes in the weeks to come.
Also lots of infrastructure work happened in the background for the underlying game sytem as you can see at the end of this post by more than 160 new classes in the game alone (and “only” about 6,200 new lines of code… infrastructure often is not very complex per component but usually needs a lot of components to be extendable and efficient enough).
Animated main title image
Krys outdid himself animating our so far static main title image. We now have a beautifully animated title image:
Graphical frames
Dialogs, windows and tooltips now can have graphical frames in order to make them visually stand out more cleanly and be more attractive.
Here are is one example, more below with the other new features:
Visual upgrade for character generation
Everything was overhauled:
Typography
Spacing
Framing
Unified color scheme
All in all character generation (considering its basic state) now is looking a lot more pleasing and still fully aligned with our planned old school charme. Here are updated screenshots – compare them to last week if you like to see the progress:
The central character generation screen – from here you control everything
Definining talent category priorities – this basically shapes your former professional life
Selecting a race
The gender selection step already was shown in the previous section and skill selection still needs to be implemented (although most of skill infrastructure already is there).
Death screen added
Death always has been a big part of ADOM and it also will be a big part of Realms of Ancardia – even though the default game will have a wonderful twist by introducing permalife instead of permadeath. More on this at some later point in time… here’s the default death screen for your final death…
Item architecture created
It’s time to get items into the game in order to finish character generation. This usually requires a lot of infrastructure for a game with the complexity of Realms of Ancardia. So this week I did a lot of tedious groundwork by implementing these concepts:
items data structures
item templates
item template generators
item containers
item types
base items
template based items
item modifiers
item traits (that cause modifies to become real)
infrastructure for implementing random items based on some base template
infrastructure to randomly generate items based on type and desired power level
Not much fun but they enable one of the major fun parts – creating cool items 🙂
Also statistics now adjust due to equipping or unequipping items, etc.
Rules and architecture for initial equipment
Realms of Ancardia uses a system based on race and initial talent category levels in order to define the starting equipment of the player character. Both the architecture for this approach plus all rules to generate starting equipment based on on 12 races, 10 talent categories and 6 talent category levels for a total of
12 x 106 = 12,000,000 starting combinations for equipment
have been implemented. And since some of the starting equipment is randomized there is an almost infinite number of setups.
More details will be added to this system later when we implement star signs, background stories, feats, etc.
Started adding item templates
Adding items will be a forever job considering that ADOM had hundreds of them. To get character generation started we added 92 base item templates in 18 type categories. More to come – even character generation is not yet fully complete (we need a lot more scrolls, rings, wands and potions).
Inventory / information screen prototyped
I started with a prototype for an information screen about all data that makes up the player character (bound to the classical “i” for inventory – but it’s a lot more than that – so “information” seems to be the better future mnemonic for this).
Here is the unstyled prototype mostly used right now to confirm that data goes where it should while building a character (Krys already has prepared nice tab images but I was too slow to implement them before the weekly update had to go out):
Just some of the basics for now on the stats screen…
A basic inventory – all the item details still are missing…
And the backpack… again all details are missing and we probably will add category filters and… and…
The skill tab has not yet been built and the tabs themselves need to be upgraded visually.
Basics of a tavern generation system implemented
Taverns play a big role in any classical fantasy setting, even more so in Realms of Ancardia with its large number of highly variable settlements. Creative struck me like lighting and I designed a tavern generation system which provides the following features:
race-specific tavern names (e.g. dwarven taverns should be very differently named from dark elven or orc taverns)
randomized potential tavern activities (from standard stuff like dining and drinking to much more elaborate stuff like pitfighting or quest access)
room types and prices depending on the specific settlement data (and some randomness)
randomized rumors you might be able to hear while staying in the tavern
randomized special events (like a bar fight or the chance of your pockets being picked)
randomized special traits for taverns (like being haunted, a smuggler’s den or fey touched)
All this should help to make taverns truly unique places that are exciting and useful (and also sometimes dangerous) to visit. Besides all the avdenturing opportunities you can rest and recover in taverns and learn more about the settlement and the world.
Calendar component added to screen
The Ancardian calendar always played a prominent role in ADOM with it’s star signs and stuff. So it will in Realms of Ancardia, maybe even more so, now that we have complete civilizations, compex government forms and a whole world to be affected by the stars…
For now the map now is graced with a beautiful calendar widget that shows the time of the day (and in coming weeks will be enhanced with a star sign display). Here is a sample screenshot:
Day and night are important… especially in settlements
Note that this calendar version is just a first draft. We are right now working on an improved design where the surface world map will show a calendar focussing on the star signs (due to the extended movement time frame on the surface world) while the settlement maps will show the day and night cycle (because that really makes a difference in the settlements).
Miscellaneous minor changes and additions
Krys added a cool font to be used for headlines.
Kry generally spent time improving our fonts and typography.
Krys started to work on star signs.
Added a tab component to our UI framework.
Added a video component to our UI framework. And will have more of them in the future (think of small animated sequences like e.g. tavern images, etc. – a little like in my beloved Bard’s Tale I-III and Wasteland). Just a tiny bit of movement and animation – but enough to be fun.
Windows now have shadows.
Total size of the codebase after this week
34,385 LOC in 603 files for the actual Realms of Ancardia game
22,761 LOC in 383 files in my own underlying TBRLAPI framework library supporting my most recent roguelike games
plus extra external configuration files, images, tilemaps, audio files, etc.
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:
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.
