231 replies to this topic

[Tchos]

I think in my readme file for this module, I'll include a brief statement that my stance for the module is that characters' speech or actions are expressions of their foundational philosophical or ethical outlooks (represented by their alignments), and not a means of changing them. As an example, in one conversation, there is an option to make an overt threat toward a clerk. Unless the character is of evil alignment and has a certain rank in the Intimidate skill, s/he will not even see the option to make that threat. In similar fashion, there are certain very polite options that only a diplomatic character can choose, and others that only a character with certain task-relevant abilities can choose. In general, these special choices result in something different happening. Sometimes permanent consequences, sometimes just a different timbre to the conversation.

In other matters, I've heard that a common feature of NWN1 was that doors that were not meant to be opened would say that the door is barred from the other side, and cannot be broken down. I hadn't experienced this myself, since I've only played the NWN1 OC's academy prelude and several premium modules, where I don't recall that happening.

I mention this because I've put in a door that's barred and barricaded from the other side. But it really is. It's not just another way of saying there's nothing on the other side. You'll be able to go around to the other side, clear the barricade, and unbar the door so that you can leave through it, after you've gone the long way around defeating the enemies who barred and barricaded it specifically to make the area more strategically defensible against invaders.



This is the more or less completed level 1 of the lighthouse, without any enemies showing.

[Tchos]

I had some predictable trouble with the walkmesh when it came time to bake again after placing all the decorations and furniture, and bizarrely it kept making the entire central tile unwalkable even when I had changed everything around it to environmental objects, when it had baked all right before. The worst part was that the tile's corner was right over the stairwell's door, making it impossible to go upstairs (though I could possibly get around that if I could trigger a conversation with the door from a distance). I was thinking that it was a matter of there being too many objects in a small space for the baking not to freak out, and I began to wonder if this was a possible reason for the OC interiors being so colossal, aside from the tiles being twice the size of a normal D&D grid tile.

However, I plowed ahead and laid out walkmesh cutters for some of the furniture surrounding the central stairwell, and to my surprise, it baked nicely! I laid down some more cutters, and soon enough had the whole thing baked functionally. There were still some messy walkmesh spots that I had to leave alone because when I tried to cut them out, they caused another whole-tile loss, but they're past a wall and won't affect anything.

This was the second time I've used an object with dynamic collision, and it was for the barricades this time. It took a couple of tries to get the settings right, but now you can bash them and get through to unbar the door.



I used a trigger to determine whether you were on the right side of the door to do it. If you're on the far side, it just tells you that you can't unbar the door from that side, and once you get to the other side, it gives you the option to do it (both via conversation). While setting that up, I followed an include of one of the ga_ scripts, and found that there are some very handy and useful functions in ginc_param_const.

I checked the 2DA entries for the BCK placeables I used for my walls, and confirmed that none of the BCK wall pieces are set to fade. I changed the setting for the piece I used to construct the partitions, and checked to see how that would affect my area. Now the upper half of the interior partition walls fade to transparent if the camera goes behind them. The panel I use to line the edges at the top does not currently fade. I'm inclined to leave it that way, if it won't be too distracting.

[Tchos]

So, the big news is that it's not July anymore, and this is still not released. I'll explain why I thought it would be enough time, and why I think it wasn't.

I thought it would, primarily because my Dragon Age: Origins module didn't take this long, and I was learning everything from scratch there. I thought this would be much faster having had that experience.

As for why it wasn't, there are many reasons. One is that I scaled up far too much. Last year's project Trouble In Rainesfere had only a single quest, with 4 or 5 stages depending on what you count, with only two questgivers (one was just a breadcrumb to the main one). I had wanted to add a side quest, but I didn't have time. There were a total of 6 NPCs, not counting the enemies. There were no special items, and no interactive placeables unless you count doors. There was a total of 2 exteriors, though one of them was very large and had several distinct sub-zones. There were 3 interiors in total. There was only 1 custom placeable, and that was an autumn-foliage tree. What little scripting I had was very crude and rudimentary, and the less said about it the better.

