Many battles fought again by tongue

Strange day today. Not just because it would have been Mike’s birthday, but because for some reason I found myself fixing a bug in Doomdark’s Revenge. Back in January I had a bug reported to me by Simon Foston, I managed to get some save games from him and just needed to find some time to look at it. Now, it’s taken a little while for me to find that time, but for some reason I looked at it today. It wasn’t a conscious decision, I was just looking through some emails that needed dealing with and noticed Simon’s bug report.
A quick look through the code and with a tip off from Simon’s report, it became apparent that the ghosts of dead lords were continuing to take part in battles. I checked the original code and it looked as if the bug was there too, however, I then found that the isDead check was happening later in the process. Strangely what it means is that battles at a dead lords location are processed as part of a dead characters turn, and not as part of other characters in the location. In my case, I’d missed the later isDead check and therefore the dead lord actually took part in the battle.


So, it seemed strange to be working on a bug in Doomdark’s Revenge that included the dearly departed, today of all days. I’m sure Mike had a wry smile..

Related Posts:

In the forest, the trees grew tall and shady and bright flowers carpeted the floor

Screenshot 2016-01-06 23.01.13I finally got round to spending some time converting some Citadel data. On of the issues that I had was that I have the map data in LBM image format. It’s obviously not a great format for the terrain data, but this was given to me by the original programmer and I’m not sure how they were processed for the final game. The other issue is the difference in game styles. This data is for a 3d free roaming map and some of the maps are different sizes. The region map are 128×128, however I can’t believe that the citadel could be played out as a 2d landscaping game, without seriously playing with the time taken to move. Therefore, I decided to make the Citadel map 256×256, this is in keeping with the map that Mike drew up for Eye of the Moon, and therefore as the Bloodmarch was originally going to be the setting for EotM it seems fitting to go with the same size.

Last year I did some work on transferring The Lords of Midnight and Doomdark’s Revenge maps into Tiled. I figured that if I could create a tool chain from that, I could possibly edit the maps for future campaign updates to the games. I did all the work on converting to Tiled and coming up with data formats, but never did any work on the toolchain to get the data back into the game. This is something I still need to do.

With that in mind, I produced a draft Tiled version of the Citadel map which you can download to take a look at. It has layers for Realms and Regions, and then individual layers for each terrain type. The Citadel map was very sparsely populated compared to LoM and DDR, and although the current terrain types account for 19 different terrain, which is actually three more than both LoM and DDR, these terrain really are base landscape terrain. Land, Water, Trees, Mountains, Swamps, etc…. it is lacking anything remotely of interest. There are no Liths, Villages, Hits, etc…

If a game is going to come of the Citadel, this is something that is going to need to be rectified.

LoM and DDR pretty much share the following landscape terrain types: Mountain, Forest, Downs, Lake, Frozen Wastes, Plains, and Hills.

LoM adds: Citadel, Henge, Tower, Village, Keep, Snow Hall, Ruin, Lith, and Cavern, while DDR adds: Gate, Temple, Pit, Palace, Fortress, Hall, Hut, Tower, City, Fountain, and Stones.

The Citadel has landscape types of: Mountains, Craggy Mountains, Forest, Hills, Plains, Land, Valley, Lakeland, Swamp, River, Sea, Bay, Lake, Foothills, Isle, and Downs, and adds: Castle.

As you can see, there isn’t a great deal of variety in those none landscape terrains. Citadel, City, and Castle pretty much replace each other, as do keep and fortress. I seem to recall that Maranor is the Dark Citadel, but I am not aware of any cities.

So, apart from Snow Hall, I see no reason why the additional LoM and DDR terrain types could not be used within a Citadel scenario.

The question then becomes, should there be any new terrains?

My first process is to make sure the Tiled map all holds together. I needs a little tidying up which will need to be a visual process. I’m not sure if there were problems with the original, but I noticed things like trees in the sea. I never got that far in the game, so I don’t know if there were indeed trees in shallow water on the coast line, but a few things like that should probably be ironed out.

At this stage I would like to get some Terrain graphics so that I could drop the map into the engine, and start walking around. There are some issues here, as The Citadel introduces water in a way that LoM and DDR didn’t, so there will need to be engine changes to handle that.

