In the mouth of a broad tunnel, they paused to look one more time upon the fair land of Midnight.

Here is something that I have been working on in the background – Tunnels in The Lords of Midnight. It’s not something that is going to be used in the main game, but I am hoping to have a new scenario released later this year, early next at the latest.

For those of you who have read Drew’s novelisation, then the need for tunnels will make sense. For those of you who haven’t, well something for your list…

Normal Tunnels

Now, you’d think that adding tunnels to LoM would be pretty straight forward. It is as you may know from following my posts, the same codebase as Doomdark’s Revenge, having been unified a few years back. However, there are some issues.

Firstly, even though they are the same engine, and use the same data structures etc, the games are built conditionally as separate projects. This means certain part of the engine is not compiled depending on the games. For example, tunnels, mist, AI lords, special objects, are not part of LoM. Regiments, Ice Fear, and Waypoints, are not part of DDR. There are other little things like critters and battles working differently, and small UI changes.

The engine is written in c++ and most of these features are turned on or off using preprocessor macros like this..

            if ( !IsDead() ) {
#if defined(_DDR_)
                flags.Reset ( cf_inbattle|cf_wonbattle|cf_preparesbattle);
#endif
#if defined(_LOM_)
                flags.Reset ( cf_inbattle|cf_wonbattle );
#endif

Some of it is handled with c++ object inheritance.

Some of it is not handled very well. The code base, like many projects has morphed and evolved over the years. I as a 30+ year veteran software developer, understand the vast gulf of academic based code structure, and real world getting it done with deadlines. And it’s no surprise that the engine has many of these pitfalls.

The following piece of code makes sure that two characters tunnel status is the same. ie: These two characters can only see each other if they are both either in, or both out of the tunnel.

#if defined(_DDR_)
            // they both need to be in or out of a tunnel
            if ( c->IsInTunnel() != IsInTunnel() )
                return false;
#endif

The thing you will notice is that the preprocessor check that will include this code is _DDR_ which means, it only gets compiled when I build Doomdark’s Revenge. Ideally this code should either be governed with a _TUNNELS_ feature preprocessor macro or better still, a feature check based on the capabilities of the scenario. So, that was the first thing I had to do and it took a few iterations to get it right.

The landscaping view for DDR is different as it has a header, therefore the tunnel view needed to be modified.

New graphics were used to distinguish the two.

Text had to change. The DDR strings database has ways of describing that a character is in a tunnel, or can see and entrance. LoM did not.

I found a bug on the think page that is in DDR in that it will show you information about a character in a location that does not have the same tunnel status. There were a couple of other UI issues specific to LoM for showing characters or armies in a tunnel. These just come out of different code paths.

Narrow tunnels

You will notice in the above image, a slightly different tunnel view. This is for narrow tunnels. The novel explicitly has Farflame not entering the tunnels when Morkin does even though they are together, and this is because he is too large. This is a story specific plot device, but that makes no sense when we consider the tunnels in DDR. So the change I made to accommodate this was to have normal and narrow tunnels. In this instance Farflame can enter the tunnels, but there are some important areas that he cannot go because they are too narrow, and the game indicates this with the slightly different layout. Narrow tunnels will also be extended to armies, and too many characters in one location.

Something else I have done with the tunnels is to tweak the concept of entrance and exit. In DDR these are always one of four terrain types – Palace, Pit, Gate, and Temple. However using the mapping software you can now override this and mark any location as an exit, an entrance, or both.

Tunnel view in mapping tools

And finally, while I was make changes for the mapping I extended two other features. Firstly impassable mountains. This was added as a rule recently to help make games optionally harder or just different and it was locked to just mountains. However, I have now added a feature to allow any location on the map to be marked as impassable. In this instance it will be used for all the mountains around Ushgarak. This means that the only way to enter the plains of despair is to take Kor and Grarg. The slight pass at Vorgath as been closed off but I am having to think this through a little more because of the consequences to a western attack.

And finally, respawning of things. In DDR critters and things (claws, thorns, springs, etc) regenerate randomly. I am planning on adding this to LoM as a rule, but for the next scenario I am also adding it as a mapping feature so that certain locations can respawn. In this instance I am using it for critters in the tunnels.

Tunnel Exit

There will be more information about the Novel Campaign later as I work my way through it.

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…

 

 

In the forest, the trees grew tall and shady and bright flowers carpeted the floor

Screenshot 2016-01-06 23.01.13I finally got round to spending some time converting some Citadel data. On of the issues that I had was that I have the map data in LBM image format. It’s obviously not a great format for the terrain data, but this was given to me by the original programmer and I’m not sure how they were processed for the final game. The other issue is the difference in game styles. This data is for a 3d free roaming map and some of the maps are different sizes. The region map are 128×128, however I can’t believe that the citadel could be played out as a 2d landscaping game, without seriously playing with the time taken to move. Therefore, I decided to make the Citadel map 256×256, this is in keeping with the map that Mike drew up for Eye of the Moon, and therefore as the Bloodmarch was originally going to be the setting for EotM it seems fitting to go with the same size.

Last year I did some work on transferring The Lords of Midnight and Doomdark’s Revenge maps into Tiled. I figured that if I could create a tool chain from that, I could possibly edit the maps for future campaign updates to the games. I did all the work on converting to Tiled and coming up with data formats, but never did any work on the toolchain to get the data back into the game. This is something I still need to do.

With that in mind, I produced a draft Tiled version of the Citadel map which you can download to take a look at. It has layers for Realms and Regions, and then individual layers for each terrain type. The Citadel map was very sparsely populated compared to LoM and DDR, and although the current terrain types account for 19 different terrain, which is actually three more than both LoM and DDR, these terrain really are base landscape terrain. Land, Water, Trees, Mountains, Swamps, etc…. it is lacking anything remotely of interest. There are no Liths, Villages, Hits, etc…

If a game is going to come of the Citadel, this is something that is going to need to be rectified.

LoM and DDR pretty much share the following landscape terrain types: Mountain, Forest, Downs, Lake, Frozen Wastes, Plains, and Hills.

LoM adds: Citadel, Henge, Tower, Village, Keep, Snow Hall, Ruin, Lith, and Cavern, while DDR adds: Gate, Temple, Pit, Palace, Fortress, Hall, Hut, Tower, City, Fountain, and Stones.

The Citadel has landscape types of: Mountains, Craggy Mountains, Forest, Hills, Plains, Land, Valley, Lakeland, Swamp, River, Sea, Bay, Lake, Foothills, Isle, and Downs, and adds: Castle.

As you can see, there isn’t a great deal of variety in those none landscape terrains. Citadel, City, and Castle pretty much replace each other, as do keep and fortress. I seem to recall that Maranor is the Dark Citadel, but I am not aware of any cities.

So, apart from Snow Hall, I see no reason why the additional LoM and DDR terrain types could not be used within a Citadel scenario.

The question then becomes, should there be any new terrains?

My first process is to make sure the Tiled map all holds together. I needs a little tidying up which will need to be a visual process. I’m not sure if there were problems with the original, but I noticed things like trees in the sea. I never got that far in the game, so I don’t know if there were indeed trees in shallow water on the coast line, but a few things like that should probably be ironed out.

At this stage I would like to get some Terrain graphics so that I could drop the map into the engine, and start walking around. There are some issues here, as The Citadel introduces water in a way that LoM and DDR didn’t, so there will need to be engine changes to handle that.

Once a clean version of the map is available, the next stage would be to hand populate the map with the other terrain types. I don’t see this being a quick exercise because I think a lot of thought will need to go into this process.

Only at that stage, will I be anywhere near thinking about an ACTUAL game. There is a lot of underlying work do consider with how the game should work, how the AI in the original works etc. Without help this will also be a lengthy process.

So basically, don’t hold your breath, but slowly slowly catchy monkey…