Firstly, I wrote a lot of code for DDR back in October 2006, I had a good few programming sessions on it, and then as usual faded away. I coded most of the NPC’s AI; Follow Liege, Follow Foe, Go after Object, Go home, Do Nothing, Approach a Lord, Pickup Objects on their travels, and Move. I coded the moving mist and wild thing regeneration. I also coded most of the battle code… and then I got distracted by shiny objects.

Since then I’ve changed computers and compiler; so loading up the project yesterday I found that it didn’t compile in a big way. So tonight I have mainly spent all the time fixing compiler issues… and there are an awful lot of them.

One of the other problems I have had with the project is that the graphics are getting so complicated that while running in debug mode, the project runs a little slow. I’ve been putting up with it because it isn’t so bad in Release mode but slowly it has been getting me down and distracting me from the issues. It’s hard to test logic if the frontend isn’t working properly.

I’ve wanted to move the graphics subsytem to make use of the hardware. By moving the 2d logic to use 3d cards I would be able to massively speed everything up. However, I’m not a 3d programmer and again the task just keeps distracting me away from things.

I had a word with Jon Alma today who has been working on the Legends Engine and hopefully he is going to knock up a quick wrapper for some OpenGL stuff that will allow me to move the graphics forward and solve the speed issues.

So today I felt that I made a little progress…

Don’t you just hate it when you leave your code in a none working state! One was some bad XML, incorrect closing elements, and the other was some memory being trashed. The memory problem was due to my string class doing a shallow copy on assignment… well actually it wasn’t, but the compiler was for some reason not using my string assignment operator and instead doing it itself! Actually I have no idea what the compiler is doing at that point… grr…

It seems that the compiler differentiates between these two bits of code…

figure1

int example_function ( const string& source )
{
string new_string = source ;
}


figure2

int example_function ( const string& source )
{
string new_string ;

new_string = source ;
}


figure2 creates the correct constructor code for new_string and the correct assignment operator call for new_string = source. Figure one just makes new_string exactly equal to source. I think I must be missing something somewhere!

One of the main goals with The Midnight Engine, was its openness… this is part of the holy grail of all game development, the data driven engine (DDE); in this case I actually think it’s particularly important.

To me the DDE splits into two parts, the data and the scripting engine. The first is pretty obvious, one big database with all definitions for everything in the game. In TME this is a Access Database that gets exported to XML for the engine to read. It holds tables for Characters, Strongholds, Regiments, Waypoints, Races, Genders, Areas, etc… Part of this is also configuration options. For example just one variable change will change how the recruitment model works… however there is also a need for some form of code scripting to allow a developer to make code changes without actually changing the engine. More on this later.

TME covers two destinct aspects, the frontend and the backend. The backend is the game engine and is completely seperated from any graphics output. This part of the engine can be used by 3rd parties and is indeed used by Andrew Smart’s wonderful War of the Solstice. The frontend is game driven and for my covers Lords of Midnight and Doomdark’s Revenge primarily. There are currently two versions of the frontend, the older LOM and the much newer DDR.

The transition from LOM to DDR has seen the frontend engine change dramatically. In fact most of it has been re-written. And this is where my current slowdown has occured. Sometimes writing frontend GUI code is just damned tedious – add this to my requirement for openness.

The frontend is configured through a series of XML files, every screen, every gadget is held in an XML file. This stops the ending from being recompiled for every screen change. Now ultimately this is a honouress goal, however in the short term all functionality needs to be coded. Which in the end means that development of the engine and therefore DDR goes slower than I would like, but development for other scenarios or games that follow are easier. And crucially, this is what my eye is on. Yes we all want to play a nice shiny new LOM or DDR, but I also want to play The Citadel and Eye of the Moon.

So that’s a bit of background, what have I been doing latley?

Well I have the framework for the GUI in place and many of the gadets are fully operational. The last few days I’ve been adding data collection functionality. What this means is that when a screen is displayed, or screen fragment (think panel at the bottom), the screen has a entity attached to it. All controls/gadgets/widgets that belong to that screen can retrieve data about the entity and display it without the need for any engine code.

Here is an example. ( This is generic XML, the formatting has been changed only to show it here… I need a diff plugin to show XML/HTML tags )


[guage id="ID_WARRIORS" zorder="2"]
    [background]ui_panel/bckg_3a.tga[/background]
    [knuckle]ui_panel/i_man.tga[/knuckle]
    [pos]153,148[/pos]
    [max]1200[/max]
    [bound var="character"]warriors.total[/bound]
[/guage]