Once a clean version of the map is available, the next stage would be to hand populate the map with the other terrain types. I don’t see this being a quick exercise because I think a lot of thought will need to go into this process.

Only at that stage, will I be anywhere near thinking about an ACTUAL game. There is a lot of underlying work do consider with how the game should work, how the AI in the original works etc. Without help this will also be a lengthy process.

So basically, don’t hold your breath, but slowly slowly catchy monkey…

Related Posts:

We must find friends as well as enemies…

A new bug came to light in Doomdark’s Revenge. I had a report of a crash bug that occurs after 138 days, that’s one hundred, one score, and eighteen days since the Moonprince rode forth into the Icemark.

The problem appeared to be that an AI character’s liege was getting set to himself. This causes a problem in the AI logic for a character choosing to follow their liege. The AI goes something like this…

I want to follow my liege, but my liege is dead, so I need to follow my liege’s liege and this character will become my new liege. The code ripples up the liege tree until it finds someone to follow, or bails and decides to hunt down Luxor instead. When the bug occurs it follows the tree and finds a liege who is dead but they are also their own liege, and thus we get stuck in an infinite loop.

Once I found this as the source of the crash, I needed to work out WHY it occurs.

There are only two places where the liege can change, the aforementioned follow liege routine, and being recruited.

I stuck some debug info on both cases and set the game to run on automatic to see if the issue triggered, and it did.

Here is the scenario…

Anvarorn starts with Fangrorn being his liege. Fangrorn’s liege is Shareth. Fangrorn gets recruited by Anvortheon the Barbarian, and thus his loyalty changes to the barbarians, and his new liege becomes Anvortheon. Anvarorn decides to follow his Liege, who is still Fangrorn. When he gets to the same location as him he notices that they are not the same loyalty and thus tries to recruit him. He succeeds. Thus Fangrorn’s liege becomes Anvarorn. So we now have a circular liege issue. This becomes a problem if Fangrorn dies, because in this instance Anvarorn decides to follow his liege, finds that his liege is dead so takes his liege’s liege as his new liege and therefore becomes his own liege!

I went back and checked the original code, and this issue can happen. The only place you would notice it would be on one of the description screens where it would say, Anvarorn’s liege is Anvarorn – or words to that affect. At worst the character would end up following themselves and end up not moving. This is something that has been mentioned as possibly happening in the current version.

When I implemented the liege tree walk, I did just that, I implemented it as a walk up the tree, and because of the circular issue, a dead lord who is their own liege will create a circular loop if they are someone else’s liege. The original code doesn’t do that, it only takes the next liege up the stack and therefore slowly makes its way up the liege tree over a number of nights. Thus no infinite loop.

This would possibly occur with characters following their foe. If their foe is dead it walks the liege tree of the foe to find the next foe.

Fix to follow soon…

Related Posts:

To Luxor, everything now grew clear

Clumping together...I’ve spent some more time looking at the AI for Doomdark’s Revenge, trying to work out why it doesn’t quite appear to be playing like the original. One thing I noticed is that I have completely misunderstood the recruiting logic when it comes to Loyalty and Treachery. I made changes in the last version, but I am going to need to revert them.

The approach algorithm

  • compare the the attributes of the lords and looking for matches gain +1 for each match.
  • If the character being approached is not loyal then +1
  • If the character being approached is treacherous then * 2
  • if the recruiting character is the liege of the character being approached then +3
  • If the recruiting character carries a crown of persuasion then +2
  • If the score is greater than 3 then the approach will succeed.

The basic concept that I have misunderstood is: Loyal characters are less likely to be recruited away form their current liege and un-loyal characters are more likely, therefore the algorithm gets a +1 for none loyal characters. And that treacherous characters are more likely to leave and thus the *2

The next thing I have missed is the lords following the objectives of their lieges.

It works like this.

If the lord has a liege and that liege is following their liege or their foe, then we must follow our liege. Otherwise pick a new objective.

There is a 32% chance that we will pick a new objective. Although that should be 25% because we could pick the objective we already have. That leaves a 68%/75% chance that we continue doing what they were already doing.

The problem for me is the first check. If we use Shareth as an example. She has a 12.5% chance that she will choose to follow either her foe or leader. As she has no leader she reverts to Luxor, which is her foe. So she has a 12.5% chance that she will follow Luxor. All the lords that follow her now have a 100% chance of following Shareth, and this ripples all the way down the stack of lords. Which at the start of the game means that 47 Icelords will disregard what they are doing and follow her.

The mistake I had made is that I had made the following lords take the objectives of their liege when their liege was following their liege or foe. What this means is that when the liege is following their foe the lord follows their own foe. So using Shareth again as the example, when she is following her liege ( Luxor by default ) then all her minions will head to her location, but when she is following her foe ( Luxor ), then all her minions are heading to their foe and not to her location. So as an example, Imgaril the Icelord would be heading to Imgorthand the Fey, who, is likely the the other direction of Shareth.

Hopefully this fix should make the game more like the original, but it bothers me that it is a flawed AI. I ran the game for the first ten days, up until the first battle took place, I ran it on the emulator too to compare notes. Here is what Shareth did over those days.

  1. Head Home
  2. Head Home
  3. Head Home
  4. Follow Luxor
  5. Head Home
  6. Follow Luxor
  7. Follow Luxor
  8. Follow Luxor
  9. Search for object
  10. Head home

Now Talormane does this

  1. Head Home
  2. Head Home
  3. Search for object
  4. Search for object
  5. Follow Lorelorn
  6. Follow Lorelorn
  7. Follow Lorelorn
  8. Follow Lorelorn
  9. Follow Lorelorn
  10. Follow Asorthane

The reason for the delayed follow on day 4 is because Talormane is following Lorelorn who is following Shareth, but Lorelorn is lower in the processing order than Talormane, and thus Talormane doesn’t know that Lorelorn is going to follow Shareth in that turn.

The final thing that I changed was that there is a 6.25% chance that the change of objective will be DO NOTHING. This is especially important for being in a battle with someone who is not the lords foe, because it means that without this the lord will always leave the battlefield. The mistake I had made was that I persisted the do nothing as an objective, i.e.. The lords objective becomes do nothing. But it shouldn’t, it should stay the same as the previous objective, and this turn that objective is ignored.

Going back to Shareth. If she chose to DO NOTHING then her objective would no longer be follow liege or foe, which means that her followers would be able to perform whichever objective they chose. However, if her previous objective had have been follow liege or foe, then her followers should still be heading towards her when she chooses to do nothing. This would have the affect of allowing them to catch up on her.

Related Posts:

First week snagging…

20140220-084247.jpgRelease week is always frustrating. On Android I just cannot test on enough devices, so I know that something is always going to bite me, and Monday morning it did. None of my Android testers had had any problems with the game loading, but Monday morning a number of devices were reporting that the game wouldn’t load. Later that night I spent a few fraught hours fighting with hotel WiFi trying to get an update tested by the affected customers, and then released.

In this instance it was an easy fix. In fact, I had already addressed the issue the previous week for the Windows release. Some last minute testing on my Mac Desktop running a windows VM, full screen, highlighted an issue of loading the splash screen. At the high resolution the splash screen was larger than 2048. When this image was being loaded, it was converted into a power-of-two texture and thus a 4096×4096 texture. The texture loader I was using was choking on that. A quick change to the affected images, across all resolutions, resulted in a fix, and a 5mb reduction in app size to boot!

This was the problem that affected some Android devices. So all I needed to do was rebuild the current version for Android and send it back out. In the end, the Android release was probably a lot smoother than The Lords of Midnight.
Continue reading

Related Posts:

Shading the night sky…

One thing that got carried over from the original Midnight Engine was the shading of the landscape depending on the time of day. The original Lords of Midnight, has a different colour for night which is basically that all the white becomes black, but the blue remains the same.

In TME and therefore the remake, I have a tint colour for each time of the day, and the images are tinted toward that colour. That colour is generally a shade of grey and it is used to darken the dawn, brighten up to normal colours around midday, and then dark off fully to night. In reality, this is one area of the remake that I left in that I don’t like. Only because, it doesn’t really look like the original. The night view has a very distinctive look, and as you can see though, the remake doesn’t look the same. It’s fine as things goes, but I would have much rather made it look more like the original.

Doomdark’s Revenge however has a completely different approach. There is a dawn visual, and day visual, and a night visual.

