Alternative Lock Picking

I have had a little time to look at Kamal's latest module, "Crimmor" in the last week. Kamal never ceases to amaze me with his excellent area designs - and this time, I was also intrigued to see a new lock picking system in his work, courtesy of RWS. (And while I have not had as much time to actually play his module, first impressions look good.)

Followers of this blog will know how much I enjoy implementing mini-games for the player, and I already have a number of lock designs that the player can look forward to. However, inspired by the latest design I found in Kamal's module, I set about looking at adding another lock mini-game to my own module. To this end, I looked again at a released work by Little Baron. I had looked at Little Baron's work a while ago, but recognised it needed some script rewrites to work within my own module design, especially multiplayer gaming. However, inspired by what I had seen in Kamal's module, I decided to go ahead and adapt Little Baron's "Lock picking" system to work with my own. (I have not implemented the trap system at this stage, as I am not sure I will.)

Some of the changes are fairly simple, in that only PCs with any points in the Lock Pick skill can attempt to pick the lock. I have also changed much of the way the system works with reference to results that can occur. In my own system, here are some differences:-

1) Lock DC's altered to fit with my on system values.
2) Lock difficulty alters chance of pick breakage compared to quality of picks used.
3) No "special" picks means additional chance of DC increase on worked lock.
4) Permanent fail simply means a revert to the normal NWN2 lock pick system. (No jam.)

Not all doors and locks will use the system, only some. Those that do use the system offer the PC with the ability a slight advantage in that they can attempt to pick locks normally slightly higher than their ability. Of course, if they fail badly at the mini-game, then the lock reverts to a standard NWN2 lock pick requirement.

Gameplay: A lock can have 2, 4 or 8 barrels, each requiring 1-3 successful "picks" to disable. The higher the lock DC, the more barrels there are, and the more likely each barrel requires more clicks to disable. Therefore, the lowest DC locks will require at least 2 successful "picks" in sequence, whereas the most difficult locks, with the highest DCs, can require up to 24 successful sequential "picks".

Check out the screenshots below for what it looks like in game:

Feedback welcome.

This PC does not have any ability to pick the lock.

This PC has the skill and starts the lock pick. Note all the extra in game feedback.

If the PC fails by a large margin, then the lock will reset and the sequence has to be restarted.

Each barrel (this one has two) requires 1-3 pick attempts (3 in this case) to be successfully unlocked.

Bashing Objects

Just a quick post this week, as I have had to sort out a few personal issues, which have taken some of my time and energy. Just to say that I have been continuing to write for conversations and quests when I can, but coding in this area is progressing slightly slower than hoped. I was held up for a short while when I discovered an issue when I made my PC bash an object. The screen froze for about a second before continuing. I had not been expecting that to happen, and it diverted what attention I had on conversations to sorting this problem out.

I had not noticed the problem when bashing an object before, and so wondered if it was due to me creating a large number of items on the object at time of being destroyed. (Treasure! - Yes, large treasures might happen!) Doing a few debug checks (complicated a little by the fact that I have coded hardness factors for objects), and rewriting the function didn't resolve the issue. However, when I tested the code in a different area, it worked fine. So, I broke the code down to fire bit by bit, and eventually discovered the problem occurred on a large area with many objects; I was closing in on the problem. Eventually, I tracked it down to a loop call that was not "breaking" out of itself when an object was beyond a certain distance from the destroyed object. So, in large areas, the loop was processing a lot of objects ... and, hence, being frozen "in thought" for a brief moment.

A very simple addition of a break in the code had me up and running once detected. Now, I need to get back to writing the conversations and quests .... :)