Friday, 18 May 2012

Database Debacle: Transition Crashes!

It came somewhat as a surprise when as I was testing my module it came crashing to the desktop. I had just created an entrance to a small cave area I required and was testing the transition between it and the outside area when this happened:

What had gone wrong? I had not changed any of my scripting and was unaware of any corruption in my files, and so I was somewhat dismayed when I could reliably repeat the crash every time I tested the new transition. I then tested an older transition and all seemed fine, until that was, I tested it a number of times, and then, sure enough, it would crash to the desktop. More investigation was required ...

Deadly Database

I have often heard of the problems people claimed that the inbuilt database functions caused the game, but had never encountered anything specifically wrong with using them before. However, after some investigation, it turned out that the transition crashes were occurring after a database call had been made by one of these functions. Yet, as it turned out, it was not specifically this, but only if the database reference was new. That is, if the database reference already existed in the database, then any call to it did not lead the game to crash. However, if a database line was added to the database during the game, then the game was likely to crash at the next area transition, especially if either of the areas were large. (Larger areas appear to expedite the chance of a crash after the new database call occurs.) Even if you were lucky to get away with one transition, the game would crash at a transition soon after.

The Solution

As The Scroll makes good use of these database functions I needed to find a resolution, or all my efforts to date with them would have been for nothing! Astute readers will have probably already guessed at the solution I finally came up with: Make sure the database is established (initialised) before the player plays the game. So when a player starts The Scroll for the first time, they will now be presented with the following GUI screen:

Hopefully, players will recognise this as a minor inconvenience to help provide a crash free game session thereafter. (That is the plan at least.) Depending upon how one has used the campaign database functions will also determine how you go about setting up your function to set up the database. For myself, there were one or two simple single lines to add a single row reference, and in other instances I was able to use a loop to set aside all the rows (for objects) that I needed. For added security, I added the variable holder reference to the object in question as a local string to refer to when the database variable holder was required. This was just to make sure there was no change in variable holder name between me setting the database up and the time I needed to refer to it.


It may be that you have had some strange transition crashes in the past and wondered what caused them. Hopefully, having read this you will be armed with another potential method to overcome them. I also discovered that Runtime Errors (especially on exiting the toolset) are caused by misuse of Include files. i.e. Different scripts may be calling the same Include that is already included in another Include associated with them (if you see what I mean).

So, if you have any information on what causes a game (or toolset) to crash, which may not be obvious at first glance, then please respond in a comment. Shared info like this is definitely a "prevention is better than a cure".

Thursday, 3 May 2012

Althéa: Party Creation Rules (Manual Entry)

I have been continuing with conversations and the quest journal entries associated with them. It is the crux of the story and so is not something I can go into much detail about, apart to say that it is coming along slowly but surely. So, to give you something to read this week, I decided to show you another page from the manual that I hope to ship with the module. This week, a little more information about Party Creation and how multi-player games affect it. As I said last time, if you have any questions about the module or just wish to leave a comment, please do.

Party Creation

Before the player is finally released to explore the World of Althéa, they are offered the chance to add some more PCs to their Main PC to make a party of up to four characters. The following information screen pops up prior to the main creation screen. As it says, party creation is not required, as their are companions that can found and added instead. However, the player can choose to add some PCs now and add others as companions later when they come across them if they so wish. Once the player presses "OK" to this screen, they will be presented with the standard SoZ style party creation screen, where they can continue to create their party of up to four, or choose "cancel" to play alone.

MP Considerations: When it comes to Party Creation, the players that are playing the game count as "non-player" created PCs already. Furthermore, if the host player uses all three empty PC slots to create a party of four, then later players entering the game will not be able to add any more created PCs at all. E.g. If two players play the module as a MP game, then each player could add another PC at the party creation screen to their specifications, to make a total party size of four. i.e. Two real players, and two created PCs. Alternatively, if a group of players entered one at a time, then the fourth player to enter would fill the last fourth slot and be unable to create any party PCs. Practical usage will demonstrate how this works.