Choose Your Language

Saturday 30 January 2010

Interfering M.E.

My apologies for a late and an even more sparse update than usual this week. I have had to spend what computer time I have had on collating evidence for a report for a medical appeal regarding my condition of M.E. Any time I spend using a computer I have to judge carefully so I do not overdo it and exacerbate my condition. Having to compile a couple of reports meant no time left for any real modding this week.

The little I did manage to do involved adding a couple of lines to the "NPC seating" code so that they no longer move or get bumped out of position when spoken to (thanks to Eguintir and Shaughn for that) and editing a few more spells to work with my new crafting system. (See last week's comments for the functions involved.)

I did manage to do a little of Misery Stone at the start of the week, but this too has been placed on hold until I have more time. From my initial impression, it was a superbly designed game with respect to its area designs and had some excellent atmosphere. However, I cannot agree with most current voters of 10 because of one or two other aspects that do not match up. Don't get me wrong, it's not bad at all, but does fall short of "masterpiece" because of them. Perhaps it is just me being extra picky, but I must stick to the same standards as I have judged others, or else it would be unfair on them. I will leave my final comments until I have finished the game and vote on the Vault.

Subject to how much more report collating I have to do and tests I have to have carried out, I may or may not get the chance to do anything new on the mod for a little while. Don't worry, I am continuing, but I have to pace myself between what I need to do and what I am able to do.

Saturday 23 January 2010

Please Take A Seat

I was back at designing some "simple" ambient background this week and thought I would have a few NPCs sit around the tavern. So, knowing the ActionSit function that I have used before, I thought it would be a simple task to implement. Wrong! If you are a builder, then the chances are you already knew this, but I did not and am not always up to date with some of the hangover functions from NWN1 that do not work with NWN2. Animations had a overhaul in NWN2 and so I should not have been surprised when it failed to work. I suppose I just hoped it would be one of those functions that would somehow still tie into the code and do the job.

In the end, I searched the Vault and found a couple of entries that covered seating characters in NWN2. One was KEMO Custom Chairs, which is an outstanding piece of code, but I believe too complicated to use unless you want "sitting" to be quite a high priority in your module. However, Patcha's more basic piece of code, To sit on objects (v1.76), came with only one basic script that handles the sitting, which was far more easy to incorporate into my own module. There were one or two anomalies that I would have preferred to have working with the script, such as NPCs getting up if knocked into, but I am not sure if it is possible because of the way NWN now handles animations. I am continuing to investigate this, but you can see the results already in this shot:

Misery Stone

I have also just downloaded Misery Stone by jclef. I probably don't need to promote the quality and high standards we already know of jclef and BouncyRock Entertainment, so let's just say I am convinced you will enjoy it, even though I have not yet had the chance to start it myself. I have that privilege in the next few days hopefully. :)

Freedom Poll


The poll with respect to "How Much Freedom Do You Really Want" has come to an end and it looks to me that the majority of players (29/38) are still prepared to be responsible for their own actions in the game, even if it means they might "blow it" through miscalculated play. That serves as a comfort to a degree, because it supports my own style of play and, by default, design. I was still surprised, however, that of the 29, there were 15 who were what I would consider "ultra" responsible and ready to take the blame for any "mistake" they made even if it meant ending the game for them. This was even more die hard than I like to play.

At the other end of the spectrum for style of play, came the remaining 9 voters who prefer a style similar to the official campaign, or, for 1 voter, would like the game to guide them even more so. For those players, I hope my own design preference (minimal help) does not exclude them, because of the design parameters I have implemented that allows a player to finish a quest even if they make mistakes - unless, of course, they really bodge things up by ignoring all the warnings and indications of what may happen if they continued along their current path. That said, I have also made the decision that the main quest cannot be broken, even if a player does make it "difficult" for themselves.

Thursday 14 January 2010

Quest Writing (Design Parameters)

After some consideration, I realise that my current "design parameters" for my module quest writing are way above any reasonable level of normal acceptance. I refer to the level of freedom I allow a player to do a quest with such parameters as (a) enabling a PC to be able to attack any NPC, (b) allow PCs to approach a problem from many angles (involving multiple NPCs), and (c) even allowing the PCs to enter a quest at a different stage. Writing for just one of these parameters is involved, and as I naively discovered, trying to accommodate for all three is simply an overwhelming problem that quickly spirals out of control.

Too Many Combinations!

This has come to light as I reach the final stages of a side quest that included every parameter listed above. Considering how long this particular quest took me to write (and that this quest is only an optional one that a player may not even play), I have decided that the designing of future quests in a similar manner (covering every angle as per my original design remit) is no longer a realistic goal.