So, I scaled up, and I think I've increased the size and complexity of all of those bullet points by around 10x, but did not allocate 10x the time.

Another reason is that I didn't follow my production plan. I started out by roughing things out with the goal of getting everything functioning before making another pass for detail. I did that pretty much just with the main quest, but then I started focusing on detail with everything else. I also didn't fully polish the main quest before going and adding in the side quests. I had several side quests that I wanted to include without question, and didn't consider them optional, despite my original plans to drop side quests as necessary to finish quickly.

I also abandoned my plans to use ready-to-go prefabs for most of the locations. I couldn't help altering the prefabs I used, sometimes to the point where I might as well have done it from scratch, and so I ended up making a lot of them from scratch.

As mentioned before, the decision to have internal shops instead of open-air markets was a large time sink, though it was necessary for the atmosphere I had in mind, and my plans for shop-specific quests and recruitable companion locations.

Probably the biggest reason for taking so long is the struggle between two of my own dicta: One says "Make do with what you have, and release sooner than later. It's better to release something that can be played, rather than risking trailing off into abandonment." The other says "What you make should be a model of what you want to see. What you include should be fully realised. What you cut should be cut entirely. Cut content can find a new home in another module, but not if a pale shadow of what it could have been has already been released." These rules conflict, but at the beginning I had both of them in mind. Inasmuch as I follow the rules, I think the second one is more important to me.

This actually sounds a bit like a "project post-mortem" as is the fashion to call them, though I dislike that term, because I consider the release of a project to be the beginning, and not the end of its life. It's premature for a post-mortem at any rate, unless you consider it a post-mortem of the release date. If this were a television show, though, would this be the point at which the show jumped the shark, or when it grew the beard?

The updates will continue, until this is released. I could set another deadline. Should I? I know some people would like to have one to watch. I think given what I have remaining to do, and how long the existing work has taken, I can estimate a tight deadline or a generous deadline, but both of them would be earlier than the current Torchlight 2 estimated release date.

In the meantime, more work.

One of the doors was misbehaving. Specifically the stairwell door. You couldn't click on most of it. It could easily be mistaken for a static door. I thought it was due to the walkmesh, but it was well within the edge of the walkable area. The wall that surrounded it was environmental, as well. There was another door behind it, that was set to static. I tried moving the primary door further and further out, until finally I just moved it out to the centre of the room to see if it could be clicked at all, and also placed a brand new door from the blueprints in the spot where it should go. I also deleted the static door. This time both doors worked fine. I deleted the old door, and replaced the static door with a door-shaped placeable, because I noticed in the barred-door example, the engine seems to put priority on highlighting a door, even if it's behind a usable placeable. The current situation is now functional.

One thing I consider important to implement here is different levels of preparedness on the part of the enemies. The pen & paper modules I've read often outline several possible ways that the players might assault a particular fortified location, and chances for enemies inside being in one location or another depending on circumstances. I like that sort of thing, and I'm putting it in.

In the case of the lighthouse, they will never be completely unprepared, because they have a lookout, and it would be impossible to miss the approach of a ship, which is the only way to arrive. However, it will be possible to get from the boat to the lighthouse without them knowing. It is possible to either announce your arrival and attempt to parley (the quest provides several approaches for dealing with the situation), attempt to sneak inside using a stealthy character (who has a chance of leading the others in without being noticed), or of course, to make a frontal assault. Some of these situations will be dealt with on the approach, and other checks are made upon opening a door and making a choice.

Ideally, I would also have liked to include the possibility of having a character scale the wall and enter through an upper window, which would require them to fight that room's inhabitants alone (assuming the room is occupied) before throwing down a rope to let the others climb up. It could be done, and I think it would be nice to have, but it's an extra I think I'll do without here.

[Tchos]

