Deities & Holy Books

I have been involved with some decorating this week, which has tired me out somewhat and caused me to have little to do with the toolset. However, the little I have done has had me involved with looking again at the deities and creation of their Holy Books for my world. This was one of those areas I was not going to go into so much detail, but as the results of the current poll (at the moment) suggest around 50% quite like reading and background, then I thought adding a little more depth about the deities in the form of Holy Books might be worthwhile. Furthermore, as these are the same books that clerics use to study for their prayers, then players can determine for themselves just how much they want to pay attention to them.

(POLL: 24 days to go. Please keep your votes and comments coming!)

I have also added a new dimension to the current method of displaying pictures in my Readable Books by making the background texture have pictures already embedded, which means players will be able to see the deity icons inside the books. The picture below shows what I mean, although I have not added any text beyond the god name at this stage. I have also been editing the nwn2_deities.2da to ensure only the correct gods and/or alignment choices are available that match my world's ethos. For instance, clerics must follow a path of good or evil. Only non-clerics (or druids in particular) can choose one of the neutral aligned deities available.

You may also see in the picture above that a player can have their PC start to follow the faith of a new book they find. Taking up a faith (or possibly changing in rare circumstances) means more to a cleric than any other class and is governed by their alignment and so players of clerics should make sure they find a faith and stick to it if they want to keep their cleric's prayers being answered. However, I am also considering what following a certain faith means to classes other than clerics. And this is where you, the reader, can have some input if you like: If you can think of any benefits that a PC could have when following a faith, then let me know. It cannot be anything too extravagant, but something that may add a small benefit of some kind that would make you want to consider taking up a faith. Please comment.

Hey You!

I have also been working more on some of the Real Life responses that will come in the game. Regular readers will know that this system is my attempt to try to make the world feel as though a PCs actions bring about real responses from surrounding NPCs. Not every action is easily coded for, but my latest idea was to ensure PCs cannot simply bash down doors if other NPCs are nearby and act as witnesses to the PCs chaotic actions. And yes, bashing down a door does move a PC 1 point towards chaotic. :) Like trying to open a chest without permission of the owner, the PC will now have to consider the responses of nearby locals before they simply try to knock down the door to "Ye Old Curiosity Shoppe of Magick". Of course, if there are no witnesses nearby that can see or hear the PC's actions, then they can continue to bash away at the door to their heart's content.

My wife goes back to work next week and I should be able to get back to more coding then, and hopefully back to some of the conversations of NPCs that I have been trying to get down for the last month or so. ;)

POLL: What Gaming Style Do You Like?

Now and then I come to a point in design when I question what would be the best way to go for players' enjoyment. I know that ultimately the module will mainly be governed by what I want it to play like, but, at the same time I still want to appeal to gamers as I guess most builders want to. Having started to prepare the conversations for the main quest, I found I was writing quite a lot of text to help fill in the background of the story, which may be tedious for some gamers? I know there is always the option to allow players to skip past the "verbose" path, but at the same time, it got me thinking what the current feel is from other players out there.

For this reason, I thought I would offer another poll to readers who may be able to help me focus on the style of game they might like to play with respect to the quantity of text to read as background to the story. Once again, I am not saying that anything will fundamentally be changed, but feedback may have an impact on options and gaming styles available. So, please take a look at the poll and let me know what you feel about NWN1/2 modules.

In the meanwhile, I have also been helping to play test ZORK by Ampraphael. This is an amazing adaptation of the original Zork text adventure, and for those players with a fondness for the old generation text adventures, I don't think you will be disappointed with what he has done. Amraphael (a.k.a. Ronnie) has done some great custom content for his version and his area designs are second to none, really bringing to life the text of the old game. While ZORK is not a D&D adventure, it certainly has enough challenges and interesting design to keep an avid explorer interested and should be approached as such. I am sure that when released, it should attract a number of fans of the old game who (I would have thought) will be delighted at the chance to revisit this fantasy world.

Scripting Nitty-Gritty (Party AI)

I have been busy looking at the finer details of some scripting aspects for Better The Demon and NWN2 in general. I don't know about the rest of you builders out there, but I have found a few of the functions a bit confusing as to what they actually do at times. It may be because I am trying to code from a multi-player aspect that causes some of the confusion, but here are a few I am referring to (with their descriptions rewritten by me to help explain them better for those who may also benefit from the rewording):-

GetIsOwnedByPlayer() - This returns TRUE for a player's Main PC (*) object regardless of whether the player is currently possessing it or not.
GetIsPC() - This returns TRUE on a PC or creature object if the player is possessing it at the time.
GetOwnedCharacter() - This will return the Main PC (*) of a player who is controlling the tested creature at the time. (Returns OBJECT_INVALID if creature is not being controlled.)
GetControlledCharacter() - If this is used on a PC or creature that the player can control, then it will return the object that the player is currently controlling. (Returns OBJECT_INVALID if creature is not one that can be controlled.) After more testing with this function, I am not sure I have this right even now.

(*) For those that don't know, the term Main PC (or Owned) is used to differentiate the PC that the player joins the module with as opposed to any others they may add either through party creation or as companions.

Multi-Player PC Control In A Single Party

Even with all these functions available, the confusion arose because there was a time when I needed to GET the Main PC of a creature whether it was currently possessed or not. At the time, I thought that GetOwnedCharacter() would do the trick, but this function is limited to checking when the object tested is possessed. I considered a couple of options to get around this problem, but as I also wanted to differentiate between the possibility of more than one player playing in the same party (in Single Party Mode), each one representing a Main PC, then I also needed to be able to determine which Main PC was allocated to each PC in the same party: My idea being that each player could bring along their own PCs and control them by the standard commands that can be given without affecting each others PCs. (E.g. Using the Follow Me command would make only those PCs a player currently controlled follow them and not attract another player's PCs/companions at the same time.)

In the end I wrote my own function GetMainPC(), which I now share for those who may find it of any use. For this function to work, however, it does require some extra work by the coder to ensure a variable is correctly kept up to date whenever a PC or companion joins or leaves a player's "team" within the single party. Hopefully, the following script will help explain its reason:




All this function revision was a prelude to ensuring I could give players the most flexibility when playing their PCs in a party. Whether playing SP or MP, I like to be able to give the player as much versatility with their PCs and how to control them as possible. In a MP game, however, where more than one player controls the same party (even if each player controls their own "team" within that party), extra coding is required to ensure everything plays as it should. And what if the players want to rearrange the teams?

To give players more autonomy over their selected PCs I had to edit my own companion conversation script and include within it an edited version of the #include "hench_i0_hensho" script to ensure the correct "team leader" was listened to with respect to shouted commands. It was as I was testing this and began swapping between the different PCs when I discovered the problem that companions would revert to following the original party leader rather than the team leader whenever a player changed the PC they were possessing. This problem is what led me to learn more about the possession/unpossession hooks of which I will explain in more detail next.

Possession & Unpossession

By default, the companions and the player's Main PC are assigned the same scripts. You can check this out by examining the nwn2_scriptsets.2da. Note though, the scripts do not fire for the Main PC until the player possesses another creature, so no player HB shortcut there. ;) However, this is useful information to know, and editing the nwn2_scriptsets.2da can be a very powerful tool. Add to this knowledge that you can also assign a new set of scripts to a creature using the SetCreatureScriptsToSet function and you have started along a path of interesting AI possibilities.

I mentioned all this to draw attention to the nwn2_scriptsets.2da. If you look at it closely, you will notice two scripts in particular in the ScriptUserDefine column for when a player is possessing a companion (gb_player_ud) or not (gb_comp_usrdef). And when these two scripts are used correctly, we can tell when a player has possessed or unpossessed a PC. By experimentation, I found the gb_comp_usrdef fires when a player unpossesses a PC and the gb_player_ud fires when a player possesses a PC. If you remember this, you can use OBJECT_SELF in each script for the creature it refers to.

E.g. If a player changes possession from their Main PC to a companion called Fred, then gb_comp_usrdef fires on the Main PC and any reference to OBJECT_SELF within it is to the Main PC and gb_player_ud fires on Fred, and OBJECT_SELF within this script will refer to Fred. (NB: I have found that you can refer to both possessed and unpossessed PCs just from the gb_comp_usrdef at the time of unpossession by using GetFirstPC(FALSE) to get the newly controlled PC within the gb_comp_usrdef script. However, I am not sure how reliable this will be, as it may be affected by timing. I tried the same thing by using GetControlledCharacter(OBJECT_SELF), which you would have thought did a similar thing and it only worked sometimes.)

Practical Uses

For me, this newly discovered knowledge will serve me in a couple of ways. (I say will, as I still have to make use of it in some of the things I mention next.) Firstly, it will allow me to quickly change the player who is controlling a PC. For instance, I can now easily change the object variable representing the player who now possesses a PC. i.e. The moment a player switches to another PC, this player will now be the one whose commands the PC will respond to. Currently, the player controls this by a conversation with the PC. Secondly, and for me a performance saver, I can use these scripts to determine if the Main PC Menu (GUI) requires its data updating for viewing a different PC. Previously, I was relying on a function's internal heartbeat to keep checking the PC state while the GUI was open. Now, the same function no longer has to loop through itself making the check, as the hook is now intercepted with this new possession/unpossession function discovery.

Auto-Pause Added Toggle

On a final note related to nwn2_scriptsets.2da, I updated the Main PC Menu to have a toggle switch that allowes the game to auto-pause when a PC is attacked. This works in tandem with the Auto-Pause (Turn-Based Combat Simulator) facility, in that when it is triggered it turns the Auto-Pause facility on at the same time. NB: If players don't want this facility, then it need never be toggled on and is off by default. If, however, they turn it on and then decide they do not want the Auto-Pause facility turned on for the remaining combat, then they can simply switch it off with the new feat that every PC acquires. Below is a screenshot showing the location of the switch:

Multi-Player Considerations (Cutscenes)

Coding for multi-player is definitely a pain. You may recall my experiences in my last post on the matter. It has been a while since then, but once again its complications have returned in the form of interactive cutscenes. Hopefully, my own testings will be if use to others who may be considering MP coding.

I started to write a cutscene conversation for a side-quest (at last!) and wondered what would happen if one player should activate a cutscene in one area, while another player was in a different area (and the conversation was set to multi-player cutscene in its properties). Thankfully, (and it may have been obvious to some), testing showed the cutscene does not fire for those in a different area to where the cutscene takes place. This means it is possible for one player to see a cutscene that other players will have to learn about afterwards. Thankfully (at least for my purposes), the journal does update for all players. The point is, I like the idea that one player may witness something another may not, simply because the were elsewhere at the time. E.g. One player is buying equipment at a store, while another player stumbles into a cutscene as they were making their way to another location.

In fact, there were only a couple of minor difficulties that I have encountered when coding for multi-player gaming at the moment:

Don't 'Follow My Leader' Question

First, any companions (or extra PCs added to the game at party creation time) always follow the leader of the party between area changes even if it was a non-leader player who had originally asked the companion to join the party. In other words, if Player A had asked companion Janice to join the party, and Player B had asked Frank to join the party, then both Janice and Frank would leave the area with the leader (Player A in this case), if Player A moved to a different area to Player B.

As I say, it is a minor issue, and I have already written some code that prevents this when jumping players within the same area. So, maybe I can adapt this code to do the same thing for between areas. I mention it, just in case anybody knows a quick and easy way around the problem. I can tell you that it is not as simple as removing the tick from the Party Transition box, as this simply prevents any other players from jumping at the same time as the exiting player, but does not prevent all companions following them.

At the moment, the simplest workaround is for the players to change leadership between the players involved if one of them wanted to take the group to a different area. However, this still operates as an all or nothing affair at the moment and I would be interested if this can be coded for, without resorting to allowing more than one party in the module. I know the situation where the likelihood of such splits in the group is highly unlikely, but I would like to know if it is even possible. If it not possible, then I will simply ensure the situation where a split is required does not rely on an area change over. ;)