Now this gadget can show everything it needs without any engine code at all. What actually happens is… the gadget is bound to the variable character. This is a unique identifier of an entity. The gadget is also bound to the variable warriors and element total. So when the screen is displayed or refreshed, the gadget can obtain the correct data from the correct character and process it for itself and display the result. Now the access to the data can be complex. We could for example say riders.race.name or even liege.stronghold.warriors.race. Each time the data engine knows where to do the relevant lookups to pull in new parts of data. In that case we Get the character record, then the liege character record, then the stronghold record etc…

Using this method, the display of data is just then down to the interpretation of the gadget. With this version of the guage gadget, a knuckle (warrior) is displayed proportionally along the horizontal access of the background image.

In the following example the time is displayed by moving a sun icon into set positons on a curved image.


[guage id="ID_TIME" zorder="2"]
    [pos]144,96[/pos]
    [background]ui_panel/bckg_4a.tga[/background]
    [knuckle]ui_panel/i_sun.tga[/knuckle]
    [points]
        [point]5,32[/point]
        [point]15,21[/point]
        [point]29,12[/point]
        [point]45,7[/point]
        [point]63,5[/point]
        [point]80,7[/point]
        [point]96,12[/point]
        [point]110,21[/point]
        [point]120,33[/point]
    [/points]
    [max]8[/max]
    [scale]200[/scale]
    [bound var="character"]time[/bound]
[/guage]

Gadgets can also be enabled/disabled based on this information. Eg. a button may be bound to location.canHide

To take that one step further the engine has bult in collections that a gadget can access. This can be used say if you wanted to list all the lords that are loyal to another lord qryLordsLoyalTo. Or all the lords at the current location qryLordsAtSameLocation. By binding a datagrid or a selector to one of these queries we can then display all the information about those other lords.


[list id="ID_ALSOHERE"]
    [bound var="character"]qryLordAlsohere[/bound]
    [columns]
        [cell source="name" format="string"/]
        [cell source="time" format="hours"/]
        [cell source="race.name" format="string"/]
        [cell source="warriors.total" format="number"/]
    [/columns]


In time I would like to remove the predefined collections and just allow a very simple SQL type language to select the data.

The other stage of this is to action events. When a button is selected something has to happen…


[button id="ID_LOOKLEFT" zorder="1" OnClick="Cmd_LookLeft" /]


This tells the engine to run the internal code command Cmd_LookLeft. Which currently looks like this.

GUI_EVENT ( Cmd_LookLeft )
{
    character& c = TME_CurrentCharacter();

    return TRUE ;
}

Now, again ultimately there would be no need for the above code to be real code at all… it should just be scripting code and be included within the frontend XML file. I intend to do this in a future release, that is after DDR has been released. This script code would probably be JavaScript using SpiderMonkey – however as mentioned before, more to come on that later.

I got the mist from Jure today, so here it is in all it’s glory. I’ve tried to get a few variant shots but the location that mist is in at the beginning isn’t great – and I have no night button working at the moment! The first shot is the opening screen, you will notice compared to the same screenshot posted the other day, the old mist has gone from the bottom right of the terrain, and the new improved one is in place. The other shots show off the mist more dramatically. I also managed to do some work on that bottom left panel, not to mention fixing a few UI bugs.

Anyway, in the spirit of that; here is the current situation.

I re-wrote all the UI stuff and putting it all back has been a pain in the ass – and currently because I can’t navigate around the game properly, I tend not to do it I think. Slowly the UI functionality has been coming back and tonight I fixed the last remaining shortcut keys bug, which means that the keyboard is now working correctly. More importatnly that means that I can move around the views using just the cursor keys. So that was today’s task done.
The other day I finalised the box drawing code. Boxes look like this image on the right… The two gargoyle things on the edges are optional… both, none, left, or right. This now means that I can start work on all the popup windows that come up during the game.

The panel is almost finished apart from this part on the left side of it. There are a few bits of dynamic information to add to that part.

The left hand part of the panel is now my next mini task…

1 – Patches
The base graphic system is built on the concept of ‘patches’. A patch is a graphic xml file format. It holds instructions on how to draw various graphics based on other graphics. The idea for the system came from my interview with Mike Singleton for Retro Gamer. In it he talks about displaying the terrain for Eye of the Moon using component parts, allowing for a more varied landscape. So when I started on DDR, I thought; why not…

In it’s very simplist form a patch would just hold the filename of the actual graphic to use in order to display the patch.

[patch id='MAP' x='0' y='0' ]
    [image file='terrain\map\t2_forest8.tga' /]
[/patch]