I wrote a little gc_ script just to check a dialogue owner's tag. Another simple thing that seems like it should have been in the toolset already. I did it so I could use a generic conversation script for all my townsfolk's one-liner barks, but have specific lines for specific NPCs by just adding a node in the generic conversation instead of making a separate conversation file. It works similarly to what Lugaid of the Red Stripes achieves brilliantly in that generic conversation script, though in this case I'm trading convenience for elegance. This kind of check would likely be impractical for large quantities of unique barks, since it would become a very inefficient long list of "if" filters, whereas Lugaid's narrows things down from broad to narrow, eliminating many checks each time. I could emulate some of that by using a separate conversation file for each general region if I wanted to, but I don't expect to use this conversation much, and this is mainly just a quickie solution until I get a chance to sit down and really examine Lugaid's script.

The SoZ campaign already had the opposite script to the one I wrote, gc_speaker_tag, which instead checks the tag of the PC speaker. That's useful for SoZ companion conversations (the companions that I supply for the player to recruit), to give any of those companions their own special lines in dialogue without having to do compound checks to rule out the other party members.

As the pirate crew is largely made up of ogres, I wanted them to be a bit differentiated, but the included resources are very limited for providing that differentiation. However, there are two resources I've found that would serve that purpose. One is Avlis 2 Dynamic Lizard, Ogre, Pixie, and the other is Evil Edison's Hill Giants.

The Hill Giants pack provides several very different heads, and seems to use the ogre skeleton and animation, so they should pass for ogres, but they were designed to be hill giants. Other modders have used them as hill giants, and perhaps some have also used them as ogres, but I don't want to dilute their recognisability as hill giants by using them for something else, regardless of their skeletons, because as much as I want diversity within a monster species, I also want diversity of monster species.

The Avlis 2 dynamic ogres offer a wide range of armour parts and tintability, as well as numerous different heads. The head differences are distinct, though they may not be as noticeable as I'd like when viewed from an exploration mode distance, or when viewed outside of a group.

In a comment, I saw that Shaughn did the work that I would have done with that pack (which in its original form puts the extra ogre options in a playable race), and also offered that content openly for other builders, so I'll open up the Risen Hero campaign and see what I need to extract to implement the dynamic ogres.

Edited by Tchos, 02 August 2012 - 10:27 PM.

[Tchos]

It took a couple of hours to figure out which files I needed, and which I didn't, to get the customisable ogres into my module. I narrowed it down to 118 armour pieces, 10 textures, 70 body parts, 9 heads, and 1 line in the appearance.2da. It probably could have been done without changing the 2da if the parts were renamed to be appended to the vanilla resources, but either the Avlis 2 team or Shaughn chose to make a separate ogre appearance rather than edit the existing one, and it works, so I just left it that way.

After looking through what's available here, I must say it seems more extensive than I had previously surmised, and I'm quite happy with it. Some of the heads should be noticeably different than the others even at a distance, especially the female ones. Yes, this includes female ogres! The bodies are the same as the male ones, but the heads at least show a distinct morphology. Scaling and colouration could also be used to create a dimorphism as is commonly seen in real-life biology. I don't know if there's any established precedent for size and colouration of female ogres in the D&D lore, though.

They all include optional facial hair, which in most cases are beards (for the males), and in the rest of the cases are a pair of deadlocks framing the face. The only thing missing is separately tintable hair. The skin tint affects the hair as well as the skin.

With all the tintable armour pieces and armour types, I don't think there's any more danger of fighting an army of ogre clones!

This amount of variation also bodes very well for a second module that I've been mulling over to follow some time after this one, which would heavily involve monster races as NPCs.

I spent several more hours creating blueprints for various classes of ogre, using these variations and armour pieces. I have the custom monster blueprint sets made by Storyteller, but his pack that included ogres had only one ogre variant -- probably because of the lack of customisation options in the model. So I made my own set, in the spirit of those made by Storyteller for other monsters. I started with barbarians, and made three variations on ogre barbarians conforming to the stats outlined for ogres with 4 barbarian levels in the Monster Manual.

Then I tested them out with my level 10 party of 5 for the module. Unfortunately, ogres (even CR 7 ogre barbarian-4s) are more or less trivial cannon fodder for a level 10 party of 5. I started by fighting the recommend 4 ogres at once, and I barely had a scratch on me at the end of it. They seem to go down with 3 or 4 good hits.

