This time you’ve got me to help you…

A few months back I received an email from Marmalade Studios. Marmalade is the system I used to give me cross platform support. I pay for a licence yearly which is still covered by the ongoing sales on the long tale of the game. Anyway, the email informed me that Marmalade were pulling out of the Tools business to focus on their own development. They laid out a timetable and final release plan for the current tools but ultimately from March 2017 they will no longer be supporting their toolset. There was an offer to purchase rights to the source code, but as a small indie, that’s not really an option.

This doesn’t affect the current releases, but what it does mean is that any chances of me producing updates in the future have almost certainly been removed. And with every new OS release, the chance of the game not working are increased.

I know I have not been prolific with updates since the release of Doomdark’s Revenge settled. There was so many things I wanted to do, but just haven’t gotten around to. The reality is two fold, as amazing as the sales of the games have been, they are obviously not enough to support me full time, and secondly, the games were written quite frantically in the end and I never regained that sense of purpose after their release; this is not just for these games but for everything that I have been doing creatively.

I’ve been trying recently to tie up another release. The main reason for this is to produce a build with the latest version of Marmalade and get it out there to properly support the latest devices. In theory a new release should keep its visibility in the App Stores for a few more years. As part of this I’ve been slowing adding a couple of features: Discovery Mode, Difficulty Modes, Rationalise the code base between DDR and LOM. etc..

So with all this in mind I have been toying with the following: Uploading the source code to GitHub and making it open-source with the objective of transferring it to another cross platform solution, Cocos2d-x for example. Or, allowing people to port the engine to any other coding languages they like, so it could be used however they like.

The current codebase is written in c++, and thus moving to Cocos2d-x makes sense, but I quite like the idea of porting to c# or swift.

Moving to open source could also allow for the tool chain to be fully developed which would allow for more work to be put into ongoing development of the games.

Anyway, I shall think on this more, but if anyone is interested in getting involved, then drop me a note…



Related Posts:

Update for Doomdark’s Revenge released

ddr_icon_iosI have just pushed a new version of Doomdark’s Revenge out for ALL platforms. This brings all platforms in line with each other. The previous update was only released for Android and iOS. I apologiss for the delay in getting the last two versions out, but my heart and mind has just not been in it for the last couple of months.

Hopefully this will fix the remaining issues with the gameplay, and will also be the last of the 1.3 changes. The intention is that any update to follow will include some new features.

The Windows and Mac version should be showing up on your main menu now. Android/Amazon version should be ready now, or very soon. Mac App Store and iOS version will take a week in Apple Clearance, and Blackberry version usually takes a couple of days.

The changes are..

1. Fix recruitment check. Loyalty of character being approached now correctly gives +1 and when the lord is treacherous the chance of recruitment is halved – This fix should mean that treacherous lords are no harder to recruit for AI lords, which should stop lords swapping allegiance so much. They should therefore be able to focus on the task at hand.

1. Morkin’s AI attribute is reset once recruited. Stops him moving and allows him to move in tunnels. Previously Morkin’s AI attribute remained set after Tarithel recruited him. This mean that he didn’t work in tunnels very well, and had a habit of wandering off at night.
2. Tarithel can no longer be recruited away. Tarithel was incorrectly being recruited by AI lords.
3. Spell of Carudrium now works correctly. Previously this was bringing ALL characters to the location of the caster, and not just the the lords loyal to the Moonprince.

If the AI characters are still not behaving like the original, I am going to have to spend a lot more time analysing why. I can’t see any reason why the logic should not play out the same as the original ( other than the difference in random numbers ). This will involved a lot of debugging. But hopefully this version should just nudge everything in the right direction.


Related Posts:

I thought the War was lost and Midnight doomed.

battle_full_linesI’ve been working my way through the outstanding bug list. One of the areas that seems to cause contention, is battles.

It causes me some problems because the original is actually pretty haphazard where battles are concerned. So I’m going to talk about the battles in a little more depth, just so that you can get an understanding as to why certain things seem to be happening.

Firstly, night processing goes like this…

1. Reset all characters at dawn
2. Give all AI characters their turn
3. Process Battles
4. Place things on map
5. Move Mists
6. Remove things from map at location’s where characters are
7. Check if characters can recruit soldiers from strongholds
8. Re-spawn armies at strongholds
9. Check for important deaths

Secondly, the interesting point here is, characters are given a chance to move BEFORE battles take place. So, if you attack a character, there is a good chance he will move and thus a battle will not take place.

To understand that a little more, let’s look at the AI turn.

The AI character must decide what to do every night. Each character will react to a number of objectives.

