For Midnight!

Posted on December 6, 2013 by Rorthron

For Midnight! For Midnight and the Free!
Hear me, Shareth Heartstealer;
we ride to tear the Frozen Empire asunder!

It’s with a heavy heart that I write this. While working on Doomdark’s Revenge this eve, I had to accept the cold realities, and admit to myself that it is very unlikely that I can make a Christmas release.

It’s not that the game is very far from finished, it’s almost there. It’s just that there are so many things going against me at the moment. I had hoped to upload a test version to Testflight at the weekend, that never happened due to spending time with my parents. I’m working away at the moment, so I get nothing done at the weekends. Having been away all week, it’s important to catch up with the family. I couldn’t build a test version on Monday because I left the licence locked on my home machine.

This time last year, Lords of Midnight was in test and I was still working from about 6pm till 2am every night including weekends. At the moment, because I’m working away and in a new contract, I can only manage about 4 hours a night.

The real issue is testing. Apple close down over the christmas period, which means I have to release on the App store on 20th at the latest. That means submitting a good week before. That would be Friday the 13th. Now I’m not a superstitious person, but I will be driving home for 4 hours that evening. Therefore it must be done by the 12th. And that is exactly one week away. That means I must put a version into test this weekend, and at best it will get a couple of days testing… I think all of you who know the difference between Doomdark’s Revenge and The Lords of Midnight, can see that that just wouldn’t be wise. I’m pretty sure that most of the UI stuff would go through test, and the little bits that turned up could be resolved in that time, but the AI?

I would have to work all this weekend in order to make sure that all the AI code is indeed finished. I think it’s pretty much done. I haven’t tested through all aspects yet. I spent this evening watching Lords wander around on the map. But they have battle’s to fight ( not written ), objects to pickup, Lords to recruit…

If I did submit on 12th or 13th, I would have no chance to remedy any last minute hiccups, and then I couldn’t fix anything on an Apple Device until the New Year anyway because of Apple’s closure.

I need to make a final definitive list of all the areas that need finishing off. They might just be little things, like a bug I’ve noticed on the overview map screen, but they might be a little bigger, like the fact that I haven’t coded any of the win/lose conditions, let alone tested them.

GoG can’t release the Windows Version until the New Year due to time constraints, and even if I could finish the game, I’m not currently able to build the final OSX version due to a problem with the Marmalade SDK. Added to that, I haven’t done any real device testing other than loading onto the iPad.

Then I’ve got the Website to build… PR to do… a trailer to make… the Manual to finish…. Stores to decorate…

Just typing this is exhausting me! 🙂

In all my time in development, there is nothing in the above that says anything other than… “Don’t Go”. The only reason to launch, would because I said that it should be ready for the Winter Solstice.

So here is what I will do. I will continue all guns a blazing to get this finished as soon as possible. I will attempt to get a test version on Testflight this weekend. This gives me two weeks of testing to iron out as much as possible. I will then aim to release an official BETA on the 21st ( Winter Solstice ) – on all formats. The Apple devices will be covered by Testflight. I will let you register one device on there for testing, in order to give as many people as possible a chance to play the iOS version. ( I only get 100 testing slots from Apple ). The Android devices will be covered by Google Beta on Google Play ( I think! ). And Windows, OSX, and Blackberry will be on this site.

That way, many of you who have been following this release closely can get the chance, if you so wish, to play a pretty final, if not an actual final version, before release. Hopefully, that will also mean the game gets a good testing over the Christmas break, and I can do an all formats release early in the New Year.

Chris

Shading the night sky…

Posted on October 27, 2013 by Rorthron

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.

: Original Night

: Remake Night

Doomdark’s Revenge however has a completely different approach. There is a dawn visual, and day visual, and a night visual.

: Dawn

: Day

: Night

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.

: Dawn

: Day

: Night

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.

Tunnel Vision

Posted on October 3, 2013 by Rorthron

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!