Well as some may have figured out, I have paused my icy episodic adventure for the community project, which will actually see a little more work from me than this adventure would have produced.
Unfortunately there has been a big delay as our group hak isn't working. I'm trying to work around it but limiting your tools and variety of items to use also limits your inspiration at times.
I've been looking to maybe partner up with at least one veteran modder and making a decent game of it. I figure this community project would be a sneak preview. I was thinking it could be even more but it seems a lot of my submissions will be much larger than the others, so not quite the same experience.
City Adventure
I'm not quite sure what the NWN2 toolset can do for my city adventure I got cooking in my mind. It may never happen as it is fairly ambitious. On the other hand I have no problem at all chapterizing it and have learned how to build that way. Additionally I'm not sure what toolset I would use. I want real legitimate control over the architecture, and nwn2's collection of "prefab" placeables does nothing to help this, and I (and the population of the vault/forums seem to agree) am simply getting tired of seeing the same tired old models ad nauseaum. But Dragon Age's tool set has all of six monsters. So really, what do you do with that??
And you can rotate placables in all directions, but you cant resize or recolor anything. Puke. It's like having to choose one meal for life, between two essential piles of food, with each one givine only half of what you need to keep from dying of nutrition.
I wonder if there is a new toolset on the horizon...
The ages-old struggles of Eguintir P. Eligard as he tries his hand at various aspects of game modification.
Sep 25, 2011
Jul 2, 2011
1 month episode: Still alive
Yes this thing is going. It's amazing how fast post dates get away from you during the summer.
The project will still be a 4 week total effort, I just haven't been able to do anything recently. I've got about 2 weeks into it and really it's just time to ramp ahead. I'll let you know as momentum picks up and anything you can add to my modules forum post for ideas would help fill it in.
For future reference, offering even a slightly circular or branching path to achieve a goal (even if all branches are required, but can be done in random order) adds considerable time to a rapid fire project. A Live Forever style module, as nice and well written as it is, is MUCH quicker to make.
Additionally, I am wondering how to handle party chatter. It will be central to this ongoing series because they are basically your supporting cast. The problem is I don't believe in instant raise deads after battle or for the sake of conversation, so I am trying to get a handle on how I would ensure you spend enough of your time alive to get in on all of them. Ideas?
Skipping the dead companions line isn't really an option here as it was with Islander, as there will hopefully be some pretty intricate comedic exchanges that don't fit the bill with the punch lines missing.
The project will still be a 4 week total effort, I just haven't been able to do anything recently. I've got about 2 weeks into it and really it's just time to ramp ahead. I'll let you know as momentum picks up and anything you can add to my modules forum post for ideas would help fill it in.
For future reference, offering even a slightly circular or branching path to achieve a goal (even if all branches are required, but can be done in random order) adds considerable time to a rapid fire project. A Live Forever style module, as nice and well written as it is, is MUCH quicker to make.
Additionally, I am wondering how to handle party chatter. It will be central to this ongoing series because they are basically your supporting cast. The problem is I don't believe in instant raise deads after battle or for the sake of conversation, so I am trying to get a handle on how I would ensure you spend enough of your time alive to get in on all of them. Ideas?
Skipping the dead companions line isn't really an option here as it was with Islander, as there will hopefully be some pretty intricate comedic exchanges that don't fit the bill with the punch lines missing.
Jun 4, 2011
Concepts introduced for the Adventure Episode


Here is a quick video and breakdown of systems I put in that will hopefully be used in any future campaigns I make. For sure they will debut in this 1 month adventure episode.
I recommend using 720p on youtube and make the screen full to see what is actually going on.
The video
Things to see in the video:
- Infinity style floating text descriptions on ALL click placeables that have descriptions
- Custom parka hood (hehe not that big of a deal)
- Non standard room sizes - check out the inn carefully. Rooms and halls are tight, small and in rectangular, cube, or whatever size and shape I want.
- Temporary black roof vfxs: note how despite using placeables for non standard room sizes, I can still conceal the contents of the room until the door opens using a black vfx and a destroy nearest black vfx on the room's door scripts. The engine will only hide the contents of the standard rooms.
I included pics of the early morning view of parts of the town. I really like how the sun hits it at this time of day, almost gives it a Dragon Age style of realism, with lower res but I think the snow hides it well.
May 23, 2011
1 month challenge
Ok back to modding, so back to blogging (I'm sure many assumed the death of both).
Some of you may have followed my thread here:
http://social.bioware.com/forum/1/topic/167/index/7156713
Now, never one to chime in with ideas that everybody (but me
) should do, I was definitely planning on implementing.
So that's what I did. I silently took up the 1 month module challenge, and I am 2 weeks in. I adopted the quantam leap style concept for an adventure "episode" of which an entire series could be built. I may give myself one extra week just because of the time spent on the pocket plane which would serve as the lobby for this and any future "leaps" into adventure.
I've decided to give it that kind of "more than one path" capability that was great in BG, and I imagine in a few P&P conversions from what I hear. It's not that complex, basically you can go around town questioning people, or if your theiving and spotting skills are keen enough, you can jump the gun and discover a bad guy in your midst earlier, and force the ensuing town meeting.
Now for this, even with 2 ways to get there and an unlinear method to communicate with the townsfolk to find out the true problem in town, got kind of complicated. So despite the brief "don't think" philosophy of this episode, some planning was in order. There is no way I could do this on the fly in game and keep all the webs stranding together.

Got a little garbled as I ran out of space, but I can figure it out easily.
Biggest challenges I've faced was fighting the urge to redo and over-expand areas, and to add a bunch of custom content one piece at a time. Leads to a lot of conflicts. Future note: check it all out first, and make one full hak, and move forward.
Another thing I really need to stop doing is baking/running areas for no apparent reason. If the area looks good in the toolset I don't need to go through the 3 minute process of getting in game and walking through it.
Here's some shots. I've finally found an excuse to be able to do any terrain I want, and I was itching to do a snow theme.

This is the pocket plane episodes begin in. The safe "home lab" where your gnome boss
sends you on jumps to places on faerun that are "karmacally unbalanced"
Some of you may have followed my thread here:
http://social.bioware.com/forum/1/topic/167/index/7156713
Now, never one to chime in with ideas that everybody (but me
) should do, I was definitely planning on implementing.
So that's what I did. I silently took up the 1 month module challenge, and I am 2 weeks in. I adopted the quantam leap style concept for an adventure "episode" of which an entire series could be built. I may give myself one extra week just because of the time spent on the pocket plane which would serve as the lobby for this and any future "leaps" into adventure.
I've decided to give it that kind of "more than one path" capability that was great in BG, and I imagine in a few P&P conversions from what I hear. It's not that complex, basically you can go around town questioning people, or if your theiving and spotting skills are keen enough, you can jump the gun and discover a bad guy in your midst earlier, and force the ensuing town meeting.
Now for this, even with 2 ways to get there and an unlinear method to communicate with the townsfolk to find out the true problem in town, got kind of complicated. So despite the brief "don't think" philosophy of this episode, some planning was in order. There is no way I could do this on the fly in game and keep all the webs stranding together.

Got a little garbled as I ran out of space, but I can figure it out easily.
Biggest challenges I've faced was fighting the urge to redo and over-expand areas, and to add a bunch of custom content one piece at a time. Leads to a lot of conflicts. Future note: check it all out first, and make one full hak, and move forward.
Another thing I really need to stop doing is baking/running areas for no apparent reason. If the area looks good in the toolset I don't need to go through the 3 minute process of getting in game and walking through it.
Here's some shots. I've finally found an excuse to be able to do any terrain I want, and I was itching to do a snow theme.

This is the pocket plane episodes begin in. The safe "home lab" where your gnome boss
sends you on jumps to places on faerun that are "karmacally unbalanced"

Nov 24, 2010
Release
Alright it's releasing whenever it hits the vault after a sunday night upload, wether my final voice actors are ready or not. Life is too short.
Sep 27, 2010
The final week
Well thanks to some handy resources from Shaun the Mentally Unstable One, I now have 6 new vocalists to make my project come to light. This week I run through everything recommended by my players and final grammar checks.
Simultaneously, my audio soldiers will record and give life to this campaign. I'm really glad it worked out because 3 years ago when I set out, I wanted to have BG2 style voice overs all along (the sparingly used ones, and rarely in cut scene format). It's going to put the polish level in near respectability with the talent I have assembled for the often ignored audio portion of modding.
Right now I have to do some checks and balances on the combats in the tour-de-force that is chapter 3.
This is the final week for my part; just whatever time it takes for all the voices to roll in after, people have been pretty punctual with this new group however.
Simultaneously, my audio soldiers will record and give life to this campaign. I'm really glad it worked out because 3 years ago when I set out, I wanted to have BG2 style voice overs all along (the sparingly used ones, and rarely in cut scene format). It's going to put the polish level in near respectability with the talent I have assembled for the often ignored audio portion of modding.
Right now I have to do some checks and balances on the combats in the tour-de-force that is chapter 3.
This is the final week for my part; just whatever time it takes for all the voices to roll in after, people have been pretty punctual with this new group however.
Sep 21, 2010
The Islander Experience
So now that Islander is complete and tested and re-completed, posts from here in will talk details.
That's it for now...
- Play time: 20 hours
- Party size: 6
- Companions: 2 forced, with 6 more to fill the final 3 spots, swappable throughout the game.
- Level: 1 - 6 (finishing well into level 6 with exp)
- Combat: Moderate
- Skill use: occasional, but essential when required, few skills ignored completely
- Traps: Average in number, but definitely requires rogue abilities
- Weapons: 1 to 2 unique magical varients of each type featured in infinity games
- Armor: 1 or 2 suits for each type of dexterity range, some class specific
- Magic use: heavy. Wands and scrolls make even your low level mages more "magical".
- Tactics: occasional, yet essential. Some encounters are really just this side of impossible without the proper plan.
- Combat style: fairly fluid easy' common battles, with distinctly tougher bosses
- Dialogue: lighter than average
- Puzzles: sporadic
- Non-combat quests: above average in quantity
- Characters: built with personalities, light but often memorable dialogue
- Alignment: good
- Race/Gender: any
- Chapters: 3
- Custom Additions: prefab and existing custom content from the community as well as never before seen placeables created by myself, and a completely re-invented spell effects array. All the most popular spells up to level 3 have new effects.
- Music: custom new track by Hoegbo
That's it for now...
Sep 8, 2010
Pre Test complete
One of the players in the pool has gotten through the entire campaign. The others are slower but have advanced through chapter 1 which is essentially where every issue was, as expected.
Not only have I corrected their issues but I have done some area "finishing" so to speak, making merely functional areas more realistic and bustling.
I added somethings strictly for fun and to more closely fit the Islander claim; I said there will be challenging boss combats, so I've added some where there was no "boss" character before.
Now it truly is down to voice acting only.
Not only have I corrected their issues but I have done some area "finishing" so to speak, making merely functional areas more realistic and bustling.
I added somethings strictly for fun and to more closely fit the Islander claim; I said there will be challenging boss combats, so I've added some where there was no "boss" character before.
Now it truly is down to voice acting only.
Aug 10, 2010
While we wait: What I have learned of the nwn2 toolset
The more I try to fix all the crap in the toolset or engine issues, the more I realize you will never fix it all, even if you waste that time. The thing about most of the bugs (primarily for my troubles and this example, initiating a conversation in a fail proof way) is that they are kind of low percentage random fails. You can't figure out why they fail so build these elaborate catches and exception scripts and then 3 people test it and it fails in two more ways.
For those who insist on using this broken product, of which there are several reasons to do so now that it has mature custom content, allow my last 3 months of hell to produce a lesson for the rest of you.
The secret cure: knowing that scripts and engine functions will work the majority of the time with random failures, place absolutely everything in question in a repetitious system. The one thing the engine has going for it is that everything has heartbeats. Using this to consistently try and re-try your intended action until it works, is the best fit way to seamless force something to work, even if a small delay gives a player pause, they will happily shrug it off and resume when it works six seconds later.
My Example:
Problem: Companion talks that occur on rest at the tavern
My approach: choose the conversation, assign it to the PC as talking to them self, and let the others join as their nodes come up
Issues:
-PC failing to talk because some action bumped it
-NPCs failing to say their line for whatever reason
-future conversations not making sense because prior ones failed at some point
-Companions /roster members going scripthidden permanently because the conversation failed and the call at the end to restore them can never fire
Fixes:
1 - The PC now, rather than being paralyzed, scripthidden etc etc in a vain attempt to get them to actually follow their action que and converse, simply is given a begin conversation repetitiously with no delay until the PC actually accepts it.
pseudo code:
do {BeginConversationWithSelf(PC) }
while (PCNotInConversation);
I noticed that this can call the script like 2000 times a second, but it works, and as soon as the PC actually accepts and is in the conversation, it stops, satisfied that whatever failed attempts may have occured, it has suceeded now.
I do not advance the conversation "counter" until in the final node of the talk, knowing that the conversation will have executed full at that point and the next rest-conversation is now allowed. This I had in long ago however, due to the random companion failures to speak that can be addressed by this method. I use a set int on the final node of the conversation, so its not directly in the script at all when it comes to advancing the rest talk counter.
2 - Fixing the "stuck invisible" roster members
While resting or leaving the area restored "in-party" members, if a conversation broke and everyone was invisible, the roster members (out of party companions) were gone forever.
I tried and wasted about 2 weeks trying to solve this, setting them to un-invis right before a rest talk (in case they were invised by the previous one) but this was still obviously a bug, I also set it to uninvis all members at the end of the conversation, as well as entering the tavern. While re-entering would re show the roster, in the end it was a bunch of work for what was still, a bug.
Final solution: in the taverns heartbeat script, if the PC is not in a conversation, then neither can his roster members be, there fore, set all roster members to VISIBLE if the PC is in the area and not conversing:
Pseduo-code for the tavern heartbeat script:
if (PCIsInTavern)
{ If (IsPCConversing (FALSE) ) SetAllRosterMembersVisible() };
This second method rather than using an infinite while loop simply fires every 6 seconds on the heart beat. By the time the player even notices they are gone they are already reappearing.
So really there is two options for a fail safe, either an infinite loop for instant trys and re-tries or the heartbeat wait, which is 6 seconds. Note that certain commands could cause an overflow error if using the infinite loop so I recommend the heartbeat whenever possible. The overflow error doesnt appear to be fatal though, it just means the script will fail, but if you are retrying it anyway it should resume the next try once the overflow is resolved.
I got this idea from looking at Obsidian's own way of making a conversation mandatory, via the CreateIPSpeaker() function. It simply spawns an IP speaker and keeps trying it every heart beat.
No weeks of frustration, no blocks of code for every possible failure. Just a clean, single line, that keeps knocking the door till it opens. This is ultimately the best and most efficient way to deal with something you know will randomly fail, and there is nothing you can do about it.
For those who insist on using this broken product, of which there are several reasons to do so now that it has mature custom content, allow my last 3 months of hell to produce a lesson for the rest of you.
The secret cure: knowing that scripts and engine functions will work the majority of the time with random failures, place absolutely everything in question in a repetitious system. The one thing the engine has going for it is that everything has heartbeats. Using this to consistently try and re-try your intended action until it works, is the best fit way to seamless force something to work, even if a small delay gives a player pause, they will happily shrug it off and resume when it works six seconds later.
My Example:
Problem: Companion talks that occur on rest at the tavern
My approach: choose the conversation, assign it to the PC as talking to them self, and let the others join as their nodes come up
Issues:
-PC failing to talk because some action bumped it
-NPCs failing to say their line for whatever reason
-future conversations not making sense because prior ones failed at some point
-Companions /roster members going scripthidden permanently because the conversation failed and the call at the end to restore them can never fire
Fixes:
1 - The PC now, rather than being paralyzed, scripthidden etc etc in a vain attempt to get them to actually follow their action que and converse, simply is given a begin conversation repetitiously with no delay until the PC actually accepts it.
pseudo code:
do {BeginConversationWithSelf(PC) }
while (PCNotInConversation);
I noticed that this can call the script like 2000 times a second, but it works, and as soon as the PC actually accepts and is in the conversation, it stops, satisfied that whatever failed attempts may have occured, it has suceeded now.
I do not advance the conversation "counter" until in the final node of the talk, knowing that the conversation will have executed full at that point and the next rest-conversation is now allowed. This I had in long ago however, due to the random companion failures to speak that can be addressed by this method. I use a set int on the final node of the conversation, so its not directly in the script at all when it comes to advancing the rest talk counter.
2 - Fixing the "stuck invisible" roster members
While resting or leaving the area restored "in-party" members, if a conversation broke and everyone was invisible, the roster members (out of party companions) were gone forever.
I tried and wasted about 2 weeks trying to solve this, setting them to un-invis right before a rest talk (in case they were invised by the previous one) but this was still obviously a bug, I also set it to uninvis all members at the end of the conversation, as well as entering the tavern. While re-entering would re show the roster, in the end it was a bunch of work for what was still, a bug.
Final solution: in the taverns heartbeat script, if the PC is not in a conversation, then neither can his roster members be, there fore, set all roster members to VISIBLE if the PC is in the area and not conversing:
Pseduo-code for the tavern heartbeat script:
if (PCIsInTavern)
{ If (IsPCConversing (FALSE) ) SetAllRosterMembersVisible() };
This second method rather than using an infinite while loop simply fires every 6 seconds on the heart beat. By the time the player even notices they are gone they are already reappearing.
So really there is two options for a fail safe, either an infinite loop for instant trys and re-tries or the heartbeat wait, which is 6 seconds. Note that certain commands could cause an overflow error if using the infinite loop so I recommend the heartbeat whenever possible. The overflow error doesnt appear to be fatal though, it just means the script will fail, but if you are retrying it anyway it should resume the next try once the overflow is resolved.
I got this idea from looking at Obsidian's own way of making a conversation mandatory, via the CreateIPSpeaker() function. It simply spawns an IP speaker and keeps trying it every heart beat.
No weeks of frustration, no blocks of code for every possible failure. Just a clean, single line, that keeps knocking the door till it opens. This is ultimately the best and most efficient way to deal with something you know will randomly fail, and there is nothing you can do about it.
Subscribe to:
Posts (Atom)