I tried again after placing twice as many of them in the lighthouse, and this time I did end up losing about half of my HP on my two tank characters, with the rest of my party being pretty much untouched. I'm not sure about this. I may have to lower the recommended player level to level 8 or so, and maybe suggest (but not enforce) keeping the party size at 4 members. I do all my testing on the hardest difficulty, using characters who have level-appropriate gear, and I want it to be at least reasonably difficult at that setting.

Whilst doing this testing, I found a bug that would have been terrible if I hadn't caught it here and now. It was possible to cast spells at the enemies on the other side of a wall in the lighthouse. I checked the 2DA, and confirmed that all of the wall pieces were set to block line of sight, but the wooden beams and posts were not. So I set the posts to block line of sight in the 2DA, and it functioned properly on the second test.



Due to the no-ceiling build of this area, though, the player can see what enemies are lying in wait for them, when they shouldn't be able to. I'll use a trigger to make them visible only once the players have gotten within at least another room's distance, in a way that won't put stealthy characters at a disadvantage.

Then I went through the SoZ and MotB folders to collect any useful scripts I might find there. I had collected some other resources from SoZ, and the campaign mod scripts, but not the generic scripts. And it was also interesting to go through the ones that I couldn't directly use, because you never know where you might find some function or routine similar to what you wanted to accomplish for a quest.

Next I made a couple of ogre shaman healers. I don't have any staves long enough for them to hold them 2-handed, though. Any suggestions?



Here's the current lineup. We have 3 barbarians, 2 shamans, and the bosses First Mate Scoursinge of the Fifty Lashes and Bosun Fiercejaw the Shrill. Ideally, Scoursinge would wield a whip, but since those don't exist in NWN2, I gave him a flail as the nearest available approximation.

Next I need to design some ogre rogues and fighters, and I think that's all I need as far as ogres go. Better grab your ogre-slaying knife! It's got a +9 against ogres!

Edited by Tchos, 03 August 2012 - 10:28 PM.

[Tchos]

It was a P&P session day, but I got some work done anyway.

I designed a warpriest of Vaprak after reading of this god worshiped by ogres, and what their priests wear.

Next I set about writing a script that I had been putting off, which is kind of a cutscene script, except I'm doing it in the manner as is done in Valve games. I find Valve's approach to cutscenes to be the most appealing, as they have them in the Portal games, the Half-Life 2 games, and the Left 4 Dead games -- the approach is to not take control away from the player in order to show a movie. This is important to me. Instead, the scene occurs in the world in realtime, and the player can choose to either watch just as passively as s/he would in a normal cutscene, or walk around and choose different vantage points at leisure, perhaps RPing actual participation, or even leaving if preferred. It's strange to me that in role-playing games, arguably the genre of game most concerned with player agency, choice, and control, so many of them nevertheless frequently remove that control in the name of narrative, turning the player into a passive observer. It was especially bizarre in things like the NWN2 OC, where cutscenes would often show scenes that happen nowhere near the player, in secret, and in so doing they separate the player from the character, and reveal information that the PC should not know.

I prefer Valve's approach much more. The information you obtain is only information that is revealed in your direct presence, and you are never separated from your PC, nor is your control taken away unless the character itself is physically incapacitated in some way. I understand Skyrim takes an approach like this, though I haven't played it. As I've expressed before, I dislike that the majority of games have instead taken the path away from player agency toward passive entertainment, like movies, to relay certain information. That's why I'm relaying all information in other ways.

So, knowing what I wanted to accomplish, the task became to determine how to accomplish it. I first looked at the built-in scripts for scripted waypoints. While partially illuminating for other purposes, I decided they weren't very well-suited to this particular task.

I also looked into commands like AssignCutsceneActionToObject() and AssignCommand(), and all the commands that begin with the word "Action", because my understanding is that those commands are put into an NPC's action queue to be executed one at a time, as they are completed, rather than all at once as quickly as possible.

