• Announcements

    • That Which Mourns Soundly

      Logging in   05/10/2017

      If you had an account and can't log in as of 5/9/17, this may be because of a change in logins with new forum software. You can log in using your publicly displayed name (not your username) or your email address and the password you used before.   If you have problems with this, please ask any of the mods or admins. 
Sign in to follow this  
Followers 0
Celtic Minstrel

Item Descriptions

23 posts in this topic

Although I've implemented the ability for E3-style item descriptions, I'm having trouble deciding on some of the details. Currently, the descriptions are always visible, even when the item is unidentified (which appears to have been the case in E3, as well). I personally think this is important, but in some cases it might be nice to have a different description for when the item is identified. Also, ADoS wrote his descriptions in the assumption that they are only visible when identified, and it would be a shame to waste the ones that give away what the item is.

 

Personally, I think it makes more sense for the item descriptions to not depend on whether it's identified (it's not like it looks any different once you know what it does!), but I can kind of get why you might want to change them (particularly for items with a concealed ability, such as the mist globes). I'm not entirely sure of the method, however. Also, I don't think it's really a problem for item descriptions (for unidentified items) to occasionally hint at the fact that an item is magical, or even be specific enough that you can pretty much tell exactly which item you have. (For example, "Shield of Klin" might well have Klin's name engraved into it. This doesn't make identification totally useless, though, as identification reveals specifically what it does... in most cases at least.)

 

Another problem I have with my current implementation is that each item has its own unique description, but in many cases these descriptions are identical for a number of similar items. Using scenario strings (instead of strings stored with the item) is also out of the question, because items can be carried between scenarios.

 

Here are some of the possibilities, in no particular order. Some of them may be mutually exclusive.

  1. Create a registry of generic item descriptions in the scenario, which would be used only for unidentified items. The description stored with the item would used when identified, if present. Exactly how the generic item description registry would work is uncertain; I was thinking maybe using the unidentified name of the item as a dictionary key, though.
  2. Parse the item descriptions differently depending on whether the item is identified. For example, eliminate passages in square brackets if the item is not identified.
  3. Store two separate strings with the item, one for when it's identified and one for when it's not.
  4. Leave it as-is, but don't show the description when unidentified. I feel that this defeats the point of a description though, which in my opinion should mainly be a physical description of the item.
  5. Leave it as-is and accept that some item descriptions may be a dead giveaway.
  6. Leave it as-is and rewrite some of the descriptions of unique items. I'm not totally opposed to this, but some of those descriptions are quite nice, and ADoS wouldn't be happy about losing them. (This is an open-source project, so he may have to get used to the idea that his work may be incrementally overwritten, but ... well, this would require more than just minor tweaks. The affected descriptions would need to be rewritten from scratch. And some of them seem pretty good to me.)
  7. ... I get the feeling that I forgot one thing I was going to say here.

 

I'm kinda leaning towards #1 and #2 at the moment (or maybe #1 and #3), but I thought it might be good to get some input as well. Perhaps there are other possibilities I haven't thought of.

 

(For the curious, the current descriptions from ADoS can be read on the repository. Some of them still need improvement, particularly the slith spear and vahnatai items, but many of them are quite good.)

Share this post


Link to post
Share on other sites

Some games will even change the GRAPHIC of the item when it is identified, not just the description. I know Castle of the Winds did this, and I'm certain there are others. From a literal standpoint, the item doesn't change shape, but from a gameplay standpoint it can be desirable depending on how the game is designed. Beyond that, the dry physical description of an item alone isn't going to be especially interesting to most players, and I fear it would become busywork for the designer, instead of flavor for the scenario which I think is the interesting part of the concept.

Share this post


Link to post
Share on other sites

Some games will even change the GRAPHIC of the item when it is identified, not just the description. I know Castle of the Winds did this, and I'm certain there are others. From a literal standpoint, the item doesn't change shape, but from a gameplay standpoint it can be desirable depending on how the game is designed. Beyond that, the dry physical description of an item alone isn't going to be especially interesting to most players, and I fear it would become busywork for the designer, instead of flavor for the scenario which I think is the interesting part of the concept.

Perhaps items would, by default, have the same graphic and description regardless if it is identified or not. The designer can add a second graphic and description for when the item is identified if they so desire, but it wouldn't be necessary. Though I think the Vahnatai and Slith items should have two descriptions, as an account of the Vahnatai's whole culture is a bit too specific for a funny looking sword :p

Share this post


Link to post
Share on other sites

I'm not really suggesting we offer swapping graphics so much as emphasizing that realism isn't always the goal, especially in a game where the sprites are 28 pixels by 36 pixels. BoE is and always has been a creative-writing based game. I think any extra text that is included would be better to be about creativity and flavor rather than strict realism.

Share this post


Link to post
Share on other sites

I slept on it and this is my official position on the matter: We should either hide the string when unidentified or allow for two strings. Otherwise, we should eliminate the feature altogether. I believe physical-only descriptions are boring and will just make extra work for designers for no useful benefit, and creating a syntax for hiding parts of it will make extra work AND be just one more thing for designers to learn for no useful benefit.

Share this post


Link to post
Share on other sites

What do people think of this proposal?

 

1. Every item has a description stored with it. This description is shown only when the item is identified. In this description, the sequence %% (or something similar) will be substituted with #2, below. Additionally, if this unique description is an empty string, it will be ignored.

 

2. Each scenario stores generic descriptions that are shown for unidentified items. These are edited in the same way, through the Description button in the item edit dialog, which will now have two text fields and clarify that one of those descriptions will apply to all items with the same unidentified name.

 

3. Have a flag in the item which makes it use its unique description even when unidentified (alternatively, a separate description stored with the item). This allows things to have customizes unidentified descriptions even if they have the same unidentified name as something else.

 

With this system, unidentified items may change (or even lose) their description when carried into a different scenario.

 

EDIT: Oh yeah, if the item has no unique description, then maybe the generic one could be copied into it when you leave the scenario.

Share this post


Link to post
Share on other sites

It just seems so complicated. I think it would be better to just have two description fields that call Scenario Strings or some sort of Description String we could add, and then just write the string permanently to the item when leaving the scenario. That would take care of duplicate descriptions and all the associated copy-pasting, and still keep things very easy to understand. It would be intuitive because it follows the already-existing scheme of other message fields.

Share this post


Link to post
Share on other sites

Okay, first of all, let me respond to a couple of things that I missed (or more accurately, skipped over) before.

 

I don't think the item descriptions need to be just boring physical descriptions. I think physical descriptions is their primary role, but there's no reason why humour and additional background info can't be included in some cases (like mention of the sliths or vahnatai). I do think descriptions of the item's properties and uses are a little out of scope (with the possible exception of some items with concealed abilities; I'm mainly thinking of the mist globe here).

 

About swapping graphics... well, that just kinda makes the situation even worse in my opinion. My point is that identifying the item does not change its appearance. If you're swapping the description when it's identified, it doesn't necessarily suggest that the item looks different when identified. If you're swapping the graphic, well... suddenly identifying an item changes its appearance.

 

If you accept that the item descriptions function as a detailed physical description of the item, then it's obvious that the item description should be the same independent of whether the item is identified. On the other hand, from that premise it's also obvious that some items would need to have descriptions which effectively identify what they are, even when they are technically marked as unidentified. For example, "This is a large shield with the name KLIN inscribed on the back." makes it obvious that the item is, in fact, the Shield of Klin and not some other generic shield. Or, "It's a small rock with bits of glitter in it." makes it obvious that what you have is not an ordinary rock but is in fact something more valuable, such as silver ore or rough diamond. So there's a clear problem with accepting that the item descriptions function as a detailed physical description of the item, even if you accept in the first place that that's what they're for.

 

Now, the basic premise - "item descriptions are primarily a physical description of the item" - does not necessarily contradict a system where identified and unidentified items have different descriptions. You could argue that the identified description simply includes additional details that you had not noticed before you identified the item. But when those details are things that you could have easily noticed just on a cursory inspection, it kind of strains belief. Personally, I don't think it's necessarily a bad thing for item descriptions to sometimes hint that the item is more valuable than it appeared at first glance, nor do I think it's necessarily bad for a few items to have unique descriptions that instantly give away what they are, though I would prefer to avoid the latter as much as possible. Still, even in such a system, instantly knowing what the item is doesn't tell you its stats (unless you're metagaming and looking up the stats outside the game). So it's still useful to get that item identified even though you technically know what it is.

 

-----

 

Now, on to what ADoS just said about the complexity of my earlier proposal. It's true - it's a complex proposal. (I'm particularly uncertain on point #3.) From the designer's perspective, they would be presented with a dialog offering two separate descriptions, but one of those descriptions is shared by multiple items, and changing the item's unidentified name has the side-effect of altering its unidentified description. I'm not entirely satisfied with the solution, which is kinda why this thread exists in the first place.

 

As for your alternate proposal... well, referencing scenario strings is definitely possible. It's not even particularly difficult. However, it causes problems when you leave the scenario, and/or when you enter a new scenario. Copying the strings into the item properties does kinda work as a solution. It feels like an ugly solution, but it's doable, certainly, and it's quite true that it solves any problems of fully-duplicate descriptions (though it doesn't solve partially-duplicate descriptions). In summary... I don't like your solution, but I can't see any strong points against it, either.

 

-----

 

On an unrelated note... something needs to be done about preset items. These are the starter items that are given to your PCs at character creation time, as well as the potions made with the alchemy skill. Not only do they lack a description currently, they also don't stack with equivalent items in scenarios (when applicable - eg, arrows).

Share this post


Link to post
Share on other sites

My philosophy on anything in BoE is to give more control to the designer wherever possible. I've been saying that all along and it hasn't changed. The designers are the drivers of the interest in this software, without whom players have no reason to use it, and I am in favor of removing all restrictions, even related to balance issues, which are not required to make the software function. Just because we can't see a use for something doesn't mean someone else can't come up with something creative with it we hadn't imagined. BoE has always been about that, and there has always been soft, community-based control over excessive "Monty Haul" type scenarios and badly-written scenarios without needing to actually force it on people. That's how designers have always learned and improved.

 

As for preset items, I say the most generic descriptions possible, if any, should be applied to starting equipment. "This is a simple knife. It does a small amount of damage with a sharp edge, and does more damage with increased Strength and Edged Weapons skills. More Dexterity will let you hit more often." Sorta give a little gameplay tip for new players, since this is the first equipment a new player will see. Alchemical potions maybe ought to be set within the scenario, with a handful of strings set aside for them. As for stacking, I think it'd be best if, when you pick up something that stacks with something you have, the new description overwrites the old one, so you always have the fresh one from the scenario you're in. This includes starter arrows.

Share this post


Link to post
Share on other sites

Also, as far as...

 

(though it doesn't solve partially-duplicate descriptions)

 

...I think I can say with a good amount of certainty that you are the only person on the planet who would at all be put off by partially-duplicate descriptions. That's what Copy-Paste is for. I get you're the lead developer and you make the final decisions, but I can still advise recognizing that designers like to do the designing, and remember that any time someone came up against a limitation Jeff implemented, there was a lot of griping and insults headed his way. The design community has consistently despised any form of limitation that Jeff put in just because he personally felt it was a good idea rather than because it actually adds something useful to the software. I don't expect that will change.

Share this post


Link to post
Share on other sites

How did this conversation devolve into attacking Jeff?

Share this post


Link to post
Share on other sites

Okay, now can I get feedback from people who aren't ADoS? If I only wanted feedback from ADoS, I wouldn't've bothered to post here.

Share this post


Link to post
Share on other sites

Who's attacking Jeff? I'm not. That's old stuff and he's always done his best. I've always admired him. I was just saying, people getting annoyed at all the limitations is a major part of the history of BoE and its community, and getting rid of them was always something people badly wanted from an open-source release. I can blame Spider for the limitations if you want.

Share this post


Link to post
Share on other sites

I didn't really have any opinion on the matter, but after some thinking I've concluded #2 may be the best option. I can't really think a good way for #1 to be implemented, or if it would even make anything better (it'd mean Iron Shield and Shield of Klin would have the same description, and I think they shouldn't because KLIN). #3 is probably a bit too much, as I'm assuming an item description wouldn't change THAT much for the designer to have to use a whole new string.

 

That's what Copy-Paste is for.

I think the reason for trying to get rid of duplicates is the fact that it makes the program unnecessarily large (and slow). I'm a first year IT student so I don't know much programming, but I at least know copy-pasting code, when you don't need to, is kinda bad. In this case though, with so many items that are so similar, it might not be possible to elimiate duplicates altogether. Maybe if the system of items were changed to have a 'base' (say, Knife) with modifiers (i.e. Iron, Steel, Magic) instead of what it is now, but I don't really see that happening.

Share this post


Link to post
Share on other sites

Thanks for your input, MisterManlyMan! :D

 

For reference, the entirety of BoE is about 20 MB, if you don't count the documentation. The program will not be large or slow just from having a few hundred extra 256 character strings. I just did the math and if you have 512 items each with unique 256 character identified strings and unique 256 character unidentified strings, it will add 262,144 bytes to the scenario. That's not really a concern for computers made during this millenium.

Share this post


Link to post
Share on other sites

So basically, you're favouring the idea of parsing item descriptions based on whether the item is identified? I'll note that this by itself doesn't do much about eliminating duplicates, though.

 

Size is not the only concern with duplicates. It makes it harder to work with descriptions when several items have the same description, because when you want to change that description, you need to change it in several different places.

Share this post


Link to post
Share on other sites

Right, and using Scenario Strings or special Description Strings (which could be used for other description stuff like Special Items, Jobs, and I think we should put strings on monsters for Scry Monster) would make that simple. You make your items, plug in the number to each item you want to have the same description, and you're done. -1 leaves a default or blank or something.

 

EDIT: Come to think of it, using regular Scenario Strings would allow them to be easily accessed by nodes and such, if you wanted to call a description in Display Message or something, for whatever reason. If that were important to anyone.)

Share this post


Link to post
Share on other sites

yeah i don't think size should be a concern. i mean, it's been a bit since I looked at stuff, but wasn't one of the plans for the new scenario format to compress everything? Even if it wasn't, designers will just pop their .exs in a zip anyway, to also throw a README in there.

 

as a happy medium, perhaps some sort of find/replace functionality that could hit all item descriptions? i dunno.

Share this post


Link to post
Share on other sites
i mean, it's been a bit since I looked at stuff, but wasn't one of the plans for the new scenario format to compress everything?
The new scenario format (which is .boes instead of .exs) is literally a tarball with a specific directory structure. So yeah, it's compressed. (I guess designers might still pop it into a zip so they can add a readme, though.)

 

Find/replace functionality for strings would certainly be great; you can already open the XML files in a text editor and use the find/replace there, but, well, that's quite a bit less convenient - you need to decompress the scenario first. (You don't need to recompress it though, since the editor can work just fine with a folder that has the same directory structure as a scenario tarball.)

Share this post


Link to post
Share on other sites

idea to make that super duper convenient: a magic button "manually edit strings" or something, that passes that xml on to the system's default text editor. user does find&replace/regex/whatever, hits save, boe does a quick validation to make sure it's still XML and puts it back in the proper spot

Edited by sylae
just copy the xml to /tmp/JAFNKLFDHSDJKLNLKGNS/strings.xml or something, and wait for the mtime to be changed i guess?

Share this post


Link to post
Share on other sites

...

 

Well, I suppose that's a possibility.

 

I think I'd prefer something that doesn't shell out to an external text editor, honestly. Anyway, shelling out to an external text editor is likely not as easy as it sounds.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0