I do not come to this decision lightly, as the end result of the quest I wrote that does have these goals included has turned out as versatile as I had hoped for. If I could have continued in this vein for every quest I wrote, then I believe the results would have been quite stimulating for the player. However, the continued effort required to achieve this kind of open-ended play is unachievable for a single developer, which I am. At least, it is if I want the module released sometime this decade.

Note: I do not intend to do away with any of these design concepts, but to avoid the kind of problem I had when writing the last quest I have simply decided to streamline the approach by aiming to use only one of these concepts (or two at the most) at any one time. And as the ability to attack an NPC cannot easily be prevented (or changed) without it feeling like I am "forcing the play", I expect any new quests I write from now on to involve fewer NPCs or limited access to the same quest instead.

To put this problem into perspective, but without going into too much detail, the last quest involved at least 4 important NPCs, 3 of which would be considered critical. (The quest itself involves even more NPCs.) Every NPC can be killed at any time by the PCs, meaning plot points had to make sense if the PCs managed to pick the plot up at a later point. Furthermore, the same quest could be accessed at 5 different nodes subject to which NPC was still alive and/or what the PC had already learned. This required an inordinate amount of variable and quest log tracking to ensure it always made sense when played. As it turned out, the nature of this particular quest forced these requirements of flexibility of design from me. However, with hindsight, there are one or two changes I would have made to reduce the amount of work, and if I had not already gone to the trouble of coding it, would have removed them from the original design.

Future Designs (Allowing NPC Deaths)

As I intend to keep the ability for the player to be able to attack any NPC at any time (and for other builders who wish to allow the same) I recommend these design structure points for writing quests:

1) Try to avoid further quest progression with the NPC quest giver, in case
the PCs kill the NPC after receiving the quest or at any stage
thereafter.

2) Ensure any other participating NPCs remain unknown (or undiscovered) until
their involvement is required, in case the PCs kill them before their
involvement in the quest.

3) Ensure to either allow the quest to be continued with the death of an NPC
(by the PC gaining information another way) or end the quest in the journal (if
for a side quest only).

4) Only allow "quest recovery" options (PCs can pick up on a quest a
different route) for the main quest only. (See next.)

UPDATE: I am looking at a system that makes NPCs permanently "friendly" (invulnerable) all the while a quest is active from (and further involves) them - and if there are no other mitigating circumstances. (I.e. If there is a way to do the same quest even when killing the NPC, then they will not be made invulnerable.) While this is a minor compromise, I believe it is justified as it allows me to concentrate more on the plot than spending too much time trying to protect against unexpected play.

Player Freedom (Poll results)

