Command Queues wrt Input Handlers
Goto page 1, 2  Next
 
Post new topic   Reply to topic    mudlab.org Forum Index -> Design
View previous topic :: View next topic  
Author Message
Cornelius



Joined: 13 May 2005
Posts: 42
Location: Florida

PostPosted: Wed Jul 13, 2005 7:16 pm    Post subject: Command Queues wrt Input Handlers Reply with quote

Traditional diku polls a socket for input and when present, parses accordingly. It is simple and works great for most applications. However, it presupposes that the character is able to perform the requested command at the instant it is attempted. If not then the command simply fails. If however, we are waiting for something- e.g. character is stunned or another command is pending- then the player must wait for the previous condition to clear and then type the command again. The problem then becomes a matter of telling the player when they are again able to perform an action: if stunned- when they recover, if another command is pending- when it is complete.

Typically this kind of thing is handled on the player end by simply spamming the server; eventually your desired command will get through and usually quicker then waiting to receive a confirmation and then attempting to execute a command. But this player-side solution is undesirable.

A more recent method for dealing with these situations is event handling where a command triggers an event that will execute after a certain time. Thus we can spam all the commands we want and their time delays will simply stack up as much as a coder allows them to. This is a nice solution in my opinion but one which lends itself more toward delayed actions than delayed commands. The distinguishing feature being that a delayed action is the result of an already processed command. Though I am really just reaching so that I can argue the following point Smile

What if we had a queue of player input with a marker that locates the position on the queue where the next command should be executed. Everytime the game polls the socket it stacks the current input (if any) to the queue and checks to see if it can execute the marked command and advance the marker, doing so if able.

For example:
My command queue allows for 5 commands (+1 current) to be stacked. Because of my past command history my queue looks like this:

rest - stand - eat - drink - smile - *NULL

The '*' is the marker that tells the input handler that the NULL command is pending, every time my char is polled so long as I dont enter anything my command queue will look like this. Then I cast a spell that has a chanting time: cast 'chanting monk', the command is added to the queue.

rest - stand - eat - drink - smile - *cast

Then instantly the command is executed, adding some waitstate to my char and advancing the queue:

stand - eat - drink - smile - cast - *NULL

Then while casting I see a frind pop into the room, I extend a greeting:

stand - eat - drink - smile - cast - *wave

Since I am still in my chanting waitstate the command is not executed yet, and lo and behold a few more friends pop into the room:

smile - cast - *wave - nod - greet - curtsey

Now finally the chanting is done- the next poll the impending command is executed and the marker, no longer impaired by a waitstate advances to the next command:

smile - cast - wave - *nod - greet - curtsey

At the very next poll the same thing happens and so on, until it reaches the end of the list and resets the current command to NULL:

cast - wave - nod - greet - curtsey - *NULL

I think this idea has some good potential; we now have an in-game command history, we can stack commands, we can even apply this concept to multiple command commands.

So... does any of this make sense? Has anyone done this or something like it before and what were the results? Are there any glaring problems with such a system that I missed, if so are there any obvious solutions to them?

Thanks in advance for your thoughts on the matter,
Back to top
View user's profile Send private message AIM Address
Author Message
Kelson



Joined: 18 May 2005
Posts: 71
Location: SC

PostPosted: Wed Jul 13, 2005 11:34 pm    Post subject: Reply with quote

I've done similar things, but why make every command wait? Some commands, like combat related, should necessarily be delayed. I have to wait x seconds before I can bash again no matter what.

On the other hand, some commands (like socials) don't negatively effect the game if we immediately execute them. Therefore, it seems reasonable to allow them to immediately execute (which I think would be much nicer than waiting 5 minutes for my bash to go off, then 30 other socials)..

For my game, if you were delayed in combat, your combat related actions would be queued up. Non-combat actions (talking included) were not, this allowed someone to talk while fighting - something I have no problems with in my game, but that others would.

- Kelson (The One And Only!)
Back to top
View user's profile Send private message Send e-mail AIM Address
Author Message
Tyche



Joined: 13 May 2005
Posts: 176
Location: Ohio, USA

PostPosted: Thu Jul 14, 2005 2:06 am    Post subject: Re: Command Queues wrt Input Handlers Reply with quote

I think it's an absolute horror to link command parsing in a way that's interwined with the network subsystem. Traditional Diku does this as well as
some LPMuds. I would advise complete separation.

You might look at the Paradigm and Mesh server codes that I released, feeble as they are, for some ideas.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Kelson



Joined: 18 May 2005
Posts: 71
Location: SC

PostPosted: Thu Jul 14, 2005 2:17 am    Post subject: Re: Command Queues wrt Input Handlers Reply with quote

Tyche wrote:
I think it's an absolute horror to link command parsing in a way that's interwined with the network subsystem.


Unless I'm missing something, that wasn't an issue? Wasn't it regarding the point after the command parser, when the game world is actually executing the command (actually, whether to queue the command up or execute it...).

- Kelson

Now with 70% less gratuitous self-implementation love!
Back to top
View user's profile Send private message Send e-mail AIM Address
Author Message
Tyche



Joined: 13 May 2005
Posts: 176
Location: Ohio, USA

PostPosted: Fri Jul 15, 2005 5:07 am    Post subject: Re: Command Queues wrt Input Handlers Reply with quote

Kelson wrote:
Unless I'm missing something, that wasn't an issue? Wasn't it regarding the point after the command parser, when the game world is actually executing the command (actually, whether to queue the command up or execute it...).


Possibly, possibly not. Maybe I read it wrong.

Quote:

Everytime the game polls the socket it stacks the current input (if any) to the queue and checks to see if it can execute the marked command and advance the marker, doing so if able.
Back to top
View user's profile Send private message Visit poster's website
Author Message
shasarak



Joined: 29 Jun 2005
Posts: 134
Location: Emily's Shop

PostPosted: Fri Jul 15, 2005 9:34 am    Post subject: Reply with quote

Cornelius,

I think that system is a very sensible one. One small change I would suggest, though, is to add the ability for a player to flush his command queue.

Imagine that you've typed the sequence:
Code:
place ladder against tree, climb ladder, pick apple, climb down, eat apple

Several of these actions will take a finite amount of time.

If, at the point where he's still placing the ladder, someone enters the orchard whom he wishes to wave to, it's unrealistic to force the player character to go through the entire sequence before being able to wave. Realistically he should be able to change his mind about climbing the ladder and picking an apple and wave to his friend instead.

So I would have a standard command like a full stop (period) by itself which means "flush all queued commands and, if possible, interrupt the current one in the middle".

I've been thinking about a system like this for handling non-automated combat: player queues up a sequence of combat manouvers as a "combo", but can change his mind half way through if it looks like it isn't working. It would also allow a player to interrupt a bit of speedwalking in the middle if he sees something interesting.

Oh, and in order to avoid the spamming problem, each action definitely needs to require a measurable amount of time to execute - if it takes no time at all for the server to respond "you're stunned" then the player can still queue up as many attempts as he likes. (Admittedly, being able to interrupt the command queue doesn't help with that).
Back to top
View user's profile Send private message
Author Message
kelson76



Joined: 27 Jun 2005
Posts: 30

PostPosted: Fri Jul 15, 2005 3:50 pm    Post subject: Re: Command Queues wrt Input Handlers Reply with quote

Tyche wrote:
I think it's an absolute horror to link command parsing in a way that's interwined with the network subsystem. Traditional Diku does this as well as
some LPMuds. I would advise complete separation.

You might look at the Paradigm and Mesh server codes that I released, feeble as they are, for some ideas.



I absolutely agree with this. I've been working on writing from the ground up, because I want a multi-threaded architecture. This gives me a comm_handler, cmd_handler, update_handler, log_handler for worker threads. When something new comes in on a socket, I just throw it over to the cmd_queue, which is the communication point between the comm_handler and cmd_handler threads, where the cmd_handler can act on it.

I like the idea of putting network IO and file IO on their own threads, using queues as the hand off between them, to keep everything in the correct order w/r/t processing.

However, this does create the issue of a backlog being built up in the server, because I don't wait for a cmd to be processed before allowing another to be put on the queue. I'm trying to determine if only allowing a user to put 3 items on the queue might be the best way to handle an out of control script running the cmd queue up to a ridiculous level.

I don't plan on delaying commands based on the players state. If you are stunned, I'll tell you so when you try to do a command and make you run the cmd again when you are not stunned. To much can change that you may need to react to while you are in that state, you don't want a long backlog of commands leaving you helpless.


- Kelson
Back to top
View user's profile Send private message AIM Address
Author Message
Kelson



Joined: 18 May 2005
Posts: 71
Location: SC

PostPosted: Fri Jul 15, 2005 6:17 pm    Post subject: Re: Command Queues wrt Input Handlers Reply with quote

kelson76 wrote:
I want a multi-threaded architecture.
<snip>
I like the idea of putting network IO and file IO on their own threads, using queues as the hand off between them, to keep everything in the correct order w/r/t processing.


The classic issue then becomes ensuring proper synchronization where necessary (for example, load requests need to complete before the data is used). I'm pretty happy with just asynchronous network IO, unfortunately my solution to the problem (using IoCompletionPorts) is not at all portable (Windows only).

kelson76 wrote:
I don't plan on delaying commands based on the players state. If you are stunned, I'll tell you so when you try to do a command and make you run the cmd again when you are not stunned. To much can change that you may need to react to while you are in that state, you don't want a long backlog of commands leaving you helpless.


Thus the usefulness of a flush queue command. That would allow you to change your mind, while the system still gives you the capacity to prepare for the moment you are no longer stunned.

- Kelson (Stop stealing my name!)
Back to top
View user's profile Send private message Send e-mail AIM Address
Author Message
Cornelius



Joined: 13 May 2005
Posts: 42
Location: Florida

PostPosted: Fri Jul 15, 2005 6:47 pm    Post subject: Reply with quote

Quote:
I've done similar things, but why make every command wait? Some commands, like combat related, should necessarily be delayed. I have to wait x seconds before I can bash again no matter what. - Kelson


I understand where you're coming from but If I am chanting or stunned I shouldnt be able to use communication commands or socials- If I separate 'waitable' commands it would only be to allow access to helpfiles and possibly OOC channels while in waitstate. But really waitstate should never be more than a few seconds to a minute max, I think players can wait that long between OOC. I like allowing communication while in combat but I would prefer the talking to be part of the combat- taunting and whatnot- I mean, I would hope that my players in combat will not have much opportunity to engage in discussions about the price of tea in Zanzibar as they are parrying and riposting.

Quote:
So I would have a standard command like a full stop (period) by itself which means "flush all queued commands and, if possible, interrupt the current one in the middle". - Shasarak


This is a good point, and quite necessary I believe. Stopping chanting to say hi to a friend makes more sense to me than trying to say hi while chanting.

Quote:
Oh, and in order to avoid the spamming problem, each action definitely needs to require a measurable amount of time to execute - if it takes no time at all for the server to respond "you're stunned" then the player can still queue up as many attempts as he likes - Shasarak


True but what is the point? If the command is queued up then your command will wait for the current condition to exhaust before executing- there is no way to speed it up (granted that I am stunned or otherwise impaired). Queuing up more commands just means you want to execute the command that many times in succession... I see no problem with that.

I also think it would be beneficial to somewhat limit the amount of commands that can be queued up to some reasonable number- I imagine that number to be somewhere less than 10. I mean its been said Bobby Fischer didn't even look 10 moves in advance.
Back to top
View user's profile Send private message AIM Address
Author Message
bullseye



Joined: 19 Jul 2005
Posts: 10
Location: Kansas

PostPosted: Tue Jul 19, 2005 10:18 pm    Post subject: Reply with quote

I highly support a singular command queue in an asynchronous network IO model. However, I think that a command queue, as proposed, opens up a huge can of worms from a playability standpoint.

For starters, from a player's perspective, how difficult is it going to be to figure out which commands are queued, versus which ones are immediately executed? Would the help files address this on a command by command basis? In what states do queued commands kick in? Also, will there be a command to see which commands are queued? Do I flush the queue, or flush n-commands from the queue? If I am knocked out while spamming "kill mob", am I going to maul the first thing I see when I wake up?

Since most players are used to a instant feedback type system, by delaying commands, or assigning different priorities to them, it seems like that model would be creating an artificial lag situation. Example: I'm stunned and start spamming "stand". If nothing is happening then there certainly is not going to be a reduction in spam. Look at the typical number of commands input in a lag situation. Most players (maybe myself included) are not the personification of patience.

If I receive a "your command has been queued until you are no longer stunned", I suppose that might help, but I guess the real question to ask is whether or not it is really worth the effort involved.
Back to top
View user's profile Send private message
Author Message
Huri



Joined: 18 Jun 2005
Posts: 8

PostPosted: Wed Jul 20, 2005 10:17 am    Post subject: Reply with quote

It might make sense to divide your commands into two categories; interruptible and non-interruptible. If a player enters a command while an interruptible command is being processed, the old command is aborted and the new one executed directly. Otherwise the new command is queued. I'd prefer if the que only allowed one command, if you enter a new one the old is replaced. Then you won't need any 'flush' command. The reason I don't like 'flush' is because it's by it's nature an ooc command, a sort of meta-command, and I like to keep them down to a minimum. This is just personal preference though, I can see advantages with a longer que as well.

A disadvantage of a command que is that it can lead to very strange ic behaviour, like someone continuing chatting, greeting friends and eating while the tavern he's sitting is is being eaten by a huge chaos-daemon. Smile
Back to top
View user's profile Send private message
Author Message
Lindahl



Joined: 29 May 2005
Posts: 56

PostPosted: Wed Jul 20, 2005 2:43 pm    Post subject: Reply with quote

I agree with bullseye on this one. The benefit it provides compared to the complication it brings to the user interface makes it a questionable feature. I generally always bend in favor of a simple user interface, so my stance on this is obvious.
Back to top
View user's profile Send private message
Author Message
kelson76



Joined: 27 Jun 2005
Posts: 30

PostPosted: Wed Jul 20, 2005 3:07 pm    Post subject: Re: Command Queues wrt Input Handlers Reply with quote

Kelson wrote:
kelson76 wrote:
I want a multi-threaded architecture.
<snip>
I like the idea of putting network IO and file IO on their own threads, using queues as the hand off between them, to keep everything in the correct order w/r/t processing.


The classic issue then becomes ensuring proper synchronization where necessary (for example, load requests need to complete before the data is used). I'm pretty happy with just asynchronous network IO, unfortunately my solution to the problem (using IoCompletionPorts) is not at all portable (Windows only).

kelson76 wrote:
I don't plan on delaying commands based on the players state. If you are stunned, I'll tell you so when you try to do a command and make you run the cmd again when you are not stunned. To much can change that you may need to react to while you are in that state, you don't want a long backlog of commands leaving you helpless.


Thus the usefulness of a flush queue command. That would allow you to change your mind, while the system still gives you the capacity to prepare for the moment you are no longer stunned.

- Kelson (Stop stealing my name!)


The problem w/ a "flush" command is that you need to perform a level of processing on the commands in the queue prior to execution. I like to keep command execution atomic in the sense that when it's a command's turn to be processed, it is done from start to finish. If I allow players to have several commands queued up, then flush, that's alot of work purging the command queue of all commands for that one user, plus I need to do pre-processing to determine if the command should get bumped to the top of the queue.

I suppose an easy way to do it is a circular queue of players, each with their own queue of commands, so I can just purge their personal queue w/o traversing the entire command queue, but that still leaves me with command pre-processing that breaks the architectural design.

I'm a big fan of not using special cases, makes things much easier to troubleshoot, especially when you have a bunch of threads going.

- Kelson
(Nah, I'm gonna keep using the name...been using it to long to change.)
Back to top
View user's profile Send private message AIM Address
Author Message
Tyche



Joined: 13 May 2005
Posts: 176
Location: Ohio, USA

PostPosted: Wed Jul 20, 2005 3:11 pm    Post subject: Re: Command Queues wrt Input Handlers Reply with quote

kelson76 wrote:

However, this does create the issue of a backlog being built up in the server, because I don't wait for a cmd to be processed before allowing another to be put on the queue. I'm trying to determine if only allowing a user to put 3 items on the queue might be the best way to handle an out of control script running the cmd queue up to a ridiculous level.


Yes you will need an input governor regardless to protect oneself from intentional or non-intentional DoS or flooding. But that is a game independent problem I think. One new configuration option I've recently implemented is to do a random shuffle of the set of descriptors on each pass. I'm not sure this qualifies as game extension intruding on the network code or just a generic fair access policy.

With a message queue the responsibility of determing the order, frequency and/or quota is in the game engine. Although it would be possible to use the observer pattern and bypass a message queue, either sending the output to a single command dispatcher, multiple command dispatchers, or the user object itself.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Kjartan



Joined: 13 May 2005
Posts: 110

PostPosted: Wed Jul 20, 2005 5:13 pm    Post subject: Reply with quote

After seeing the "flush" idea suggested here, I implemented it in my diku. Players love it - we have frequent situations where players are either stunned or engaged in some ongoing action that takes a while to complete so their commands sit in the queue until a timer wears out.

Thanks!
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    mudlab.org Forum Index -> Design All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2001, 2002 phpBB Group
BBTech Template by © 2003-04 MDesign