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.

The running total is available here.

State of our internal ticket system

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 😉

  • 148 open issues in total
  • 59 closed issues in total