1. Goto Liege
2. Goto Foe
3. Goto Object
4. Goto Home
5. Do nothing

If they have a liege, and that liege’s objectives are 1 or 2, then this characters objective also become 1 or 2.

Otherwise, we pick a new objective

When picking a new objective we pick a random number between 1 and 16. If we choose 1 to 5, then these are our objective. Otherwise we continue with our current objective.

So as you can see, there is a 68% chance that we will just continue on with what were we previously doing. Which means that unless you are at a characters stronghold, and his current objective is to go home, then the likelihood, he is moving away from you.

There is only a 6% chance that the character will stay at his current location.

Personally, I am very surprised at these stats, because it makes battles bloody difficult. Unlike The Lords of Midnight where a nearby army would drop everything to attack, or an attacked army would stay until the death, in Doomdark’s Revenge, everything apart from battle seems to be of more interest.

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:

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:

A Map Editor

lom_mapLooking for a coder who fancies writing a Map / Campaign /Scenario Editor for Lords of Midnight and Doomdark’s Revenge… and anything else that might follow.

I’m afraid it’s not a paid gig, nothing more than a bit of respect and possibly some penny whistles and moon pie…

It can be Mac OSX only or preferably cross platform. It can’t be windows only.

If you are interested, give me a shout.

Related Posts:

“I slew score upon score of his foul creatures yet always there were more to take their place”

I can only apologise for the delays in this project, but can assure you that I more than anyone am eager to see this released.

The summer has proved much turmoil to my schedule. Not because I am too busy, but more because I am out of sorts with development in general. The house move came at a time when I was in full flow, and unfortunately, it had the dramatic affect of completely killing my momentum. And I am only very slowly getting that back.

Anyway, over the last few weeks I have pushed out 2 new versions for testing, and have already added some features read for next weeks drop. The first included changes to the Ice Crown quest. For those people who are very familiar with the original game, the quest mode is way too easy. So I wanted to spice it up a little. Ideally, I was going to move the location of the Ice Crown, or even have it randomly assigned to a location, so that you would have to do some questing to find its location, before you can perform the quest itself. However, I decided to leave that to later in game campaign updates. So all I did was add a few extra armies on the north western flank, the route that Morkin would usually take to perform the quest, and then add some additional logic for generating new armies that are interested in the Ice Crown, should it be lifted from its original location. Current testing suggests that the quest may be a little too hard! 🙂

Second update added some small features to the lord selection screen. The ability to instantly see which lords are at night, dawn, in battle, and to be able to filter on them.

Next weeks drop includes additional features for the map screen. Namely easily locating yourself on the map, scaling, and being able to select things from off the map. Hopefully, I will also add in support for iPhone5 for next week, because currently the wide-screen nature of it, is playing havoc with the game.

In other news, I have a Blackberry tablet dev kit winging its way to me, courtesy of RIM and Marmalade. Which in theory means that the game could launch on this device at the same time as iOS, something that I unfortunately cannot extend to Android.

And… still looking for artists… if you know anyone who might like to get involved, point them in my direction!

Related Posts:

Lords of Midnight – iOS – Update

Just thought I’d post a quick update.

I’ve now been working on this project for a tad over 2 months. Mike contacted me tail end of January, and we started work beginning of Feb.

However, I only work midweek evenings on the project, and then only for 4 evenings. Actually sometimes it’s less because some nights I’m just knackered from burning the candle at both ends and in the middle too. I get anywhere between 3 and 6 hours of coding time. Recently I’ve spent less time than I would like due to having a persistent neck problem that is affecting me sitting in front of the computer – and as I do that all day, it gets hard to do it in the evening too.

Anyway, I’ve nearly finished getting the game fully functional. I spent some time doing underlying UI code recently. We decided against using AirplaySDK’s UI stuff, just because it’s too much baggage. But now that my UI stuff is done, knocking stuff together is pretty quick.

Currently everything is still very simple. I have resisted the urge to throw everything that was in winLOM and winDDR into the mix. The objective is to get the game functional and then start the work of turning it into what we actually want – a small piece at a time. We know how the current overall game works. So once it is working, we can then identify what we want to change, write a design document, and then change it once step at a time.

Tonight I will be putting the character select screen in. Currently you can choose the 4 main characters from the main view, and you can recruit everyone else – you just can’t select everyone. After that I just need to put in the night screen and I’m done.

At that stage I will start testing on different devices. I would like to be able to get a number of people across the following formats – iPhone 3Gs, iPhone4, iPad1, iPad2, Windows, Mac, Linux, Android. If you are interested then keep an eye on the blog, I will post a call for help soon.

Related Posts: