From nicolas.weeger at laposte.net Mon Nov 16 15:28:58 2009 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 16 Nov 2009 22:28:58 +0100 Subject: [crossfire] Feature proposition: [img] tag Message-ID: <200911162229.02114.nicolas.weeger@laposte.net> Hello. I'd like to suggest a [img name="xxx"] tag for client-side rich tags, as defined in "mediaTags". As implied, the tag would display a picture from its name :) Uses: - illustrate a text - show a bigger picture of something (map, illustration, ...). What do you think? Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20091116/91041200/attachment.pgp From nicolas.weeger at laposte.net Mon Nov 16 15:32:05 2009 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 16 Nov 2009 22:32:05 +0100 Subject: [crossfire] How to integrate old stories in the game? Message-ID: <200911162232.05656.nicolas.weeger@laposte.net> Hello. How would one integrate old (as some hundred years old) in-game stories in the gameplay flow? Right now, we have kind of the "Know-It-All" sage who will conveniently know everything of things that happened hundred years ago, without any mistake or such. Things I could envision: - old manuscripts, in languages a player would need to learn to decipher - wrong (plain or slightly mistaken) things around, to have the player try to figure what to trust - partial stories only, leaving the rest to deduction. Opinions? :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20091116/8b3496a6/attachment.pgp From nicolas.weeger at laposte.net Mon Nov 16 16:11:58 2009 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 16 Nov 2009 23:11:58 +0100 Subject: [crossfire] Changing connection texts Message-ID: <200911162312.02249.nicolas.weeger@laposte.net> Hello. Suggestion to change the various messages at login: "Hello you nice soul, and welcome to this world. My memory is slightly blurred lately, could you tell me your name, again?" [prompt for name] If new player: "Ha, you're not on my registers, so you just had the authorisation to incarnate on this world, he? My name is [find name], and I'm here to help souls incarnate. [if perm death] Please note that on this world your corporal incarnation will be destroyed if you die, so take care. [if reincarnation] It could be recovered, but you'd need help from some nice soul. [if not perm death] You're lucky, here even if your corporal incarnation dies, you can still use it. Nice, isn't it? Anyway, now you must choose your corporal incarnation. I hope you'll enjoy it, whatever you select." If current player: "Ha, nice to see you again. Now if you'd be so nice as to prove me you indeed own this incarnation?" [prompt for password] What do you think? :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20091116/66ead390/attachment.pgp From agschult at ucalgary.ca Mon Nov 16 16:52:30 2009 From: agschult at ucalgary.ca (Alex Schultz) Date: Mon, 16 Nov 2009 15:52:30 -0700 Subject: [crossfire] Changing connection texts In-Reply-To: <200911162312.02249.nicolas.weeger@laposte.net> References: <200911162312.02249.nicolas.weeger@laposte.net> Message-ID: <20091116155230.5b93cd60@ucalgary.ca> On Mon, 16 Nov 2009 23:11:58 +0100 Nicolas Weeger wrote: > Suggestion to change the various messages at login: > > > > What do you think? :) > I for one, like it. I'd say... commit time unless anyone has any suggestions :) Alex From mwedel at sonic.net Tue Nov 17 00:09:40 2009 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 16 Nov 2009 22:09:40 -0800 Subject: [crossfire] How to integrate old stories in the game? In-Reply-To: <200911162232.05656.nicolas.weeger@laposte.net> References: <200911162232.05656.nicolas.weeger@laposte.net> Message-ID: <4B023E24.50701@sonic.net> Nicolas Weeger wrote: > Hello. > > > How would one integrate old (as some hundred years old) in-game stories in the > gameplay flow? > > > Right now, we have kind of the "Know-It-All" sage who will conveniently know > everything of things that happened hundred years ago, without any mistake or > such. > > There is the lib/messages file, which will be used for random readables that show up in dungeons. However, the current instance of readables (nonmagical scrolls, books, etc) is pretty low. And even if one is generated, it could contain info about alchemy, monsters, spells, etc. And it can also have a high literacy rate requirement. > > Things I could envision: > - old manuscripts, in languages a player would need to learn to decipher One could sort of say that the literacy skill, as is, might represent that. I'd be a little reluctant to make it even harder to find useful information in readable books. > - wrong (plain or slightly mistaken) things around, to have the player try to > figure what to trust That seems completely reasonable to me. The likelihood of someone precisely recording information would be remote. > - partial stories only, leaving the rest to deduction. That is also good - but perhaps more for oral messages (the sage/random folks in taverns). Having folks with random tidbits of information may make it more likely to actually talk to folks. Certainly more game information would be a good thing. The messages file could certainly be better - more like the artifacts file so that instead of just having messages, one could assign likelihood of different messages showing up (there could very well be complete and accurate copies of information around, but quite rare), as well as literacy requirements. From mwedel at sonic.net Tue Nov 17 00:18:06 2009 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 16 Nov 2009 22:18:06 -0800 Subject: [crossfire] Changing connection texts In-Reply-To: <20091116155230.5b93cd60@ucalgary.ca> References: <200911162312.02249.nicolas.weeger@laposte.net> <20091116155230.5b93cd60@ucalgary.ca> Message-ID: <4B02401E.9020106@sonic.net> Alex Schultz wrote: > On Mon, 16 Nov 2009 23:11:58 +0100 > Nicolas Weeger wrote: > >> Suggestion to change the various messages at login: >> >> >> >> What do you think? :) >> > > I for one, like it. I'd say... commit time unless anyone has any > suggestions :) I agree - better it is now, in which some new folks get confused about character creation. One question would be: What do you do on wrong password? A not too uncommon situation is you have a new player who is trying to use the name of an existing character. We probably want something that is clear that the existing name is in use, but at the same time isn't too confusing if they just mistype their password. From mwedel at sonic.net Tue Nov 17 00:14:29 2009 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 16 Nov 2009 22:14:29 -0800 Subject: [crossfire] Feature proposition: [img] tag In-Reply-To: <200911162229.02114.nicolas.weeger@laposte.net> References: <200911162229.02114.nicolas.weeger@laposte.net> Message-ID: <4B023F45.2070100@sonic.net> Nicolas Weeger wrote: > Hello. > > > I'd like to suggest a [img name="xxx"] tag for client-side rich tags, as > defined in "mediaTags". > > As implied, the tag would display a picture from its name :) > > > Uses: > - illustrate a text > - show a bigger picture of something (map, illustration, ...). I think it is a good idea. Quick thoughts: - I'd guess that this might be static content in some cases, in which is refers to an actual image name. In that case, if the client is not using image caching, it would have no idea if it has the image or not (since it only gets image numbers in that case). I think simplest all around would be to enforce the idea that clients must do image caching - it simplifies code in a bunch of areas. - I'd also imagine one could have images that are not directly associated with any archetypes (say a map of the area). There is nothing that prevents that, as IIRC the client script will pick up any files of appropriate name in the arch directory, but it may be desirable to have a storage for such images someplace else, since if they are not used by archetypes, they don't really belong in that directory structure. From kbulgrien at att.net Tue Nov 17 02:53:20 2009 From: kbulgrien at att.net (Kevin Bulgrien) Date: Tue, 17 Nov 2009 02:53:20 -0600 Subject: [crossfire] Feature proposition: [img] tag In-Reply-To: <200911162229.02114.nicolas.weeger@laposte.net> References: <200911162229.02114.nicolas.weeger@laposte.net> Message-ID: <20091117025320.5c54f488@a850srvr.kbulgrien.att.net> > Hello. > > I'd like to suggest a [img name="xxx"] tag for client-side rich tags, as > defined in "mediaTags". > > As implied, the tag would display a picture from its name :) > > Uses: > - illustrate a text > - show a bigger picture of something (map, illustration, ...). > > What do you think? > > Nicolas I guess this is supposed to "pop-up" an image in the client or somehow inlining an image in the output stream? Can you describe what you envision a client doing for this type of tag? Are there constraints on image size, or other attributes? Not opposed in principle, but am not real sure we have content developers that are drawing and/or acquiring such images for actual use in maps. I think you have said in the past we need content more than unused features, though I see this as having potential for richer game play. Anyway, not to discourage your efforts, I suppose that does not need to matter so much. Kevin From kbulgrien at att.net Tue Nov 17 03:05:09 2009 From: kbulgrien at att.net (Kevin Bulgrien) Date: Tue, 17 Nov 2009 03:05:09 -0600 Subject: [crossfire] How to integrate old stories in the game? In-Reply-To: <200911162232.05656.nicolas.weeger@laposte.net> References: <200911162232.05656.nicolas.weeger@laposte.net> Message-ID: <20091117030509.3d445f65@a850srvr.kbulgrien.att.net> > Hello. > > How would one integrate old (as some hundred years old) in-game stories in the > gameplay flow? > > Right now, we have kind of the "Know-It-All" sage who will conveniently know > everything of things that happened hundred years ago, without any mistake or > such. > > Things I could envision: > - old manuscripts, in languages a player would need to learn to decipher > - wrong (plain or slightly mistaken) things around, to have the player try to > figure what to trust > - partial stories only, leaving the rest to deduction. It seems these kinds of ideas are good, though I'm not to sure about "wrong" information without some not insanely hard to find way to validate wrong data. Of the listed ideas, the first seems most likely to enhance play. The last seems reasonable, though perhaps better done by having the missing pieces completed as a related quest progresses as though the player is rediscovering the history through the act of digging through and using this partial story data. > Opinions? :) Without really claiming to have a vision of how to pull it off, perhaps the wrong/partial ideas could be supplemented by a mechanism by which a player can actually accumulate the stories client side for perusal in more of a book fashion instead of the encumbering NPC communication model. I think that the lore and quests in this game are hard to handle because there is no practical way for a player to manage the information in more than a piecemeal fashion. Adding wrong and partial stories seems like it could go the wrong way if something was not done to balance it out. Pieces of stories could have identifier tags of some kind that would allow them to be fit together into a document on the client. Wrong information could have the same tag as good information - causing the player to have to decide which one was right when both were found. Agree that wrong information is more realistic in some sense, but am reluctant to get too realistic in this regard as it can frustrate rather than improve the player experience. This game is based on a fantastic world rather than a realistic one. Kevin From kbulgrien at att.net Tue Nov 17 03:06:50 2009 From: kbulgrien at att.net (Kevin Bulgrien) Date: Tue, 17 Nov 2009 03:06:50 -0600 Subject: [crossfire] Changing connection texts In-Reply-To: <200911162312.02249.nicolas.weeger@laposte.net> References: <200911162312.02249.nicolas.weeger@laposte.net> Message-ID: <20091117030650.33b9c0eb@a850srvr.kbulgrien.att.net> > Hello. > > Suggestion to change the various messages at login: > > "Hello you nice soul, and welcome to this world. > > My memory is slightly blurred lately, could you tell me your name, again?" > [prompt for name] > > If new player: > > "Ha, you're not on my registers, so you just had the authorisation to > incarnate on this world, he? > > My name is [find name], and I'm here to help souls incarnate. > > [if perm death] Please note that on this world your corporal incarnation will > be destroyed if you die, so take care. [if reincarnation] It could be > recovered, but you'd need help from some nice soul. > [if not perm death] You're lucky, here even if your corporal incarnation dies, > you can still use it. Nice, isn't it? > > > Anyway, now you must choose your corporal incarnation. I hope you'll enjoy it, > whatever you select." > > If current player: > > "Ha, nice to see you again. Now if you'd be so nice as to prove me you indeed > own this incarnation?" [prompt for password] > > What do you think? :) Fun idea worth pursuing. Kevin From om at iki.fi Tue Nov 17 08:37:55 2009 From: om at iki.fi (Otto J. Makela) Date: Tue, 17 Nov 2009 16:37:55 +0200 Subject: [crossfire] How to integrate old stories in the game? In-Reply-To: <4B023E24.50701@sonic.net> References: <200911162232.05656.nicolas.weeger@laposte.net> <4B023E24.50701@sonic.net> Message-ID: <4B02B543.2070406@iki.fi> Mark Wedel wrote: > There is the lib/messages file, which will be used for random readables that > show up in dungeons. > > However, the current instance of readables (nonmagical scrolls, books, etc) is > pretty low. And even if one is generated, it could contain info about alchemy, > monsters, spells, etc. And it can also have a high literacy rate requirement. A segue to something that has bothered me a bit: there are no longer any closed houses in Scorn, having been replaced with randomly generated ones. However, there is not much point in visiting them, as they are only single- level places with the randomly-generated paraphernalia. If you are very lucky, there might be a "treasure room" or some such, but otherwise they are fairly pointless: no monsters on the first level, nothing to do, nothing to see... How about someone working a bit on the generator, for example have the ubiquitous bookshelves actually occasionally contain something useful? -- /* * * Otto J. Makela * * * * * * * * * * * * * * * */ /* Phone: +358 40 765 5772, FAX: +358 42 7655772, ICBM: 60N 25E */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki, FINLAND */ /* * * Computers Rule 01001111 01001011 * * * * * * * * * * * * */ From mwedel at sonic.net Wed Nov 18 00:43:00 2009 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 17 Nov 2009 22:43:00 -0800 Subject: [crossfire] Feature proposition: [img] tag In-Reply-To: <20091117025320.5c54f488@a850srvr.kbulgrien.att.net> References: <200911162229.02114.nicolas.weeger@laposte.net> <20091117025320.5c54f488@a850srvr.kbulgrien.att.net> Message-ID: <4B039774.7000105@sonic.net> Kevin Bulgrien wrote: >> Hello. >> >> I'd like to suggest a [img name="xxx"] tag for client-side rich tags, as >> defined in "mediaTags". >> >> As implied, the tag would display a picture from its name :) >> >> Uses: >> - illustrate a text >> - show a bigger picture of something (map, illustration, ...). >> >> What do you think? >> >> Nicolas > > I guess this is supposed to "pop-up" an image in the client or somehow inlining > an image in the output stream? Can you describe what you envision a client > doing for this type of tag? Are there constraints on image size, or other > attributes? Off the top of the head, I could imagine some quick cases, like: - Book containing information about a monster, and containing a picture of that monster - Same for other objects (more likely artifacts or unique rare stuff). However, from a tutorial perspective, displaying the different objects inline would make things much clearer, eg 'pull the lever [img=lever] to open the gate' type of thing - Last case could be maps of the area - in this case, it could just be images used from the editor and shrunk down to a smaller initial size. However, in all cases, some hint about resizing may be needed. For example, if a player is playing with a low resolution setup and has done something like -mapscale 50, probably any objects you are talking about that are map related should be similarly scaled. I'm not 100% sure on that. For large images (map areas), the client would likely need to scale down if it is too wide to fit in the message window (height isn't as much a problem, as at least you can scroll the window up/down). I'm presuming this will do inlining, and not pop up the image, but I suppose it depends on usage - one could envision maps perhaps being popped up since they are fairly standalone, but in the tutorial example, you probably don't want that popping up. > > Not opposed in principle, but am not real sure we have content developers that > are drawing and/or acquiring such images for actual use in maps. I think you > have said in the past we need content more than unused features, though I see > this as having potential for richer game play. Anyway, not to discourage your > efforts, I suppose that does not need to matter so much. At least in my examples above, those are pretty much all in game images that currently exist (the map one would have to get created, but that can be done from the editor fairly easily). I'm not 100% sure what type of images Ryo was thinking on the initial proposal. I'm not sure how hard all of this is - I'd have to look at the display widget thing to see about images, but I think the support is already pretty much there by GTK. Any image resizing can be done with the same routines that is used to rescale map/icon images. I do think some size restrictions/suggestions are warranted. Unless you are doing pop up windows, a 1000x1000 image is not that useful - it would pretty much always have to get resized to fit in the text display area. From mwedel at sonic.net Wed Nov 18 00:53:49 2009 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 17 Nov 2009 22:53:49 -0800 Subject: [crossfire] How to integrate old stories in the game? In-Reply-To: <20091117030509.3d445f65@a850srvr.kbulgrien.att.net> References: <200911162232.05656.nicolas.weeger@laposte.net> <20091117030509.3d445f65@a850srvr.kbulgrien.att.net> Message-ID: <4B0399FD.8090301@sonic.net> I was thinking about this some more, and had some other ideas. If one thinks about it, even someone not very literate can still read something - he isn't going to read a college level physics book, but could read a newspaper perhaps. If one were to go on this logic,than for any given message, it would be reasonable for what the player sees to vary based on literacy. For example: Level 5 (max requirement for this message): On the far eastern shore of the continent, at the tip of a penisula, there is a tower with many diabolical beasts. At the top of this tower is Solinter, a powerful spell casting creature. Level 4: On the far eastern shore, at the tip of land, there is a tower with monsters. At the top of this tower, there is a nasty monster. Level 3, 2 ommitted for brevity. Level 1: On the far eastern shore of this land is a tower with many monsters I suppose in those messages one would have to prefix them with something like "You don't understand most/some/a little of the message, but this is what you understand from it" In this way, even if a character does not have sufficient literacy, they can still get some of the message. I like this also in that it at least gives you some idea if the book/scroll/whatever has any information that would be useful to you. One might say "I've already been in that tower and killed everything there, so this book isn't useful" However, to do this would require extension of the message file (or the msg fields) to note the different level requirements. I do agree that some way for the player to handle/deal with these messages would be nice. I use to resort to copying information down in another window, but that takes things out of the game experience. One could imagine something like a special folio object that holds all these - the issue is still how to present them to the user. From nicolas.weeger at laposte.net Thu Nov 19 12:48:40 2009 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 19 Nov 2009 19:48:40 +0100 Subject: [crossfire] Feature proposition: [img] tag In-Reply-To: <4B039774.7000105@sonic.net> References: <200911162229.02114.nicolas.weeger@laposte.net> <20091117025320.5c54f488@a850srvr.kbulgrien.att.net> <4B039774.7000105@sonic.net> Message-ID: <200911191948.45461.nicolas.weeger@laposte.net> Hello. > Off the top of the head, I could imagine some quick cases, like: > - Book containing information about a monster, and containing a picture of > that monster > - Same for other objects (more likely artifacts or unique rare stuff). > However, from a tutorial perspective, displaying the different objects > inline would make things much clearer, eg 'pull the lever [img=lever] to > open the gate' type of thing - Last case could be maps of the area - in > this case, it could just be images used from the editor and shrunk down to > a smaller initial size. > > However, in all cases, some hint about resizing may be needed. For > example, if a player is playing with a low resolution setup and has done > something like -mapscale 50, probably any objects you are talking about > that are map related should be similarly scaled. I'm not 100% sure on > that. For large images (map areas), the client would likely need to scale > down if it is too wide to fit in the message window (height isn't as much a > problem, as at least you can scroll the window up/down). > > I'm presuming this will do inlining, and not pop up the image, but I > suppose it depends on usage - one could envision maps perhaps being popped > up since they are fairly standalone, but in the tutorial example, you > probably don't want that popping up. Well, I was thinking of popup images, big ones, with maps or zoomed items. But regular pics inline would work too. So maybe it should be [img] and [popup] at the same time? :) > > Not opposed in principle, but am not real sure we have content developers > > that are drawing and/or acquiring such images for actual use in maps. Except people wishing to contribute graphism could have fun making big pictures and contributing those, too. Or we could use generated maps, or pics from somewhere else. > At least in my examples above, those are pretty much all in game images > that currently exist (the map one would have to get created, but that can > be done from the editor fairly easily). I'm not 100% sure what type of > images Ryo was thinking on the initial proposal. Zoom on something (statues? maps? books?), or game objects. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20091119/6d94183e/attachment.pgp From nicolas.weeger at laposte.net Thu Nov 19 12:51:18 2009 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 19 Nov 2009 19:51:18 +0100 Subject: [crossfire] How to integrate old stories in the game? In-Reply-To: <4B02B543.2070406@iki.fi> References: <200911162232.05656.nicolas.weeger@laposte.net> <4B023E24.50701@sonic.net> <4B02B543.2070406@iki.fi> Message-ID: <200911191951.18525.nicolas.weeger@laposte.net> > A segue to something that has bothered me a bit: there are no longer any > closed houses in Scorn, having been replaced with randomly generated ones. > > However, there is not much point in visiting them, as they are only single- > level places with the randomly-generated paraphernalia. If you are very > lucky, there might be a "treasure room" or some such, but otherwise they > are fairly pointless: no monsters on the first level, nothing to do, > nothing to see... > > How about someone working a bit on the generator, for example have the > ubiquitous bookshelves actually occasionally contain something useful? I'd rather see real maps. The random map generator (which I did) was mostly supposed to compensate a lack of maps. If people do make maps for all houses, then the plugin isn't useful anymore :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20091119/dd369668/attachment.pgp From nicolas.weeger at laposte.net Thu Nov 19 12:50:23 2009 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 19 Nov 2009 19:50:23 +0100 Subject: [crossfire] How to integrate old stories in the game? In-Reply-To: <4B0399FD.8090301@sonic.net> References: <200911162232.05656.nicolas.weeger@laposte.net> <20091117030509.3d445f65@a850srvr.kbulgrien.att.net> <4B0399FD.8090301@sonic.net> Message-ID: <200911191950.23503.nicolas.weeger@laposte.net> > If one were to go on this logic,than for any given message, it would be > reasonable for what the player sees to vary based on literacy. I was thinking of script-based text garbling, actually, but your approach works too. > I do agree that some way for the player to handle/deal with these > messages would be nice. I use to resort to copying information down in > another window, but that takes things out of the game experience. One > could imagine something like a special folio object that holds all these - > the issue is still how to present them to the user. Client issue that can be fixed. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20091119/23dd1917/attachment.pgp From nicolas.weeger at laposte.net Thu Nov 19 12:55:10 2009 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 19 Nov 2009 19:55:10 +0100 Subject: [crossfire] How to integrate old stories in the game? In-Reply-To: <20091117030509.3d445f65@a850srvr.kbulgrien.att.net> References: <200911162232.05656.nicolas.weeger@laposte.net> <20091117030509.3d445f65@a850srvr.kbulgrien.att.net> Message-ID: <200911191955.10683.nicolas.weeger@laposte.net> > It seems these kinds of ideas are good, though I'm not to sure about > "wrong" information without some not insanely hard to find way to validate > wrong data. Of the listed ideas, the first seems most likely to enhance > play. The last seems reasonable, though perhaps better done by having the > missing pieces completed as a related quest progresses as though the player > is rediscovering the history through the act of digging through and using > this partial story data. Validating wrong data is easy - go to the place, see there is no entrance, go somewhere else :) > Without really claiming to have a vision of how to pull it off, perhaps the > wrong/partial ideas could be supplemented by a mechanism by which a player > can actually accumulate the stories client side for perusal in more of a > book fashion instead of the encumbering NPC communication model. I think > that the lore and quests in this game are hard to handle because there is > no practical way for a player to manage the information in more than a > piecemeal fashion. Adding wrong and partial stories seems like it could > go the wrong way if something was not done to balance it out. Well, for one, players do have a brain, and they could use to remember the stories :) Writing sufficently fun stories would make it worth remembering them, IMO. Though a good solution could indeed be to have client-side recording. > Pieces of stories could have identifier tags of some kind that would allow > them to be fit together into a document on the client. Wrong information > could have the same tag as good information - causing the player to have > to decide which one was right when both were found. I'd rather have the player organize tidbits herself. No point in saying exactly what story a piece of text refers to, IMO. > Agree that wrong information is more realistic in some sense, but am > reluctant to get too realistic in this regard as it can frustrate rather > than improve the player experience. This game is based on a fantastic > world rather than a realistic one. So? Fantastic prevents wrong/distorded information? :) As long as the searching itself is fun, it should be ok, I think. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20091119/d0af931a/attachment.pgp From nicolas.weeger at laposte.net Thu Nov 19 12:56:04 2009 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 19 Nov 2009 19:56:04 +0100 Subject: [crossfire] Changing connection texts In-Reply-To: <4B02401E.9020106@sonic.net> References: <200911162312.02249.nicolas.weeger@laposte.net> <20091116155230.5b93cd60@ucalgary.ca> <4B02401E.9020106@sonic.net> Message-ID: <200911191956.04626.nicolas.weeger@laposte.net> > One question would be: What do you do on wrong password? A not too > uncommon situation is you have a new player who is trying to use the name > of an existing character. We probably want something that is clear that > the existing name is in use, but at the same time isn't too confusing if > they just mistype their password. "Hum, I'm sorry, but your secret phrase doesn't match what I have written in my book. Could you restate your name, please?" :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20091119/32040150/attachment.pgp From nicolas.weeger at laposte.net Thu Nov 19 16:32:05 2009 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 19 Nov 2009 23:32:05 +0100 Subject: [crossfire] What to find in towns, what to find in the countryside Message-ID: <200911192332.08732.nicolas.weeger@laposte.net> Hello. Right now there are many houses / maps in the various towns which have monsters. What about moving all that outside the towns (which after all have guards and such, and should probably be "safe" places?), and putting them in the country side? Except maybe some mice or dogs here and there ;) This would leave the town with many houses to put NPCs, have shops, things like that. And increase the number of stories to tell to players :) What would you think of that? Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20091119/94c60e60/attachment.pgp From om at iki.fi Fri Nov 20 07:45:21 2009 From: om at iki.fi (Otto J. Makela) Date: Fri, 20 Nov 2009 15:45:21 +0200 Subject: [crossfire] How to integrate old stories in the game? In-Reply-To: <200911191951.18525.nicolas.weeger@laposte.net> References: <200911162232.05656.nicolas.weeger@laposte.net> <4B023E24.50701@sonic.net> <4B02B543.2070406@iki.fi> <200911191951.18525.nicolas.weeger@laposte.net> Message-ID: <4B069D71.3000209@iki.fi> Nicolas Weeger wrote: > I'd rather see real maps. > The random map generator (which I did) was mostly supposed to compensate a > lack of maps. If people do make maps for all houses, then the plugin isn't > useful anymore :) Obviously real maps would be the best solution. However, I think the random map generator does a fair job, specially on the multi-level dungeons; IMHO the different Scorn quest maps turn out nice and exciting. The fact that it does as reasonable a job as it does means that it might be worth putting a bit of effort into enhancing it... -- /* * * Otto J. Makela * * * * * * * * * * * * * * * */ /* Phone: +358 40 765 5772, FAX: +358 42 7655772, ICBM: 60N 25E */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki, FINLAND */ /* * * Computers Rule 01001111 01001011 * * * * * * * * * * * * */ From mwedel at sonic.net Sun Nov 22 01:02:34 2009 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 21 Nov 2009 23:02:34 -0800 Subject: [crossfire] What to find in towns, what to find in the countryside In-Reply-To: <200911192332.08732.nicolas.weeger@laposte.net> References: <200911192332.08732.nicolas.weeger@laposte.net> Message-ID: <4B08E20A.2070903@sonic.net> Nicolas Weeger wrote: > Hello. > > > Right now there are many houses / maps in the various towns which have > monsters. > > > What about moving all that outside the towns (which after all have guards and > such, and should probably be "safe" places?), and putting them in the country > side? > Except maybe some mice or dogs here and there ;) > > > This would leave the town with many houses to put NPCs, have shops, things > like that. And increase the number of stories to tell to players :) Certainly for scorn, as that is a starting area, it makes a lot of sense. And a lot of the monster maps in scorn don't make a lot of sense. For navar city, there are several quest lines that sort of go with some of the maps in the town (old wizards tower, smuggling operation, etc). But those are also better in that for the most part, there is some sequence so you just can't wander into a random house full of monsters. In terms of the NPC's, I think that can work. However, I wouldn't like there to be NPC's giving quests (not that we really have quests, but you sort of get the idea) that you have to hunt through all the houses. I think a method where most of the NPC's may have some basic information (so that for example they may have tales of haunted houses, etc) is good. Or for that matter, if there are NPC's in the houses with unique information, maybe some of the common knowledge would be about that person (Bob over there is looking for someone to ...) From mwedel at sonic.net Sun Nov 22 01:16:33 2009 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 21 Nov 2009 23:16:33 -0800 Subject: [crossfire] How to integrate old stories in the game? In-Reply-To: <200911191950.23503.nicolas.weeger@laposte.net> References: <200911162232.05656.nicolas.weeger@laposte.net> <20091117030509.3d445f65@a850srvr.kbulgrien.att.net> <4B0399FD.8090301@sonic.net> <200911191950.23503.nicolas.weeger@laposte.net> Message-ID: <4B08E551.9000907@sonic.net> Nicolas Weeger wrote: >> If one were to go on this logic,than for any given message, it would be >> reasonable for what the player sees to vary based on literacy. > > I was thinking of script-based text garbling, actually, but your approach > works too. I think we have sort of learned over time that coding in such solutions tends to lack flexibility we generally desire, or don't give as good results as we might hope. We could certainly have script based text garbling, but having it do it so that it doesn't look like something that was script based would be hard. > > >> I do agree that some way for the player to handle/deal with these >> messages would be nice. I use to resort to copying information down in >> another window, but that takes things out of the game experience. One >> could imagine something like a special folio object that holds all these - >> the issue is still how to present them to the user. > > Client issue that can be fixed. I don't think this is a pure client solution. That's just my thought. It's never really clear where the split between client and server is. But my thought is something like this: On the server side, there is something like a folio object which characters can put all those different notes into. Perhaps there is even code to see if the character already has a copy of that message. This could basically be just a container object with some special handling. On the client side, it perhaps brings up a window which shows everything in the follow, so you can quickly read through it. Maybe in the form of a book which you just page through. Ideally, each written note would have a title, so there could be a table of contents. Things like 'Dungeons of the Deserts', 'Monsters of the Southern Forests', 'Characteristics of Ogres', etc. While this could perhaps all be handled on the client (when you read something, it automatically records that information in a file), that doesn't seem ideal. The information we are talking about here is really character information - while there is nothing that prevents one from sharing this knowledge, I just don't think it would be a good user experience that if you switched to a different client (or perhaps same client running on a different machine), you've suddenly lost all that information. Things like window positions, keybindings, really are client properties, and in fact, probably would different in different ways based on system I am using (window size/layout is likely going to be different on my laptop than my desktop. Same for keybindings for that matter, since the laptop has fewer keys and some are in different locations). > > > > Nicolas From mwedel at sonic.net Sun Nov 22 01:22:28 2009 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 21 Nov 2009 23:22:28 -0800 Subject: [crossfire] Feature proposition: [img] tag In-Reply-To: <200911191948.45461.nicolas.weeger@laposte.net> References: <200911162229.02114.nicolas.weeger@laposte.net> <20091117025320.5c54f488@a850srvr.kbulgrien.att.net> <4B039774.7000105@sonic.net> <200911191948.45461.nicolas.weeger@laposte.net> Message-ID: <4B08E6B4.7070608@sonic.net> Nicolas Weeger wrote: > Hello. > >> Off the top of the head, I could imagine some quick cases, like: >> - Book containing information about a monster, and containing a picture of >> that monster >> - Same for other objects (more likely artifacts or unique rare stuff). >> However, from a tutorial perspective, displaying the different objects >> inline would make things much clearer, eg 'pull the lever [img=lever] to >> open the gate' type of thing - Last case could be maps of the area - in >> this case, it could just be images used from the editor and shrunk down to >> a smaller initial size. >> >> However, in all cases, some hint about resizing may be needed. For >> example, if a player is playing with a low resolution setup and has done >> something like -mapscale 50, probably any objects you are talking about >> that are map related should be similarly scaled. I'm not 100% sure on >> that. For large images (map areas), the client would likely need to scale >> down if it is too wide to fit in the message window (height isn't as much a >> problem, as at least you can scroll the window up/down). >> >> I'm presuming this will do inlining, and not pop up the image, but I >> suppose it depends on usage - one could envision maps perhaps being popped >> up since they are fairly standalone, but in the tutorial example, you >> probably don't want that popping up. > > Well, I was thinking of popup images, big ones, with maps or zoomed items. > But regular pics inline would work too. > > So maybe it should be [img] and [popup] at the same time? :) More likely want to have something like an img tag with hints, for things like popup, desired size, etc. Note that anything that deals with popups can be annoying in some areas. If you read some scroll and it suddenly popped up a window, I'm not sure I'd like that. It'd probably be better as a default for the message to just be displayed, something like 'This scroll contains a map. Click on map image for a larger view (small map image displayed)' It could be really annoying if you are reading through a bunch of scrolls trying to find the one that actually has useful info to keep having windows pop up. OTOH, this is really a client side issue - up to the client to decide what to do with it. One could envision that on high res displays, an image up to 150x150 may be fine to display in the text window. But on a low res screen, anything more than about 30x30 may be too big to reasonably display. From nicolas.weeger at laposte.net Tue Nov 24 16:04:35 2009 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 24 Nov 2009 23:04:35 +0100 Subject: [crossfire] Changing connection texts In-Reply-To: <200911162312.02249.nicolas.weeger@laposte.net> References: <200911162312.02249.nicolas.weeger@laposte.net> Message-ID: <200911242304.38913.nicolas.weeger@laposte.net> Hello. > Suggestion to change the various messages at login: Apparently, those messages are part of the motd / server rules / news. So they could be changed as part of the default installation, but not that useful for existing servers. It's probably more a client-side modification. Or maybe a complete login rewrite is in order ;) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20091124/3bb9021f/attachment.pgp From nicolas.weeger at laposte.net Tue Nov 24 16:07:00 2009 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 24 Nov 2009 23:07:00 +0100 Subject: [crossfire] How to integrate old stories in the game? In-Reply-To: <4B069D71.3000209@iki.fi> References: <200911162232.05656.nicolas.weeger@laposte.net> <200911191951.18525.nicolas.weeger@laposte.net> <4B069D71.3000209@iki.fi> Message-ID: <200911242307.00984.nicolas.weeger@laposte.net> > Obviously real maps would be the best solution. However, I think the random > map generator does a fair job, specially on the multi-level dungeons; > IMHO the different Scorn quest maps turn out nice and exciting. > > The fact that it does as reasonable a job as it does means that it might be > worth putting a bit of effort into enhancing it... Then maybe a base map, with random books and such? Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20091124/33fc89de/attachment.pgp From nicolas.weeger at laposte.net Tue Nov 24 16:11:22 2009 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 24 Nov 2009 23:11:22 +0100 Subject: [crossfire] Feature proposition: [img] tag In-Reply-To: <4B08E6B4.7070608@sonic.net> References: <200911162229.02114.nicolas.weeger@laposte.net> <200911191948.45461.nicolas.weeger@laposte.net> <4B08E6B4.7070608@sonic.net> Message-ID: <200911242311.22484.nicolas.weeger@laposte.net> > More likely want to have something like an img tag with hints, for things > like popup, desired size, etc. Then let's do the whole trick and use some XHTML subset? > Note that anything that deals with popups can be annoying in some areas. > If you read some scroll and it suddenly popped up a window, I'm not sure > I'd like that. It'd probably be better as a default for the message to > just be displayed, something like 'This scroll contains a map. Click on > map image for a larger view (small map image displayed)' Client-side issue. My opinion: let's implement the tag in basic form, use it, and adjust later if needed. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20091124/237a867f/attachment.pgp From nicolas.weeger at laposte.net Tue Nov 24 16:10:12 2009 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 24 Nov 2009 23:10:12 +0100 Subject: [crossfire] How to integrate old stories in the game? In-Reply-To: <4B08E551.9000907@sonic.net> References: <200911162232.05656.nicolas.weeger@laposte.net> <200911191950.23503.nicolas.weeger@laposte.net> <4B08E551.9000907@sonic.net> Message-ID: <200911242310.12098.nicolas.weeger@laposte.net> > I think we have sort of learned over time that coding in such solutions > tends to lack flexibility we generally desire, or don't give as good > results as we might hope. > > We could certainly have script based text garbling, but having it do it > so that it doesn't look like something that was script based would be hard. Randomly replace a word by random letters, with the same length. That'd do the trick, no? > I don't think this is a pure client solution. That's just my thought. > > It's never really clear where the split between client and server is. > But my thought is something like this: > > On the server side, there is something like a folio object which > characters can put all those different notes into. Perhaps there is even > code to see if the character already has a copy of that message. This > could basically be just a container object with some special handling. > > On the client side, it perhaps brings up a window which shows everything > in the follow, so you can quickly read through it. Maybe in the form of a > book which you just page through. Then let's find a volunteer to code that server side, and implement client-side too :) > Ideally, each written note would have a title, so there could be a table > of contents. Things like 'Dungeons of the Deserts', 'Monsters of the > Southern Forests', 'Characteristics of Ogres', etc. I'd add options for the client to manipulate stuff around. And also to copy items to give to other people - if you have paper, and if you have writing, the higher the level the lower the probability to make copy mistakes. > While this could perhaps all be handled on the client (when you read > something, it automatically records that information in a file), that > doesn't seem ideal. The information we are talking about here is really > character information - while there is nothing that prevents one from > sharing this knowledge, I just don't think it would be a good user > experience that if you switched to a different client (or perhaps same > client running on a different machine), you've suddenly lost all that > information. Sure, server side. We'd need a way to identify uniquely a message, though, which I'm not sure is something we already have. Messages randomly generated, and also messages from /lib/messages Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20091124/62c6df8f/attachment.pgp From mwedel at sonic.net Wed Nov 25 00:47:04 2009 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 24 Nov 2009 22:47:04 -0800 Subject: [crossfire] Changing connection texts In-Reply-To: <200911242304.38913.nicolas.weeger@laposte.net> References: <200911162312.02249.nicolas.weeger@laposte.net> <200911242304.38913.nicolas.weeger@laposte.net> Message-ID: <4B0CD2E8.1000502@sonic.net> Nicolas Weeger wrote: > Hello. > >> Suggestion to change the various messages at login: > > > Apparently, those messages are part of the motd / server rules / news. > So they could be changed as part of the default installation, but not that > useful for existing servers. > > > It's probably more a client-side modification. > > > Or maybe a complete login rewrite is in order ;) While you may jest, I still think that last comment is true. As a very basic level, the client could request both the username & password at once for login, with another button with something like 'create new character' Depending on what the user does, gets appropriate results - while I've advocated rewriting the character creation process, that wouldn't need to happen in this case - if the user clicks new character, it just dumps them in the existing character creation area (but the messages there could perhaps be customized a little better 'Enter desired character name', 'that character name is already in use', 'Please enter password for this character', type of thing. If the user instead tries to login with invalid character name/password, it should just print out a message like 'incorrect login', and not try to create a new character for them, and try again - if the user really wants to create a new character, they should explicitly have to hit the 'create new character button' From mwedel at sonic.net Wed Nov 25 00:59:28 2009 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 24 Nov 2009 22:59:28 -0800 Subject: [crossfire] How to integrate old stories in the game? In-Reply-To: <200911242310.12098.nicolas.weeger@laposte.net> References: <200911162232.05656.nicolas.weeger@laposte.net> <200911191950.23503.nicolas.weeger@laposte.net> <4B08E551.9000907@sonic.net> <200911242310.12098.nicolas.weeger@laposte.net> Message-ID: <4B0CD5D0.6040908@sonic.net> Nicolas Weeger wrote: >> I think we have sort of learned over time that coding in such solutions >> tends to lack flexibility we generally desire, or don't give as good >> results as we might hope. >> >> We could certainly have script based text garbling, but having it do it >> so that it doesn't look like something that was script based would be hard. > > Randomly replace a word by random letters, with the same length. > That'd do the trick, no? Yeah, but as said, that looks likely script based garbling. In a more real sense, if the character is not literate enough, they might not understand the message or in fact misread it. And randomly replacing some words may not do much - you could probably replace a fair number of words with the message still being perfectly clear to the end user. > >> Ideally, each written note would have a title, so there could be a table >> of contents. Things like 'Dungeons of the Deserts', 'Monsters of the >> Southern Forests', 'Characteristics of Ogres', etc. > > I'd add options for the client to manipulate stuff around. > And also to copy items to give to other people - if you have paper, and if you > have writing, the higher the level the lower the probability to make copy > mistakes. I agree - one should be able to copy notes. That said, the starting difficulty of the message would have a high degree on the literacy level of the copied message (at some point, you can only dumb something down so much without it losing most of its meaning) > > > >> While this could perhaps all be handled on the client (when you read >> something, it automatically records that information in a file), that >> doesn't seem ideal. The information we are talking about here is really >> character information - while there is nothing that prevents one from >> sharing this knowledge, I just don't think it would be a good user >> experience that if you switched to a different client (or perhaps same >> client running on a different machine), you've suddenly lost all that >> information. > > Sure, server side. > > We'd need a way to identify uniquely a message, though, which I'm not sure is > something we already have. > Messages randomly generated, and also messages from /lib/messages I'm really not sure how much we should keep the randomly generated messages - I think that may have been a method to have a reasonable base of messages, but with most randomly generated stuff, it figuring out the occurence and difficulty of messages isn't great. I'd almost rather just have the server dump all those to the messages file, and then go through and so some cleanup. We don't have any way to uniquely identify a message. There are different ways this could be done - a 256 bit hash of the message contents would do a good enough job, but that leaves you with a value that is fairly meaningless to look at (and if you fix a typo in the message, that no longer identifies that as the same message) If we gave titles to each message, you could use that - however, who is to say you might not want several things of the same title? Best would probably be to make a unique identifier in the messages file, that could be named to give some clue, but also be made differently (book_of_monsters1, book_of_monsters2). An interesting effect of giving each message a unique identifier is one could use that to track literacy. One shouldn't really get experience for reading the same message, even if just found in a dungeon. Likewise, there really shouldn't be anything that prevents a player from giving/trading something they read to someone else, and that new person getting exp. But that is currently not allowed because otherwise the same player could read it 100 times and get 100 times the exp. If you know if the character has read that message, they could only get the exp once, and giving it to someone else would only be useful if they haven't read it. This could almost be used to create real libraries within the game :) From mwedel at sonic.net Wed Nov 25 01:02:44 2009 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 24 Nov 2009 23:02:44 -0800 Subject: [crossfire] Feature proposition: [img] tag In-Reply-To: <200911242311.22484.nicolas.weeger@laposte.net> References: <200911162229.02114.nicolas.weeger@laposte.net> <200911191948.45461.nicolas.weeger@laposte.net> <4B08E6B4.7070608@sonic.net> <200911242311.22484.nicolas.weeger@laposte.net> Message-ID: <4B0CD694.5060207@sonic.net> Nicolas Weeger wrote: >> More likely want to have something like an img tag with hints, for things >> like popup, desired size, etc. > > Then let's do the whole trick and use some XHTML subset? > > >> Note that anything that deals with popups can be annoying in some areas. >> If you read some scroll and it suddenly popped up a window, I'm not sure >> I'd like that. It'd probably be better as a default for the message to >> just be displayed, something like 'This scroll contains a map. Click on >> map image for a larger view (small map image displayed)' > > Client-side issue. > > > My opinion: let's implement the tag in basic form, use it, and adjust later if > needed. Fair enough. I think my point may be more that the spec (for lack of better work) should be aware we may want to add extra specifiers, and while they client has not requirement to handle them (since we don't know what they are), it shouldn't suddenly break if they show up. It could otherwise be a real pain if we decide we want to add something like [img popup=1], and the client is only looking for [img] and suddenly doesn't work right. So in that case, an old client would still recognize that as a valid img tag - it wouldn't know what that popup=1 thing means, but would display the image just like it always had. From nicolas.weeger at laposte.net Sat Nov 28 13:10:23 2009 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 28 Nov 2009 20:10:23 +0100 Subject: [crossfire] What to find in towns, what to find in the countryside In-Reply-To: <4B08E20A.2070903@sonic.net> References: <200911192332.08732.nicolas.weeger@laposte.net> <4B08E20A.2070903@sonic.net> Message-ID: <200911282010.28743.nicolas.weeger@laposte.net> > Certainly for scorn, as that is a starting area, it makes a lot of sense. > And a lot of the monster maps in scorn don't make a lot of sense. > > For navar city, there are several quest lines that sort of go with some > of the maps in the town (old wizards tower, smuggling operation, etc). But > those are also better in that for the most part, there is some sequence so > you just can't wander into a random house full of monsters. I'd remove all monsters from town, or at least hide them. Or make them non aggressive, and they start attacking if player attacks. Or else we'll need to explain why the town guards are that incompetent! :) > In terms of the NPC's, I think that can work. However, I wouldn't like > there to be NPC's giving quests (not that we really have quests, but you > sort of get the idea) that you have to hunt through all the houses. I > think a method where most of the NPC's may have some basic information (so > that for example they may have tales of haunted houses, etc) is good. Or > for that matter, if there are NPC's in the houses with unique information, > maybe some of the common knowledge would be about that person (Bob over > there is looking for someone to ...) Well yes, you're supposed to know what your neighbourgs are up to :) That'll require much work to link information, of course. So, anyone willing to rewrite the in town maps? :) I'd start with Darcap, since there aren't that many maps. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20091128/ee47014e/attachment.pgp From nicolas.weeger at laposte.net Sat Nov 28 13:12:23 2009 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 28 Nov 2009 20:12:23 +0100 Subject: [crossfire] Changing connection texts In-Reply-To: <4B0CD2E8.1000502@sonic.net> References: <200911162312.02249.nicolas.weeger@laposte.net> <200911242304.38913.nicolas.weeger@laposte.net> <4B0CD2E8.1000502@sonic.net> Message-ID: <200911282012.23315.nicolas.weeger@laposte.net> > While you may jest, I still think that last comment is true. > > As a very basic level, the client could request both the username & > password at once for login, with another button with something like 'create > new character' > > Depending on what the user does, gets appropriate results - while I've > advocated rewriting the character creation process, that wouldn't need to > happen in this case - if the user clicks new character, it just dumps them > in the existing character creation area (but the messages there could > perhaps be customized a little better 'Enter desired character name', 'that > character name is already in use', 'Please enter password for this > character', type of thing. > > If the user instead tries to login with invalid character name/password, > it should just print out a message like 'incorrect login', and not try to > create a new character for them, and try again - if the user really wants > to create a new character, they should explicitly have to hit the 'create > new character button' What I'd suggest: - introduce user accounts, to group characters - let the client gather login, check if account exists, then either ask for password or help create account After logged in with user account, let select character or create a new one. Maybe ingame already - like in a map. Any volunteer to code? :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20091128/b838b4ee/attachment.pgp From nicolas.weeger at laposte.net Sat Nov 28 13:13:49 2009 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 28 Nov 2009 20:13:49 +0100 Subject: [crossfire] Feature proposition: [img] tag In-Reply-To: <4B0CD694.5060207@sonic.net> References: <200911162229.02114.nicolas.weeger@laposte.net> <200911242311.22484.nicolas.weeger@laposte.net> <4B0CD694.5060207@sonic.net> Message-ID: <200911282013.49823.nicolas.weeger@laposte.net> > Fair enough. I think my point may be more that the spec (for lack of > better work) should be aware we may want to add extra specifiers, and while > they client has not requirement to handle them (since we don't know what > they are), it shouldn't suddenly break if they show up. > > It could otherwise be a real pain if we decide we want to add something > like [img popup=1], and the client is only looking for [img] and suddenly > doesn't work right. > > So in that case, an old client would still recognize that as a valid img > tag - it wouldn't know what that popup=1 thing means, but would display the > image just like it always had. Have clients find "[img" then the next "]" and it'll be ok :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20091128/67b826f8/attachment.pgp From agschult at ucalgary.ca Sat Nov 28 13:25:57 2009 From: agschult at ucalgary.ca (Alex Schultz) Date: Sat, 28 Nov 2009 12:25:57 -0700 Subject: [crossfire] Changing connection texts In-Reply-To: <200911282012.23315.nicolas.weeger@laposte.net> References: <200911162312.02249.nicolas.weeger@laposte.net> <200911242304.38913.nicolas.weeger@laposte.net> <4B0CD2E8.1000502@sonic.net> <200911282012.23315.nicolas.weeger@laposte.net> Message-ID: <20091128122557.54544ddc@ucalgary.ca> On Sat, 28 Nov 2009 20:12:23 +0100 Nicolas Weeger wrote: > > While you may jest, I still think that last comment is true. > > > > As a very basic level, the client could request both the username > > & password at once for login, with another button with something > > like 'create new character' > > > > Depending on what the user does, gets appropriate results - while > > I've advocated rewriting the character creation process, that > > wouldn't need to happen in this case - if the user clicks new > > character, it just dumps them in the existing character creation > > area (but the messages there could perhaps be customized a little > > better 'Enter desired character name', 'that character name is > > already in use', 'Please enter password for this character', type > > of thing. > > > > If the user instead tries to login with invalid character > > name/password, it should just print out a message like 'incorrect > > login', and not try to create a new character for them, and try > > again - if the user really wants to create a new character, they > > should explicitly have to hit the 'create new character button' > > > What I'd suggest: > - introduce user accounts, to group characters > - let the client gather login, check if account exists, then either > ask for password or help create account > > > After logged in with user account, let select character or create a > new one. Maybe ingame already - like in a map. > > > Any volunteer to code? :) > > > > Nicolas I like that idea personally. I'd also note that if it's a new account it should probably skip straight to making a new character. As far as volunteer to code? I might be able to find time to code it on the server side during winter break... though I do feel less comfortable with any needed client side changes (C client libs are a bit hairy, and jxclient codebase is unfamiliar) Alex From nicolas.weeger at laposte.net Sat Nov 28 16:26:25 2009 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 28 Nov 2009 23:26:25 +0100 Subject: [crossfire] Player level vs monster level vs experience Message-ID: <200911282326.32196.nicolas.weeger@laposte.net> Hello. How should the monster level relate to the player level? What is the meaning of the monster level? What I can think of: - monster level is (roughly) the level the player should be to kill it - monster level 1 has some characteristics ; each level can improve a skill / competence / max hp/sp / whatever, so calculate level from that ; something like the advancement level of D&D, maybe? - monster level is just there for the sake of it Experience given by a monster has the same kind of issue. Is experience given based on the relative levels of the opponents? Is it arbitrary? How to take account special things of the monster? Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20091128/80d6f141/attachment.pgp From om at iki.fi Sat Nov 28 17:01:19 2009 From: om at iki.fi (Otto J. Makela) Date: Sun, 29 Nov 2009 01:01:19 +0200 Subject: [crossfire] What to find in towns, what to find in the countryside In-Reply-To: <200911282010.28743.nicolas.weeger@laposte.net> References: <200911192332.08732.nicolas.weeger@laposte.net> <4B08E20A.2070903@sonic.net> <200911282010.28743.nicolas.weeger@laposte.net> Message-ID: <4B11ABBF.6040704@iki.fi> On 2009-11-28 21:10, Nicolas Weeger wrote: >> Certainly for scorn, as that is a starting area, it makes a lot of sense. >> And a lot of the monster maps in scorn don't make a lot of sense. >> >> For navar city, there are several quest lines that sort of go with some >> of the maps in the town (old wizards tower, smuggling operation, etc). But >> those are also better in that for the most part, there is some sequence so >> you just can't wander into a random house full of monsters. > > I'd remove all monsters from town, or at least hide them. > Or make them non aggressive, and they start attacking if player attacks. > > Or else we'll need to explain why the town guards are that incompetent! :) Well, Scorn also has an explanation on why neglected houses have monsters in them: the situation with Old Town. -- /* * * Otto J. Makela * * * * * * * * * * * * * * * */ /* Phone: +358 40 765 5772, FAX: +358 42 7655772, ICBM: 60N 25E */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki, FINLAND */ /* * * Computers Rule 01001111 01001011 * * * * * * * * * * * * */ From akirschbaum at users.sourceforge.net Sat Nov 28 18:03:27 2009 From: akirschbaum at users.sourceforge.net (Andreas Kirschbaum) Date: Sun, 29 Nov 2009 01:03:27 +0100 Subject: [crossfire] Feature proposition: [img] tag In-Reply-To: <4B0CD694.5060207@sonic.net> References: <200911162229.02114.nicolas.weeger@laposte.net> <200911191948.45461.nicolas.weeger@laposte.net> <4B08E6B4.7070608@sonic.net> <200911242311.22484.nicolas.weeger@laposte.net> <4B0CD694.5060207@sonic.net> Message-ID: <20091129000327.GA4287@akirschbaum.users.sourceforge.net> > > > More likely want to have something like an img tag with hints, for > > > things like popup, desired size, etc. > > > > Then let's do the whole trick and use some XHTML subset? I'd rather keep the existing media tags implementation rather than switching to another encoding. We do not need maximal flexibility with many options. Instead we need a very small and fixed set of tags to make map-making easy. (Map-maker don't have to remember/choose between many options, map-maker don't have to check whether the message actually works on all systems and clients.) My two cents regarding image scaling (or other options): don't add such options; it complicates both client implementations and the correct use within messages created by map-makers. Instead refer to a correctly sized image: - refer to a 1x1 tile image for inline-images within text (e.g. for monster or item descriptions in scrolls explaining these); - refer to a (say) 5x5 tile image for a picture of the map that the scroll talks about. Having an image-only message (i.e., [img popup=1]) IMO is not too useful; you'll almost always want some explanatory text as older clients will not recognize the [img] tag and thus (silently) ignore it. > It could otherwise be a real pain if we decide we want to add > something like [img popup=1], and the client is only looking for [img] > and suddenly doesn't work right. > > So in that case, an old client would still recognize that as a valid > img tag - it wouldn't know what that popup=1 thing means, but would > display the image just like it always had. I agree with the general idea that options should be optional. But I disagree that a "popup=1" option is needed at all: We already have type information in drawinfo messages. These types can be used to decide whether the text goes to the message area or into a popup window. For example, - BOOK/CARD/PAPER/SIGN/etc. messages should display a popup window as these messages are (normally) generated by direct user-input (an item has been applied). - Types like COMMAND/ATTRIBUTE/SKILL/ATTACK/etc. go into the message area as these are generated asynchronously without direct user action. That said, explicit popup=1 images for messages that go into the message area would "be a real pain", and explicit popups for messages that are displayed as popup windows are not too useful. I have created a prototype implementation for JXClient. It implements [img=] without any options. The image is displayed as inline within the text. Open issue is how to request the image contents from the server: Option a) [img=], for example [img=altar.111] Problem: the "askface" protocol command needs an image number. It is not generally possible for a client to do a lookup from image name to image number. To do this, the server must send a "face2" command before it sends the [img] tag: the "face2" information allows the client to map between image name and image number. Alternatively, the client could do a "requestinfo image_sums" to get all available mappings. Option b) [img=], for example [img=1234] Problem: the server needs to convert [img=altar.111] into [img=1234] within msg..endmsg fields, and generate suitable "face2" commands. Option c) [img=] and make the 'askface' protocol command more flexible: Currently "askface " is used. Additionally allow "askface ". Clients would parse "[img]" tags, then request the needed face by name. I'd vote for Option c): - Option a) forces the server to parse all drawinfo messages for [img] tags. I'd rather avoid this overhead. - Option a) using image_sums causes a (client-sided) lag of 5 seconds and about 90KB overhead when connecting to the server. I don't think this is acceptable. - Option b) forces the server to convert all [img] tags within drawinfo messages. I'd rather avoid this overhead. - Option c) seems to be easily implementable (both client-side and server-side) and will not cause any side-effects to clients not knowing about the [img] tag. From mwedel at sonic.net Sun Nov 29 00:38:01 2009 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 28 Nov 2009 22:38:01 -0800 Subject: [crossfire] Feature proposition: [img] tag In-Reply-To: <20091129000327.GA4287@akirschbaum.users.sourceforge.net> References: <200911162229.02114.nicolas.weeger@laposte.net> <200911191948.45461.nicolas.weeger@laposte.net> <4B08E6B4.7070608@sonic.net> <200911242311.22484.nicolas.weeger@laposte.net> <4B0CD694.5060207@sonic.net> <20091129000327.GA4287@akirschbaum.users.sourceforge.net> Message-ID: <4B1216C9.8020307@sonic.net> Andreas Kirschbaum wrote: >>>> More likely want to have something like an img tag with hints, for >>>> things like popup, desired size, etc. >>> Then let's do the whole trick and use some XHTML subset? > > I'd rather keep the existing media tags implementation rather than > switching to another encoding. We do not need maximal flexibility with > many options. Instead we need a very small and fixed set of tags to make > map-making easy. (Map-maker don't have to remember/choose between many > options, map-maker don't have to check whether the message actually > works on all systems and clients.) > > My two cents regarding image scaling (or other options): don't add such > options; it complicates both client implementations and the correct use > within messages created by map-makers. Instead refer to a correctly > sized image: > > - refer to a 1x1 tile image for inline-images within text (e.g. for > monster or item descriptions in scrolls explaining these); > > - refer to a (say) 5x5 tile image for a picture of the map that the > scroll talks about. > > Having an image-only message (i.e., [img popup=1]) IMO is not too > useful; you'll almost always want some explanatory text as older clients > will not recognize the [img] tag and thus (silently) ignore it. I agree that you probably want other text - only popping up an image is not useful. I see it more as a hint to the client that this could be something to display in its own window and not inline. Even if displayed in its own window, I think the text that goes with it should be displayed in that window. Older clients pose more an issue. If you are doing something like maps, it seems fairly difficult to try to support that with old clients (you could perhaps do an ASCII map). You also get the case of you probably really don't want to display that ASCII map if you can display the actual PNG image. We could perhaps do something like 'if you support images, use this text, if you don't, use this other text', but that seems overly complicated. As long as the major clients support it, I think it is reasonable to state that there is no requirement to be backwards compatible - I think that adds a lot of complication, and it is simpler to just have the users use the latest client. That said, no reason to make things intentionally difficult - one could imagine there are cases where it is inconvenient for the player to bring up the image, so if the message can make things useful (or at least have a description) makes things friendlier. For example, having a message that is just something like 'this scroll contains a map [img=...]' is not very useful - more useful is something like 'this scroll contains a map of the area around Navar City', 'or contains a map showing where dungeon ... is' In that way, the player has enough information to know if they really care what that image is. Maybe you already know what is around Navar City - so don't care about that map, but don't know where a dungeon is, so do care about that one. > > >> It could otherwise be a real pain if we decide we want to add >> something like [img popup=1], and the client is only looking for [img] >> and suddenly doesn't work right. >> >> So in that case, an old client would still recognize that as a valid >> img tag - it wouldn't know what that popup=1 thing means, but would >> display the image just like it always had. > > I agree with the general idea that options should be optional. But I > disagree that a "popup=1" option is needed at all: That was just an example - that was the only option I could think of off the top of my head - there could be others. But my point wasn't to propose those options, just we should design for possibility that there may be options we add to that tag. > > We already have type information in drawinfo messages. These types can > be used to decide whether the text goes to the message area or into a > popup window. For example, > > - BOOK/CARD/PAPER/SIGN/etc. messages should display a popup window as > these messages are (normally) generated by direct user-input (an item > has been applied). I suppose this could be something that is settable on the client. I personally find pop up windows pretty annoying, and would only want to use them when really necessary. I don't consider a book that has 3 lines of text something that is needed to got into a pop up window - that can display just fine in the messages pane. But I don't really want different behavior based on the content of the book - it would be odd/confusing for some books to display in the message pane, and others to do a pop up window. Note also that one problem is that the book/card/paper, etc, types are based to object type/subtype. Thus, if you wanted to make objects of that type that don't do popups, you now need a new object type/subtype (maybe mapping to an existing readable type). That in itself isn't really flexible either. > > Open issue is how to request the image contents from the server: > > Option a) [img=], for example [img=altar.111] > > Problem: the "askface" protocol command needs an image number. It is > not generally possible for a client to do a lookup from image name to > image number. To do this, the server must send a "face2" command > before it sends the [img] tag: the "face2" information allows the > client to map between image name and image number. > > Alternatively, the client could do a "requestinfo image_sums" to get > all available mappings. > > Option b) [img=], for example [img=1234] > > Problem: the server needs to convert [img=altar.111] into [img=1234] > within msg..endmsg fields, and generate suitable "face2" commands. > > Option c) [img=] and make the 'askface' protocol command > more flexible: > > Currently "askface " is used. Additionally allow > "askface ". Clients would parse "[img]" tags, then > request the needed face by name. > > > I'd vote for Option c): I agree. Since we don't have any image names that start with numbers, it is pretty easy for the server to parse that difference. > > - Option a) forces the server to parse all drawinfo messages for [img] > tags. I'd rather avoid this overhead. It probably wouldn't be as bad as you might things, since in general the messages would be short, and it would only need to be done when the client tries to access something that has that type. The server could optimize this by checking for img tags at load time and setting a field to denote if the message has one or not - if it doesn't, then the server doesn't need to do any work. > > - Option a) using image_sums causes a (client-sided) lag of 5 seconds > and about 90KB overhead when connecting to the server. I don't think > this is acceptable. > > - Option b) forces the server to convert all [img] tags within drawinfo > messages. I'd rather avoid this overhead. The problem here also is that image numbers are not consistent - so it is not like the server can do this just once - it has to do it every time the message is used. In some ways, this is more costly as option A, as it has to copy/modify the message string at each use. > > - Option c) seems to be easily implementable (both client-side and > server-side) and will not cause any side-effects to clients not > knowing about the [img] tag. I agree. From mwedel at sonic.net Sun Nov 29 00:51:59 2009 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 28 Nov 2009 22:51:59 -0800 Subject: [crossfire] Player level vs monster level vs experience In-Reply-To: <200911282326.32196.nicolas.weeger@laposte.net> References: <200911282326.32196.nicolas.weeger@laposte.net> Message-ID: <4B121A0F.5000408@sonic.net> Nicolas Weeger wrote: > Hello. > > > How should the monster level relate to the player level? > What is the meaning of the monster level? > > > What I can think of: > - monster level is (roughly) the level the player should be to kill it That is how I see it - monster level and player level should roughly match. But in this context, I'd sort of say a group of monsters and player level should roughly match. For example, at first level, the character will be fighting typically large groups of level 1 monsters, it's not a 1:1 battle. But that first level character might be able to take on a level 4-5 monsters on a 1:1 basis, but should die if he takes on a group of them. However, in some ways, this gets tricky - some monsters are much more dangerous in groups do to overlapping spells, damage output, etc. > - monster level 1 has some characteristics ; each level can improve a skill / > competence / max hp/sp / whatever, so calculate level from that ; something > like the advancement level of D&D, maybe? Except for the most part, there are not that many things to adjust for monsters in crossfire - you do have level, hp, ac, sp, and skill levels. But if all level 15 monsters had the same hp/ac/sp, it would be pretty boring - you need to be able to have enemy wizard with a bunch of sp, but maybe not as many hp, etc. In theory, monsters should have all the same skills as players, and those be set at appropriate levels. Right now, I think a lot of the code just uses monster level for skill level, which more or less works. > - monster level is just there for the sake of it > > > Experience given by a monster has the same kind of issue. Is experience given > based on the relative levels of the opponents? Is it arbitrary? > How to take account special things of the monster? When I was doing the rebalance, I was basically setting a monsters exp based on its level, but there was still a range. That said, I think it would be completely reasonable to redo it - exp is based solely on level of the monster. If a monster is too easy for that exp, then it needs to be adjusted in some way (which could mean lowering level). However, keeping it a monster attribute does allow for maximum flexibility - for example, when redoing it, I basically had this as a exp value based on level of monsters: 1 <10 exp 2 25 3 50 4 100 5 250 on so on. But in this model, there are some big gaps - one could reasonably say a tough level 4 is maybe worth 125, and and easy level 5 (but still harder than that level 4) is 200 From mwedel at sonic.net Sun Nov 29 01:10:11 2009 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 28 Nov 2009 23:10:11 -0800 Subject: [crossfire] Changing connection texts In-Reply-To: <200911282012.23315.nicolas.weeger@laposte.net> References: <200911162312.02249.nicolas.weeger@laposte.net> <200911242304.38913.nicolas.weeger@laposte.net> <4B0CD2E8.1000502@sonic.net> <200911282012.23315.nicolas.weeger@laposte.net> Message-ID: <4B121E53.2050607@sonic.net> Nicolas Weeger wrote: >> While you may jest, I still think that last comment is true. >> >> As a very basic level, the client could request both the username & >> password at once for login, with another button with something like 'create >> new character' >> >> Depending on what the user does, gets appropriate results - while I've >> advocated rewriting the character creation process, that wouldn't need to >> happen in this case - if the user clicks new character, it just dumps them >> in the existing character creation area (but the messages there could >> perhaps be customized a little better 'Enter desired character name', 'that >> character name is already in use', 'Please enter password for this >> character', type of thing. >> >> If the user instead tries to login with invalid character name/password, >> it should just print out a message like 'incorrect login', and not try to >> create a new character for them, and try again - if the user really wants >> to create a new character, they should explicitly have to hit the 'create >> new character button' > > > What I'd suggest: > - introduce user accounts, to group characters Yes - that makes sense. Other than user account names being unique, any other requirements we should have for them? Should some game things maybe be made account wide properties and not character properties? Off the top of my head, I could think of things like apartments. > - let the client gather login, check if account exists, then either ask for > password or help create account > > > After logged in with user account, let select character or create a new one. > Maybe ingame already - like in a map. I don't really like an in-game solution. While easy to do, and easy for all of us to deal with, its not great for new players. But I'm also not sure if your ingame comment refers to selecting a character to play or creating a new one. For creating a new one, we could perhaps leave the existing mechanism there since redoing is more work. But making in game (map based) character selection I think would be more work than just doing the appropriate dialogs. In thinking about it, this is sort of the flow I see: Step A - account creation/verification: 1: Player chooses to create new account, or enters username/password for account. Note there should probably be some option to also change the account username/password. 2: If player enters correct username/password, go to character selection step (step B) 3: If player enters incorrect username/password, display message, go to step 1 above. 4: If player creates new account, need to verify unique account name, mechanism to set password. Question on accounts: Where do we store this information? May be a flat file or dbm file or something? After all, the only information associated with an account is the name, password, and characters for that account - not a lot of information here. But flat files don't work good if you have thousands of entries. Step B: Character selection: 1: Player can choose from existing characters (display names), create a new character, or associate an existing character with this account (after all, for all characters existing before this change, they won't be associated). 2: If character selects existing character, just load up that character and play - assume that if the character has been set up for account, there is no need to check password, etc. 3: If player creates new character, basically same as now, but we don't need a password - like #2 above, since the character is associated with an account, we use that password. 4: If player needs to associated a character with this account, and for character name and password. See if that is correct - if not, error out. If so, verify that the character is not already associated with an account (if so, give them an option to associate with this new account?). Once player associates character with account, go back up to B.1 - player may not want to play that character immediately - I could see a case when first creating the account that you want to associate all your characters with it. Note also that within the client, in addition the existing logout, there another option is needed. Logout could be as it is now - logout and go back to metaserver selection. But also log out character and go back to character selection - should make it somewhat easy for player to choose which character to play.