So I made a script that gets fired after closing the conversation with the player after completing a quest. I started by just writing comment lines of what things I wanted to happen, in the correct order, and then I set about looking for the right commands to make those happen. I filled out the script with a list of action commands to carry out, with walking, animation, spoken lines, emotes, and a special effect, and finally updating the journal after it was complete. These generally worked, though I needed to adjust the timing a couple of times with ActionWait(), and certain commands tended to interrupt the sequence and make it fail to complete. Another trouble was that I couldn't find a way to assign the journal-updating command to an action, so it kept updating immediately. I threw in a DelayCommand() to make it update after an estimated amount of time for the actions to be completed, but that's a non-optimal solution, since the assigned actions can take more or less time depending on whether anything's in the NPCs path when she's walking from one place to another. Also, one of the PlayVoiceChat() constants (the "cheer" one) did nothing, while another one worked.

However, I took another look at the UncleFB tavern scripts, and this time I was able to understand more of what I was looking at. I think I'm beginning to understand what they're doing, and how, and why he chose to do them that way. I had originally shied away from doing anything with a heartbeat for this task, but UncleFB's scripts use a heartbeat with a switch and local variables to determine whether to perform a task, and if so, which one(s). It looks much more robust, and resistant to breaking due to interruptions, because I can have a command or series of commands in separate cases, and on each heartbeat each case would first check to see if the task had been accomplished. If not, continue to do the task, and if so, set the variable for the next case, which the heartbeat will pick up on its next pulse. If that's how it works, then it opens up a whole new world of possibilities for setting up my character interactions! I had no idea that things could be scripted in that way. Exciting times!


Added to that, I can use the SetCustomHeartbeat() command within the cases to either speed up the heartbeat while tasks are being undertaken, or slow it down when the character is idle.

I think I'll rewrite this script to use that method instead, with of course the default case being "do nothing".

[Tchos]

Okay, I have an example now, but I have reservations about showing it, because it reveals information about the middle section of a quest. I suppose it's not too much of a spoiler, since she says what she wanted to do with the materials at the beginning of the quest, and now she's just doing that, but if I hadn't shown it here, then this little sequence would hopefully have been a pleasant surprise. I'm also showing as little of the temple as possible.

I had thought that it would be best to skip through the dialogue for this demo to just show what she does, but then I thought that would undermine my point by leaving out the important context to what's going on. So please pause the video and read what she says after I click the "DEBUG" choice, which skips to the part of the quest where you bring her the samples that you sanctified earlier.



Also, I suggest watching this in high resolution, because the floating text might be too small to read otherwise.

As mentioned before, the player doesn't have to watch this happen, and the player is not forced into conversation. She just invites further conversation once she's done. I think of it more as a bonus scene you can watch play out, or RP along with, as a reward for completing the quest. But if you just want to get to the next part of the quest, you can go do something else until she's done, then come back and talk to her.

Now, this is a pretty simple prototype, but I can envision other such scenes building more interactivity into the open-ended scenes themselves, by checking for the proximity of a PC, the PC's facing direction, skills, etc.(much like conversation checks), to determine alternate events or options.

Also, I could have a character lead the player to a particular place, and invite them to activate something, and only proceed once they do. Until/unless they do, the NPC would do something like expressing impatience, or engaging in coaxing or cajoling. And if the player prefers not to continue that questline and leave the area, I can have the NPC return to his/her usual location, in case the player decides to come back and accept the quest after all. Alternatively, the PC leaving could trigger the NPC going off to take care of things him/herself, cutting off the quest permanently.

All of those things can be done with cutscenes or just informed through dialogue, but I like the idea of having them occur out in the world.

[Tchos]

Things are rather sandbox-like in this module, with certain things that can be completed at any time, in any order, and others that only open up once a prerequisite has been completed. It's possible that you might run into the problem of an NPC assuming you have knowledge of something that you don't. Those possibilities are few, though, because most of the quests are discrete.