From the results of the "Player Freedom" poll to date, 28 out of 37 voters are happy with at least "minimal plot help", with half of those ready to accept "no plot help" and suffer the consequences of their actions. With this in mind, it would appear the builder does not need to be overly concerned about covering every angle of play (or a player's style of play). It also suggests the player is prepared to co-operate ("play along" with an obvious plot line) and not be upset at failing a quest if they have not done so. To put it another way, as long as the builder protects the player against "accidental" failings on their part (like destroying a critical plot item with a stray fireball), then the player is ready to accept that any antagonistic action they may take with their PC has the potential of ending the quest early (like if they killed the quest giver rather than helped them).

Therefore, rather than always allow a quest to be "recovered" if the player stumbles onto a path of the quest after having killed the quest giver (point 4 above), some quests would simply not be offered in such circumstances.

There are only 5 days left to vote in this poll if you want to have any more say.

Spell Alterations

Here is an updated list for the altered spells for Better The Demon:

- Virtue (D4 Temp HPs & longer duration.)
- Ray of Frost (D3 Damage)
- Divine Favour (Can scale to 6)
- Endure Elements (Increase Resistance To 3 Change Amount to 0)
- Summon Creatures (Duration 1 hour per level)
- Expeditious Retreat (Duration 1 minute per level)
- Magic Missile (Missiles increased to max of 10)
- Ray of Enfeeblement (Duration 1 minute per level)
- Resist Elements(Decrease Resistance To 12 Change Amount to 0)
- Ability Spells (E.g. Cat's Grace) (30 mins per level. Max 10 hours. d4+1 alter.)
- Invisibility (10 mins per level.)
- Knock (No scaling but line of sight required.)
- Animal Trance (Corrected range and caster level.)
- Barkskin (10 mins per caster level.)
- Aura of Glory (CHA from 4 to 2. Save Fear from 6 to 5.)
- Protection From Energy (Duration 10 mins per caster level. Resistance & Amount 12 x caster level.)
- Animate Dead (Permanent until destroyed. Scales with level.)
- Bestow Curse (Decreased effects to 2 as per description.)
- Magic Circle v Alignment (Changed to turns per level.)

Friday 8 January 2010

Revised Scripts

It's been another week of dealing with the scripting sides of things for Better The Demon. When this happens, I don't have much "exciting" to report, although I can say I have probably done just as much work as any other week. It's coding 'behind the scenes', which does not translate to being able to show any interesting new screenshots. One of the biggest script changes I made to the module this week was another revision of how I handle the PCs a player adds to their party, either by the party creation system or by adding companions. I won't bore you with the details, but I am hoping the revised scripts make the handling of party created PCs more accessible to the code, which means I can have easier access to them with respect to them giving comments during the game, subject to their personality.

Power Scrolls

I have also been continuing to work through the spell scripts to complement my revised crafting system that allows a PC to cast a spell according to the PC's caster level (if higher) rather than the level the scroll was created. I wanted to do this to give scrolls greater longevity and usefulness to the PC that carries them. For instance, what good is a 1st level Magic Missile scroll to a 15th level wizard who can cast them with a greater number of missiles than this version of the scroll would do? In my system, the wizard's own ability enhances the usefulness of the scroll, meaning it will cast at 15th level, even if it was originally written at a lower level. (I have now completed all spells to 2nd level. Only 7 more levels to go.)

Item Longevity

Item usefulness is another of the prime aims for this campaign. Hopefully, this will have come across to readers who are following the blog. Stores will not be inundated with dozens of items way beyond the PC's means, nor be of many variations of similar things, but will be more specific and useful to all PCs in their adventure. Putting it simply, I hope to make the player more interested in buying items from a store than as a place for selling them.

World Map

I have also been expanding the 2da encounter tables for the overland map. Like editing spell scripts, it is a slow and laborious task, and one that I hope will reap the benefits for future modules once it has been completed. After all, once all the templates have been completed, it is then a lot easier simply to edit a single 2da file to take advantage of the new scripts. Although I have shown similar screenshots to this next one, I thought I would show you another with one of the new creatures encountered (a dire badger). It's an excuse for a screen shot anyway. ;) It also demonstrates some differences to what one would normally expect when on an overland map: the travel information system (new GUI); the vigour system (in the main window), the edited overland map frame (no rest or party button), the CR encounter colour for the creatures (main window) and the new Date GUI button (opens a larger GUI) on the bottom right of the screen.


I am once again at the stage where I hope to begin writing another quest. I have already considered doing more towards the main quest now, and in theory, writing should get a little easier from here on in, which could even mean signs of slightly accelerated progress! I have covered most of the systems I wanted to incorporate, and even though at least three of these (spells, crafting tome and overland map) still require a great deal of work, they are things I can chip away at between plot writing.

PLOT PREFERENCES: Do Not Forget To Vote!

We are into the last couple of weeks for the current poll. If you have not yet voted, then I am still after your vote (and feedback?) on your gaming preferences as requested in this post.

Monday 4 January 2010

SetTag Makeover.

Just over a year ago I was pleased to announce I had worked out a rather convoluted system to allow a way of adding party members in such a way that they could still respond like companions. At the time, the problem had been not being able to easily assign a tag to the party member for accessibility when coding. However, not long ago a new function was added to the toolset to allow tags to be set on objects, and last week I decided to take advantage of the function to rewrite some of the core scripts around this part of the module. This is why this week's blog entry is both a little late and brief (as I am still making the final adjustments).

Using the new function has greatly increased the efficiency of the code. Here it is in use:

// ENSURE TAG SET CORRECTLY
string sNewTag = GetRosterNameFromObject(oPC);
SetTag(oPC, sNewTag);
This small piece of code replaces a ton of scripting simply because I no longer have to replace the original created party members with copies and thereafter ensure variables are carefully maintained if anything should happen to them. It impacts the following systems:

1) Initial setup of PCs.
2) Death and resurrection of PCs.
3) Further rostering of party members.
4) Between module transfer of PCs.

Many functions and heartbeat checks have been removed and replaced with one off scripts because of these changes, making the whole module less CPU intensive and more efficient as a whole.

PLOT PREFERENCES: Do Not Forget To Vote!

If you have not yet voted, then I am still after your vote (and feedback?) on your gaming preferences as requested in this post.