> Oooh. That is a pretty cool idea. Removes the whole problem of
> scripting/faster connect/etc.
Thanx 8)
> How do you deal with multiple people fighting?
On my MUD combat is always one on one (for good reason as players do not do
the actual combat, it is done in proxy [think Pokemon but not really])
I will probably make a public release that will eventually included
abilities to process multiple players.
> How do you deal with out-of-turn-based-comabt action (like healing from
a non-grouped
> member on a person who's currently in combat?).
I'll asume you mean a person not in combat trying to affect a person in
combat. The only thing I can think of (off the top) is to use a que (no
idea how to spell) to process outside events. The only thing would be
deciding which things pulled the affector into combat and which didn't (is
the action hostile?) Also you would _have_ to process all the outside
events at the same time (for fairness) probably at the start of the next
combat round. Or allow the Imm to set a number of combat turns per mud
minute and the process the ques every 'minute'.
> How do you deal with people entering and leaving an existing fight?
Much the same way it is now.. Basicly have a [F]lee menu option and it
will remove the person from combat.. The adding will take a little more
work. I think the "combat turns-to-mud minute" would come into play here.
-- [snip Oasis Explination]--
Thank you!! You are awesome! (I knew I always read your posts for a
reason)
> Don't forget either; many, MANY people enjoy the communication
> aspects of MUDS, and that includes things like asking someone to heal
> them, or getting tells from their newly-logged on friend... even if
> they're in battle. A menu system with only limited forms of input
> wouldn't allow you to respond. At worst case, if it refreshs/clears the
> screen, you wouldn't even see the tell in the first place.
My thought here is 2 fold.. One add some menu things like [G]ossip and
[T]ell to the menu. These would be accessible even after "IS_PLAYER_READY"
is set (possibly a WAIT_FOR_OTHERS menu) Then I'm thinking add a "window"
above the menu that 'refreshes' when new input is sent. The draw back, if
a player types "A" and then waits and the "window" refreshes their input
would no longer be visible. I don't think that's a big deal but it could
be..
> That's assuming you've included your new CON_MENU_BATTLE in the
> IS_PLAYING() macro, so people are still able to be 'seen' by other
> functions.
Would kinda have to to make it all work the way I want 8-)
BaH
P.S. If you are interested in working on a system like this /with/ me let
me know, I would love to work with someone 8)
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/04/01 PST