Just in case you missed it… Doomdark’s Revenge is out on all formats.
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 finally managed to push out the update to Lords of Midnight. All platforms have been updated to 1.11
This is the first time that all platforms have shared the same code base, and it’s the first time I have updated all platforms on the same day. It’s quite a big day as I’ve been trying to get this update out for a while, and I feel this marks the proper hand over to Doomdark’s Revenge. So, I really hope I haven’t missed something massive somewhere!
This will likely be the last update this year, unless of course I’ve messed something up. For the next 6 months I suspect all my focus will be on Doomdark’s Revenge. Not only getting it released, but those first few updates that will happen to it early next year after the initial release.
I full list of changes can be found here….
But I thought I might pickup and summarise a few of the items.
Big change was adding new grouping controls. You can now scroll around lords that are grouped making it easier to select lords from the select screen when they are grouped. You can also merge groups, disband with one click, change the leader of the group, and drag a lord from one group to another. You can also disband a group or leave a group from the think screen. Video of it working here…
There is more keyboard support on screens. This is for the desktop version and hopefully Android where it has keyboard support.
Mouse wheel support is there for the desktop version.
The scaling on the map is now available to the mobile versions. You can scale with pinch and spread, but I have also left in the scaling gadget on the mobile versions too.
Selecting lords on the Map screen has had a little work. You can now select the multiple lord icon in order to gain access to all the lords.
For iOS I have added an option to toggle between an ebook novella and pdf novella. I hadn’t considered that people might not have iBooks installed. But I have also added ebook support to the OSX version now that Mavericks is shipping with iBooks.
Two biggies that will make a difference to the game. You can no longer select a lord from the map screen when Luxor is dead and Morkin does not have the Moon Ring. This was a bug that would have allowed you to still control your lords even though you didn’t have the Moon Ring – sorry that exploit has now been plugged!
And, armies were fighting double at night. Which means battles would have been quicker than they should have been because double damage was being dealt out. This would have meant that you could have lost a fight without the chance of escaping, because you should have had a turn between the two battles. Or the armies on both sides are unable to get reinforcements between the two battles.
I hope you enjoy…
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!
Early on, when Mike and I were starting the process of thinking about how The Lords of Midnight might look, we played around with a few tentative ideas. We spent some time thinking about being in full 3d and then settled on building 3d models of the terrain and rendering them down to 2d. The main reason for this was performance. Mike was worried that we wouldn’t get the fidelity and quality out of realtime 3d that he was looking for. The option was to go for slower renderer to crank up the quality.
We were unable to get anyone who had time to build the models so we continued on with normal 2d images so that we could have the engine up and running and game most of the game complete. We could then drop the correct imagery in at the end.
We obviously couldn’t go with the original graphics. There was just no way that we could keep the blocky originals. First Mike did some hand drawn versions of the originals.
Then he did some coloured versions.
We could never agree on the coloured versions. I didn’t particularly like them, but we agreed that they were a work in progress and gave us a talking point about what we did and didn’t like about them, and the problems that the approach raised. A proper artist was going to be needed to do them properly.
I wanted to use graphics that I had used in TME. Not the original Lords of Midnight ones, but the graphics that Jure had produced for Doomdark’s Revenge. But I just couldn’t convince Jure to work on the project! 🙂
One of the ideas with the coloured versions was a concept that Mike was calling Ink. With 3d you get lighting. With 2d if you try to do lighting it is usually very flat. Mike’s idea was to give each 2d graphic its own normal map. This would allow the 2d images to have directional lighting. The images would also be made of a very small palette, say 8 colours, and this palette would be expanded to use variants of the colours depending on the lighting etc. The idea is that a terrain is generally only a few colours, it may be many shades of that colour, but still only a few colours. The palette would also be adjusted depending on location, owner, night and day. Things like windows could be lit up at night, and the same graphic could have different lit windows depending on its location.
For a while Mike played with the idea of painting this lighting information onto a 2d image directly to remove the requirement of building models.
We then played around with some more specific hand drawn images. Chris Webster offered to have a bash at coming up with some ideas. The following show some of these early tests.
In principal Mike liked them, as did I. But we couldn’t agree on them. Mike didn’t like the fact that they hilighted the squat nature of the original graphics. The more realistic hand drawn versions just seemed to enhance the problem. I however, liked it as a style thing… unfortunately we never finally pursued this area to it’s logical conclusion because of time.
After Mike died I started looking at how the images could be drawn by me. Ross Harris handed me a quick filter idea on photoshop. The idea being that the images were more of a medieval painting, which is how Mike always saw the original game. The view was more of a tapestry.
After seeing Ross’ idea, I had a play around with photoshop trying to achieve something that I might be happy with.
Luckily, it was about this time that Jure offered to help bring the project to conclusion!
Jure produced two sets of images. One set that were faithful to the original, and an alternate set that he would have preferred to use. One day I do intend to release a version of the game with the alternative set.
And finally, here is an image of Luxor that I found on Mike’s machine…
I just read an interesting review of The Lords of Midnight on the iOS store from PlaystationPaul. I’m posting it here and am going to discuss it as I have no right of reply for reviews.
Be warned – no proper save option
So the porter of this game is quoted as saying “We wanted you to have the ability to save but remove the temptation to just reload your game when something went wrong” and “But you have the ability to undo to dawn if you really mess up.”
Well thanks buddy for completely ruining the game, even the original Spectrum version had an option to save and load at any point – it’s meant to be a strategy game not a rougelike. The “undo” feature can only do so much – I lost Morkin after about an hour of play and can only go back to the dawn – he’s gone permanently along with all that progress – great! Do I really feel like going back and repeating all my actions again just to get to the point where I lost Morkin? No – not really – so thanks for completely spoiling a classic game by omitting one of the bare bone features which makes it enjoyable to play. Hopefully an update can rectify this somewhat arrogant and time-wasting decision.
I don’t know the circumstance on how PlaystaionPaul carelessly lost Morkin. Firstly, if he attacked something and died, then why not just perform a single-undo, and then send someone to his rescue, or keep trying the fight and undo approach. It’s as close to load and save as you are going to need.
Secondly, if he lost him in battle over night, well that’s the game. Maybe Morkin shouldn’t be left unattended where Doomdark’s armies can easily pick him off, and definitely not used in battle.
I presume by mentioning not wanting to redo the day’s work it was the former, so I really don’t understand not using the single-undo option.
‘Such and arrogant time-decision‘ – lets see. An arrogant time-wasting decision, made by Mike himself. Being honest, Mike wanted it removed completely, he didn’t like the idea of people arbitrarily loading and saving just to get passed a particular battle or fight. It took a lot of discussion to get the undo-to-dawn feature in the original release, and then I added the undo-one-turn during an update after a lot of discussion with other fellow Midnight players. So, if I am indeed guilty of arrogance, it’s by overriding Mike and adding the undo-one-turn option. Therefore Mr Playstation Paul, I shall not be releasing an update to rectify a somewhat arrogant and time-wasting decision that Mike and I spent a lot of time discussing and considering its impact on the game.
PlaystationPaul, email me personally and I shall refund your £2.99 and in future I will contact you before I make any design decisions on the game, because you obviously know what this strategy-adventure game should be more than Mike did, and without him around for me to consult, I obviously need to take advice.
“I hope you enjoyed yourselves. Excuse me for not showing you out. Straight up the stairs. You’ll find the way. I’m terribly busy. Whole day wasted. Goodbye to you. Goodbye.”
Demo of new grouping features from the upcoming update. See here for list of changes…
I finally submitted the OSX version of The Lords of Midnight to Apple last night, it’s been a long time coming, a lot longer than I expected. I didn’t start it as early as I expected due to supporting the mobile version until March. Some of it has been because of technical issues, I struggled to get the code, more accurately the resolution code, to work satisfactory. Another part was being burnt out. I hadn’t realised how much getting the Mobile version out, took out of me. I found myself not really interested in developing the desktop version, so I found myself bitting at it and not staying focused. In fact a lot of the code ended up being developed on a Saturday morning while my daughter was diving, like I am now. I have a an hour and a half to kill while she dives, you can only give your full attention for so long, and that was always a good excuse to have my laptop with my and work on LoM.
All being well with the Apple submission process, the game will be available in the Mac App Store for the Summer Solstice. The Windows version needs a little more testing and I need to find a home for it to be distributed. If that all doesn’t happen during the next week in order to hit the same release date, I suspect it will be the week after.I now find myself thinking about the next steps. Jure has already started work on, if not almost finished, the artwork for Doomdark’s Revenge, so there is nothing to hold me back there. I suspect that the actual next steps will be a new build of the mobile version of LoM to include the scaling map, the keyboard controls ( for bluetooth keyboards ), and a few bug fixes that were dealt with during the desktop development. The desktop code is just a different branch of the mobile version, so I just need to roll everything up. Being truthful, I also need to put an advert in the mobile version for the desktop version, it would be nice to pickup at least another 6k unit sales.
Demo of the upcoming Desktop version, showing the mouse and keyboard support.
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.