Monday, 24 June 2013

Lights, Camera, Action!

In 5 ... 4... 3 ... 2 ... 1 ... You're on!

I thought I would refocus the area of module development I am currently working on, and decided to start looking at some of the cutscenes I wanted to include. (Hopefully, that will be the only pun I use in this post.) As I have said in the past, my ability with cutscenes comes in a close second to area design when it comes to implementing them (i.e. poorly), but I appreciate the benefits they add. And as NWN2 has "camera objects" to help out the builder, I felt obligated to give it a go.

The Light Problem

One of the first problems I encountered was the "light object tag" problem. I have encountered this before, but during some cutscene testing, this problem raised its ugly head again: A "light object" can lose its tag in certain situations, normally on a reload or (as I recently discovered) when travelling between modules. So, basically, if you have any scripts that rely on acquiring a light object by its "tag", there are circumstances when the tag no longer exists and the light object is not "returned", even though it still exists in the area/module.

My solution was to apply a search for all light objects (that I might later need to reference) at the start of the game, and add a local variable to them which I could search for instead. Add to that a change in the way I searched for lights, using GetNearestObject for a LIGHT object rather than by its tag, and I believe I have now fixed all light references in my modules.

Setting The Camera

Once the lighting was sorted and in place, and knowing the scene I intended could now actually be seen in the right light, I worked on placing the cameras, which I decided would be called from a conversation. After all, I have found that using cameras via conversation to be a straightforward operation. However, what was not so easy, was having the conversation (with the camera views) start at the moment I needed it to, to allow the cutscene to work as I intended. There were added complications about what the player was doing when the cutscene was to play. I was designing some to start on an unusual encounter scene, and others if the PC triggered certain events. Having the cutscene start and allow the events to continue to act out as I intended required careful timing, which required experimentation to figure out. There was also the lowered "sound" issue one experiences when a PC is having a conversation. i.e. I have some effects that play sounds as they occur, which work fine outside of a conversation, but you can hardly hear the sounds when inside the conversation. I overcame this problem by adding some sound objects independent of the effect to play as required.

And Onto The Action!

Finally, after the experimentation and tweaking, I have ended up with some cutscene template scripts that cover most (if not all), of the situations where I hope to give the player the occasional cutscene moment. I am glad that it is something I managed to resolve in the end, because the final results are encouraging, and I hope are something that will help add towards the players enjoyment of the experience. It's true these scenes may come as their PCs are about to meet a grisly end, but that's action for you!

Cut! OK, that's a wrap!

Thursday, 6 June 2013

In Game Help & Information

Things have settled down again here now, and I have had a little time and energy to attend to this blog ... which also means I have a little more information about the module. I have decided that some of my in-game interfaces may need more information for the player when encountered for the first time. Therefore, to this end, I decided to put together a single "Help and Information" script that is called from clicking on a button that these interfaces may have.

I have not yet decided on all the gaming elements that will include this system, but the way I am implementing it is very simple and flexible enough to include for any of those that beta-testers feel require a little more information for usage. A few lines of code can simply be added to each XML script that requires the extra button to link to the "help box", which in turn feeds the relevant help text to the new box that clicking the button brings up, all from a single script. Below is an example of the kind of thing I mean - this is an example of somebody reading about interacting with a "Combination Lock" for the first time:

Hovering over buttons brings basic information.
The player requires some extra information about potential interaction and so clicks the option.
The player can scroll to read all the extra information available.
From my own experience, I have found that some games do not give enough "instructions" for my liking and having a quick discrete button to additional information and help seemed to be the best solution as far as I could see.

I continue to chip away at the final stages to this module ...