I knew therefore that when I got around to releasing Doomdark’s Revenge, I was going to have to deal with this issue. The tinting method just didn’t cut it. Because I could tint to red, or tint to yellow, but not combine them.

To give you a little background. The colour changing was relatively easy on the ZX Spectrum. Partly because the images were very simple and were constructed, but also because of the way that the spectrum only had two colours in a 8×8 grid – known as the paper and ink. So all the effects were done by just changing the paper and the ink. These colours were not stored with the bitmap either, it was a different memory area. So in fact, what Lords of Midnight does is, clear the screen with paper and ink both white, draw all the pixels to the screen, which you can’t see, and then fills in the paper and ink colours which makes the screen appear.

Now, the choice I made when porting the game was to use full 24bit alpha’d bitmap images. I can discuss the merits, and the whys, and possibly the mistakes, of this decision. But, it’s not been one I can change easily.

The upshot is: changing colours on the fly isn’t easy. It’s much easier with 8bit palletised images. But believe it or not, despite the fact that the terrain images only use two colours, they actually use at least 255 colours in order to get smooth edges, as well as being alpha’d. Changing to palletised images just made it look awful.

Once solution that I knew could work would be to write a custom shader. Shaders are dark voodoo magic that happen on the graphics card. And I’ve never written one in my life. Had Mike been around, he would have knocked one out very quickly. But obviously he wasn’t, and as I was heading toward the original release of The Lords of Midnight, I didn’t have time to look into them.

Now however, I couldn’t ignore it any longer. With the latest update of The Lords of Midnight sat awaiting approval from the platform holders, I turned my attention back to Doomdark’s Revenge, and the next thing to address, was making the dawn landscape look proper. I was going to have to learn to write shaders. And that’s what I spent yesterday doing.

The end result is that I now create all my terrain images as being black and white. These two colours will be replaced by the shader as the image is being drawn to screen. However, I can’t just replace the two colours, I need to make sure that I where the two colours meet they get blended.

mountain_fragmentIf you click on the Mountain fragment you will see a blow up of the image, and see how this would work. Affectively the image can be considered thus; all black, all white, mixed. The mixed part always being where the two meet. So if we consider that we will replace all black (0,0,0) with new colour_a and replace all white (255,255,255) with new colour_b, the other colours will be a shade of grey from (1,1,1) to (254,254,254). What we actually do is  use the value of one of the colour components to work out the mix of our two new colours. so 0 is 100% colour_a and 255 is 100% colour_b. A value of 153 for example would be 40% colour_a and 60% colour_b.

Now, it’s not rocket surgery, there’s nothing particularly clever going on here, but for me I had to turn this into a shader, and that was new territory.  However, working within the Marmalade SDK and using the OpenGL ES shader reference manual, and a little bit of google… the process turned out a little easier than I expected.

Here is the landscape without the shader active.

Screen Shot 2013-10-27 at 02.07.47


But with the shader active, and the two colours adjusted depending on the time of day, we  get the following.

And, if we now revisit The Lords of Midnight, we get the resulting night landscape that I always wanted.

Screen Shot 2013-10-27 at 01.10.33


Not sure when this will make it back into the current release, probably after Doomdark’s Revenge is released and I’ve been able to fully test the shader across multiple platforms. But it will make it back.

Related Posts:

Tunnel Vision

tunnel_statusI’ve been working away for the last few weeks, which has meant that my development has had to take into account that it is being done primarily in bars an restaurants. I know many of you are waiting for the latest version of The Lords of Midnight, but although I have spent some time fixing bugs and adding a few new features, I am not in a position to Build a release version. I have to have access to my desktop to do that, and the few days I’ve spent at home with my family, I hope you can understand that spending time in my study on my computer is not the highest order of the day.

After declaring an end to any changes to Lords of Midnight, I spent some time merging the codebases of the different versions that have been branched out over the the year. Namely, Mobile version, Desktop Version, and Doomdark’s Revenge. I now have a unified code base which means that when I release a update for LoM soon, it can be across all formats.

Once the merge was complete I decided to spend some time working on Doomdark’s Revenge. I am hoping to release a test version soon. The night AI will not be activated but you will be able to wander around the map, above and below ground. And generally check out the UI differences between the games etc. This will then give me a good base to slowly turn on AI features and test them thoroughly up to release later this year. For the record that would be in about 12 weeks!

