> >Secondly, has anyone developed a round-time based command
> system, like that
> >of GemStine III and Dragonrealms?
> seconds it
> >takes before you can execute the command again. Obviously, as
> you get better
> >in the skill your round-time for that skill-command decreases. Do players
> >mind this?
>
> Check out wait states.
> Look in the bash command for an example of how to
> use them.
>
"Yeah but"... simply tying into the wait_state game PULSE stuff doesn't
really take into account the players skill level (it provides a static
limitation on a commands execution regardless of other situations - as far
as I can tell). Please tell me if I'm wrong though (I've just started
coding Circle). Would it even be feasible to apply the "game pulse" timing
to an individual "player pulse" timing? System things still need to happen
based on the game pulses, but there should be a "player pulse" that is taken
into account.
I'm glad someone brought up the "timing" issue actually, because I'm looking
into using some cyberpunk rules that rely heavily on a characters
"Quickness" (sort of like Dexterity and Agility rolled into one)... only
now am I pondering how this is going to fly with how things currently work
with the Circle-based code. (Bear with me, the following are my thoughts in
progress... *smirk*)
Every command has to fall into several categories - like Simple Action or
Complex Action. Take just one example, reloading a weapon.. some weapons
require a complex action to reload while others only need a Simple Action.
Using another example everyone should understand.. when you "look in corpse"
(supposedly rummaging through a corpses pockets and "searching" the body)
that is a Complex Action and should take LONGER than a Simple Action command
like "get <item>".
Another question I think he was asking.. "Does it affect playability?" - "do
players mind?" Yes, definately. If you typed a command to "look in corpse"
and every time you tried typing "kill monster" the system returned with "you
are currently doing something else"... would the player mind? To me, on one
hand, it's much more realistic and your actions have to be planned a little
more.. do you really want to search that corpse and "get all" when another
monster has just entered the room and could attack? BUT, on the other hand,
in real life you'd STOP searching the corpse and start to fight whatever was
attacking you (then go back to searching the corpse again after killing the
new attacker).. SO does it really matter how long it takes to search a
corpse? No. Actions like "get" and "look in" shouldn't be affected by
timing.. because it would severely affect the games playability.
However, with BASH, I think timing should definately be a factor (throwing
yourself bodily at an opponent - it'd take time to recover yourself, so you
shouldn't be able to do anything else)... for a period of time after
bashing, the system should respond "you are recovering yourself". AND if
you have a higher skill at BASH, then it should take less time to recover
(this is important.. it shouldn't take the same amount of time for every
character to recover after bashing).
I've decided to implement timing with the LOAD/RELOAD commands.. so if a
player is reloading a weapon, then attempts to IMMEDIATELY fire that weapon
at an opponent, the system will say "you are still reloading"... and if you
have a higher Quickness rating, then you should be able to reload faster.
I don't think the players would mind a LITTLE realism, but if every single
action had to take place in "real time" then the game would be very lame.
There. That's what I think about time as it applies to a players actions
and how it affects playability. Now I just have to figure out how to
implement "player pulse"... heh.
---
Joe Rykowski ('Cyklop'), SysAdmin/Builder/Coder
>> C.O.R.E. MUD - a post-cyberpunk adventure
>> http://members.xoom.com/CoreMUD/
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST