It’s been mentioned to me recently that it would be nice to have modding functionality for The Lords of Midnight. Opening the engine up was something I always wanted to do but I’m not sure to what level this needs to happen. Therefore if there is anyone out there who would be interested in modding LOM or using the engine, drop me an email, and we can discuss what approach to follow to make this happen.
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.
If 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.
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.
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.
I’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!
I recently registered for Blackberry development through Marmalade. The reason was because RIM were offering a free device on loan to test your application. I figured I had nothing to lose, so why not. Anyway, the process was pretty quick and within 10 days I was accepted on the program, qualified for the device, and it turned up today.
I installed the Native SDK, which in turn allows Marmalade to target the device natively. I registered all the certificates etc that I needed. Built the app. Deployed to the device. And well…
There you go. The process was pretty painless. The Marmalade SDK did it’s thing and it just worked. The previous work I did on resolution independence paid off. I just have a few tweaks to make because of the widescreen. But other than that… fully functional.
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!
Since the start of this project there has been an interesting issue with Doomdark’s armies reaching Blood too soon. I’d noticed it while playing, and the testers have brought it up more than a few times. I have checked the code, doubled checked the code, triple checked the code, and the fact is, there is absolutely no reason why Doomdark’s armies cannot reach Blood the first night.
There are two regiments that start the game at the keeps at the Gap of Valethor, lets call them regiments 100 and 101. These are both riders set to wander.
A wandering regiment has 6 turns in the night. Firstly it checks up to 3 locations away, if there is anything interesting between it and 3 locations, it will make 1 turn step toward it. If not, it will randomly pick a direction, and as long as it isn’t frozen wastes, make 1 turn step in that direction.
Movement costs depending on terrain and direction. eg: Cost is *2 turns for a warrior, and a mountain costs 4 turns. So a warrior walking out of a mountain will take 8 turns. You take the terrain cost from the terrain you are leaving not the one you are stepping into. So a warrior walking from plains into mountains will take 2 turns, leaving 4 turns. The next move will cost 8 turns, but the fact they only have 4 turns left, is not important, they take the move, but then have -ve turns left, and thus their processing ends.
The process will be repeated until the 6 turns have been exhausted.
Now regiment 100 starts at the keep directly north of Blood. If on its first move, it decides to move south, then that places it within 3 locations of Blood, which means the next turn will focus it on the stronghold, and therefore it will guaranty hitting Blood in the first night. A movement of southeast, or southwest, will reduce the chance that the regiment will hit Blood in the first night, but it is still a possibility.
So, the original AI for Lords of Midnight, makes it possible that Blood could be hit on the first night. But it hardly ever happened. On my version, it happened almost every time. And every time makes it impossible for you to recruit Lord Blood, let alone try and mount the Blood Defence.
I figured that the random number generator mustn’t be functioning, so tested that, double tested it, and then tested it again. It seemed to be giving a reasonable stream of numbers. Didn’t change the fact that the results I was getting were not desirable. So I considered placing a delay command on those regiments, just to slow them down.
Last night I was talking through the issue again with Mike and we decided to throw out the random routine, and use another one instead. He gave me the C code version of the one used in Midwinter. The results were the same! But then I noticed something. The random number functions generate a number between 0.0 and 1.0 And thus picking number between say 0 and 8 just involves multiplying 8 by the random number, and there was the problem. This number needed to be converted to an integer, a whole number, and it was being done with a cast to int. And this truncates, which means the number is ALWAYS rounded down. In theory it just means that in this instance, 8 would almost never be picked. And in the case of these wandering regiments, that just means losing Northwest. However, changing that one line of code in the random number generator, has put those wandering regiments, back on the right track.
Blood can still be hit, but it is hit much less often than before.
I thought I’d better post here, because it seems it’s been a while!
I know many people might be thinking that this project is going the way of all the others… vapourware, and to be truthful there is always the chance of that. I do find it very hard to get the work done in the evenings, when I have so much going on. And we’ve had such a good summer, in the scheme of things, that I’ve found it very hard to do any coding in the evenings.
The last few months has seen me going through a merry go round of my work contracts, and in particular I’ve been working silly hours.
I also had a lot of problems with Marmalade, the SDK I’m using to give me the cross platform. They have only recently been resolved.
Anyway, enough of the excuses, other than to say that 6 months has disappeared and the project hasn’t moved on a great deal!
The intention is to fire up the quatro, and make a real push to get work done started again from Jan. I’ll also try and keep the blog up to date.
I noticed that man people have visited and will have seen no movement for a while… 🙁 sorry about that!
So, watch this space…
Thought I’d post an update for LOM. I realise that it’s been over 2 months since I last had anything to say on the subject.
Firstly, it’s been a busy few months for both Mike and myself. Mine work related and Mike’s more personal. That combined with a little bit of sidetracking on Eye of the Moon.
Two of the issues with this project is time and getting it right. Neither of us are working on project full time and it’s very easy to lose a week before you know it, just because you were overly tired or didn’t feel like sitting in front of a computer. I’m sure that winter is the best time to do development and not in the summer.
The getting it right aspect is about thinking about the project more than actually doing it. Over the last 2 months I’ve been going round in circles about the graphics of the game. I’ve been thinking about a number of different approaches that we have considered for the look and feel, and the way the user interface will work.
The original LOM had a very distinctive look and feel. Simple, but very affective. Somehow with the very powerful modern technology, we have to achieve the same result. I sat down recently and gave some thoughts to the way LOM was going to look, and was not happy. I’ve had firm ideas about the direction of the graphics for a long time. Mike brought new ideas to the party when we start discussing the new game. And in general we had a consensus about the way forward. But then I started to doubt… I kept thinking about Jaws. Jaws works because the brilliant robotic sharks that Spielberg was going to show off all over the place, didn’t work. In the end he had to work around them, utilising them sparingly. The end result, much more suspense to the film.
For LOM, the shark was the graphics. Mike wrung an awful lot from the spectrum, but in the end, the setting of the story was defined by the minimalist graphics – a world full of white snow! So, as you start to up the quality of the graphics you are moving further into working shark territory. LOM was stylistic and I feel it has to remain so. Simple and stylistic.
I discussed this with a few people and then went back to Mike in order to tell him that I thought we were the wrong people to be thinking about the graphics. And that if we continued down the path we were following, I felt we were going to make a mistake. Mike agreed.
So, last week I had a meeting with an artist. Fergus McNeil ( some of you may remember his 8 bit days with Delta4 ) and asked him to take over artistic control of the project. I’ll keep you posted with anything I can on the visuals.
In the mean time. Tonight I am back at the computer – coding!
It seems a little strange, that after all this time, something might just finally become of this project! 🙂
The first stage was to get the Midnight Engine up and running under iOS. Well I tried that about 3 years ago without any major success. However, it’s a little more important now. So I downloaded the Airplay SDK which Mike and I had decided to evaluate, and started porting the engine.
It was a pain! Differences in compilers, changes in the language, blah blah blah… it took a couple of days of monotonous work before I had a project that loaded the TME data in. While I was working on that, Mike was playing around with some graphic ideas that we had talked about implementing – mainly to do with lighting.