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

I was just playing around with the scripting again, and 2 very old annoyances started bugging me.

The first of these is the very limited 'Move to' Command. Its great if you want to go from point A to point B, but if you also want to go to point C,D,E,F,G,H and Z, including waiting periods and sword movement, you will find you spend hours getting the pathing right(Trust me, I know). Thus, I wish to request a new command, "Set Path" This would allow the user to select a spot, and then using the usual DROD keys, define exactly where a character moves, inculding the wait key and the turn sword keys.

The second thing I wish to request is a 'Wait untill speech end" command. this simple command would keep the character that is speaking still for the duration of the dialoge(well, all the dialoge placed in that character with no other commands inbetween). This would be an immense benefit to people on both sides of the spectrum, as Architects would have less polishing to do to conversations, and users would be able to much around during converstions(instead of the expected behavior, which is to stay still).

Pretty Please?

zex20913
Level: Smitemaster

Rank Points: 1723
Registered: 02-04-2003
IP: Logged

I like both of the ideas, especially the first one. It seems intuitive. What, though, would happen if the path is interrupted? I suppose the standard would be what goes on with the current pathing ability--a try to get back method.

The second one, however, has been discussed before--the thing is, the pace of the text is not dependent upon the movecount, but rather a time-per-letter count (or something similar). As the units don't exactly match, it'd be really tough to do. At least, that's the argument put forth from the team, IIRC. Quantifier.

____________________________

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

The second one, however, has been discussed before--the thing is, the pace of the text is not dependent upon the movecount, but rather a time-per-letter count (or something similar). As the units don't exactly match, it'd be really tough to do. At least, that's the argument put forth from the team, IIRC. Quantifier.

Thats not hard to get around, have it so it simply does not trigger any of the commands in the script exept speech commands for the allocated time.

eytanz
Level: Smitemaster

Rank Points: 2708
Registered: 02-05-2003
IP: Logged

But what's the "alloted time"? The way the game is currently coded, the scripting engine has no idea whether the speech is running or not - that's handled by a totally different engine. The way it works is totally unidirectional at the moment - a script can send information to the speech engine but not get any information from it. I've spoken about this to Mike (I had the same thought as you, back in the days of 2.0 beta) and it would require a total rewrite of the entire game to enable it.

____________________________
I got my avatar back! Yay!

coppro
Level: Smitemaster
Rank Points: 1309
Registered: 11-24-2005
IP: Logged

Plus, there is a much easier solution that I discovered. It has the added bonus of the player being able to skip cutscenes.

I'll leave this one as an excersize for the student.

Banjooie
Level: Smitemaster

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

Well, couldn't we just add a new speech engine, and make that 'newstyle' speech? That way, we wouldn't lose any backwards compatibility...

eytanz
Level: Smitemaster

Rank Points: 2708
Registered: 02-05-2003
IP: Logged

You'd have to ask Mike for a definite answer, but according to my understanding the reasons are as following:

- Having two seperate speech systems running at the same time is wasteful; the game is slow enough on older systems that adding a mostly redundant process taking system resources seems like a bad idea.

- More importantly, you misunderstand where the problem lies. It's not that the speech engine cannot be modified to send information back. It's that the *gameplay* engine cannot be (easily) modified to accept any sort of real-time information. In other words, it's not that the speech engine needs to be rewritten from scratch. It's most of the rest of the game that will need to be rewritten.

- It's probable (though I'm not certain about this) that there's a reason that the gameplay engine cannot do any of this beyond "Mike didn't think of it soon enough". In other words, the reason rewriting the gameplay engine to be able to respond to speech events is unlikely isn't just that it would be a lot of extra work for Mike, but also because it might cause problems with other aspects of the game.

- That said, I'm not saying that there aren't solutions to this issue. I'm just saying that if anything is going to be done about it, it's likely that it will be handled in a different manner than NiroZ's suggestion.

____________________________
I got my avatar back! Yay!

---

[Last edited by eytanz at 10-15-2006 10:22 PM]

silver
Level: Smitemaster
Rank Points: 915
Registered: 01-18-2005
IP: Logged

