I am slowly continuing with my Amstrad game port At the moment I am building all the objects inside the different locations, doors, etc. Thing is that this game happens inside a space station and, already in the Amstrad version, the environments were quite detailed. However, due to the lack of RAM, I used a trick that worked very well: since all the furniture in the station is mainly the same (made by the same company and using the same materials) I easily managed to create common definitions for things like “upholstery”, “plastic”, “steel”, “concrete”, etc. that could be happily used in many locations to give the player generic (and trivial) details about the construction of some objects.
PAWS mostly works associating a noun with a verb (actually, just the first 5 letters of the noun, to save even more memory). This means that in a location I could have a plastic and a sofa and the commands “x chair upholstery” or “x sofa upholstery” would be interpreted just as “x upholstery” and produce the same output. In the same way, something like “x the upholstery in the chairs” or “x dirty upholstery” would be equally valid, since “examine” and “upholstery” are the only things being checked. Therefore, if you give “upholstery” a definition that is general enough, the approach works well in many circumstances.
I am creating several general multi instance objects with the same idea in mind and I was wondering if there is a way to just allow the player to refer to a particular object noun independently of the adjective he/she is using (and, in general, any other words). I was looking for info about this, but sadly I could not find anything besides how to override an adjective if it is between " " or using wildcards for names :/.
You should look at the powerful <<>> adprose mechanism, whose can be abused up to becoming like a scripting language of sort.
in your specific case, the desc of the multi instance obj became something along the lines of:
(BEWARE: is a concept coded on the fly, and absolutely NOT tested)
Sadly, the <<>> mechanism don’t support switch…case, but you can programmatically do this:
desc {
{switch (gplayer.isIn)
{case room0: room0txt; break;
case room1: room1txt; break;
case room2: room2txt; break;
// case room3: room3txt; break;
default: "generic description"; break;
}
}
followed (or preceded…) by the text definitions:
room0 = "description of the item in room 0";
room1 = "description of the item in room 1";
and so on… (I actually used this mechanism for a really complex player character description, but the adaption to object in description is done on the fly, surely isn’t precisely correct)
HTH and
Best regards from Italy,
dott. Piergiorgio.
(Caveat, below is all for adv3; adv3lite could have different nuances.)
Question, do you want the game to alias even adjectives that make no sense (ie >x underwater upholstery) when none such exist in game? Or only adjectives that make sense? Assuming the latter, and in order to avoid tiresome disambiguation, I think you would need to play with MultiLoc (see page 255 of Learning TADS3). If I get a window, will testdrive a solution later, but it would probably go along these lines:
class UpholsteredFurniture : object; // mix-in to identify where you want the upholstery
upholsteredChair1 : UpholsteredFurniture, Chair
vocabWords = 'reclining chair'
// std definition stuff
;
chintzyUpholstery: MultiLoc, Decoration
vocabWords = '(chair) (sofa) (dirty) (plastic) (etc) upholstery'
name = 'plastic upholstery'
desc = "Cheap, industrial upholstery. Not the pattern you would have gone with. "
initialLocationClass = UpholsteredFurniture
;
You would need to exhaustively provide all possible (adjectives) in vocabWords to disallow non-game words. I think you would want this instead of MultiInstance as the latter, while being more 'realistic' would result in disambiguation hell.
I encountered an analagous many-location vocabWords complication and created a PreinitObject to automatically add location nouns as adjectives where instantiated (ie would add chair as an adjective to chintzyUpholstery automatically). Not sure how that would play out with multiple chairs in a room, would need to test. Would be happy to share if that is helpful.
If you really, truly, wanted to ignore nonsense adjectives and match anyway, I think you would need to play with the matchNameCommon method (pg 309 Learning TADS 3), though that feels maybe riddled with gotchas and would need careful application.
…it occurs to me that you might be able to alternately use MultiInstance upholstery in conjunction with CollectiveGroup (Learning T3, p 260). Without playing with it, not sure which solution is cleaner/closer to what you want. (Collective Group should match any present instances of upholstery and provide a single description, though I think you would want to provide identical descriptions in both the MultiInstance and CollectiveGroup, as there are nuances to when CollectiveGroup kicks in.)
Lol, am posting way too fast. I am still internalizing the implications of the >verb (ignored adjective) noun command paradigm. This means no room can have say two chairs, right?? That probably means your noun space is very disciplined, and may provide some optimization opportunities to make things easier. Though because that is at war with TADS parser basics could ALSO make it harder to reimplement. Ie, my first cut might be to modify the core ThingmatchName()/matchNameCommon() to ignore adjectives and see how fast things unravel.
I'd be afraid of disambiguation hell, but maybe your noun space is already disciplined enough to survive that?
It seems that it was not a trivial question after all, and possibly above my skill level at this point. However, it is really great to know ways of how to tackle this. What I am going to do, at the moment, is to keep adding things to the game and covering most of the possible logic adjectives by hand.
It is true that in the original game you can type any nonsensical crap before the noun and it just works the same, but I don’t know if I really want the same in the PC version, now that you mentioned it :D.
At the moment I am building all the objects inside the different locations, doors, etc. Thing is that this game happens inside a space station and, already in the Amstrad version, the environments were quite detailed. However, due to the lack of RAM, I used a trick that worked very well: since all the furniture in the station is mainly the same (made by the same company and using the same materials) I easily managed to create common definitions for things like “upholstery”, “plastic”, “steel”, “concrete”, etc. that could be happily used in many locations to give the player generic (and trivial) details about the construction of some objects.