As for the other things, I do understand that such things can occur... I've stated that there may be things that I haven't foreseen which could break what I've scripted. I also stated that people have found bugs in my previous work (none of which was ever opened to playtesters before release, and which had a far greater active player base than what we seem to have here at this time), and a much more complicated mod like this one is much more likely to have bugs. I'm just not entirely persuaded that the potential benefit of a closed beta would outweigh the detriments, such as having to delay release while waiting for playtesting reports, and diluting the pool of those few who would play it after its release. What if a potential trouble exists, but there would have been no need to fix it because the conditions for breaking it are so unlikely for a normal player that no one would have stumbled upon it in the course of normal play? If a playtester is actively trying to break the module, then that's not exactly representative of someone playing to enjoy it. I actively try to break it myself, just in case.

That said, I could try a single playtester. If someone could agree to play it through and report back in a way that wouldn't excessively delay its release, such as during the time after I've completed all the content, and am in a final pass of going over everything to polish it up. But if I end up waiting too long, then I would just go ahead and release it. If anyone reading this wants to be that one, knowing that you would be playing a release that's less polished than it could be, then please send me a private message on the forum.

I had a bit of a scare yesterday, when my monitor went dark without warning, and everything stopped. The computer didn't respond to any commands (including ctrl-alt-del) so I powered down, and then turned it on again. The screen remained dark, and the hard drive light remained solidly lit up, without the telltale flickering to indicate normal activity, despite giving it ample time to boot up.

I powered down again, and decided to let it rest a while while I went out to run some needed errands, and dreading finding that it would need to be repaired in some way, which I can't afford. When I returned, and turned it on again, my period of anxiety was remarkably brief before I was treated to a very speedy bootup as if nothing had happened, beyond the usual "Windows didn't shut down correctly. How do you want to proceed?"

I had my module open during this crash. When I reopened the area I had last been working on, it showed me a room with nothing but tiles, and no placeables. Brief panic! But no, it was because the filters were set to "hide all" which is one of the things I've been doing to try to get the town area to load without crashing. (Can't tell for sure if it's more successful or not, but it seems like it loads more often.) Everything seemed to be safe. Nothing lost. Yay for directory mode!

Worked on another shop, instead of the 2nd lighthouse level, which I should be more excited to work on, due to the design elements I have in mind for it. Instead, I'm doing a bard shop, and so I had to bring in the musical instruments from the Item Placeables pack.

I'll say one thing -- the standard interior wall with the bordered wallpaper needs to have more wallpaper variations. That pattern looks to be entirely on the tint map, so it shouldn't be hard to make some more patterns. I'll consider that for a future work. In the meantime, Jaesun999 has some additions to the textures that I'm using.

[Tchos]

Designing the bard shop was actually rather tedious. especially when I found that the instruments wouldn't fit on the estate shelving with which I had already lined the place, and I had to replace them (scrapping a lot of assembly, placement, scaling, and tinting). And, of course, it's hard to create much of a store when there are only 3 instruments in the game. I made a fourth with scaling, but it's just as well that this shop caters not only to magic of the musical persuasion, but also to other styles.



I looked around for some additional musical instrument placeables, but only found a few for NWN1 such as a piano and a harp. Must make it difficult to be a Harper in NWN2 when there aren't any harps. I looked for information on converting NWN1 models to NWN2, but the RWS tutorial had dead links to a required document, and also involved running the model through multiple programs that I've never used, including 3DS Max. It also said that the free alternative Gmax would work, though, so at least expense would not be a barrier if I decide to take the time to learn it later (after this module).

I'll leave the rest of the music shop for later and get back to the lighthouse, in case anyone here can tell me of some other instrument models I may have missed.

[Tchos]

Eguintir responded very promptly to my email, and gave permission to use those instruments, as well as possibly others!

So I finished the music shop, and added the shopkeepers. Aldanon the Sage makes a fairly decent Väinämöinen, who sells the magical bard equipment. Joukahainen, not being as talented in the singing department, sells the more skald-like style of bard equipment. Building the shops for the two of them took more time than I would have liked, and a search for themed prefab stores on the Vault was unfruitful. Bonus Blueprints comes with a good selection of them, but didn't seem to have any that specialised in bard gear.



Joukahainen also is going to offer a melancholy quest. Maybe I shouldn't have decided to add another side quest, but it was just the perfect opportunity. I've put in the skeleton of it, but I have to stop for the day.