Now getting more complex the patch can reference another patch and also more crutially reference variables. So it can decide to include a graphic or patch depending on conditions that have been setup prior to the patch being displayed. If we used the simple example of scale, the patch file can choose different images to display depending on what scale we wish to draw the graphic at. This allows for the effect of mip-map rather than allowing the graphics device to scale the pixels. This might mean that you get a better finish on the graphic, however, in most of the cases in DDR, this means we can subtly change the image because, a smaller scale usually means further away, and thus we can apply some form of distance effect to the image in pre-production rather than at post.

[patch id="_default" ]
    [image file="t2_forest0.tga" scale="1.00" var="6" value="0" /]
    [image file="t2_forest0.tga" scale="0.70" var="6" value="1" /]
    [image file="t2_forest0.tga" scale="0.45" var="6" value="2" /]
    [image file="t2_forest0.tga" scale="0.37" var="6" value="3" /]
    [image file="t2_forest0.tga" scale="0.28" var="6" value="4" /]
    [image file="t2_forest0.tga" scale="0.21" var="6" value="5" /]
    [image file="t2_forest0.tga" scale="0.17" var="6" value="6" /]
    [image file="t2_forest0.tga" scale="0.13" var="6" value="7" /]
[/patch]

This patch uses the same image but scales it depending on the size variable.

Some of the variables that a patch has access to are…

By working with these variables we can display the same patch file, but allow the patch file to decide how it should display itself. So for example in the tunnels the patch would check the direction vars to decide if a patch should be on the left or right of the screen. Thus giving the correct affect of looking up or down a tunnel. It might also use the domain variables to decide a look for the graphic; it might display beams in the tunnel for particular values of domain.

[patch id="VIEW"]
    [patch id="forest-leaf" var="8" value="2" cond="< " break="true"/]
    [patch id="forest-leaf-pine" var="8" value="7" cond="<" break="true"/]
    [patch id="forest-pine"/]
    [/patch]

This tree patch uses the domain%10 variable to decide on the type of forest that the patch belongs to. Here we have 3 types of base forest type. This makes the forests on the landscape different depending on where on the map you are.

A patch also has its own random no which is used for the chance% variable, this random is seeded to a value specific to the use of the patches. For terrain patches this is based on the coordinates at the domain. What this means is that every time that patch is drawn for a given location, the random no sequence will always be the same. This allows a patch to behave differently from an adjoining location, but always the same at the same location.

[patch id="VIEW" ]
    [patch id="mount-small" chance="15" break="true" /]
    [patch id="mount-very-big" chance="15" break="true" /]
    [patch id="mount-small-medium" chance="30" break="true" /]
    [patch id="mount-big" chance="30" break="true" /]
    [patch id="mount-medium" /]
    [/patch]

This patch is for a mountain. You can see hat there is a 15% chance of the mountain being small, 15% chance of very big, 30% chance of small-medium, 30% chance of big, otherwise it's medium. What this does is make sure that a single moutain is not always the same size. You could check the domain an have a graphic without snow or have all mountains in a particular range being the same size.

Now as these patches break down further we can use it to build up parts of the image itself and not just choose what image to display. If you click on the image of the moutains you will see that there are 10 different images used to make a mountain. We use either 'base' or 'small' to start with, but overlay any or even all of the component parts of the base image to create a multitude of mountain types. Because a patch can reference a patch, then very complex sub routines of patches can be developed and then called upon randomly to build up the images. So if you break the image down to many smaller parts, then the final result can be very complex and have a tremendous amount of variations, but the patch code can be relatively simple. By using the numerous variables at our disposal we can make sure that the mountains of the Icemark are very varied without too much effort, or too many graphics.

To me, this is one area that is very exciting for Doomdark's Revenge. It means that the landscape becomes very rich and varied and removes the monotony of seeing the same terrain over and over again. The same system can be used for people...

This final image shows an exit from the tunnels. As I’ve mentioned before, the tunnels like all the other terrain graphics, are made up of patches. This means we can get a lot of variety into the visuals depending where on the map you are. This is an exit into a man made building rather than a pit.

Here is a category search…

However, despite its strong sense of location, there was little impetus to idly explore the countryside. While the land of Midnight has a stark beauty, the limited range of elements leaves little room for any surprises. If you’ve seen one mountain you’ve literally seen them all, so the few times the game does surprise, the impact is all the more for it. One of the more spellbinding moments came late into the game, when I felt like I was further north than any other man had ever been, and I saw ahead of me distant tower. Except that it nestled safely behind the frozen wastes. Having become accustomed to the frozen waste’s role as the implacable edge of the game, this seems like a mirage. Or a bug. Any thought about the campaign at hand was put to one side as I explored this anomaly. And so it was: in one corner of the world it was possible pick a path through the wastes into a little oasis of land. It’s a small, unremarkable thing, but when I was there, surrounded by the claw-like peaks of the frozen wastes, it felt like a real discovery.

