Review: Storm of Zehir

Yes, I'm a little late deliver a review, but I thought I'd offer my opinions on the expansion. I starting playing on Christmas Day and finished it off yesterday, so I'd say I got maybe 20-25 hours gameplay out of it. I've had a little bit of a look around various websites and noted there are still a few more things I could do, but it seems I've covered the majority of the game's content.

Overall the gameplay was interesting, and the mixture of exploration and building a trading empire held my attention for a while. However, the new feature of the overland map is definitely a double-edged sword. I really do like the idea, and it's very reminiscent of "Sid Meier's Pirates!", but ultimately I found it was a bit tedious. In the lower and middle levels, it either requires you to run around avoiding and encounters that you might fail to hide from, or simply battle your way through a near never-ending supply of enemies. Once you add this to the tendency of the game to force you to backtrack repeatedly across the overland map, and this happens needlessly on a few occasions due to poorly worded or outright incorrect journal entries. The exploration aspect is a nice touch, but it just felt a bit arbitrary, and all the locations or special interactions you could find ended up feeling a little shallow.

I thought the trading system to be a bit dull to be honest, as there seemed to be very little point to trading manually, with the only real benefits coming from establishing caravan routes. This added in an extra hassle on the overland map of having to protect your beleaguered caravans when one of the local monsters decided to prey on it for no apparent reason. However, one thing I was pleasantly surprised by was the means by which it both rewarded you with inordinate amounts of gold, yet required major investments in order to establish and improve it. This, in combination with the new useful crafting system and a few big ticket items in stores, meant that I was never ridiculously rich, at least not until the very end of the game. Obsidian deserve a big medal in this department for managing something that virtually all RPGs get wrong.

Atmosphere and design were a mixed bag as well. Samargol and the Temple of the World Serpent in particular were very nice, but other areas felt a bit drab and pointless. Again, I believe this is a symptom of the overland map, forcing a greater number of less interesting areas rather than fewer better developed ones. I really must commend the music score, although it felt a little bit too grandiose in the lower levels when I was fighting zombies and skeletons to a glorious crescendo. The new crypt theme and ambient hills theme are probably two of my favorite tracks, and major thematic elements of the music provides a really nice consistency throughout the game. The music tracks definitely felt more cohesive than the OC or MotB, though I confess that I greatly prefer the MotB theme to the new SoZ theme.

However, the one area where I really feel SoZ fell short is in the storytelling and roleplaying department. The story never really grabbed me, and it always felt as though I knew the direction in which it was heading. The fact that I reached its conclusion without really knowing anything more about Zehir than "he's a new deity" which I got from the developer videos hammered home this weakness. It just didn't seem as though any story had been told, nor that my characters had achieved anything particularly significant aside from setting up a thriving merchant company. After coming from the epic tale of Mask of the Betrayer, it felt like I was being given very little motivation to do anything within the game.

This lack of storytelling flowed into the roleplaying aspects of the game as well, for while there were plenty of skill checks and extra conversation options due to skills, none of them ever felt important. Many of the skills checks didn't actually have any effect on the overall outcome of a conversation, and after this happened repeatedly, it gave me the impression that they were somewhat useless and peripheral. In my opinion, not seeing any benefit from having the skill checks is worse than not having them there.

Overall, Storm of Zehir was interesting, but very much an "old school" RPG. In the days of the Gold Box games, the focus was on the mechanics, exploration and combat, and there might have been a somewhat interesting plot that accompanied those. SoZ very much fits in that category, but personally, I feel the RPG genre has evolved to something greater since that era. Don't get me wrong, I enjoyed and romanticize about the many, many hours spent playing various Gold Box games (I played through "Death Knights of Krynn" over half a dozen times), but times have changed. Mask of the Betrayer was an excellent example of the new world of RPGs, so SoZ felt like a rather large step backwards in contrast to it and Obsidian's previous releases. It's not to say that Storm of Zehir is a bad game, it just doesn't deliver what I've come to expect from the modern RPG. As a trip down nostalgia lane, it's an enjoyable romp, and it offers some nice additions for module creators, but as a contender in the modern RPG environment, it feels a little lacking.

News: Better Quest Guide available

Just a quick note to those that haven't already had a look, my guide on "Making a Better Quest" is available now from the vault.

News: Release - Making a Better Quest

Another small project I've been working on in recent times is a short tutorial and analysis of quest design. The result is a 14 page PDF called "Making a Better Quest".

Making a Better Quest is a short analysis of the components that make quests exciting and interesting for players. Drawing upon examples from many games in the broader RPG genre, the document provides writers and designers with guidelines that will help produce stronger and more engrossing quests and quest lines.

The guideline should appear on the vault before too long, and you should be able to find it here once it has been approved.

News: Release - Christmas Toy Workshop

Well, despite the toolset crash I mentioned previously, (thanks for that backup batch file, Amraphael!) and falling ill over the past couple of days, one of the things I've been working on is done and available from the vault right now.

Christmas Toy Workshop is a fun little game I developed over a few days, offering players with the ability to help produce toys for the festive season.

While working on the toy production floor, players must deliver colored toy components to the appropriate corner of the workshop and activate the production mechanism at the correct times. Of course, nothing is ever simple, and there are complications in the production: malfunctioning machines, dangerous heat ventilation and vermin invading the production floor!

I hope you'll take a look at this module and embrace the Christmas spirit!

Status: Toolset Crash

Joy of joys, I had a significant toolset crash which caused various issues today. I should have backed up this small project more regularly...

The toolset crash not only managed to destroy a dozen blueprints, but also filled four rather large scripts with absolutely nothing. Even more strangely, it reset all my toolset settings back to as if I'd just installed the game.

I've just recovered the blueprint, and now have to rewrite those scripts before I can finish with this small project - and I was just doing my final pre-release test too!

I guess patch 1.13 isn't so reliable after all... :(

News: New and Coming Work

Just a quick update to let people know that I've posted a short pdf with some area proofing tips which gives a quick list of things to check before finalising an area. While it's not a fully-fledged guide to area creation, it's intended to be a useful tool for area builders and prefab makers to use before declaring an area finished.

I thought I'd also mention I have two other small projects in the works that should be released within the next week or so... Keep an eye out for them both here and on the vault!

Design: Principles - Roleplaying (Part 2)

While I was going to respond to the comment in yesterday's post, I felt that they deserved a little more attention, so I'll expand on my thoughts here.

First of all, I probably should have been more specific in defining my boundaries of roleplaying. While I've not played Storm of Zehir, the consensus from people who have is that it's not a story-driven experience like NWN2 or Mask of the Betrayer.
Everything I've read leads me to believe that it's more of a sandbox game. Something akin to Sid Meier's "Pirates!", where there is a plot, but the world and the player's advancement and fame/wealth are the linchpins of the gameplay. That's not to say it's a worse game, it's just different.

The categories I defined were what I felt are key elements of a story-based RPG. This would have to be my favourite type of RPG, as it can make players fall in love with their character and the NPCs they travel with. That kind of emotional attachment is something that will last long after a player has finished playing, and inspires a great degree of nostalgia years later. It's the very reason so many people still feel so strongly about Baldur's Gate 1 and 2. Whether it was Minsc's antics with Boo, a cautious romance with Jaheira, the desire to hunt down Jon Irenicus or simply to bring the end of the Bhaalspawn war, there were hooks to draw the player in emotionally.

That kind of immersion and motivation is exactly what I was referring to in creating an experience for players. There should be that same attachment as when reading a book, that you don't want it to finish, that you want to be able to continue on and keep have experiences with these characters.

And that's my point about the ability to replay a good RPG. It should be like an excellent book that you want to go back and read later on, except that you know that this time you can influence the story in a different direction.

I feel I should address the issue of Planescape: Torment. It is an excellent game, but if anything, its failing is that the story is too strong, hence getting through the game again in a different method almost feels like it would be a betrayal to the essence of the story. But more accurately, much of the suspense and drive of the game comes from a desire to work out what is happening and how it can be fixed. When you've completed the game once, those two aspects are missing, which makes a repeat play that much harder, as you lack those two driving factors.

The trick is to balance the strength of the story against the strength of the characters, so that even if you know how the story unfolds, the characters of the game make the journey a fulfilling experience, even when you know all the twists and turns of the plot. That's why I could replay Baldur's Gate 1 & 2, Mass Effect, NWN2 OC and MotB (though to a lesser extent), but why I couldn't replay NWN1 or PS:T. The characters made the journey fun, even though I knew the ultimate destination.

Design: Principles - Roleplaying

In another post in the series of design principles, today I want to discuss roleplaying. I must admit, I feel in many cases this is an area that is overlooked in community modules, or at least, seems to fall short in its implementation. While I could write a lengthy essay on the subject, I'll just give a brief overview of what I believe are key elements of roleplaying.

Story
First and foremost in any RPG is the story the player is being told. If this does not grip the player and spur them to keep playing, to find out that next piece of the plot, the game is already fighting an uphill battle to maintain the player's interest. An RPG requires just as much depth in its story as a novel, if not more.

Without an exciting story, why does the player even care what happens to their chosen character? It is the story that makes the player care about their character and their choices, why it makes people develop an attachment to their gaming experience that simply does not occur in FPS or RTS games. It is the story that provides the player and their character with a motivation to play.

Motivation
The motivation of the character is a key component in defining their personality. Many players have an idea of a character in their head when they play an RPG, and the options are many and varied:
· A hero striving to destroy evil at all costs, even if it means their life.
· A lawful zealot, dispensing justice without mercy.
· A selfish scoundrel, trying to make a profit without risking their life.
· A manipulative powermonger, using deception to further their own ends.

Of course, these are just a few quick examples, and there are hundreds and thousands more options. The aim of the RPG is to provide the ability for the player to roleplay their character and its motivations, whatever they might be. Therefore, "the problem is choice".

Choice
This is a core element of roleplaying. It is choice that provides the ability to shape a character, to have an effect on those around. It is choice that means the player is not simply on a pre-defined path. The story must be flexible enough to allow the character's motivations to affect it, yet still be strong enough to keep player on a path to its conclusion. Without choice, the player may as well watching a movie or reading a book, but there cannot be so much choice that the story becomes weak or inconsistent. This balance is one of the hardest aspects of the game designer, as it means providing consequences for those choices.

Consequences
But in allowing the player to make choices, there has to be a reason for them, and more importantly, a consequence. If choices do not have ramifications, then what difference does it make if the player picks one over another? Consequences make the player think about their actions, to make them consider their decisions and to roleplay their character. Consequences reward roleplaying with a believable and engrossing experience – they provide verisimilitude.

Verisimilitude
Many RPGs are set in pre-established worlds or universes because they already contain the necessary background. More than a year of the development for BioWare's Mass Effect was spent simply creating the intellectual property to provide the setting. If a player doesn't believe the setting they are in, it breaks the immersion and this is one of the things that game designers attempt to avoid as much as possible.

Just as the player has their own personality and motivations, so do all the people in the world that they meet, and this should come through in their speech and actions. This is the means of tying together all of the above points into a cohesive package that makes a player want to keep gaming.

And that is the ultimate aim – to create an experience that the player not only does not want to put down, but to go back and experience it again after they've finished.

Design: Principles - Scaling

Following on from yesterday's post, I'm making a very important statement about a very significant topic. Be warned, this post is a little long...

Scaling
Scaling of encounters has a bad name, and I'd say that's because of one big name RPG - The Elder Scrolls: Oblivion. Oblivion was a fairly bad example of what happens if scaling is done wrong, but I believe it is possible to do some scaling and have it work.

Believe it or not, there are actually a few fights in my Fate of a City module that are scaled, and the scaling is based on the player's party size and/or character level. This was mainly because if a character reached some of those fights solo, they couldn't possibly tackle a full complement of enemies, but similarly, with a party of 3 they became fairly trivial if the combat was balanced for a solo player. So keeping this in mind, here are two simple rules to keep in mind regarding scaling in an RPG.

1) Only ever scale upwards.
2) Only scale key fights.

I'll explain why.
1) Scaling should never make encounters easier. There's nothing more ridiculous than being told how fearsome a location is only to fight that it's populated with nothing more than a few kobolds that die with a single sling bullet to the head.

People should not be rewarded for doing something that they've been warned repeatedly that they shouldn't, as that just encourages them to keep doing it, and overall the story and the setting become significantly weaker.

2) Key encounters are either fights that are with key plot figures, or fights that have to be fought and will "weaken" a character for a major fight to come.

These are the tools to make the player really feel like they are fighting a truly powerful enemy, and to make them feel like they have accomplished something when they finally defeat their opponent(s).

If the player simply waltzes through without even breaking a sweat, then the thrill of the battle and the threat of danger aren't there, which means that the game doesn't have the same level of excitement.

Oblivion got scaling wrong on both of these points. For starters, you could go pretty much anywhere you liked on the map whenever you wanted and you would generally face monsters that you had a pretty good chance of defeating. Not facing additional danger because you're going deep into the wilderness where no-one has ever been in years is bad because you exploring the unknown doesn't have the element of danger that it otherwise would. A green adventurer going deep into the highlands knows they are not going to be attacked by some minotaurs in the mountains, only a lone wolf that they can easily dispatch.

Secondly, the mid-to-late game felt ridiculous. Suddenly all bandits were wearing amazing armour worth thousands of gold pieces, Daedroth and Atronachs roamed the countryside freely, and Daedra Lords guarded every Oblivion tower. What happened to the Clannfears and all the other weaker Daedra? Even worse, where did all these people and monsters suddenly appear from? It broke the realism completely (as much as it exists in a fantasy setting), and made fights longer and more tedious by arbitrarily increasing their difficulty.

Scaling must be done for a concrete gameplay effect, but the realism of the setting must take precedence over that, meaning that there must be a cap on the scaling. Having enemies that are renowned for their weakness suddenly becoming powerful enough so that they rival the player ruins realism in a terrible fashion. Furthermore, if the heroic player can only barely defeat a group of goblins, why aren't these same goblins overrunning the cities, seeing as they typically exist in ridiculously large numbers?

In short, combat scaling should be restrained, and ideally, completely invisible to the player. If it's not, then it becomes obvious what is happening and the realism of the setting is completely broken, and overall the game is less fun for the players. And when it comes down to it, games are made for the players, so the ultimate aim is to please them.

Beta Release: PacSquire

I made a post on the NWN2 forums earlier today about a small project I started working on yesterday. It's called PacSquire, and is a little bit "different".

PacSquire is a mini-game designed to be played either single or multiplayer. The basic premise is that you must go around the playing field collecting the "Coldstones" scattered around. However, doing so is not straightforward, as the field is scattered with monsters who will try and kill you as you attempt to do so.

Each player has three lives, and being killed by the monster foes will deplete one of those lives. However, players are in competition, and if a player kills another, that does not deplete their number of lives, but it does put them out of the game for a short period of time.

I've uploaded the module to the vault, and it can be found here.. Any feedback, suggestions or bug reports would be greatly appreciated.

Design: Principles - Combat

I've said recently that I'm going to change my approach a little from Fate of a City for its currently planned sequel Fate of an Empire. Given that some people have voiced concerns about changing the formula, over my next few posts, I'm going to explain what I meant by those statements and clarify my intentions for it. Today's post is going to be on the topic of combat. Note that if you haven't finished Fate of a City, there are a few spoilers in this post.

Combat
While I said I would include more combat in a sequel, I'm not planning to go overboard. As far as I'm concerned, a role-playing game should offer role-playing. Neverwinter Nights 2 is a role-playing game, and any module that I claim is going to be a role-playing module will be just that. As Fate of an Empire is the sequel to Fate of a City I want it to contain just the same amount of role-playing, if not more.

While I have ideas for other modules that might take on different forms, I don't have plans to turn Fate of an Empire into a hack-and-slash festival. I've played quite a number of mods that have had enough hack-and-slash to make the average Diablo player happy, and while I do like Diablo, I'm not playing NWN2 module to get my Diablo fix. While I like NWN2 combat more than NWN1 combat, it's still not the reason I play the game.

I believe the main difficulty in using combat well in a module has been explained perfectly others, in that combat should be there for a reason. Now, of course, the reasons are many and varied, but I don't believe that the hero or heroes should be wading through hordes of enemies without breaking a sweat. Of course, there is an exception to this if the enemies are meant to be weak in comparison to the almighty adventurer, but then surely the sight of the adventurer might be enough to inspire terror in those same enemies?


There will be sections in Fate of an Empire that will have a level combat closer to the keep assault in Fate of a City, but that's due to two main reasons - the increased flexibility for fights in this level range, and the increased scope of the module. I'll let you know now that the beginning of the module will start off a little more combat oriented, but the roleplaying won't take a backseat in the module.

The one thing I will say is that I'll do everything I can to make combat interesting and different. I tried to do this in Fate of a City, for example the mixed enemies in the keep assault or the confrontation with Kaladyr. Another example of trying to do things differently is the fight with Sergeant Mallum and his summoned shadows at the conduit. And finally, there are fights that don't actually need to involve combat at all, like the confrontation with the Shadow Being.

I'll be aiming to deliver more variety and unique fights given the increased durability of the heroes and the broader scope of Fate of an Empire.

Status: Reviewed and Refined

Well, after a bit less than a month, reviews for Fate of a City have been coming in with mixed opinions. In general it seems that gamers want more combat than is provided and that quests have made some players feel as though they are a Fedex Warrior at times. I've taken these comments on board for any future work that I do, though I don't foresee undertaking major modifications to Fate of a City in order to meet these requirements. There are several modders and players who have helpfully identified issues with the module, and I'd like to thank everyone who provided constructive feedback.

However, I have done a significant amount of reworking and refining of the module since its initial release, having made major changes to many areas, adding in a world map and also including a grabbag of new items. Hopefully version 1.08 should prove a completely stable and enjoyable experience for all players, but I'll still be open to tweaking the module further to provide additional support to players if they wish it.

Particularly pleasing was the review from Alazander in which he gave the module some considerable praise. The focus on choice and consequence a core aim of Fate of a City, as was providing a high level of polish to give a professional feel to the adventure.

His comments on area design being a little weaker than other aspects of the module caused me to re-examine that aspect of the module a little more closely, and as a result, I made some changes to several areas of the module.


The above is the source screenshot for the original loadscreen for the rich quarter for version 1.0. While I was happy with it at the time, it does appear somewhat bare and plain upon re-examination. The subtly of differences in texturing and colouring simply do not come out as strongly in game as they do when looking at the game from a static shot in the toolset. Increasing the contrast in textures and colouring, in combination with adding to the general "clutter" of the areas has provided a much improved look for the 1.08 release.



Finally, today I added a fairly comprehensive walkthrough for the module to the module's page on the vault. In closing, if you've already played the module, I hope you'll consider playing again, and if you haven't, then go and download it now! And I hope you vote for it!

News: Halloween Module

Yes, I know, I'm way behind everyone else in advertising this on their blogs, but I thought I'd give a shout out to the NWN2 Community Halloween Module that was posted to the vault a few days back. This is a great effort by 25 builders to produce an eclectic mix of Halloween themed houses. While I've not visited all the houses yet, it has been fun so far.

I hope that people who play mine can get a bit of enjoyment out of it. It may be a little short compared to some of the contributions, but seeing as it was done from scratch in about 8 hours including bugtesting, I don't consider it too bad an effort. I had more ideas to implement if I'd had more time, but sometimes life gets in the way of modding.

In other news, I've also trying to do a bit of gaming as I wait for more reviews of Fate of a City. I may post a review or two here in the future.

Status: RELEASED!

Fate of a City has now been released and is available for download from nwvault!

I'd just like to say an extra special thanks to all those people who've given me support and comments during the development process, and all the regular visitors to my blog.

I hope that everyone enjoys playing the module!

Sneak Peek: Companion Preview 2

Previously I promised some screenshots of Veolus Wend, one of the two companions available in Fate of a City. During my current bugtesting, I thought I'd take a few screenshots and give you a taste of his appearance and personality.

If you read the description I previously gave of Veolus, you'll realise that Veolus is not one for kindness and benevolence.

However, while Veolus is ruthless, he is not entirely without emotion. There are people, places and ideals that he holds in high regard, and even his cold disposition can be softened at times.



You may get to know him much better very soon...

Status: Beta Testing!

Yes, I am testing! This fun process has already seen me squash a few minor bugs and a some more annoying ones. Given that I've done testing throughout the development, I do not foresee a prolonged final testing phase, but I'm going to make sure that the initial release is as bug free as possible!

The release date is getting closer and closer, and the Fate of a City will soon be determined...

Status: [END DIALOG] {finish the game}

Hello to all! I have finished my hiatus due to moving to the UK and am eagerly back into modding after getting a brand new computer yesterday!

The title of this post indicates a line present in a conversation that I finished today. In fact, in several different conversations. Which means I've reached an extremely exciting time - I am very, very close to a finished alpha version of Fate of a City!

There's still bits and pieces of work to do - finalising all the load screens, doing a final full playtest for balance and continuity. Then there's converting to a campaign and doing any bugfixing before packaging everything together for release.

So Fate of a City will be coming soon...

Status: Companionship

I'm not yet in the UK, but I've still got a computer at my disposal, albeit not my own. That said, I've still been able to work within the toolset in recent times, even though I can't actually run the game itself. While this is not conducive to many aspect of modding, it still enables me to do dialog and scripting, which I have been doing with great enthusiasm. Unfortunately, not being in a situation to my work illustrate with any screenshots, this post will be somewhat text-centric, but given that's been my work environment, it seems somewhat appropriate.

The bulk of work in question has been related to completing the conversations for the second companion within Fate of a City. To give you an indication of the depth and effort that has been put into these characters, I'll give some word statistics (which may scare some of you). At the current time, the current word count of the module is just shy of 140,000 words, with approximately 30,000 words dedicated to the various interjections, comments, and conversations of the two companions within Fate of a City. So while I wanted to include more party members so as to offer greater diversity and choice... I'm sure you can understand that the amount of work required to bring them to life so they wouldn't feel bland in comparison to the existing characters is no simple matter. So without further ado, here's an introduction to the second companion available within the walls of Darthall...

-----
Veolus Wend

Veolus is a priest who typically inspires very strong reactions to those that meet him, and those feelings are almost always negative, as his chosen deity is Bane. He is unyielding in his determination and ruthless in the pursuit of his goals. However, as to what they might be, Veolus is not forthcoming, as his service to the church is not a topic he cares to discuss.

Despite his faith, Veolus will ally with any who will tolerate his views, provided he thinks they are capable enough. However, if ostracised too much, Veolus would be more than happy to turn on previous friends, for any perceived enemy of the Black Hand is a target for divine retribution by his hand.
-----

Hopefully I'll add a couple of screenshots at a later date, though Veolus has already appeared in a few times in previous screenshot galleries.

This has represented a significant portion of the remaining work for Fate of a City, which means that the complete alpha version should be ready sooner rather than later. Then it comes down to testing the finished product... I only hope that phase goes as smoothly as it did for my Amstralloween contribution to BouncyRock's project! :)

Status: Out for a while

As I write this, virtually all my belongings are in boxes in transit to the UK. This also means that I'm about to depart my home in Australia to follow them, and as such, I'll be without a computer for at least the next few weeks.

However, with trusty pen, pencil and paper, I'll still be trying to get some work done on Fate of a City, in the form of writing out the conversations, scripts and perhaps jotting down a few notes to be used in the final stages of development when I manage to acquire a new system after my move.

But right now, I'm going to give a little more information about the companion influence system I've implemented in Fate of a City. Influence will be handled primarily through conversations, though there will be a few instances where your actions will directly impact upon your relationship with your companion(s). Many of the quests within the game will include conversation options that will affect your influence, and in addition, there will be other situational dialogs that will occur for a companion to provide you with some information or their opinion, which will also include the ability to gain (or lose) influence with them.


In addition, typically, just because you say one wrong thing does not mean that you will necessarily fall out of favour with a companion... though if you continue to disregard their opinion, they may not be happy about it. Of course, having (or lacking) a certain level of influence with a companion will help (or hinder) your relationship with them, so you may not wish to annoy them too much.

However, the last couple of days of modding haven't been without their annoyances. The one that's annoyed me most recently is a weird issue that I can only call a lighting issue, yet the problem persisted even when I removed all the lights from the area. Rather than try and explain the problem, I'll demonstrate through a screenshot...


This weird black area is actually a closed door, yet for some reason, it does not display nicely at all. Even more frustrating is that as soon as the door is opened, the problem goes away, and even if the door is shut again, the area is not in shadow. In addition, if I use a "see-through" door - such as a gate or portcullis, then there is no issue either. It's as though the game thinks that the southern side of the doorway (this is a N/S oriented door) is "unexplored". After several hours of fruitlessly banging my head against the toolset (and repeatedly going in game to test) in the hope of fixing the problem, I was eventually forced to rework my interior design to avoid the problem. I'd curious as to whether anyone has encountered a similar issue, or has any clue as to the cause (or even better, a solution!).

Final note/question: Does anyone have any suggestions as to where I should/shouldn't buy a computer/computer parts in the UK once I arrive?

Status: It's My Birthday (and I'll Mod If I Want To)

In celebration, I decided to give myself a bit of a break from packing my belongings into boxes today, and treat myself to some time off to work on Fate of a City. Knowing I'll be on a hiatus for a few weeks is simultaneously motivating and demotivating, as I don't want to start anything and leave it half-finished, but at the same time, I want to get as much done as possible. That brings me to the recent work I've been doing, which has been a veritable medieval merchant wagon full of dialogue, and a healthly loot-bag full of scripted sequences and cutscenes.


I've added a few new screenshots to my gallery so you can see some of the work that's been done - I just wanted to pick the shots I was most happy with up there. In addition, I don't want to give too much away of the plot just yet, especially not when I'm coming so close to finishing. My estimates tell me that I've less than 10% of work remaining, so the final stage of bringing everything together into a complete package is rapidly approaching.I'm still steering clear of a release date for the moment, simply because I don't know how long it will take to be to return to modding after I leave.

Design: A Halloween community

Many of you might be aware of Bouncyrock's Halloween community project, which is a chance for all modders to create a little house area with a Halloween theme. Working on a contribution to this project has provided me with some entertainment for the last couple of evenings. Given time constraints with my imminent move (which will leave me without a computer for a while), I had to produce something small in a relatively short time frame. What I've created is something that is a little different from the standard sort of adventure, but hopefully will provide some measure of amusement for people. Though you'll have to wait until October to get your hands on it... and I'm not going to spoil the surprise in the meantime! But I hope you enjoy my Amstralloween special.

If you're a modder and have a little time to spare, then I'd encourage you to make a contribution. Even if it's only small, I'm sure it would be appreciated.

Sneak Peek: Load Screens

Recent times have seen me going back and tweaking some existing content as a result of my previous testing, as well as working on some new creatures, areas, items and visual effects. While a frustrating toolset bug has caused some annoyances, I've been able to work around it with a judicious bit of scripting.

I've also been working on the creation of load screens for various areas, both new and old, just to add an extra touch to the aesthetic appeal while players are waiting during transitions.


I've also been creating a swag of NPCs that will both fight with and against the player, and have taken a few screenshots of the kind of action that may eventuate during 'Fate of a City'. Both the load screens and battle shots (along with numerous other screenshots) can be found in this gallery.

Design: A Prefab Sidetrack

Today is something a bit different, as I've taken a small amount of time off today and yesterday to produce a small prefab area. I've submitted it to the vault, and it can be downloaded here.


I've got a small gallery here of screenshots of the prefab, which is a 4x4 exterior called "Canyon Grove". I had the idea for it two days ago, and after sketching out a rough pencil drawing of its appearance decided that I would have to take a small break from 'Fate of a City' to produce it. (That said, I've still managed a couple of small encounters in-between small breaks on this prefab.)

I hope you like the look of it, and please, download it and take a look at it in full. I'd love to hear any comments or critique you might have about any aspect. I know that I've picked up quite a few tricks since producing my last prefab area, but I'm always open to suggestions on ways to improve.

Toolset Tidbit: Quality Assurance

I've been taking a little time out recently to do a little bit of QA testing and general tweaking of various issues. When I first started Fate of a City, my development was very much "test-as-you-go", in that I'd make changes, go in game, test them out, and then correct as necessary. Now, I've switched to a fairly solid workflow of writing out a quest or a sequence in its entirety before running a playtest, during which time I review the dialogs and scripts, then playtest numerous times trying different options and following different choices (of action and dialog). While I'm finding the latter more efficient at the current time, the former does have its uses depending on circumstances.

Testing-you-go is useful at a few times. For one, if you're doing a complicated script sequence, then it potentially can be better to break up your testing into parts and test each one individually. This is particularly good for multi-part scripts - as you can divide the script up for testing purposes, test each separate part for any bugs, and then once each component works correctly, combine the scripts together for a final test. Make sure you do that final test, as without that, you've got no guarantee you haven't got some weird dependency that can cause strange script behaviour. If you're a beginner scripter, I strongly recommend trying things repeatedly, as if you try and script everything at once and then go in for a final test, you can end up with some really strange behaviour that can be impossible to debug. I must admit, I was guilty over doing too much without scripting before testing when I first started, as coming from a programming background, I was comfortable with my logic - but that doesn't necessarily translate to the nuances of NWN scripting.

Once you're more comfortable with the toolset and scripting and you've got a comfortable workflow, you'll find that you can create rather complex sequences without getting in there and testing first, which can potentially can save you time. But again, if you're finding that something doesn't work, don't be afraid to break it down into something more simple to debug it - or alternatively ask one of the helpful people on the forums or #nwn2-cr for advice on how to fix the problem!

I will share one useful tidbit I've got into the habit of doing for making sure that conversations work properly. Firstly, in most conversations, make sure you have a specific blue node (ie PC line) with the line [End Dialog] to end conversations. The first benefit to this is that it avoids the "[Continue]" text in dialogs that will actually result in the conversation stopping. Small details like this bug me as a player, and while you might call me pedantic, there is a very good reason as a builder that I like doing this, if you'll bear with me. Most "[End Dialog]" nodes will not contain any scripted actions, and indeed I try and avoid them wherever possible - sticking actions on the previous speaker node if I can. In addition, whenever I have a node that ends the conversation, I try and link to a single "[End Dialog]" node within the conversation. All this applies to NWN1 style conversations - for NWN2 style cutscene dialogs simply have two empty nodes to mark the end of a conversation - one blue and one red. A thought I've just had now is that if you really want, you could put "{End Dialog}" as the text of the red node to indicate to you the purpose without displaying anything to the player.

Now I understand you might be asking "Why?". The answer is simple. When you've finished writing your conversation, widen your dialog window so that the "Text" column of the dialog window ends the screen. Now, if everything isn't already expanded, then hit "Expand all" button. At this point, scroll down through your dialog and look for any node that doesn't have a grey line underneath it. Any such line is a potential problem - as it indicates a conversation end. Virtually every line should have a grey line underneath it, either linking to another conversation node, or the "[End Dialog]" node that you created earlier. Obviously there will be some exceptions, for example, if the player ends the dialog e.g. a blue node labelled "Goodbye.", or perhaps a dialog node that results in some other unusual action occuring - e.g. an area transition, the NPC attacking, some type of scripting sequence, etc, etc.

This technique makes debugging conversations far quicker at a cursory level, and avoids any missing links in complex, branching conversations that can easily get out of hand for builders. While it won't solve all your problems, it's definitely something I've found useful.

That aside, I've been working on quality assurance in the graphical/aesthetic department as well, tweaking lighting, texturing, sounds and general decor just to make sure that the atmosphere and visual appearance is achieving the effects that I was originally trying for i.e. - what I have written down in my design document! To that end, I've created another swag of screenshots for people's perusal just to give a big more of an indication of the minor tweaks that I've been working on.


Some of the differences might be minor, and of course, the sound modifications can't be conveyed via screenshots, but rest assured that the variable rain is accompanied by appropriate sounds. Now, if only there was some way to modify exterior lighting via scripting...


Of course, no testing is without annoyances... One such annoyance is using the MotB rest system - in that I've copied the scripts over from MotB for the major module events, yet when I rest in my module, I still get two messages sent to the player indicating the rest has been started and canceled when the rest window pops up. If anyone has experienced the same behaviour (or even if they haven't!), then I'd love to hear from you. I really would, and doubly so if you have an idea of what's going on! :-)

Sneak Peek: Companion Preview

I know I made a post just yesterday, but I thought I'd make another post to cover one of the companions in 'Fate of a City', as well as to provide some rough information about interacting with the companions. This is because recently, I've been doing a lot of work on the various aspects of dialog for one of the companions, whose name is Kyandra.

-----
Kyandra Daarzir

Kyandra is a brave and fearsome warrior who learned her trade while traveling in merchant wagons around Sembia, Cormyr and beyond. Though circumstances have currently brought her to Darthall, she is not overly fond of the city, and would prefer to not be confined by its walls.


Kyandra has a good heart, and is a stalwart companion to those she trusts, but she is not regarded fondly by many in the town. Kyandra's prowess in battle is great, and when she chooses to wield an axe against a foe they have a right to fear her.

-----

Now, I also said above that I'd cover interacting with companions in 'Fate of a City'. For starters, the companions are very pro-active within the party. They will have something to say in many conversations, whether giving their opinion on the actions the player or others, or to mention something relevant that they know. In addition, at certain times and places, both companions will initiate conversations about various events, locations or people, not to mention that they may be interested in finding out about you.

How you react in these situations will have an effect on the character's opinion of you, and you may well find that they react differently to you depending on how you've treated them or other people in the past. If you keep pushing their patience too far, you might find that their opinion of you drops considerably. That might be something to keep in mind before you choose to repeatedly malign their opinions or ignore their requests. But, you may also find that you can develop a closer relationship with them if you so desire.

Of course, you can also choose to initiate dialog with them to ask them a few different things, and again, they will react different based upon various circumstances, including how much the companion likes the player and also any quests the player might currently have.

And finally, if you decide you don't like the companions, you can always tell them that you don't want their help or company. Though even the most stalwart adventurer may want a friend to help them when danger could be lurking around any corner in the city...

(PS If you read my status update yesterday, it may have changed a little depending on how early you saw it.)

Status: Fate of a Release Date

The first thing you may notice about this post is the new design of the site. I felt as though some tweaks to the appearance of the blog were long overdue, and while I could quite easily spend a long time tweaking the presentation of the site, I just wanted to make a few small facelifts. I'd love to know whether you like the new look.

In development news, I have been making significant progress on multiple fronts, and I'm now approximately 80% complete in the module. The strands of the plot are starting to tie together for the finale, and it's quite exciting to see the form of the module taking a shape verging on its final form.

However, despite the progress I've been making, my real life commitments are peaking, and my move to the UK is looming ever closer, meaning the amount of free time I have to mod is diminishing. This is in addition to needing to really push through and do some more voice-over recordings for Melirinda's module "A DeathStalker", where I'll be playing the role of Saemon Havarian.

As a result, my desire to release by September will probably go unfulfilled; it must follow the fate of all release dates and suffer a delay. Instead, my loose release date is now "November". While I know this is somewhat vague, it should give some indication of when I think all development and testing will be completed. I'd love to release earlier, but I want to make sure that I release a high quality, bug-free module that will be an intense and fulfilling roleplaying experience. I want to make sure that when you sit down to play 'Fate of a City', you'll get to play a module that you won't forget anytime soon.

So rest assured that I'll post updates when I can, and I'll be working away on adding to the adventure within Darthall whenever I have a spare moment.

Status: Word spaceflight

The Federation Aeronautique Internationale defines 100,000 metres as the altitude at which spaceflight begins. If each word in my module is worth one metre, I am officially in space. Yes, what I am saying is that I recently hit 100,000 words total in my module (and that doesn't include my design document!), which I'm somewhat pleased about. While it may be an arbitrary number, and quality is more important than quality, it's nice to reach a milestone like that which gives a large round figure to point at.

In celebration, I've decided to post 10 more screenshots for your perusal to give an indication of some of the things I've been working on lately. While I can't go into much detail about the locations depicted here, the mood for these is definitely a lot darker and more foreboding than some of the previous areas I've shown. For all adventures come with danger and grave adversity, and your experiences in Darthall will be no different.

Status: Close Encounters Of The Toolset Kind

Today I'd like to espouse the magical powers of backups. If you don't backup. Start. Right now. Keep several copies of your mod in various places on your hard drive and make sure you have a stable version somewhere at all times. I had two areas go corrupt on me at the same time, for no apparent reason that I could determine.

The result was very strange, as the module would load up perfectly in the toolset, and exhibit zero problems while working on it. But as soon as I attempted to enter one of these areas, the game would crash. What's more, it would cause every subsequent attempt to run to the mod to crash as well. Attempting to remain calm, I mustered what sanity I had left, copied data from a previous backup into a new directory, copied the clean updated files from my working copy to that new directory, and then proceeded to test. A couple of hours later, I was happy that everything was back to normal and I indeed had not lost the entirety of Fate of a City.

That scary encounter aside, things have been quite busy, but I've managed to work a bit more, having finished and carried out playtesting on what is probably the game's largest side quest, clocking in at over 7500 words and 19 possible journal entries, including a few alternate solutions. I performed virtually all the development before testing, and was encouraged to find that it only took a few hours of playtesting to iron out all the bugs. (Or at least all the ones I could find!) I've also worked on and finished another area and a couple of cutscene sequences, which have turned out quite well.

It also appears that custom music is a popular choice according to my poll, so despite the two people who think my music sucks (and I'll love to hear alternate musical suggestions or what you don't like about the tracks), I'll be implementing a number of custom music tracks within Fate of a City. Currently, the music consists of six tracks for a total of 14 minutes music, and hopefully I'll be able to add to that before release.

So, having taken the plunge to include a hakpak, I thought I may as well go the extra mile again, and include custom load screens to add another extra touch. After a lengthy period of producing different load screens with little success (see the unsuccessful and successful ones here), Elharc (from the #NWN2CR irc channel) finally provided me with that nice grey stone border that you can see underneath the rather lacklustre spears in this picture. After giving it a few adjustments, I managed to produce the final loading screen and the border will be the template surrounding all the load screens within Fate of a City. The picture below is for the Rich Quarter of Darthall.

Toolset Tidbit: PC-Less Screenshots

It's time for few more screenshots today, most of which are showing off a new area I finished this evening. While many of the areas haven't been the most well-to-do of locations thus far, the house interior that features in four of these screenshots is most definitely home to some wealthy people.

You'll also note that in a couple of screenshots, I have no player visible, as in this screenshot below!

I am sure some of you may have known how to do this already, but I only discovered how to do it today. Even better is that it is really simple! All you need is a single line script to accomplish it:

SetCreatureAppearanceType(GetFirstPC(), APPEARANCE_TYPE_INVISIBLE_HUMAN_MALE);

You can also make it so you can toggle the invisible state on and off, but this plays havoc with the PC's movement rate for some reason, so I'd advise against it.

I named my script a very descriptive "z_hide". All I need to do to use it, is to go into the game, bring up the console with the ~ key, type in "debugmode 1" (without quotes) to enable debugmode (amazing, huh?). This lets you run scripts by using "rs ". So simply typing "rs z_hide" will allow me to make the PC invisible and take screenshots freely!

I imagine this would work beautifully for taking screenshots for custom load screens...

Also if you haven't already done so - check out the trailer in my previous post, and vote in my poll!

Status: Productivity Streak

I'm back and working on the module in full swing again, after a couple of weeks (mostly) away due to work. But since returning to the module in full force, things have been quite productive! I've finished off four more areas, and have mostly completed four quests, added in a handful of items and creatures, and done some general all-round improvements. My progress tracking tells me that I'm approximately 60% complete, which means I'm (almost) hitting the home stretch.

To celebrate returning to the working on Fate of a City again, I decided to make a little teaser trailer for everyone out there, just to give you a bit more of a feel for the atmosphere and appeal of Darthall. So, here it is!



You can also hear snippets from three music tracks that I've produced, which may yet make it into Fate of a City. Which is why I'm asking in my latest poll, would you like custom music in Fate of a City? This is steering away from my original "no hak pak" policy that I'd established when I first envisaged the module, but from what I've seen on the forums, people are somewhat tired of the default music that comes with the game, and also have no issues in using hak paks. I'm here to please and entertain, so let me know your opinion!

Scripting: Roster Companions and Sitting NPCs

I know I said I wasn't going to be working on Fate of a City for two weeks, but I've managed to steal some time in my hectic schedule (no, it's not a holiday, unfortunately) to work on a few things, from tweaks and bugfixes to NPC verisimilitude.

Little things being the operative word here, but I must admit, I do get a small of a kick out making those little touches that add a little bit of extra class. To that end, I've done some minor fiddling with the visual effects editor, which although didn't result in massive production, it has at least made one encounter a little bit nicer.

Two bugfixes were in regards to the handling of roster companions. In numerous generic scripts I've written, it is only the main PC who should be affected or interact with a specific object. I discovered that my previous solution to this problem was actually a little flaky, and unfortunately I was forced to resort to using GetFirstPC(), which basically ends any notion I had of trying to support cooperative multiplayer in Fate of a City.

The second bugfix, and this is rather a big flaw, I feel, is that the default ga_take_item does not function as it should when the item is in a rostered companion's inventory - namely gc_check_item return true, yet ga_take_item will not remove the object! Obviously, this is very significant if you have rostered companions, so I coded up a replacement version to deal with that instead.

// ga_take_item
/*
    This takes an item from a player
        sItemTag    = This is the string name of the item's tag
        nQuantity   = The number of items (default is 1). -1 is all of the Player's items of that tag.
        bAllPartyMembers     = If set to 1 it gives the item to all PCs in party (MP only)
*/
// FAB 9/30
// MDiekmann 4/9/07 -- using GetFirst and NextFactionMember() instead of GetFirst and NextPC(), changed nAllPCs to bAllPartyMembers
// AmstradHero 22/06/08 -- Recoded it to go through Roster members instead of faction members

#include "nw_i0_plot"

void main(string sItemTag, int nQuantity, int bAllPartyMembers)
{

    int nTotalItem;
    object oPC = (GetPCSpeaker()==OBJECT_INVALID?OBJECT_SELF:GetPCSpeaker());
 object oTarg;
    object oItem;       // Items in inventory

    if ( nQuantity == 0 ) nQuantity = 1;

    if ( bAllPartyMembers == 0 )
    {
        if ( nQuantity < 0 )    // Destroy all instances of the item
        {
            nTotalItem = GetNumItems( oPC,sItemTag );
            TakeNumItems( oPC,sItemTag,nTotalItem );
        }
        else
        {
            TakeNumItems( oPC,sItemTag,nQuantity );
        }
    }
    else    // For companions
    {
  string sTarg = GetFirstRosterMember();
        while ( sTarg != "" )
        {
   oTarg = GetObjectFromRosterName(sTarg);
   if ( nQuantity < 0 )    // Destroy all instances of the item
            {
                nTotalItem = GetNumItems( oTarg,sItemTag );
                TakeNumItems( oTarg,sItemTag,nTotalItem );
            }
            else
            {
                TakeNumItems( oTarg,sItemTag,nQuantity );
            }
   sTarg = GetNextRosterMember();
        }
    }

}

Note that I've removed the GetFirst/NextFactionMember calls entirely, so this will probably only function correctly if you have rostered companions only. I haven't experimented with all the different methods of adding people to your party, so I can't really comment further. All I know is that this is working for me.

I finally decided to bite the bullet and fiddle with making sitting NPC function in a reasonable manner, which took a bit of effort as I tweaked various things. I realise a lot of people have probably already implemented a similar system, but I thought I'd present mine here. The first was producing a heartbeat script for NPCs to have them sit and then randomly talk occasionally while staying seated.

//b_hb_sit
//Heartbeat script for creatures to simulate sitting and talking occasionally

//Function used to delay the playing of the sitidle animation to avoid "skipping"
void delayIdle()
{
 PlayCustomAnimation(OBJECT_SELF, "sitidle", TRUE, 1.0);
}


void main()
{
 //Determine if I want to sit randomly or if I want to talk
 int nAnim = d2();
 if (nAnim == 1)
 {
  PlayCustomAnimation(OBJECT_SELF, "sitidle", TRUE, 1.0);
 }
 else
 {
  //I'm not idling - grab a different animation
  //These animations last for 5.33 seconds, hence the delay command to switch it to idle once they're done
  nAnim = d3();
  switch (nAnim)
  {
   case 1: 
    PlayCustomAnimation(OBJECT_SELF, "sitfidget", FALSE, 1.0);
    DelayCommand(5.33, delayIdle());
   break;
    
   case 2:
    PlayCustomAnimation(OBJECT_SELF, "sittalk01", FALSE, 1.0);
    DelayCommand(5.33, delayIdle());
   break;
    
   case 3:
    PlayCustomAnimation(OBJECT_SELF, "sittalk02", FALSE, 1.0);
    DelayCommand(5.33, delayIdle());
   break;
  }
  
 }
}

The delay function is necessary because you can't use DelayCommand() directly on PlayCustomAnimation(), and you want to make sure that you play "sitidle" immediately after any other sit animation finishes because otherwise the NPC may decide to stand up "in" their seat, which looks weird. You also can't loop the other commands because then you get a jump as it switches between them. I also steered away from the "sitdrink" and "siteat" animations because it looks a little silly when people are drink or eating without anything in their hand. If anyone has a good solution to this, I'd love to hear about it.

The second issue was making it so that anyone sitting down would not turn to face the PC when clicked on, which typically makes their legs or some other part of their body magically pass through the seat they are sitting on. To solve this problem, all that is needed is a simple one line script added as an action to each start node of their conversation. (I'm only using barkstrings, but it should work for larger conversations too because I set bLockOrientation to TRUE.)

//ga_stay_face
//Makes an NPC stay facing the same direction rather than turning to face the PC
void main()
{
 SetFacing(GetFacing(OBJECT_SELF), TRUE);
}

So with those two scripts, voila! People will happily sit down, occasionally animating to talk to the person opposite, and will not turn to face the player for a conversation.

All that you need to do is to create a seat placeable, make sure it is not static and doesn't have dynamic collisions, and then place the person "inside" the seat. Basically the torso of the character will not move forward from where you place them in the toolset, only their legs will move forward when they go into a sitting pose. Also, if you're using benches (as is often the cases with taverns), you may need to create a walkmesh cutter to prevent PCs from walking through it - or just place more people on the bench! :-) Also make sure that you set your NPC's bump state to un-bumpable.

I'd like to thank weby and GrinningFool from the NWN2 IRC chat server for their help and input on the various issues I was having with some of the scripts I've mentioned.

Finally, congratulations to all the winners of the AME Golden Dragon Awards! They were all well-deserved accolades.

Status Update 13-Jun: More Screenshots

The next couple of weeks will see me with little time to work on 'Fate of a City', so I've decided to post a quick update on my recent progress. This update includes another bunch of screenshots, which can all be found here.

As for recent progress, I've developed quite a few areas (some of which are visible in the posted screenshots), and a substantial amount of dialog. I've also been taking the time to add some extra polish to previously done work (see my previous post :-) )

Throughout all of this, I've made certain that there are plentiful opportunities to use the various skills available, and you can be assured that conversation skills will come in handy. I've also tweaked the city itself, so that it is a vibrant and dynamic environment. The townsfolk wander about, entering and leaving areas in a way that feels realistic, and the weather ranges from fine to raining with moderate force.

The mod currently sits at 65000 words and 40 areas, and is approximately 50% complete. A recent playtest I did took about an hour and a half, and I covered less than half of the current content I have implemented. As such, I've readjusted my stats on the sidebar of my blog to indicate that the size of the module will probably be about 4-8 hours long, and will enable the PC to reach up to level 7. A low level adventure doesn't have to be about killing rats and beetles, and you'll be swept up into a dangerous plot of death and deceit as soon as you start.

Design: Plan and Prepare to Re-Imagine

One vital tool that any builder has in their arsenal is a good design document. I could go into a large amount of detail on how I've gone about making my design documents for 'Fate Of A City', but that would be an entire post, if not more. (If people are interested, let me know, and I'll cover it in future!) Instead, I'd like to focus on a little thing I've been covering lately, which is 're-imagining'.

Every builder has gone through the process of making an area/character/conversation/cutscene in line with their idea/design document/auguries of fate/pick your inspiration of choice, and finished it with a sense of joy and achievement. Often, the builder is then likely to leave it alone and not touch it again until they are ready to bug test/release their module. Especially in a work/professional environment, this is necessary in order to meet deadlines. However, where possible, I would strongly encourage people to go back and look at previously completed work a month or two later, and re-imagine and refine that work (making sure to keep its scope the same).

There are numerous reasons why. From a bug testing point of view, you've got the exact nuances of the work out of your head, which will sometimes result in you doing things in a fashion you hadn't thought of during the creation process - and help you identify a bug or inconsistency. I've picked up a few such inconsistencies or conversation flow anomalies in a couple of side quests by going back and checking them over the past week.

The second major reason to revisit is to help improve overall coherence. Part of the work I've been doing lately has been improving my introductory sequence. I've seen many good books on game design or writing suggest that you do the introduction last! While this might seems strange, just for starters, it means that you don't spend all your time on this segment of the game and hence let the rest of the game suffer. It also means there is a clear idea of where the story is headed, hence giving you the best opportunity for throwing in bits of information or ties to the main sequence of the greater plot. Mask of the Betrayer and Mass Effect do this very well. In the introductory sequences of both, there are key points of the plot that you are exposed to (I won't go into details to avoid potential spoilers) that you don't realise are significant until quite a bit later.

Lastly, revisiting allows you to take advantage of any improvements in your knowledge or work processes that you hadn't come across when you were developing it the first time around. I know I've been finding quite a few things lately that have allowed me to improve little things in my module, whether it be changing the appearance of tiles (yes, I know that sounds hideously basic, but I'd manage to miss how to include variations!), scripted waypoints, playing with weather and sounds via scripts, or whatever new trick you've just discovered. Or you could have just got better at area design. For example, take my redesign of my fountain in the rich quarter, which went from its old, original, and somewhat stale design below...


To the new...


Ignoring the obvious considerations of camera position and lighting, the latter has significantly more aesthetic appeal. The first consisted of two placeables, some water, reeds and rocks (not visible in that screenshot), whereas the second includes terrain, placeables, water, grass, tinting, and visual effects. Yes, the second involves significantly more effort, but I didn't necessarily have the skill to do it the first time around. (Or at least, I wouldn't have been able to do it as well!)

So in closing, don't be afraid to revisit and re-imagine. You'll likely be pleased you did, and so will your players!

Scripting: Learning to Love the Locals

Time for another couple of scripting tidbits today, but covering something that is an important and extremely useful aspect of scripting and blueprints - Local Variables. I see lots of script examples where values are hardcoded into the script. While this is functional, it is something that I try to avoid, because generally, with a little bit of extra effort, such scripts can be turned into gems that can be reused and save hours of production time.

One great example that ships with the game (and most people would be familiar with) is the SpeakTrigger. Simply paint the trigger, edit the variables to set the correct NPC to speak, whether it's a cutscene, whether they talk immediately or if they have to run to you first, whether it's a one shot or able to be used multiple times, and you're done. You don't have to open up the script and save a new copy each time you want a speak trigger.

It's significantly easier to enter in these variables rather than recoding the script everytime - have you delved inside the gtr_speak_node and the call it makes? Recoding that everytime you wanted a different speak trigger would be fraught with danger (you could break the script by typing in the wrong place) not to mention inefficient. Each separate speak trigger would have its own script that the NWN2 engine would have to load up (small processing overhead) and store (small storage overhead). Sure, a few fractions of a second or kilobytes here or there don't seem like much, they add up. But enough harping on about how great local variables are - let's get on to some examples of WHY!

I've got another example that I created for my module that enables the use of skills in an "invisible" fashion. What I wanted was a trigger blueprint that would do a skill DC check on the PC the first time the PC enters the trigger. I want to be able to specify the following things:
* The DC to check against
* The skill that is being test
* A script to run upon "success"
* Whether the script is run when I succeed the check, or when I fail the check

So my blueprint looks like this:



Now, while I'm espousing the qualities of local variable to cut down on scripting, you'll notice that I've I'm running another script when the test "succeeds". So you might argue I'm not saving much in terms of scripting, but the bonus is that I don't have to duplicate my skill dc check code everytime I want a new skill dc trigger.

Basically, I yanked the code from the gc_skill_dc script and modified for use on a trigger. The code looks like so:

// tr_en_skill_dc
/*
 NOTE: You *MUST* use a unique tag for every object that uses this script.
 Will do a skill DC test for the PC *ONCE ONLY*
 The parameters below should be set as the variables of the object.
 If the check succedes, the script will execute the script specified by the "script" variable on the object.
 
 ALTERNATIVELY:
 It is possible to set "nFailCheck" to 1, and then the script will execute if the PC FAILS the check

 Multiplayer note: It also may be desirable to give the option to only fire once - ie destroy self afterwards.
 
 Parameters:
  int nDC   = dc check value 
  int nSkill  = skill int to check
  string script = script to run upon "success"
  int nFailCheck = whether to run the check on passing or failing the check
       0 = run the script if the check succeeds (default)
       1 = run the script if the check fails

 Remarks:
  skill ints
  0 APPRAISE
  1 BLUFF
  2 CONCENTRATION
  3 CRAFT ALCHEMY
  4 CRAFT ARMOR
  5 CRAFT WEAPON
  6 DIPLOMACY
  7 DISABLE DEVICE
  8 DISCIPLINE
  9 HEAL
  10 HIDE
  11 INTIMIDATE
  12 LISTEN
  13 LORE
  14 MOVE SILENTLY
  15 OPEN LOCK
  16 PARRY
  17 PERFORM
  18 RIDE
  19 SEARCH
  20 CRAFT TRAP
  21 SLEIGHT OF HAND
  22 SPELL CRAFT
  23 SPOT
  24 SURVIVAL
  25 TAUNT
  26 TUMBLE
  27 USE MAGIC DEVICE
*/ 
// BMA-OEI 9/02/05
//AmstradHero - 16/05/08 : Modified to deal with multiple PCs and companions

#include "ginc_param_const"

void main()
{
 object oPC = GetEnteringObject();
 if(!GetIsPC(oPC))
        return;
  
 int nDC = GetLocalInt(OBJECT_SELF, "nDC");
 int nSkillVal = GetSkillConstant(GetLocalInt(OBJECT_SELF, "nSkill"));
  
 object oOwner; 
 if (GetIsOwnedByPlayer(oPC))
 {
  oOwner = GetControlledCharacter(oPC);
 }
 else
 {
  oOwner = oPC;
 }
  
    int nDoOnce = GetLocalInt(oOwner, "DO_ONCE" + ObjectToString(OBJECT_SELF)); // a unique do-once
    if(nDoOnce == 1)
        return;
    SetLocalInt(oOwner, "DO_ONCE" + ObjectToString(OBJECT_SELF), 1);
 SetLocalObject(OBJECT_SELF, "oActivator", oOwner);
 
 if (GetIsSkillSuccessful(oPC, nSkillVal, nDC) == TRUE)
 {
  if (GetLocalInt(OBJECT_SELF, "nFailCheck") != 1)
  {
   string script = GetLocalString(OBJECT_SELF, "script");
   ExecuteScript(script, OBJECT_SELF);
  }
 }
 else
 {
  if (GetLocalInt(OBJECT_SELF, "nFailCheck") == 1)
  {
   string script = GetLocalString(OBJECT_SELF, "script");
   ExecuteScript(script, OBJECT_SELF);
  }
 }
}

I've included all the comments from the original script with a few additions - that way I can easily open up the script to remind me which value corresponds to which skill. Also, please note the point at the top where it says every trigger must have a unique tag - if you don't, then running over one tag will result in another tag not reacting the first time you run over it.

Two interesting things from this script. Firstly, it only operates on a party leader, and only takes their skill into consideration. That's what the oOwner logic is doing - making sure that any companion is ignored for the purposes of the skill check. It wouldn't be too hard to add in another local variable that would allow you to take advantage of companion skills as well, and then add the appropriate logic in for that. (If anyone is particularly interested in this script, I could code up and post a modified version that would allow just that.)

The second is that you'll also note that I've got a SetLocalObject call that stores the PC (oOwner) as an object on the trigger. This is to allow future access of the PC (if required) for any script that is activated by this trigger.

With those things in mind, using this trigger is practically complete. All you need to do is paint the trigger, fill in the relevant variables and then code up the secondary script. I've found it a useful way to code up little encounters and skill checks.

If you want something a little more specific, then I made a modified version of the above that performs a "tracking" test on the PC, and can get the PC to comment based on whether they have succeed the check or not.

// tr_en_track
/*
 Description:
  
 Modified version of tr_en_skill_rank.
 Checks search and Survival to determine success and displays floating text on success.

 NOTE: You *MUST* use a unique tag for every object that uses this script.
 Will do a skill rank test for the PC *ONCE ONLY*
 The parameters below should be set as the variables of the object.
 If the check succedes, the script will execute the script specified by the "script" variable on the object.

 Multiplayer note: It also may be desirable to give the option to only fire once - ie destroy self afterwards.
 
 Parameters:
  int nRank  = minimum rank to return TRUE
  string sText = text to display as floating yellow text if check is successful
  string sFail = text to display (if any) upon failure
  int xpReward = amount of XP to give to the player as a reward for succeeding the check
    
  Checks Search and Survival to determine success
  
*/ 
//AmstradHero - 16/05/08 : Modified to cope with multiple PCs and companions

#include "ginc_param_const"

void main()
{
 object oPC = GetEnteringObject();
 if(!GetIsPC(oPC))
        return;
   
 int nRank = GetLocalInt(OBJECT_SELF, "nRank");  

 object oOwner;
 if (GetIsOwnedByPlayer(oPC))
 {
  oOwner = GetControlledCharacter(oPC);
 }
 else
 {
  oOwner = oPC;
 }
  
    int nDoOnce = GetLocalInt(oOwner, "DO_ONCE" + ObjectToString(OBJECT_SELF)); // a unique do-once
    if(nDoOnce == 1)
        return;
    SetLocalInt(oOwner, "DO_ONCE" + ObjectToString(OBJECT_SELF), 1);
  
 if ( (GetSkillRank(19, oOwner) >= nRank) || (GetSkillRank(24, oOwner) >= nRank) )
 {
  string sText = GetLocalString(OBJECT_SELF, "sText");
  AssignCommand(oOwner, SpeakString(sText));
  GiveXPToCreature(oPC, GetLocalInt(OBJECT_SELF, "xpReward"));
 }
 else
 {
  string sText = GetLocalString(OBJECT_SELF, "sFail");
  if (sText != "")
  {
   AssignCommand(oOwner, SpeakString(sText));
  }
 }
}

