On Mon, 14 Aug 2006 22:21:38 -0700, Mark Wedel <[EMAIL PROTECTED]> wrote: > id being the archetype probably makes the most sense. If you make it > numeric, > it would have to be some sort of hash I'd think so that it is consistent, and > then there is always the danger that something new is added causing the hash > conflict, resulting in the hash changing anyways.
In most cases, using the archetype as <id> is the best choice. But I would also like to be able to document some artifacts, not only the archetypes. For the artifacts, the best choice would probably be "archetype name + title", which should be unique. > Alternatively, the number itself could be in the archetype, but that would > seem to be full of problems - duplicate numbers, etc. > > Given this content isn't sent very often, not sure if using the longer > archetype name would be a problem. Right. Even if the string is a bit longer when the title is included, that should still be acceptable for something that is not sent often. > Spells: > As of now, you can't learn a spell unless you are sufficient level to cast it > (DM's could teach you spell without that restriction, but that is a bit of an > edge case). Now it is possible you learned a spell, died, lost some levels, > but > then in that case, you still knew all the attributes at once. While it is > reasonable to say that since you can't cast the spell, you can't remember the > details - the problem is that could then lead to outside game notetaking on > what > you did know. Yes, I was thinking specifically of the case of a player losing levels after a painful death. And I think that it is better to let the player keep the information, but simply add a note saying something like: "you are currently unable to cast that spell". > For the same reason, I think it is good to give full information for the > spells the player knows. Some of it could be figured out empirically - I'm > denied healing, and can't cast that spell, thus it must be in the healing > path, > etc. But some is playability - if that information is really needed, and > isn't > being provided, I'll just go elsewhere for the information (spoiler, > whatever). In that case, there is really no reason to keep the random books about spellpaths. If learning a spell is enough to know which path it belongs to and if the table of spells can be sorted by path, then the books about spellpaths are almost useless. The only hint that they could still provide is the name of some other spells belonging to the same path and that are not known yet by the player. However, this information is not very important and some of the spells may not even be available at all (e.g., special prayers). > Storing information: It should be stored in the archetype it describes - > the > addition of files in the lib directory to describe archetype is the wrong way > to > go (if anything, we are trying to move away from that, with things like the > .trs > file). Right. When I mentioned a file in the lib directory, I was thinking about where the server can find this information. But it could of course be collected from the archetypes, just like the treasure lists. > There is the lore/endlore fields right now which was envisioned to hold > information on various things that would then go into books. I'd suggest > that > could be used, with perhaps defined tags for different fields, eg: > abilities: ... > desc: .... > other: .... > > and so on. Good idea. Using the "lore" attribute is probably the best solution. > There may still need to be some information in the lib directory for data > that > isn't directly related to any archetype (rumors of a dungeon, etc). One > thought > on that is that the file should probably be extended to have region clauses - > it > doesn't make much sense to be hearing about information of a dungeon near > scorn > if you're in wolfsburg. By localizing the messages, it then means when in > scorn, you'd get lots of information about what is in and about scorn, etc. Also a good idea. This would encourage the players to visit other regions and collect their random books. The region-specific information could even be part of the maps module rather than the server module and then collected and stored into a file in the lib directory. > > - If the player already knows some piece of information, it would be > > nice to leave the corresponding page(s) in the game instead of > > taking it away. This is how spell books and skill scrolls work > > today. How should the server know if the page(s) should be removed > > or not? Should the server keep a list of all things that have > > already be sent to the client? > > I might have missed it further above, but this note here suggests that this > information in cached client information? Yes, my idea was to cache this information on the client side in order to allow the player to browse through it offline. I would like to have enough information in these player books so that the Crossfire spoiler and handbook would not be necessary anymore. And it is useful to be able to read this information offline, without playing. The client could provide its own interface for reading this special book (e.g., a large window with various tabs for the different kinds of information: monsters, spells, etc.) but I think that it would also be useful to be able to read it in a standard HTML browser, directly from files generated and stored on disk by the client. The HTML view could use nice CSS and images to make the information more attractive. Offering the HTML output would also make it easier for the clients: some clients could implement the book browser in their own interface but some other clients could simply rely on an external web browser and would not have to worry about displaying text and images from all these messages. So when a player using such a client gets a new piece of information and wants to read it, the client would simply trigger some external web browser or help browser, as this is done in other programs to display online docs. > If so, I'm not sure that is a good approach or not - there is no guarantee > that players will be on the same computer, and thus would lose that > information > (currently, the only thing the client really stores locally is the user > preferences). I'd say that would be unexpected by most players. And if > done, > then such caching would have be be segregated based on the server it came > from, > since different might not agree on all the data. > > The client caching the data would also infer that this knowledge is really > player knowledge, so if you played a bit and made a new character, that first > level character would have a lot of knowledge. Maybe that isn't bad - not > 100% > sure. Sure, these are pros and cons to the client caching option. I would like to have it because I am not permanently online and I would enjoy being able to read some of the hints and other information collected by my character even if I am not connected anymore. One way to avoid problems when players use multiple computers or connect to multiple servers would be to do a cache synchronization when the player (re)connects. If the server keeps track of what each character knows then it could send this list to the client, which would then remove some of the messages from its cache and request the missing ones from the server. I think that the general information about the religions, quests and other random messages should never be removed from the cache. Maybe this could even be the case for the monsters and artifacts. The only categories that the (non-cheating) client should remove from its cache are the list of spells and all formulae (alchemy). > I do say I think it would be nice from a game perspective to actually know > what information the character has learned - alchemy could require you know > the > recipe, quests/npcs could give pieces of missing information, etc. Yes. The drawback is that the server would have to keep track of all that on a per-character basis and that could be a rather long list. > > - These special books could be represented as objects in the players' > > inventory or they could be "out of the game" with a specific client > > interface to access them (just like the list of skills or spells can > > be obtained without using an object). > > I'd think that if they are in game, then if you applied one, there would be > too much information pretty quickly to reasonable read/parse, so I think some > other interface is needed. Well, of course I never intended these objects to display their information in the normal info window. What I had in mind is that if these books are shown in the player's inventory, applying them would open the new book browser (new interface with images, etc.) or maybe even trigger an external web browser. Just like some programs do when you press F1 to get help. Showing the special book as an item in the inventory would simply provide another way to start the book browser (the other way being via the client menus) and maybe also a way to add weight to the player if the book contains a lot of information. > It could really be seen as an interface to the characters memory. Yes, that's a good way to describe it. So maybe it does not need to be shown in the inventory. > > - All messages described above can be sent in plain text (maybe with a > > bit of markup for cross-references), including the images if they > > refer to existing faces. However, if we find an artist who has a > > lot of spare time to spend on crossfire, it may be possible to > > enhance the messages with custom images to be included in the HTML > > rendering of the player book. How should the images be sent to the > > client in this case? As special faces or as part of the messages? > > There isn't any reason that the image couldn't be added in the archetypes > and > sent in the normal way (I'm not even sure if there is any real maximum size > if > it is just an image not displayed on the map). Sending it as part of the > message would seem ugly. Large images could be useful in some messages. For example, we have some random messages containing ASCII art maps. Replacing them by a nice PNG image would be an improvement. Especially because the ASCII art maps do not work anymore with a proportional font. Thanks for the feedback on this proposal. It is not for the near future anyway, but maybe some bits of it could be considered for 2.x or 3.x? -Raphaël _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