Cutscene Camera Question

The second minor issue occurred when I ended a multi-player cutscene conversation for all players. After choosing "Goodbye" and ending the cutscene, the player making the conversation choices has a "clean ending" and the camera returns to a pleasant viewing angle. However, (in my own testing), as the conversation comes to an end for the second player who is viewing the conversation, the camera suddenly jumps above their head looking down. Again, it is a minor nuisance, but is one that I hoped someone else may have encountered and know how to "fix".

Fixing The Small Things

Not too much to report this week. I managed to get through most of the outstanding crafting points I wanted to get done this week (all but completing the second tome) and managed to fix a couple of other things along the way: (1) Alignment issues of companions when the player might perform an act opposite to their own ideology; (2) Stolen Goods text colour when the player had the chance to rename their items.

I know I have said it before, but I really am closer to getting into writing the plot now, and I hope I can start doing so with more frequency in the coming weeks. In fact, I can only foresee one more mechanics issue that may take some of my time, and that relates to the mapping system.

A Trip To Queensdown Warren

On a personal note, my wife and I took a trip out last Sunday to a local warren close to where we live, called Queensdown Warren. The weather was definitely on the plus side for the time of year and the bluebells were in full bloom, allowing me the chance to take some photos with the new digital camera we bought last year. The photo to the left is of a tree I thought was quite interesting, as it appeared to have a face in it that reminded me of the classic Treants of fantasy.

If you like to see some of the other shots I took (and even get to see what my wife and I look like), then feel free to check out the slide show at this link, which also shows off the bluebells. Unfortunately, a few of the shots are more blurry than I would have liked, but at least I am getting the practice now. :)