Once area that I have been working on this week, is tunnels. Tunnels are one of the new features that Doomdark’s Revenge implemented. So I have been slowly working my way through the code base, adding in all the little things that need to be there in order for them to work.

It’s a little different with The Midnight Engine, ( which by the way is the underlying code that powers both The Lords of Midnight and Doomdark’s Revenge ), over the original games, in that there is one code base. Doomdark’s Revenge was released as completely new game, and therefore much of what didn’t remain of The Lords of Midnight was just removed and the new code was added. This is a big issue with my codebase, as my original brief for creating The Midnight Engine was to be able to play both games and in theory create a game that mixes the features from both LoM and DDR. So, if we take tunnels as an example, I could just turn tunnels on in LoM, and everything would just work.

Now, let me try and give you an example of why that thought process gives me a nightmare when implementing something like tunnels.

In LoM a map location is split up into [ Terrain, Area, Object, Flags ], in DDR it is just [ Terrain, Flags ] – both area and object are generated. TME uses an expanded format [ Terrain, Variant, Area, Climate, Flags, Object ]. So the generated areas in DDR are stored, as are the objects. ( For the record, objects change every night ). For both, objects are classed as things you find or things you see. So Guidance, Cup of Dreams, Dragons, etc…

Now tunnels are a flag. A location has a tunnel beneath it or it doesn’t. If the terrain is GATE, PIT, PALACE, CITY, then the tunnel is an entrance/exit. If the terrain is PLAINS, FOREST, HILLS, MOUNTAINS, then it is considered a passageway. Now, this is where things start to get messy.

A tunnel location can only have a critter ( dragon, wolf, skulkrin, trolls ), when it is a passageway. And the location directly above ground can only have a critter when there isn’t a passageway below. So affectively you have two locations sharing the same space but only one critter at the location who could be in either of the two locations.

It seems a pretty straight forward thing to think about, but when your code base works on the concept of a single location, suddenly everything changes.

When drawing the landscape, the frontend asks the backend for the information about a given location. It draws the terrain graphics and any critter imagery that is required. The backend has just told the front end that there is a critter at this location. However, now it has to consider if we are above or below ground, and the type of below ground we are on. Based on that information the frontend can decide if that critter is visible or not.

When at a given location the frontend asks the backend for all the lords that are at a given location. But now it has to consider if that lord is above or below ground. The list of these types of checks goes on and I’ve found myself having to work through the engine making sure that I am always using the correct context. More importantly I am trying to make sure that any logic is in the backend and not in the frontend. Therefore the backend now returns the information in the form of, here is the information at the location requested, this critter is above ground and this critter is below ground. It doesn’t matter that there can’t be a critter in both, that is a backend problem not a frontend one.

A similar thing happens with the discovery map. There are flags on a location to say that it has been seen, looked at, or visited. Seen is a distance thing. Two locations away may have been seen, and you know what terrain is there because you can see it on the landscaping view in front of you, but you might not know what it is called. Looked at is for locations directly in front. You know the terrain and the name. Finally, visited is exactly that, you have stood on that piece of ground. But, you might not have stood under that piece of ground. So now we have to introduce the concept of tunnel visited and tunnel looked at. How about, we have walked down a tunnel and got to the end, and we know the tunnel finishes, as opposed to not quite making it to the end, so we have looked at the tunnel location in front, but because we didn’t visit it, we don’t know if the location after that continues as a tunnel, or this is indeed the end of the tunnel.

That one bit flag in DDR ‘tunnel’ suddenly becomes so much more when you are trying to keep a flexible engine. That one bit flag also creates limitations. Two tunnels adjacent to each other must be connected. You can’t run a tunnel under a palace because a palace is always an exit/entrance. This is used to create a one way tunnel in the game.

I have considered removing the bit flag, and replacing it with the concept of layered maps. You would then have a map for all the terrain above ground and then a map for all the terrain below ground. Following that approach would me that the limitations could be removed and it would allow things like different critters above ground than below. Or types of tunnels. But for now, I’ll leave well alone!

