25 Dec, 2010, donky wrote in the 1st comment:
Votes: 0
Right, so the one misguided soul who occasionally sends me emails about lackings in my MUD codebase has asked about ticking and combat. Surely there must be some standard core which lies at the heart of MUDS that aren't going out on some batshit crazy limb of their own?

Now I think having a per-object tick is in these days a naive simple approach. It should be possible to formalize a higher level system where authored actions, combat or not, implicitly just work in the way they should.

These modern times, I would expect there to be a queueing system. Walk west two hundred furlongs, turn north at the fallen tree and then at the cliff edge climb down to the cave. Or drop and punch the Orc in the family jewels, then turning and running for the exit. Or simply "kill orcs", "take all from Orc corpses", "return home"…

Now a command would have either have a duration, or wouldn't have one.

Without a duration the command would happen instantly. An example of the might be the naive "look" command, which immediately starts, performs it's function and then exits.

With a duration, it gets a bit more complicated. Using as an example a "search" command that is applied with as much effort as the player wants to put into it. At some point it should be obvious to the player that they feel any further of this action is futile. Maybe the command starts, gets ticked building up state and feeding output to the player, until futility is reached. But a better way to do it would to keep the search knowledge as persistent player state rather than per-command execution state, then the command could be implemented as a unit action that was simply repeated building on external state using a combination of recent past attempts and skill to determine per-duration result.

Then there are the more complicated actions. What if you attempt an action, but for the attempt to proceed you need to attempt it for a minimum amount of time. Any time spend doing it past this point contributes to the amount of success, but at any time from that point until the maximum duration the action can be concluded. A curve would determine the factor of success based on the point reached between minimum and maximum duration. Perhaps linear, perhaps exponential. If the latter a maximum duration would perhaps be pointless.

In any case, an action would at its simplest have a pre-effect, and a post-effect. It would have a duration. Actions should queue, but non-game actions should neither have duration nor participate in the queue.

At this point, while I can settle on the basics, I feel I should write a combat or game action transcript and then treat that as a script to be executed and use it to drive the implementation. In fact, that might be worth experimenting with just to see how it works as a general way to drive game development without avoiding thinking about the gameplay.

Anyway, this post is really just me passing some time trying to give some attention to this and make some headway. Time is short and I am gonna go have some noodles and dumplings. P.S. An iPad is just a glorified ebook reader and games doodad, it isn't designed for writing forum posts…
25 Dec, 2010, donky wrote in the 2nd comment:
Votes: 0
Here's a simple transcript..
Quote
TRANSCRIPT Simple combat
ACTOR ActorOne
ACTOR ActorTwo
spawn two swords
00:00:00 ActorOne: take a sword
00:00:00 ActorTwo: take a sword
00:00:00 ActorOne: attack ActorTwo
00:01:00 ActorOne.. readies sword
00:03:00 ActorOne.. focus ActorTwo
00:10:00 ActorOne.. uses sword on ActorTwo
00:10:00 ActorOne.. hits ActorTwo with sword
00:10:00 ActorTwo.. receives damage

Ideally I should be able to cobble together a range of these that express the different actions I see happening in my game. However, writing them I wonder.. These transcripts could also define game behaviour. You could enumerate the different types of objects that were mentioned in the scripts, the ways they were used, the process which their usage went through and the effect their usage had. Even still, testing transcripts would then be a higher level form of transcript which did not define anything other than expected observations.

Okay, time to implement a prototype.
25 Dec, 2010, David Haley wrote in the 3rd comment:
Votes: 0
At the risk of having missed the obvious, was there a question here? It looks like you wanted to talk about event systems at first, but ended up talking about commands that take time to execute, and you dropped the bigger question of general events. Is there a standard for MUD event systems? Not really, other than Dikurivatives having basically the same very simple ticking model, etc.
26 Dec, 2010, Ludwig wrote in the 4th comment:
Votes: 0
try to incorporate the theory of special relativity in there.
27 Dec, 2010, Runter wrote in the 5th comment:
Votes: 0
There's really a number of concepts discussed here. The one I wanted ti respond to was commands that have state(in this case a timer). The easiest way to solve this is a coroutine/continuation/generator which by definition is a function with state. Another less appealing option is a simple disassociated timer that's ticked down elsewhere with a callback. I don't really like that design. I'd advise not solving the problem with threads/sleep. Although that's an easy way in some languages. Instead if going that route I'd suggest a light weight concurrency mechanic like erlang processed or ruby fibers or just timers with lambda callbacks.
0.0/5