Tahnan
Level: Smitemaster

Rank Points: 2467
Registered: 11-14-2005
IP: Logged

You know what I'd love to see? Semaphores. Which isn't very descriptive, but it's the only thing I know to call them.

That is to say: a pair of new script commands, "Send <x> to NPC at ..." and "Wait for message <x>". So that, for instance, character 1 could, whenever he reaches the end of his script, send a message to character 2 to say "Start", and character 2, who was waiting for the message "Start", would go on to her next command.

(It's something I would have found useful in my Al Dente programming--right now, the only way an NPC can transmit any information to another NPC is by moving, and it would have been nice for an NPC to tell another one "OK, this is what I just did; put yourself into a new state based on that.")

Beef Row
Level: Smiter
Rank Points: 471
Registered: 12-28-2005
IP: Logged

This is an interesting idea, but scripting with it is maybe sort of error prone.

For example, if NPC X has a script which waits for NPC Y to send a message, and Beethro kills Y, X's script is effectively over. Ditto if Y were to turn into a monster.

Not so complicated to adjut for in that case, but what if you have three or more NPCs with mutual communications? Scripting or testing a room using this kind of network would get ugly, fast.

____________________________
"Now I will repeatedly apply the happy-face rule"

NiroZ
Level: Smitemaster
Rank Points: 1302
Registered: 02-12-2006
IP: Logged

Perhaps it should be "Set character as '..'" and "Trigger character '..'"

Tim
Level: Smitemaster

Rank Points: 1979
Registered: 08-07-2004
IP: Logged

Tahnan wrote:
(It's something I would have found useful in my Al Dente programming--right now, the only way an NPC can transmit any information to another NPC is by moving, and it would have been nice for an NPC to tell another one "OK, this is what I just did; put yourself into a new state based on that.")

I think this is probably the most useless/redundant feature request I've ever seen.

This is DROD, where any result can only be shown either as speech or movements. For speeches, these commands are useless as the speech is happening in between turns (and can be synchronized by using one central character), and for movements, well, as you said, there's already something for it. Anything else is just hiding information to the player (and you can already do that by putting trapdoors under tar), and is totally unneccesary.

____________________________
The best way to lose customers is to let little kids running loose on a forum with too many mod points.

NiroZ
Level: Smitemaster
Rank Points: 1302
Registered: 02-12-2006
IP: Logged

Tim wrote:

Tahnan wrote:
(It's something I would have found useful in my Al Dente programming--right now, the only way an NPC can transmit any information to another NPC is by moving, and it would have been nice for an NPC to tell another one "OK, this is what I just did; put yourself into a new state based on that.")

I think this is probably the most useless/redundant feature request I've ever seen.

This is DROD, where any result can only be shown either as speech or movements. For speeches, these commands are useless as the speech is happening in between turns (and can be synchronized by using one central character), and for movements, well, as you said, there's already something for it. Anything else is just hiding information to the player (and you can already do that by putting trapdoors under tar), and is totally unneccesary.

It is, however, damn convenient when you have 2 or more NPC's moving about.

Banjooie
Level: Smitemaster

Rank Points: 1645
Registered: 12-12-2004
IP: Logged

I find that if you sufficiently abuse 'wait for NPC', that does the job nicely.

Tahnan
Level: Smitemaster

Rank Points: 2467
Registered: 11-14-2005
IP: Logged

Tim wrote:
I think this is probably the most useless/redundant feature request I've ever seen.

Oh, I've seen more useless and more redundant...

But in any case, as I said, one room in my Al Dente hold involved various internal change-of-state things that would have been insanely hard to determine if each character had to have all kinds of separate subroutines to track the player's movement on their own; as opposed to one character tracking one thing, and sending out a signal when it happened.

Additionally, with relative movement added, I'm not 100% convinced that a simple "wait for NPC at" will still be sufficient.

Tim
Level: Smitemaster

Rank Points: 1979
Registered: 08-07-2004
IP: Logged

Tahnan wrote:
Oh, I've seen more useless and more redundant...

Well, it's useless because this is not a request for semaphores (but inter character messaging, which is NOT the same), and it's redundant as an alternative already exists. I've requests before that were either more useless or more redundant, but this is the first that is both...

But in any case, as I said, one room in my Al Dente hold involved various internal change-of-state things that would have been insanely hard to determine if each character had to have all kinds of separate subroutines to track the player's movement on their own; as opposed to one character tracking one thing, and sending out a signal when it happened.

I can't comment on your room since I don't know which one it is.
But that's not my point. The point is, that while "various internal change-of-state things" is an interesting suggestion for many things, it is -like a raygun- not very suitable for DROD. By hiding the states in characters, it goes against the spirit of showing all the information on screen. And while I might like to be able to play sokoban, space invaders or mastermind (just some examples) using this trick, I've seen other games doing those things better (and they are called "sokoban", "space invaders" and "mastermind" ).

And I must say, if the states are "insanely hard" to determine, even for the architect, then I have this very bad feeling that room wasn't tested properly by the architect.

Additionally, with relative movement added, I'm not 100% convinced that a simple "wait for NPC at" will still be sufficient.

Well, I never said it was simple, and there are more things you can use besides "wait for NPC at". But it is also not terribly hard.

____________________________
The best way to lose customers is to let little kids running loose on a forum with too many mod points.

Tahnan
Level: Smitemaster

Rank Points: 2467
Registered: 11-14-2005
IP: Logged

Tim wrote:
Well, it's useless because this is not a request for semaphores (but inter character messaging, which is NOT the same)

So, all right, I'm a linguist, not a computer scientist. I reached into distant memory and came up with what I suppose must be the wrong term (or, I think, the term from a programming language I used to use that used the term wrong). I think there were nicer ways to tell me that than "useless".

The point is, that while "various internal change-of-state things" is an interesting suggestion for many things, it is -like a raygun- not very suitable for DROD. By hiding the states in characters, it goes against the spirit of showing all the information on screen.

See, on this point I disagree. I don't think that internal change-of-states is any less suitable than any other element of scripting, any of which can hide information from the player. Example: imagine a mimic, not visible, sword overlaying a bomb, with the script "Wait 137 turns; appear"--you've now hidden quite a significant piece of information from the player. Is this good architecture? Heavens no, not in my opinion. As with many other things, what I'm suggesting here could be abused by architects, or it could be used well, but I don't think it's inherently as flawed as a raygun.

And I must say, if the states are "insanely hard" to determine, even for the architect, then I have this very bad feeling that room wasn't tested properly by the architect.

Well--while I appreciate your vote of confidence, allow me to clarify that (a) I tested the room thoroughly, and (b) the information that was insanely hard to track was hard from the programmer's perspective, not the player's.