1056 réponses à ce sujet

[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.

[PJ156]

Tchos wrote...

Unlike in the OC, where if you were scouting ahead with a super stealthy character, with your party waiting at a safe distance, once you got close to the boss, suddenly your entire party is teleported out into the open to be ambushed. Very irritating, and not what I would call immersive.

I very much agree though I do not have this fixed properly in my efforts. It sounds like you have a better handle on it.

I see what you have in mind with the cut scenes and I think that works well. How does she deal with interruptions, might the pc stop this happening and affect the forward flow of the mod?

PJ

BTW: Do you plan to make the quest giver system public once you are done. I really would like to try out that for my next project.

Modifié par PJ156, 06 août 2012 - 12:24 .

[Tchos]

The possibility of the PC interrupting her actions is the reason I went with a heartbeat script, combined with a journal stage, and multiple internal script stages in the form of cases within a switch function.  If you try to speak to her while she's going about her business, she will not turn to address you, and will speak a 1-line bark indicating that she needs a few moments to prepare her potion.  The script checks her progress, and refreshes her commands until she reaches the next stage.

I think I've built in enough failsafes to pick things up where she left off in the case of interruptions, based on my tests, but there may be situations that I haven't foreseen.

As for the quest indicator system, I'll release it with full documentation shortly after the module, and of course you're welcome to extract it directly from the module, as with any other resource.

Modifié par Tchos, 06 août 2012 - 12:48 .

[PJ156]

Tchos wrote...

I think I've built in enough failsafes to pick things up where she left off in the case of interruptions, based on my tests, but there may be situations that I haven't foreseen.

Happy to help with playtesting if you are going down that road?

Tchos wrote...

As for the quest indicator system, I'll release it with full documentation shortly after the module, and of course you're welcome to extract it directly from the module, as with any other resource.

Thank you, I can wait for the release. It would slow this project down if I included it but also I think it lends itself really well to a more sandbox style rather that a fixed game facilitator(s) which my mod uses at the moment.

PJ 

[Tchos]

I haven't decided about inviting playtesters, but if the number of potential playtesters is only marginally outnumbered by the possible end players, then I think it's best to just continue playtesting it alone to the best of my ability as I complete each part. I typically test things over and over until I've fixed every bug that I've been able to discover, but in my previous works I've been quick to release patches when other bugs are discovered that I'd missed.

[Dann-J]

Tchos wrote...

The possibility of the PC interrupting her actions is the reason I went with a heartbeat script, combined with a journal stage, and multiple internal script stages in the form of cases within a switch function.  If you try to speak to her while she's going about her business, she will not turn to address you, and will speak a 1-line bark indicating that she needs a few moments to prepare her potion.  The script checks her progress, and refreshes her commands until she reaches the next stage.

That's the approach I also use for NPCs going about their day-to-day business, outside of cut scenes or conversations. As long as the HB script checks whether they're in conversation, combat, or already have something in their action queue, you should be covered by most eventualities. For a series of separate actions, a local variable set on them that keeps track of what they've just done helps to keep them on track (rather than trying to queue up all the actions at once with delays).

I often run the HB scripts from iPoints rather than have every potential NPC run a complex HB script simultaneously. That way the task-specific iPoint chooses the NPC and sends them on their way, ensuring that only one person is engaged in that activity at any one time.

I've yet to find a way of checking whether a wandering merchant is selling you something though. They stay put while you're in conversation with them, but tend to wander off while you're making a purchase. It's not only rude, but a terrible way to conduct business.

[Tchos]

I have two local variables that this script sets and checks -- one is the which case of the switch function should be running at the moment (if 0, then the script does nothing but execute the standard heartbeat script), and the other is whether or not the case is currently "busy". If busy, then it doesn't try to run any of the commands again. I put a few actions that take no time, and at most 1 or 2 that take a little time in each case. A delayed command for after the tasks in the case are complete both sets the variable to not busy, and advances which case to execute.

During the running of the script, conversation just does the bark, but for things that I want to be interruptible, I'll have to remember to check if they're in conversation. I tried checking the action queue, but certain valid actions seem to show up the same as invalid. How do you handle that?

I'll also look into the iPoint method, for the situation you describe.

For the wandering merchant, how about checking the distance between the merchant and the PC, with GetDistanceToObject(), and if the PC is within a minimum distance, make the merchant stand still?

[Dann-J]

I usually have my NPCs run up and use a usable object (chairs, lampposts, etc). That way I don't have to tell them to move to a point and then do something. I just have to tell them to use the usable object, and they take care of getting to it themselves. The object's OnUse script can then set variables on the NPC to let the HB script know that they've successfully done something, as well as have them perform certain animations while doing it. Having the object tell the NPC (or player) what animations to perform, and what results to spawn (effects, sounds, etc) means you don't have to try to time all those things yourself. They happen immediately when the object gets used, no matter how long it takes the NPC to get there.

I have my HB scripts check whether the NPCs have a 'use object' action queued up in their action queue. Before I built that check in, my NPCs were doing things twice if it took them more than six seconds to reach the object, and another 'use object' action was queued up. I've also had no trouble checking whether a creature is moving to a specific point (as opposed to randomly wandering).

As for merchants - it's a pity their HB script can't check whether their store interface is open or not. Or if there *is* a way, then I've not stumbled across the right script function yet.

[Tchos]

Some of my NPCs are set to use usable objects like chairs as well. Others use the other method, and others, because I was experimenting with different methods. But in this particular script I have a lot of different actions being assigned to the NPC's queue, and I didn't find a good way to check if any of them were going on, because checking for not-invalid didn't work.

I do want to look into the idea of the used objects controlling the NPC's action when it uses the object, since it looks like that could be useful.

I don't know of any ways of checking the store interface (I don't have any experience with that), but perhaps set a variable when you open the store, and have the HB check for the variable instead?

[kamal_]

Nytir's battle system (iirc) and my commoner ai both control npcs via placeables. It's not onUsed per se, but you could have the npc script check variables on the placeable and just change local variables on the placeable when its interacted with via the onused (make sure its only set when the npc uses it, not the pc). It's fairly straightforward to do.

[Lugaid of the Red Stripes]

@DannJ: You could always toggle a variable in the conversation that opens the store, and toggle it off with the store's on-close script.

[Dann-J]

Lugaid of the Red Stripes wrote...

@DannJ: You could always toggle a variable in the conversation that opens the store, and toggle it off with the store's on-close script.

Thanks for the idea - I haven't looked at stores much, so I wasn't aware they could have scripts attached to them. I suppose they're a usable object like any other though. It sounds like they're a bit like a iPoint with an inventory.

If they have an OnClose script, does that mean they also have an OnOpen script? If so, then it would be easier to set the variable in the OnOpen, rather than have to insert an action script into each conversation node that opens a store.

[Shaughn78]

Tchos wrote...

I haven't decided about inviting playtesters, but if the number of potential playtesters is only marginally outnumbered by the possible end players, then I think it's best to just continue playtesting it alone to the best of my ability as I complete each part. I typically test things over and over until I've fixed every bug that I've been able to discover, but in my previous works I've been quick to release patches when other bugs are discovered that I'd missed.

From experience I would suggest you have at least 1 tester run through the game for you. Someone who isn't intimately familiar with the workings of the campaign, and knows how eveything is suppose to work. I was amazed how some players managed to break my campaign.

[kamal_]

Yes, you normally need testers for exactly that reason. As the builder, you know exactly what needs to be done and how to do it. Things are very obvious to you, but may not be at all obvious to a player. Unless things are completely linear, they also have a knack for doing them in an order you didn't anticipate. Plus they're good at picking out things like typos that you miss because you've spent so much time looking at the writing.

[Tchos]

Regarding playtesting:

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 don't believe there will be any spelling or grammar errors to find in my work, though, typographical or otherwise. I'm rather fastidious about that. Though if any have occurred, they would be typographical in nature. Perhaps I should offer a prize if anyone finds any?

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]

Glad the folder info was of use, Tsongo. PJ did volunteer as playtester earlier, so there may end up being a bit of playtesting after all.

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.

Modifié par Tchos, 09 août 2012 - 12:41 .

[PJ156]

Iveforgotmypassword wrote...

I think the real testing only starts when a module is released to the world as that's when you hit all the possible combinations due to the numbers of people playing.

What ... you mean six people.

So I just think that Mr 156 is drooloing over your mod and can't wait to get his hands on it much like myself.

Yup!

Seriously, I value playtesting because I make mistakes and I like the release to be the best it can be. My typing skills leave much to be desired so playtesting give me a lot of help.

You are right though, the great masses of players waiting out there are the final test of a game.

PJ

[kamal_]

I think Eguintir Eligard had a piano in his mod. The Zork module also had a bunch of unusual placeables, it may have had instruments.

[Tchos]

@Kamal: I had checked Amraphael's placeables pack before, which he says has all of the original placeables used in Zork, but I looked again just in case, and didn't see any instruments there.  I just checked EE's module, and you're right -- it has a piano, a set of chimes, and a harp, and doesn't look like a conversion from the ones in that NWN1 pack I was looking at earlier.



I looked for info on reuse permission, but didn't find any.  As it seems to be original work, and was not released as a modders' resource, I won't use it without word from Eguintir that it's okay to reuse.  I'll send a PM or an email and ask.  The missing texture pictured here would be easily correctable.

@Tsongo: At first I thought you were saying that 156 people were waiting to play this, since I tend to drop the numbers when I refer to people's names.    I like the flavour comparison you made there, and as I have a birthday around this time (updates are going to be a little spotty for a little while), a cake of that flavour would be an excellent idea.  I can't think of a reason either for why a game like this didn't come with those items already made as placeables, but I'm glad for the Item Placeables pack.

Incidentally, while I was looking through the game resources, I found a particular table whose model wasn't referenced in the placeables.2da.  It's called "ledger" and it's a table with a unique-looking ledger book on it.  The table looks like a bench, and there are some candles and an inkwell and quill attached to it.  I don't recall having seen it in the game anywhere, though ideally the ledger book itself would be separate from the other elements.  I put it into my 2DA and made a blueprint for it even though I don't have a place in mind to put it in my module.

[Dann-J]

There are lots of unused models lurking in the game. Some of them look quite good, although it's obvious with others why they were never used (like the placeable petunia garden beds).

That ledger table looks to be several separate models joined together. It might be possible to separate them out again using Snip MDB:
http://nwvault.ign.c...ls.Detail&id=80 

Modifié par DannJ, 10 août 2012 - 01:06 .

[Tchos]

I haven't seen the petunias, but if they're anything like the ones on top of one of the buildings, I can see why they wouldn't have used them on the ground.

I looked at Snip MDB just now, but it says it's made to join multiple MDBs into 1, rather than split 1 into several. Does it do both, to your knowledge? If so, that would allow me to use one of the statue placeables I wanted.

[Shaughn78]

If your looking to join models, make some prefabs. That way your not just limited to placeables but can join most anything into a group. The larger groups do load a little show though.

[MokahTGS]

 Any chance we could get someone to list those missing placeables so the community knows that they are there?  I know it was done a while ago for the missing VFX.