Tag Archives: Doomdark’s Revenge

The Moon Ring lends us the power to change our plans

Posted on by

For those of you that do not follow my personal blog, I thought I’d update you on a few issues that have been plaguing me… for those of you who have, you can skim down to nearer the bottom…

About six months ago I received an email from Marmalade detailing their intention to withdraw from the SDK market. Marmalade is the system I used to develop The Lords of Midnight and Doomdark’s Revenge in order to facilitate the cross platform nature of it. Using Marmalade gave me the ability to target iOS, OSX, Android, Windows, Windows Phone, Kindle, and Blackberry.

A month or so later, Marmalade confirmed that the SDK had been sold to another company, and that further support may become available from them.

That process has now taken place. I have less than a month of my Marmalade licence left, and they have not turned off the Licence server to I can still build and continue to work. However no future support will come from them. The new company are offering a 12 month bridging licence at $100 more than my previous licence fees, but this also comes with no support. I’m also not convinced that they intend to be around for the long term. The main reason they appeared to by the Marmalade system was for internal development.

A few weeks ago I received an email from Google. Doomdark’s Revenge was now in breach of one of their policies and needed to be resubmitted or removed from the store. A quick recompile and the problem was solved.

A couple of weeks ago I received an email from Apple. The Lords of Midnight was due to be removed from the store in 30 days. This is due to them culling old apps that were not being updated and/or were not 64 bit. If the App is removed people who currently have it will still be able to play it and re-download it, it just won’t be able to go on any new devices or be updated.

In theory, a recompile would solved the problem, and as I had slowly added some new functionality, this should gain me a stay of execution for possibly another 5 years.

Over the last few weeks I’ve ben wrestling with a Marmalade SDK that is not supported and an inability to build a new version. Eventually, after a lot of heartache and pain, and getting close to just giving up, I have managed to get a working build, however, there is a catch, it doesn’t work on iPad1, iPad2, and iPad Mini 1. iPad1 is no surprise, I can’t target anything lower than iOS 6 anymore and iPad1 only goes to 5.1 The iPad2 and iPad Mini is more of a problem. The issue appears to be the Marmalade system incorrectly reporting those devices as Retina devices even though there are not. I’m still trying to fix this, but it’s proving difficult without current access to any of the devices. So, I might have to make a decision. The deadline is under two weeks now and in order to stave of the executioner, I might have to upload a version that doesn’t support those devices. And this is where the real catch is; I can’t exclude those devices without going iOS10 or purely 64 bit, or both.

Using iOS10 would allow me to target iPhone5 up, and iPod Touch6G, iPad4 up, iPad Mini2 up. Going 64bit would be much more restrictive.

It hurts to think I might lose iPad2, iPad3, iPad Mini1, and iPhone 4, it seems harsh, especially as I have an iPad3 which it does work on! I have no idea how many of these devices are currently playing the game, Apple don’t break down the numbers to devices with that amount of granularity.

To be fair, I don’t have a current enhancement plan for the games, so it’s not like people who currently have the game will be losing out much, but it just feels wrong.

I’ll have to make a decision early next week in order to upload LoM and DDR and at least stop the rot. However, once those versions are up, I don’t know how much longer I might be able to build them again for.

Long term, I need to look at porting the games to another platform, and this is something I have spoken about before…

Many battles fought again by tongue

Posted on by

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..

We must find friends as well as enemies…

Posted on by

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…