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!

Lords of Midnight Graphics

Posted on September 24, 2013 by Rorthron

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.

Example of a lighting map.

An early test of a simple model that Mike rendered.

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…

Thoughts on Load and Save and ranting reviewers

Posted on September 11, 2013 by Rorthron

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