Gaming
 

Talk:Tavern system

From NWNWiki

This system is actually a work-in-progress. Anyone with ideas or suggestions please feel free to air them right here. Thanks! Klingon Mage 12:15, 17 Dec 2005 (PST)

[edit] Running Comments and Notes on Development

  • Decided against weekly rentals. It will be easier to implement the rental system by simply "selling" the PC a key, which they use on the room. After 24 hours the key disappears and must be "bought" again. It would be easier still to have the key disappear when used, but that won't be fair to the players. When they rent, it should count for the whole night not just a single use. I want a simple, easy way to implement this idea. Haven't come up with one yet.  ;) Klingon Mage 12:46, 17 Dec 2005 (PST)
  • I don't think disappearing keys add any realistic flavor. Unless they are magical, of course. For this same reason, I do not use any doors that automatically close by themselves. Keys that disappear when used are also not "realistic" (fuzzy word there, when you are in a fantasy environment). Instead, we could just hook the OnPlayerRest event that prevents the PC from resting due to <whatever conditions>. My pseudo code would be:
    • PC transported to front door of inn
    • PC gets face down animation
    • Door to inn slams shut
    • PC hears shout from door "AND STAY OUT, YOU BEGGAR!"
    • PC notices his backpack inventory is still inside the inn.
    • // Brick Thrower 16:32, 17 Dec 2005 (PST)
  • Well the MOST realistic would be to rent the room by paying in advance for a certain number of days and then having the innkeeper or bouncer or whomever come dunning the PC after the previously paid for time expires. There, again, there needs to be code to determine the expiration of the time. However, you've given me some ideas to think about. As for your pseudo-code, I am afraid you lost me. ;) Klingon Mage 20:38, 17 Dec 2005 (PST)
  • Ok, I've broken the system down into it's component subsystems with discussion on the room-rent thing. Klingon Mage 23:06, 17 Dec 2005 (PST)
  • I think what Brick Thrower was getting at is to use the OnPlayerRest event such that if the PC attempts to rest in the room and is no longer paid up, the PC gets kicked out. Then follow through with the rest of his pseudo-code. However, it does not seem to address the issue of players simply leaving and not returning the key. You may wish to try something along the following lines (this is just a quick brainstorm, feel free to rip it apart):
    • Create a specific door named Inn Exit, with a specific tag that should not be changed. Include the door in the ERF with the rest of the system.
    • Give that door a special OnAreaTransitionClicked event script. This script will:
      • Scan the party to see if they have a key.
      • If so, check the date the key was sold, and if different, fire a conversation, possibly with the innkeeper, or maybe a bouncer by the door, who will direct them to speak to the innkeeper before leaving.
      • The conversation will ask if the PC wishes to "check out" (returns the key to the store) or "renew their key for another night" (updates the date the key was sold).
    • You may also want an OnEnter script for the main area of the inn that does something similar to the above, but incorporates Brick Thrower's idea as well. This way if a PC leaves on the same day (which does not fire the conversation above) and keeps the key, the innkeeper can attempt to charge them for the extra days, and if they don't have the proper amount of gold, they get "tossed out", without whatever gear was left in their room.
    • Builders would then just need to place the "Inn Exit" at any exit they have from their inn. They could adjust the appearance as needed.
      • I LIKE IT! This method also retains my idea of putting everything, as much as possible, on the doors themselves. Ok that's a good workable plan there...
    • Possible problem: Using the same key/door names for all inns in a module will not work. Builders will want to start numbering from 1 for every inn, unless specifically documented that they cannot do so. Either you need to continue to increment your room/key numbers for the entire module so there is no overlap, incorporate some form of the inn name into the tag of the key and door (which will rely on builders to get formatting right), or develop some other system to track which inn the key belongs to. Otherwise keys from one inn will work in another. SSB Syrus Greycloak 08:06, 30 December 2005 (PST)
  • Yes I can see that. The numbering of ROOMS I had already thought of and incorporated code to allow an open-ended room numbering system. I hadn't thought of the module-wide key usage thing because I tend to think in terms of single-player rather than PW. However, it's a valid concern. Two things that could be done about it and one of them is what you said. Another might be to not allow the PC to remove the key from the inn. That brings us back to keys that disappear on use, of course. Klingon Mage 12:31, 30 December 2005 (PST) (further comments below)
  • After rereading the article again, there will also be problems with the "special waiting area", bartenders, waitresses, staff, etc. if there are multiple inns because the NPCs would all have the same tag, and would you want them all to go to the same "special waiting area"? It isn't really an issue, unless you want each inn to have it's own waiting area, meaning you'd need different area tags as well to be able to locate and select the right NPC. I think some type of inn and tavern naming/numbering convention will need to be developed to differentiate between the different inns, if you want to keep things standard. The erf can contain template NPCs with "xxx" in the place of where the builder will need to update for whatever naming convention is decided upon. The NPCs can be named OSRS Template Bartender, or some such. In the comments section for these template NPCs, as well as the main documentation, include a reminder to edit a copy, rename them, and update their tag with the appropriate inn or tavern location identifier. So instead of nrs_tavern_bartender, you may need nrs_tavern_bartender_<loc id>. You could store the <loc id> for the inn as a local on the main area of the inn. SSB Syrus Greycloak 08:35, 30 December 2005 (PST)
  • Not sure exactly what "special waiting area" you are referring to, unless you've jumped into the taproom service/shift change idea already. If so, it's a point I hadn't considered. Given the issue you bring up as well as the one about room keys and inns, I think your <loc id> thought is a good one. Simple numeric IDs would give the possibility of 999 inns to a module and 999 rooms to each inn and so your names become things like os_room_III_RRR, os_innk_III, os_barmaid_III, and so forth. Good call there! Thanks! Klingon Mage 12:31, 30 December 2005 (PST)
  • I'm moving away from the idea of using the Merchant GUI to sell keys and more into conversations and scripting. The reason is that, given the concerns raised by Syrus and others, and the proposed fixes for them, the builder is going to end up having to creat e a god-awful lot of individual keys during development. The other way, only the doors need be created in advance, along with key templates for the different room-grades. Individual keys keyed to specific doors can be created on the fly during play thereby. Unless I am missing something? Klingon Mage 12:37, 30 December 2005 (PST)
  • Yes, I was referring to the shift change "off-stage" area. You can be fine with one. What concerned me more was the tag issue with the NPCs. As to you latest comment, using a conversation system and scripts is probably better for creating keys, since you can specify a tag when you create the key. The issue then becomes one of tracking which rooms have already been rented so you don't issue a key for an "unavailable" room. SSB Syrus Greycloak 13:37, 30 December 2005 (PST)
Retrieved from "http://nwn.wikia.com/wiki/Talk:Tavern_system"