Choose Your Language

Wednesday, 25 March 2015

Saving The Day!

There's not much I can report on this week, as it's mostly been about scripting and conversations. I'd be giving too much away. I can mention that I managed to "fix" a potential problem related to AUTO-SAVING a game, and post a couple of screen shots to show what I am currently working on, so that's what I'll do ...


Background: There's a function available for single-player games (DoSinglePlayerAutoSave), where a builder can force an auto-save for the player if they think one may be important (or required) to prevent the player from suddenly finding themselves "dead" without having saved for a while.

The auto-save facility also has a related "automatic" save every few minutes, which is often used in multi-player environments. The problem is, however, many players don't like the timed auto-save taking place when they are in the middle of a game and edit the nwn2player.ini to stop this "feature" of the game from working. However, when this feature is disabled within the ini file, it stops the single-player function mentioned above from working as well, as I found out from my own experience.

This caused me a potential problem because I needed to make sure a game is saved at the start due to some database coding. In The Scroll, if a player starts the module and leaves again without saving first, then they cannot start the game afresh with the same PC. i.e. They can only return to the game with the same PC from a saved position. Hence, I needed to make sure there was an AUTO-SAVE at the start of the game. And while a simple message may have been sufficient (and is still the way I do it in a multi-player game in this case), I wanted to ensure the game was saved in a single-player environment.

The bottom line is, I was able to work around a copy of the existing save game GUI and create my own AUTO-SAVE facility that bypasses the ini check ... and even allows me to NAME the saved game file. So now, when the player exits the GUI warning about the game needing to be saved, the game does an AUTO-SAVE in a single-player game using the name I specify. Players who usually have the AUTO-SAVE feature disabled need not worry, as this is currently the only place I use the facility. However, it is good to know that I have a facility to do an AUTO-SAVE if I need to now ... and one that can be used in single or multi player environment and can have the save file named.


Where the player saves the game's day play, the heroes simply save the day ... usually. And while nothing too special, I thought these two screenshots might be interesting to some players ... the first shows the RWS tielset in action and the second a personalised SEF in play. NB: The SEF has been edited to not give any major spoilers.

How Do We Get Over There?

Unlocking A Projection!


Monday, 9 March 2015

Checking The Logic

It's been a while since my last post, but that's because I have wanted to use the time and energy I have to keep this project moving forward. Health issues have hampered me as usual, but I am still managing to make progress ... slowly, but surely.

I have been continuing to work on a dungeon (a crypt), which the heroes have to explore. This dungeon, however, supports a theme I have been working on and involves quite a bit of thinking ahead on my part, to ensure the logical flow works for the player irrespective of the path they take. Part of that logic check involves deciding if the player already controls PCs that can or cannot perform certain tasks according to their abilities. (I know I am being vague, but I am trying to not give spoilers.) Then, subject to that, I am designing the dungeon to work according to events that have already occurred in the past ... or may be happening still. While sorting through that logic, I am writing scripts to ensure certain items become available at the correct time, and trying to make sure everything balances in terms of combat and skill checks.

It occurred to me as I was working through the process that this is probably one of the most time-consuming tasks I have to do ... plan and check the logic of events and tasks that can occur for a player. Most of this takes place in pencil and paper as I make notes about what I intend to do. Then, the writing of the script is the next stage, before finally adding the objects to the module to test.

QUESTION: How do the rest of you builders manage your dungeons?

Do you plan events as you go .... (or are your events more straightforward) ... or do you also find there are a number of events you have to consider that may affect the overall running of the dungeon? I recognise that most builders will have a selection of dungeons where some are more straightforward than others. However, it is the planning of the more complex dungeons I would be interested to hear how you plan.

This door does not open in the normal manner!
I have also had to work around a couple of glitches I found in a tileset (RWS Dark Ruins), which ended up requiring more time. However, the end result has ended up in a neat idea that I hope will keep the players on their toes!

Hopefully, this dungeon won't take much longer to get to a working stage, and then I will switch to finishing another I was working on. My campaign design requires a number of placeholders between dungeons, and I like to work on each placeholder as I do the internal testing. This means I do not necessarily complete one area before another, but complete areas as the story requirements develop.