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:

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:

Amazon Underground

amazon-underground-app1A month or two back, Amazon approached me about putting The Lords of Midnight and Doomdark’s Revenge on their new service. It had just a project name then, and I had to sign a whole host of documents before I was even told watch the service was, and then another whole host of documents when I agreed.

Before deciding that I would, I thought long and hard. Essentially, I never wanted the Midnight games to be advert driven, and I couldn’t see a compelling way to have “in app purchases” that would generate the kind of sales required to support the game, without an amount of work that would be loss leading.

By having the Midnight games as a full purchase game, it has probably stopped it from being installed as many times as it might have been when free, indeed I have seen the spikes when the game has been reduced in price for promotion. But even those extra sales have not amounted to much in the way of cash as the price reduction has obviously hurt.

That said, the games have sold around 30k units which I couldn’t be happier at. That just hasn’t resulted in a great deal of money, in the scheme of things. Rough fag packet calculation, if you take the average price at £2.50, taking into account price reductions, different platforms, and multi-currency, you get a turnover of £75k less Commission 30%, and VAT at 20%, it’s just £37.5k – and divided between Jure and Mike’s family, pretty much a three-way split, I’m looking at £12.5k over 2.5 years. Without doing an accurate calculation, I can say that number feels about right, and it’s still a long way from covering my time costs if I apply a day rate to it.

Android sales of the games are well under a 3rd of Apple, but they appear to have a 10:1 piracy ratio when taking into account rough internal data calculations.

So, as we hit the tail end of sales, I wondered if the Amazon pay-for-play where they pick up the tab, might be an interesting approach for some additional Android sales. The gamble was, will people who won’t buy it on Android, possibly pick it up and play it for a while, enough to generate a small trickle of income, that might be greater than the normal Android sales. This could all possibly be maximised by being an official launch app for the service.

Android still accounts for about £50 a month in sales, this last week has seen and additional £3k units downloaded through Amazon Underground, accounting for less than a £1 worth of pay-for-play. Amazon pay a fraction of a penny per minute played. So not a great start, but I’ll have to see how it goes.

I know the t&c’s for the Amazon offering are a little harsh, and the privacy settings quite extraordinary, but still understandable considering what they need to achieve, however I figure that the target audience who don’t want to pay for the games in the first place, probably don’t care. And those who do, have either already bought the game, or still have the option to through Google Play, or Amazon Store proper.

I just need to keep an eye on whether the Amazon Underground sales hurt the Android sales, better them, or just become another small income stream.

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:

Tell me what ails thee

ddr_c64Version 1.3 has now been pushed out on all formats. You will start to see it coming live over the next 7 days. As usual, Android will be first ( probably already is live ), with iOS and OSX being last. If you have a Windows or OSX version directly from this site, or through GoG, you should see an UPDATE menu option appear on the main menu. will also go live with the update in their time.

There are a embarrassingly large number of bug fixes in this version. Thanks to a number of very eagle eyed players, in particular Mark Wright, I have been able to fix up many specific differences between the initial release version and the original 1985 release. I also spent a large amount of time pouring over the original code, looking for anything that might alter the way the game played in a way that I might not have foreseen.

doomdrk1On the whole, I think we have most of them, but there is always a chance that there are a few differences still. In particular, the remake is based on the original ZX Spectrum version, and there are definite differences between the Spectrum and the C64 version. So, if you were a C64 player, then the game will not being playing quite as you remember it.

The last few weeks has really made me understand the intricacies of the original game to a level that I never fully appreciated before. It’s quite amazing the small amount of time that the original game was developed and tested in, that said, it’s because of that that you understand why the original had more problems than Lords of Midnight ever did.

There are a number of bugs or oddities that I have chosen not to fix, these are because they are in the original. To players coming to the game anew, or even returning to the game without the same outlook of 30 years ago, some of the AI logic might not make a great deal of sense. I intend to address these issues in a later version by adding different playing modes.

The intention is to have the following playing modes, Original Spectrum, Intended Spectrum, Original C64, Updated.

Intended Spectrum will fix a couple of obvious bugs inherent in the original release, the main one being movement. There are some movement values that would change the way certain races move across particular terrain, for example giants and mountains, but these were never applied in the original due to a bug that referenced the wrong table.

The Original C64 will apply a couple of AI differences to the Spectrum version, namely the aforementioned movement issue. In C64 the functionality was added, but the terrains are different than the Spectrum Intended version. The other change would be that recruited lords start at dawn in the C64 version I believe. Please feel free to call out any other known differences ( apart from the sun 🙂 )

Updated will allow me to make a number of slight AI changes.

Firstly I will change the behaviour of fighting critters. I think it’s wrong that a lord with an army can be killed by a critter, especially on not much more than a flip of a coin. Currently a Lord’s army takes damage from the critter, which should remain, but a lord should not engage the critter until the army is wiped out.

Secondly, I will add some changes to make it less likely that a lord that you attack just continues on with their objectives and completely avoids a battle. I think that if they start the night in a location with an enemy army, there should be a large chance that they remain there and engage in battle. If they are near a location with an enemy army, there should also be a smaller chance that they will attack.

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:

Doomdark’s Revenge Status Update

Quick update. The release of Doomdark’s Revenge was not too bad in the scheme of things. Online press has been good, good coverage on Twitter, sales numbers seem to be in line with The Lords of Midnight release.

All platforms were released simultaneously, which in itself isn’t too be sniffed at. The only problem was that OSX on the Mac App Store didn’t make it. Hopefully the issues there will be resolved soon.

The only Major glitch was a graphic memory problem that was hitting a few Android devices, but with the help of some supportive customers, I was able to iron that out last night an get and update out overnight. Interesting, the problem also affects The Lords of Midnight and probably explains some of the random startup crashes and incompatibilities I’ve had there. So as soon as things settle I will update that.

Despite a stressful few hours, I think the Android release probably went better than The Lords of Midnight Android release. Biggest problem was releasing while staying in a hotel where the Wifi decided to be very very poor!

There are a few issues that have cropped up. Mainly recruiting and battles, and a few cosmetics. The Recruitment issues make the game easier, the battles make it harder. I will try and resolve all of them ASAP.

Related Posts:

No ice, no storm, no sword or shaft shall keep me from thy side


Just in case you missed it… Doomdark’s Revenge is out on all formats.

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:



For those coming back to Midnight, or indeed those new to it, you might want to check out Online Multi-User Midnight – Midnight/MU It’s a great experience. It’s been running now at least 10 years, and you can play the Lords of Midnight Scenario, Doomdark’s Revenge Scenario, as well as a host of newly specially created scenarios. The games have been tweaked and well honed to cater for issues caused by Multi-User play, and a number of new features have been added. But essentially, if you are familiar with Midnight, you will get along here.

Register on the game site and on the forum. It’s a very friendly community. There are usually plenty people around to help you with training games, although it might be a little quieter than usual at the moment due to holidays.

Related Posts: