Hokies it’s been a week since I meithered you so I’ve got a couple of easy ones and I’m after opinions on playability for them before I implement them into my proper game, first is that I remember seeing ldesc and sdesc around a few times and I only thought of it the other day but now I can’t find much on it… Am I right in thinking that
This is the sdesc
treasureRoom: Room 'treasure room'
"It's a big room full of treasure"
And this is the ldesc
Cos up til now I’ve just been calling them a room name and desc, but I had the notion of giving a room a desc when you enter and one for when you type look
The other one is a shower I made as part of an en-suite (I have a testworld game which is basically a home in which I’m making things work how they should as a learning tool) in which you can use. I’ve just made a verb for ‘wash in’ so you could wash in shower(or take shower works too ) or clean in sink (I figured clean is a verb already there so it makes sense) I was wondering about if I were to make a WashIAction to go with it… I’m guessing I’d have to add it to the actor and then add some preConditions (I just made one of those too yaay) but I’m wondering whether or not it’s arbitary and if I’m right about how to put it into the game.
If I recall correctly, ldesc and sdesc are TADS 2 terms. They’re not used in TADS 3. So your query is a little hard to interpret. But looking back at older threads, it appears you’re using T3. Assuming the latter, in the example you gave:
treasureRoom is the name of an object – that is, it’s the internal code name that you would use when referring to the object in your own code. This object is defined using the Room class, which is a class defined by T3. The name by which this object will be known to the player is ‘treasure room’. This is the roomName property of the treasureRoom object. The desc is “It’s a big room full of treasure”.
You will note that there’s no period at the end of the desc. In addition to the period, a text should have a trailing space character at the end, so that the output filter can do its job correctly.
What you’re doing here is making use of a template, so that you don’t have to specify the names of the properties (roomName and desc) that you’re defining. You can look up the Room template in the Library Reference Manual.
Yeah the bit I used was just something I typed up for an example but that explains why I heard about ldesc and sdesc but there not really being anything in the manuals, they’re used in one of the (a couple maybe) examples in the manual describing a red book, so it was just a hunch that they were still being used in tads 3 so that clears that one up, I knew it was a stupid one to ask. Thanks Jim , I was hoping to have a room desc as a way of telling the story, kinda… I dunno, like
and then for a look command… Maybe
Personally I think it looks better and would fit together better in a storylike manner that way, I haven’t played many if games so I’m wondering on how people generally feel, I’m now also wondering how easy/hard it might be to seperate the two
You can do this type of thing easily enough, and in several different ways. A lot depends on how you want the reader to encounter the story! The example you gave makes at least one assumption that is probably bad: You’ve jumped from “an old couple” to “Geoff and Elsie.” I would speculate that you’re assuming the player will start a conversation with the old couple and learn their names, but that’s a poor assumption, because many players will fail to do so, and NONE of them will know what you’re expecting that they will do.
You need to be aware that the player may enter the courtyard numerous times, so your upon-entering code needs to be carefully tailored so it will read properly each time. I would also suggest not putting important information (such as about the exits) in the upon-entering text. That belongs in the basic look-around description of the room.
With that preamble, here’s an easy way to do the sort of text output you seem to want:
courtyard: Room 'Courtyard'
"<<one of>>When you first enter the courtyard you\'re amazed at the festive
atmosphere. <<or>><<stopping>>Three clowns on tricycles are circling the fountain
at breakneck speed, and a sheepdog has set up a card table on which he\'s selling
bowling trophies. Paths lead north and south. "
north = anotherRoom
south = thatOtherRoom
;
The <> syntax is new in TADS 3.1, and it’s extremely useful for this type of situation. But in the example above, the first sentence will only appear once, so you dare not put any essential information in it.
Oh! I’ve used <> and <> I was thinking of a way to distinctively seperate the look desc and the entering room desc (which I realise is just the same) so that I could use <> and <> so when a character enters a room it’s described ‘as part of the story’ and then look around kind of an ‘inner diologue’ describing it (which would be more a description of what’s around the character) the Geoff and Elsie thing was just on the assumption that the character knew who they were btw
Would modifying enteringRoom to say desc2 instead of LookAround work do you thinks?
Oh and thanks for the tip about the exits, I was planning on listing them in the first time desc maybe so the player would know which ways go where in case they might not want to do an explicit look around in each room (such as a corridor with doors or similar that you might just pass through to get somewhere)
Kelly, I’m going to be brutally honest here. I hope you won’t take it the wrong way. My earnest suggestion for you would be to start by writing a whole bunch of basic game stuff without trying to do anything fancy. You can then start adding fancy stuff one bit at a time as you become more conversant with TADS.
TADS is a complex system. There are many ways to do what you’re thinking of. I didn’t mention afterTravel, for instance, because I wanted to keep it simple. If you want a different description the first time the player enters the room, you could also write an actual method for desc rather than using the desc property as set up in the template. For example:
courtyard: Room 'Courtyard'
desc {
descCount++;
if (descCount == 1) "When you first enter the courtyard you\'re amazed at the festive
atmosphere. ";
"Three clowns on tricycles are circling the fountain
at breakneck speed, and a sheepdog has set up a card table on which he\'s selling
bowling trophies. Paths lead north and south. ";
}
descCount = 0
// other code for the room goes here....
I would tend to use this approach rather than messing with enteringRoom, because I’m less likely to create a bug. And that’s the point: Do things the simple way until you’re thoroughly familiar with the TADS system. Trying to do it the complicated, customized way right off the bat is a great way to get discouraged and give up, which would be a shame.
(Trust me on this – I’ve been there. The first time I tried to learn T3 I gave up in frustration, because I was trying to implement a window that the player could look through, and that was just too complicated for me at the time!)
It’s not that I don’t know the basics, in fact since I’ve started learning tads I’ve spent every night (except fri/sat and sometimes tues) reading the tour guides and adding to my testworld, learning each bit at a time, I’ve been building up a home with items that interact with each other and making things act differently under different circumstances (such as a hairdryer that fizzles and breaks if it’s wet, a room that’s only lit when the curtains are open).
I’m also pretty used to playing with descriptions so that they change dependant on what the objects look like (A gem puzzle I created where they glow different colours depending on how many are on each side of a tube). I’ve also used the likes of <><> in my descriptions, like I said it occured to me that having the description shown when you enter a room each time be different to the one you get when you type look would be more appealing and read smoother when played. Sorry if that came across like a bit of a rant by the way I really do appreciate your help I just wanted to explain where I feel I’m up to.
I’m having a night off from looking at code tonight, I was just asking if you thought it might work or if there’s an easier way.
I’ve been there myself with a few different languages (not given up - just had to backpeddle to the basics) hence I have been starting simple and avoiding things that would be too complex too quick (I haven’t even looked at actors and I’m not comfortable with lists yet) I’m just trying to build on what I do know in the hope that when I do produce the game I want to make it’ll look/play/feel good and be as interactive as (I and) the player wants.
Super – sorry I was misunderstanding where you’re coming from!
You might want to use beforeTravel on the room from which the player is departing. This is good for describing the travel itself, as it prints its output before the room name of the destination appears. afterTravel on the room itself … I’d have to check where its output appears in relation to the room name and description.
If you only care about using a different description the first time the player arrives, you can use roomFirstDesc.
If you want a random or cycling list of descriptions, I would replace desc() with a method that picks a double-quoted string from a ShuffledEventList or a CyclicEventList.
Personally, I like this effect, but lots of people have told me that they never read text that appears right before the bolded room description. The bold catches the eye and they start reading from there.
That’s great, I can think of a few instances that would be really handy as well as for describing the travel (which will be a great addition - Thank you!) I’ll look into afterTravel as well as soon as I get chance (I’m up at 5am tommorrow so not tonight :S )
Oh hi bcressey it’s kind of a combination of that and a completely seperate ‘look’ desc I’m after to give a different perspective (i.e. one being narrated in the 2nd person and the other from your perspective) as for people not reading a travel desc, it doesn’t mean I shouldn’t put it in - if I can make it better I should for those that do notice the little things. I’m planning on putting the little things in plus some random tidbits for anyone that cares to notice
Hi again, forgot to post this but what I actually did in the end was modify Traveler (changing LookAround to enterMsg) like so[code]modify Traveler
describeArrival(origin, backConnector)
{
if (isActorTraveling(gPlayerChar))
{
say(gLibMessages.intraCommandSeparator);
gPlayerChar.location.enterMsg;
}
else if (travelerSeenBy(gPlayerChar))
{
callWithSenseContext(
self, sight, {: describeNpcArrival(origin, backConnector)});
}
}
;[/code]It’s actually worked better than I thought too, since showing the roomName is part of the look around function the text follows on without displaying the big bold text. So if I use beforeTravel along with it then there’s no break between the travel message and the next room description to get distracted by I realise this may need tweeking at some point to include certain surroundings that may or not be there (such as characters that move around or choosing to have a roomName display for certain points in the story) but I’d rather a minor inconvenience like that than playing with the LookAround method (which apart from being a stupid idea that would cause all kinds of problems, is suprisingly huge!). Anyway this is how it looks in my testworld
I like the effect. It’s neat to see >look reinvented as something besides a scrollback shortcut. The output reminds me of Erik Temple’s Experiential Movement demo.
As you say I think it’ll be fairly important to reference the most relevant objects in both descriptions, so that for example if the alarm clock turns out to be important, the player can discover it by moving between rooms instead of needing to remember to look as well.
The danger is that it turns into something like the examine / search distinction, which is a rich source of design debates. Although here it’s at least obvious that something unusual is going on; half the problem with search is that it’s so easy to forget.
Thanks bcressey, glad you likes it, I keep forgetting about search tbh it seems ‘too similar’ to just looking in/on/at/through something so I’d probably just remap it, but it’s a good point to remember. I don’t want the player to feel like they have to look around each area, though at the same time I want them to feel like it’s them looking around so they can if they want. I figured it could work well in places that don’t need to be described explicitly (who wants to look at a hallway?) and adding a bit of personality to the character… I also thought it might be fun to have characters react if you keep looking at them but I’ll definately keep it in mind to make sure people don’t feel ‘obliged’ to examine everywhere and everything
Actually it’s funny you mention the alarm clock, I was having trouble with a senseConnector (as in not connecting) and decided to do away and just use a distanceConnector (which is easier and makes more sense too), now I get this when I try to look at the alarm clock from the bathroom
I’ve made the soundSize large so when you listen to the noise specifically you get ‘It’s a loud annoying buzz’, I’m just a little unsure how to deal with looking at the alarm clock.
edit> I just had a look at the experimental movement demo, which seems pretty sweet and could be used to some great effects, for example you could have an event that happens on lower high street that the player could make the player stop (or at least want to) mid journey or as the example shows just have random events to occur on the trip down the road to give a sense of travel
Sure thing, I realise it probably should be an OnOffControl rather than a button but I did actually have a button at first so you could just type ‘push button’ (it’s all for playing around with while I learn so it all gets a little messy)
+ alarmClock: PlugAttachable, Attachable, Button 'alarm clock (button)''alarm clock'
"It's my alarm clock, it's got a screen which shows the time and a button to turn the alarm off. "
dobjFor(TurnOff) asDobjFor(Push)
powerOn = (isAttachedTo(socket))
attachedObjects = [socket]
canAttachTo(obj) {return obj is in (socket);}
dobjFor(Detach)
{
action()
{
alarmBuzz.isEmanating = nil;
inherited;
}
}
dobjFor(Push)
{
action()
{
if(alarmBuzz.isEmanating)
{
"The noise stops as soon as you press the button";
alarmBuzz.isEmanating = nil;
}
else
{"Pressing the button again doesn't do anything";}
}
}
afterAction()
{
if(gActionIs(AttachTo) && powerOn)
{"The time on the screen lights up. "; }
if(gActionIs(DetachFrom))
{"The screen goes blank as the clock dies";}
}
;
++ alarmBuzz: Noise 'buzz/buzzing''buzzing'
isEmanating = true
sourceDesc = "The alarm clock is buzzing away. "
descWithSource = "It's a loud annoying buzzing sound. "
hereWithSource = "The alarm clock buzzes loudly. "
displaySchedule = [2]
soundSize = large
;
Oh the other one will be the displaySchedule I have on it, I just thought it looks silly that I can hear it but not hear any detail when I look at the clock, I don’t see any reason why it wouldn’t show up right though.
Looks like objects use distantDesc / distantSoundDesc when examined through a DistanceConnector.
alarmClock: PlugAttachable, Attachable, Button 'alarm clock (button)' 'alarm clock'
"It's my alarm clock, it's got a screen which shows the time and a button to turn the alarm off. "
distantDesc = "It's my alarm clock. "
distantSoundDesc = "I can still hear it. "
;
Ahh that makes sense
I had making the sightSize to large on the alarm clock but that still gave me the message ‘You can’t hear any detail from this distance’ after the normal description, ideally I wanted to give a custom description since obviously not all the objects would be visible from the bathroom (the wardrobe for one, which I could easily just make a small object and I thought the bedside cabinet being obscured by the bed would be a nice touch) rather than ‘you can’t make out any detail. But it buzzes loudly’.
Thankies I didn’t think of looking for a distant desc x
) or clean in sink (I figured clean is a verb already there so it makes sense) I was wondering about if I were to make a WashIAction to go with it… I’m guessing I’d have to add it to the actor and then add some preConditions (I just made one of those too yaay) but I’m wondering whether or not it’s arbitary and if I’m right about how to put it into the game.
, I was hoping to have a room desc as a way of telling the story, kinda… I dunno, like