I gave it a little thought and wondered what it is about the game that has drawn me to it for 20 years. I think that the beauty of Midnight is in the atmosphere of the imagination. For some reason that game landscape just allowed the imagination to run free. Once I started playing the game I would just get lost in the story of it. I still do. Which is one of the reasons whyI set up the wiki to try an realise all the information that we know about, and create so much more that we don’t. I want the place to be real, I want the place to live. Yes, the story is full of typical fantasy cliches but there are so many oppurtunities to iron them out and create a very interesting place that more people could inhabit. I am closer to the characters of Midnight, than probably any book that I have ever read. Would I rather have Midnight or Lord of the Rings? Midnight every time!

Wayne Britcliffe caught the mood just about right in my Retro Gamer Article..

Even when actually playing the games your imagination takes you beyond, especially in the case of the original’s 8-bit limitations, what you are actually presented with. Swords clash, men scream, the plains fill with marauding enemy armies and smoke rises in the distance as snow begins to fall. Lord Blood dies surrounded by those he has slain in the gatehouse of his overrun Keep – a valiant defence against impossible odds. Shimeril escapes by the skin of his teeth only to have to turn and fight before his Citadels walls.

He discusses the merits of the game when you consider it as a Lord of the Rings inspired epic.

See Also: Similarties to other Fantasy Stoires…

I’ve been having a hard time with my work on The Midnight Engine I get so little done nowdays and I’ve started to get disheartened by it. Anyway after a plea for help from the rest of the midnight commuity I think I may be ready to get on it again… watch this space…

The base engine has been changed to handle most of the differences in a global fashion, however, I have created multiple versions of a mechanic where needed. eg. A scenario writer chooses which type of battle system, recruitment system, etc…

Lately I have got caught up the the frontend – this has been rewritten to allow easy change, the idea being that scenario writers can affect the frontend as well. However this has been much more of a pain than I anticipated and has, to be honest, bogged me down!

I got over a major hurdle today, and thus I hope to get back on track.

The graphics system has completely changed from the LOM version, and anyone who has seen the screenshots will admit it looks lovely. The whole engine works with a patch system allowing for the terrain to change depending on which location it is, this means that the panormics look differently all the time. This process is also used in the tunnles which allows the tunnels to have distinct appearnces depending on where you are.

Ther resolution is 1024x768x32 – which is causing some speed issues at the moment, due to the amount of graphic work being implemented. For example, there is a haze layer that is applied over the seven sizes(distance) of graphics. In some way almost every pixel is adjusted a number of times before being written to the screen. This will all get sped up at the end.

Jure has produced lots of new graphics, and has worked with Bill to use the DDR shield templates and produce TME versions – thus keep consistency across the midnight games.

The last work that I know Jure was working on was the fog system, and we also discussued and inverse landscaping for the sky.

I recently implemented all of Andrews TME mods that he used for WOTS into the new codebase, and will be handing a version of TME over to him real soon so that he can hopefully get moving around the DDR map in the WOTS engine.

Hopefully, once I had it over, requests from Andrew combined with my own needs will move the project along.

My resolution for this year is to get back to be organised. Over the last few years my self organisation has slipped muchly and every part of my life now requires that my organisation skills get back on track.

Things to do:

Personal
Finish TME ( Doomdark’s Revenge Scenario )
Start TME tools for Scenario writing – or preferably Igor will work on UniMapGen and his suit of tools.
Finish Wizards Lair Dataformat for John Dow
Finish Firelord Dataformat for…
Finish Spectrum Dataformat DISZ80 Tools
Revamp website
Add all Doomdark’s revenge section to website
Work on Midnight/MU Campaign Manager
Work on Midnight/MU Forum Website
Work on ‘Personal Jesus’ – My Novel #1
Work on ‘The Harry Anderson Journals’ – My Novel #2
Work on ‘unamed’ – My novel #3
Finish Retro Articles
Write new articles
College
Get fit
Lose weight

Home
Decorate New study, Rebekah’s Bedroom, Jacob’s Bedroom, Victoria’s and my Bedroom
Work on the Garden
Fix Garage Door
Convert Loft
Decorate Stairs and Landing
Spend more time with Victoria and the Kids

So, as you can see, my life is a little busy and I have a lot to do… aim high as they say!