All you need to do is create a new trigger blueprint, add in the relevant variables to the blueprint (I'd suggest adding a default XP reward value on the blueprint), then attach the script. These are fairly simple scripting examples, but they're useful tools for providing some extra skill checks into a module. Players like their skills and choices to have an effect, so make life easier for yourself by using little scripts like these to make using them a simple affair!

Status Update 27-May: Lipflappers and Crafting

Things have been moderately productive since the last update, but I don't have many more fancy screenshots to show for it. I've been working on fixing up some of the conversations through the module, as well as adding in quite a few more. Unfortunately, posting screenshots of these would most likely give away some fairly significant plot points... but rest assured that I'll post more as I'm going along.

One of the major causes of extra work has been my discovery of Rogue Dao Studio's lipflappers. While I had heard of it previously, I'd never known where to find it or what it did or how much effort was required to implement it. For those who know, feel free to skip the rest of this paragraph, for those who don't, it provides lip movement for character during conversations. All you need is to copy it to your working module directory (you ARE building in directory mode, right??!?) and then you simply use the name of the "sound" files (minus the .wav) under the node tab on each speaker's node in a conversation. All you need to do is adjust the number to equal the length of seconds the speaker talks for. With those easy steps, your woes about characters with non-moving lips disappear! It's a Godsend and it makes cutscene style conversations look much better. I can't recommend it highly enough.

The rather inconclusive poll results regarding crafting made me decide not to implement my own custom crafting system within 'Fate Of A City'. However, I was pleasantly surprised to find that implementation of the OC's crafting system is as simple as adding in the necessary ingredients, workbenches and tools. As such, the OC style crafting will be available to those that wish to use it. While in a low-powered adventure you may feel like picking a crafting skill is underpowered, but I'll try and add in a few extra bits and pieces that give an added incentive to those that chose to spend their precious points on those skills.

For some quick statistics: the module is currently sitting at 31 areas, 54500 words, 83 scripts, and 92 conversations. And there's still plenty more to come.

Status Update 18-May: Screenshot Bonanza

Yes, I know, there aren't any screenshots visible in this post. But rather than posting the occasional screenshot here in the blog, I've been saving up some over a few days to post them in one big group. This way, I can include a link to a screenshot gallery so that people can view them all eighteen of them in one place. Also, if you've got an opinion on me posting one or two screenshots here occasionally or saving them up for a post like this, I'd like to hear it!

If you flick through those screenshots, you'll notice a new party member by the name Veolus Wend. Veolus is a rather poor tempered individual that very rarely receives a favourable reception from others, but he does not endear himself to others. Veolus is a hard man with very little time for others, for his prime concern is himself.

I also hope that the dialog screenshots give you a good indication of the quality of the dialog you can expect (and I hope you like what you see!). Not only are options and outcomes dependent on your abilities and skills, but expect to be able to choose from a variety of different answers. Your answers will have consequences, whether it is the immediate consequence of an alignment change, an NPC reacting less favourably, or even more far-reaching than that...

Also, I'm interested to know whether people are interested in having crafting implemented in the module. I'm still debating this decision myself, though I'm leaning towards trying to implement the OC/MotB system so as to provide players with a familiar experience and to limit the amount of additional effort required - adding in a whole new crafting system isn't exactly a small undertaking. So please, vote away on my latest poll and comment freely!

NB. Yes, I know I wrote "particular" instead of "particularly" in the middle poll option. I've made a mental note to pay more attention when I'm creating polls, as it's not possible to change them after the first vote! :-(

Design: Area Texturing and Colouring

Today I'd like to discuss my approach to texturing and colouring of landscapes. I developed this technique while working on my Highlands area for the Obsidian Exterior Area Competition, but I've since refined it. Specifically I'm going to focus on mountains and hills, but the techniques can be applied more or less to most landscapes. I'm going to be explaining it with a step-by-step illustration using the northern edge of the slums area for 'Fate Of A City'.

I like a blended look, so I very rarely try to lay down a 100% texture on top of my base. Firstly, this helps provide a more constant look throughout the area, and secondly, the blending gives the texture a little added depth. There are some circumstances where you will want to use a 100% brush - for example, if one of the finer dirt textures is your base texture and you are making a cliff, the dirt texture looks a little strange as an underlay on the rock. I suppose for a more general rule, if there is a disparity between the size in terms of individual visible elements of the texture, it is more likely that you will want to use a 100% brush.

For this area, I have Dirt_05 as my main texture, and I've laid down some small swabs of Grass_23 and Rocky_03 over the landscape to start with, as they are my primary textures for this area. You can see the starting point in the screenshot below. Note that all the development screenshots have been taken from within the toolset and you can click on the screenshots for a larger image.


Use a fine brush for this initial step - I like to use the small brush or perhaps up to a 1-4 (1 inner, 4 outer) brush. Map out all the areas which you want to be strongly textured and lay this down. You may only dab a dot or two in some spots, but that's fine for now. The aim for this step is to lay down your promiment cliff faces with your cliff texture. I used Cliff_02 and 75% opcacity for this first step below.


Next, drop the opacity of that texture by 15-30%. (I originally used 15%, but I've found that larger percentages work just as well, if not better). Consider using 25%-30% if you used a 100% brush to start with. Use a brush in the range 1-3 to 1-5, and trace around the edge of all the edges you just painted. You'll also want to extend it at points, for where you still want that texture applied, but at lesser intensity. For example, if the cliff is not as sheer, extend it further than the edges of your higher brush. For my screenshot below, I used 50% opacity.


Then, we do the same again. Drop the opacity another 15%-30% (again, depending on your initial starting opacity) and you should be at most around the 40% mark, and using a brush in the 1-4 to 1-7 range. Again, trace the edges of your previous texturing, and extend a bit further where necessary. This is typically a reasonable level to end your texture blending. Note that the toolset results never look the same as the in game results (at least as far as I'm concerned they don't), so you may want another SMALL blend at around the 20% mark - though often it's not necessary because now it's time to colour. Typically the toolset blending appears less smooth than in the game itself. Additionally, the colouring we'll do later on means that any sharp differences will be less noticeable. The screenshot below is the final use of Cliff_02, this time at 25% opacity.


The next step is to lay down what I call the "buffer" texture. This is generally something that provides a contrast from your base texture, and is used to separate the cliff texture and the grass texture. You want to use an opacity in the range 30%-50%, and a brush since around 1-3 to 1-6. I must admint, I generally use 1-4 as my "workhorse" brush. Here, I've used Rocky_03, and a 35% opacity.


The final texture step is to use your grass texture, putting it down in most of the flatter areas that haven't yet been touched by another texture. Of course, you won't want to apply it everywhere, unless you're going for the appearance of grassy hills. Having an occasional slope with a generous helping of grass is nice as well, just as something to break up the landscape and make it a little more interesting. For my screenshot below, I've used Grass_23 at 40% opacity.


I can't emphasise how important colouring is. It brings an ordinary landscape to life. The first thing to do is to drop the opacity right down. Generally I find I don't want any more than 20% for normal work, and typically stick at about 10%. 1-4 is my staple brush as it provides a smoothed effect that avoids deep texture colour on a single vertex at smaller brush sizes. I find anything smaller can very easily make sharp edges that look very unappealing.

I'll only cover two colouring steps here, because although you can use further colouring afterwards to add more depth if you want, these two steps are sufficient for a nice effect. The first is the blending of the "buffer" texture. Basically the trick is to pick a dark, semi-satured brown (something that is almost in-between the last two series of browns in the colour picker) and paint around the edges of your buffer texture. The trick is to do it erratically, going in and out of the edge into the grass or the rock. It is also nice to apply it to some of the grass or rock areas as well, notice the cliff in the centre of the image that I've coloured heavily to get a dirty looking rock face.


The second colouring step is to weather it using a colourless tint. I find that using 100% black has less desirable results than using something around an 80% grey. This steps is a bit more haphazard and artistic. It's a matter of colouring some things that are exposed, as well as some of the deeper gullies, and random patches about the landscape. There's no real hard and fast rule for this final step, except for making sure that you don't have large patches with even application of colouring.


Of course, it would be remiss of me to have done all this work without actually showing you what it looks like in-game...


While it's only visible as the background, (and the foreground is by no means anywhere near completed) it gives an impressive vista to peer at from the edges of the map.


I hope this has been interesting to see my approach to area texturing, and that you've picked up a few tips and tricks that you find useful!