ID:154621
 
Here's an email (posted without permission) from someone that has developed a Task List / Que system for his MUD. Reading through it, I think this would be really easy to implement in BYOND. I'm posting it for all the great ideas it provides :).




Ben wrote:
I known I've gone into detail about it many times in the past, but unfortunately my archive searches haven't turned up any of the posts in question. So here it is again...

Each character has a task list. The top node in the list is considered their current task: the one they are doing at this moment in time. In fact, their room description is generated based on this task: for example, you might see "Bubba is sitting here, honing a steel dagger" or "Boffo is standing here, eating an apple."

Tasks have a number of parameters, including priority (MENIAL, MOVEMENT, LIFE_OR_DEATH, and MUST, in accending order), target entity, accessory entity, time remaining to finish the task, and extra data which is specific to the type of task.

Almost all commands do nothing except to add a task to the character's current task queue. The task add function inserts the task into the queue in front of any tasks of lower priority (but behind tasks of the same or greater priority). The most common scenario, of course, is that you have no tasks to begin with, and so the new task simply becomes the top node in the list.

If you already were doing something, and this task interrupts it, the other task is "suspended" and its time delay is saved, and you switch your attention to the new task.

Many tasks that take a long time (such as the famous digging the canal example) are actually broken up into many small tasks, each one which increments your "progress" on whatever it is you're doing. This covers singing songs, repairing items, honing a blade, picking locks, eating, and so forth. There are a few tasks which never end on their own, but instead wait for the player to interrupt them with something else. The primary example is the "hide" task.

Currently these long-term tasks don't easily allow for interruption. Originally it was set up such that it was easy to take a bite of your bread while honing your sword. This turned out to be too unplayable, so it was changed a little bit. You can still interrupt a lower priority task with a higher one - such as movement, or combat.

You can type "stop " at any time to stop a task of any priority lower than MUST, or you can type "stop" to simply stop everything you are doing.

The task handler has a lot of verification functionality, where it makes sure that your target and accessory entities are still accessable. For example, if you're picking a lock, and you walk away, it will cancel the lockpicking. Ditto if someone breaks down the door from the other side...

An example. Out of band comments are in square brackets.

% l
A Room
exits: n e w s
% fish
You toss your line towards the water and begin to fish.
% hone sword
['hone' is equal priority to 'fish', so it gets added to the end of the queue]
%
[pause]
You reel in your line, a catfish on its hook.
You begin honing a sword.
[pause]
You drag your whetstone along the blade.
% w
[movement is higher priority than honing, so the task interrupts]
You head west.
[pause]
Another Room
exits: n e w s
%
[pause]
You drag your whetstone along the blade.
[pause]
You flip the blade over and begin honing the other side.
[pause]
You drag your whetstone along the blade.
[pause]
You finish your honing.
The blade is slightly sharper.
%

In practice, the "coolness" of the priority queue is mostly lost on players. 95% of the time they are doing one thing at a time. Probably the main advantage that they notice is that they are never stuck in artificial "lag" that many muds use to delay player actions; they can always stop what they are doing, or interrupt it with something of higher priority.

In fact, the tasks system has turned out to be not so much a gain to the players, but a gain to me as a developer. I can make actions stretch out over time the way that they should without having to write anything special, because it's all handled by the task system. I just flesh out the "prepare" and "resolve" functions for a given task, and don't worry about the red tape of making it happen.

In fact, there is NO special code for handling the flow of combat. Starting combat is simply a matter of adding the combat task to each combatant, and then the combat resolve function decided whether to launch an attack or a defense (both of which are tasks). Players can insert their own combat tasks at any time (with commands like "attack", "resuce", "battlecry", "retreat", "flee"...).

Another nice side-effect is that there's never a need to "spam" commands. One only needs to type "retreat" once, for example, and your character will continue to try to leave combat until they succeed (or you type "stop retreat").

There's more, but that's the jist of it. All in all I'm quite happy with it, and it pains me to see that many (most?) muds are still using a more antiquitated system for character states and actions. In fact, I'm currently pondering a source release - it's not difficult to implement, so perhaps showing how easy it is might inspire a few implementors.

Adam

_______________________________________________
MUD-Dev mailing list
MUD-Dev@kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev


The Sims is a game built around character task lists, and they came up with a nice simple solution to having complex series of tasks in the world without having to program in all the steps.

What they do is give each object in the world the ability to broadcast what it can do.

So say your character gets hungry. Well, food in the refrigerator broadcasts that it can reduce hunger. So the character grabs a frozen steak.

But they can't use the frozen steak yet. It needs to be cooked.

The stove broadcasts that it can cook food. So the character puts the steak on the stove and cooks it.

The brilliance of this approach is that the programmer never had to say "If you get hungry, go to the fridge and get food, then take it to the stove..."

And the programmer can drop, say, a microwave into the world and suddenly characters will start using it, even though they were never explicitly programmed to use microwaves...
Pretty neat!

I came up with a related idea a while back, but it quickly became cumbersome and ugly. Now this has got me thinking about taking another stab...
In response to Deadron (#1)
And the programmer can drop, say, a microwave into the world and suddenly characters will start using it, even though they were never explicitly programmed to use microwaves...

That's an awesome idea! In BYOND, that would be so darned easy it would be laughable, too!

All you'd have to do is define a simple variable containing a string that the object can do. So food would have a "reduces hunger" in it. When hungry, the person would search the world for items with "reduces hunger", and pick the first one they notice. Then they would look for the first "cooks food" they notice, and get it. You could even put in multiple variables containing strings, like "reduces hunger", "requires cooking", and "red meat". (In case you have a carnivorous desire =).
In response to Spuzzum (#3)
All you'd have to do is define a simple variable containing a string that the object can do. So food would have a "reduces hunger" in it. When hungry, the person would search the world for items with "reduces hunger", and pick the first one they notice. Then they would look for the first "cooks food" they notice, and get it. You could even put in multiple variables containing strings, like "reduces hunger", "requires cooking", and "red meat". (In case you have a carnivorous desire =).

Hmmmmm... that is promising, isn't it?

Or what if a given object actually contains all the logic for a mob to use it? Say you have some magic arrows lying around. The mob picks them up, and in the process, the arrows look for the mob's "ranged-weapon" task and insert a reference to their own handling proc. Then, the next time the mob needs to use his ranged-weapon task, he'll check to determine whether it's appropriate to use the magic arrows...

Nifty!
I've been playing with this for the past... 13 hours and have come to the conclusion that if I'm ever going to get one working that I like, I'm going to have to be a better programmer -g-.

I managed to get a sample Task Manager running and even the ability to fish, but I had to put all the actual code within the Task Manager (though process could link off) and then I had to put in a lot of safety checks to make sure that the conditions for executing the task were met.

After awhile, I just got overwhelmed with the complexity of coding in a single task. If someone else does one, or comes up with something similar let me know. I think, at least for the meantime, I'll stick with doing a roundtime check for each skill used.

- -
Well, here's a stab at something that might be useful. It could use some more commenting, a more impressive demo, and more thorough testing, but I think the idea is fundamentally sound...

MOB brain/task management code

If this looks at all interesting to you, send in your feedback, questions, flames, whatever... I will probably keep refining it and coming up with examples of usage as time goes by, since I plan to use it myself shortly.
In response to Guy T. (#6)
If this looks at all interesting to you, send in your feedback, questions, flames, whatever... I will probably keep refining it and coming up with examples of usage as time goes by, since I plan to use it myself shortly.

Sorry Guy, I've been unusually busy over the last few days (not to mention unusually crippled... =), so I haven't had a chance to check that out yet. I'll look at it when I get home (about an hour from this post time).