eytanz wrote:
It's not that the speech engine cannot be modified to send information back. It's that the *gameplay* engine cannot be (easily) modified to accept any sort of real-time information

like keystokes, mouse events, and operating system events?

every windows program is built around an event loop, because that's how windows passes in inputs from the user.

while I do not doubt there's an explanation why this would be difficult, I think you might have misunderstood Mike at some point.

(and I also object to this feature request because I like being able to skip cutscenes)


____________________________

---

[Last edited by silver at 10-15-2006 11:05 PM]

Jatopian
Level: Smitemaster
Rank Points: 1842
Registered: 07-31-2005
IP: Logged

Alloted speech time would allow things like: "You have 50 seconds to slay these monsters." and once the speech is gone the character closes an orb.

____________________________
DROD has some really great music.
Make your pressure plates 3.0 style!
DROD architecture idea generator

silver
Level: Smitemaster
Rank Points: 915
Registered: 01-18-2005
IP: Logged

that's the best explanation yet of why this feature or any other real-time-timing feature should never, ever be included in the scripting engine. one of the great things about drod is that it's a full on think-all-you-want-between-each-move puzzle game and not an arcade game.


____________________________

---

[Last edited by silver at 10-15-2006 11:26 PM]

Ezlo
Level: Smitemaster

Rank Points: 1224
Registered: 01-08-2006
IP: Logged

But the other idea is one of the best ideas I've heard of ever! That would make scripting so much easier!

eytanz
Level: Smitemaster

Rank Points: 2708
Registered: 02-05-2003
IP: Logged

I do like the other idea. I'd rather that instead of just having an opaque "move to set point" command, though, once you set the path it will appear in the script as a series of normal movement commands.

____________________________
I got my avatar back! Yay!

Jatopian
Level: Smitemaster
Rank Points: 1842
Registered: 07-31-2005
IP: Logged

Heh, in the debate over the second proposal I forgot about the first. What eytanz said.

____________________________
DROD has some really great music.
Make your pressure plates 3.0 style!
DROD architecture idea generator

mrimer
Level: Legendary Smitemaster

Rank Points: 5106
Registered: 02-04-2003
IP: Logged

eytanz wrote:
- More importantly, you misunderstand where the problem lies. It's not that the speech engine cannot be modified to send information back. It's that the *gameplay* engine cannot be (easily) modified to accept any sort of real-time information. In other words, it's not that the speech engine needs to be rewritten from scratch. It's most of the rest of the game that will need to be rewritten.

- It's probable (though I'm not certain about this) that there's a reason that the gameplay engine cannot do any of this beyond "Mike didn't think of it soon enough". In other words, the reason rewriting the gameplay engine to be able to respond to speech events is unlikely isn't just that it would be a lot of extra work for Mike, but also because it might cause problems with other aspects of the game.

I'll answer this again here, noting that I've outlined the issue at hand before but I'm not motivated to look up the thread(s) right now. So, in a nutshell:

When you play the game, let's say we have a speech command where an NPC waits until current speech is finished (or some variant thereof) in real-time. Demos store move information at a coarse interval (100th of a second resolution) and only to a maximum of 2 1/2s per move. So if a move takes longer than that (say, the person waits and listens until dialogue ends), this won't be recorded in demos. Demos would have to be reworked to handle this, but this would make saved games at least 50% larger, which doesn't seem like a good cost-to-reward ratio.

Also, what happens when a demo is played back of this room and the user plays it back at a different speed (using the UI controls on the demo screen)? Or steps forward and backward through turns? Saved games would have to become even larger in order to store per-turn real-time information of internal game state, which it doesn't do now at all. This is largely against the nature of DROD anyway, so I personally would like to add time-sensitive elements, but to a different kind of game.

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

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

I guess I have to agree that, seeing your arguments, this feature would be too open to add some sort of real time to DROD(even though that is definatly not its intention).

What about my other suggestion?

*fervently hopes*

Ezlo
Level: Smitemaster

Rank Points: 1224
Registered: 01-08-2006
IP: Logged

*fervently hopes along with NiroZ*