Other things have crawled out of the subterranean landscape… For example, two characters at the same location are not actually at the same location when one is above ground and one is below ground. Thus, the newly added grouping functionality suddenly needs to take into account tunnels!

Related Posts:


dragonI thought I’d post an update of where things are at, at the moment.

I’ve been having a bad run of “can’t be arsed”, this is not just on the Midnight front, but with a number of things. It happens now and then. I think part of this is due to the fact that from October I worked tirelessly on Lords of Midnight right up to release, and then followed the release with two months of updates. In the end, I think it burnt me out a little. That combined with the day job and that I work for some of my clients in the evening as well. The problem is that I have now lost a little bit of momentum and I just need to get that back…

The desktop version is almost ready. I hoped to put it into test a few weeks ago, but didn’t because I was waiting to add one more feature, which is the MAP scaling and movement gadget. I did the temporary graphics, but haven’t implemented it yet. Once that is in I will make a request of Jure for the final graphics and then upload for test and open the forum for testers.

I intend to formally request Jure start work on Doomdark’s Revenge at the start of May, so that is my new goal; I’m going to aim to have the desktop version in test and DR started by the 1st May. And then aim for DR to be ready for at least the Mac App Store  by the end of May.


Related Posts:

The Marshal of Ithrorn is sorely pressed

dragon_redThought I’d better post quick update about what I have been doing for the last month, or more to the point, what I have not been doing. I’m not quite sure where all the time has gone, but it has gone nonetheless.
On off I’ve been trying to get over a particular hurdle on the desktop version, and it’s just about swapping resolutions. I don’t want to just allow the player to swap through all the possible resolutions that their monitor can handle, so I have implemented a system of, Fullscreen, and then Small/Medium/Large window version. The main issue is changing the internals of the system after the initial selection. It’s not a big, nor complicated job, it’s just one of those meh pieces that I seem to be unable to keep myself interested in for more than a few moments. It kind of feels a little like the Android version. That became a toil because I wasn’t really that interested in it at first, that is, all the work required to support multiple resolutions. So the work just dragged.
I think this is also on the back of two solid months of coding on the project. It feels like I’m having a little post release wobble. Hopefully I can get my coding mojo back soon so that I can get the desktop version out of the way….

Related Posts:

His war-cry rang out across the still dawn


This weekend should see the submission of Version 1.06 of The Lords of Midnight. It has a number of fixes and a couple of new features.It will likely be the last update, aside from a major bug fix, for the next month or so. Once reason for this is that I think I have exhausted a number of minor additions that I wanted to include. Over the month since the initial release, I have added about 20 new features, tweaked a number of features, and obviously had a number of fixes. I think somewhere in the region of 60 work items have gone into the last month.

Most of the bug fixes have not been major, but they do polish the game. Luckily, most of the changes should not had too much affect on players, unless you are particularly familiar with the workings of the original. I’m pretty happy now that the next release will bring the game as close to the original game play as I can get. I have a couple of more tests to do on a couple of possible problems with the AI over the next few days – just to ascertain if they are problems or not. But my initial gut feeling says they are not, but the proof is in the pudding.

Some of the feature changes again give the game more polish, but also help move toward Doomdark’s Revenge. So they have been worth the extra effort.

The main reason for not pushing out any more changes is that I need to move forward. I need to spend the next month getting the Desktop version complete. To be honest there isn’t much to do, but some of it is fiddly work. The identified changes are currently:-

1. Mouse Pointer – There needs to be one along with the context of what it is doing.
2. Resolution selector – The user needs to be able to choose which resolution to run in.
3. Full screen – The user needs to be able to toggle running full screen or in a window.
4. Graphics – The underlying assets need streamlining.

Of the above, option 4 is of interest, because I am hoping that this will help reduce the size of the assets required for the mobile version, and make it easier to include graphic sets in later releases.

After that, I can’t honestly see much that must be changed to make the desktop version. I play it all the time on my desktop. The above changes just tidy it up.

Once the desktop version is complete and shipped, I can then move on to Doomdark’s Revenge.

Over the months that I develop Revenge, I will trickle more features into LoM. But I will only start that once I break that back of the initial development. I would like to release a version by the middle of the year that includes some difficulty level changes and new scenarios. I would be nice for you to be able to replay the game a number of ways with different challenges.

Related Posts: