>
> I'm looking to implement Menu driven Turn based Combat. Basicly I want to
> make an Oasis style interface to combat. The turn based part isn't to
> hard.. I'm thinking that a check like:
> if (!IS_READY(ch) || !IS_READY(vict))
> at the begining of preform_violence (or is it hit()?) will do the trick..
> My main problem comes to the Menu driven part. There are a couple things
> I want to do differant from Oasis or anyother menu driven system.
> 1) I want the character to continue to recieve any kind of messages (on a
> toggle so they can turn it off if they are gettin spammed or something)
> 2) Okay never mind just one thing I want differant..
>
> The true problem comes in when I look at how Oasis works (or the Oasis
> add-ins like HEDIT) I don't understand what's going on and don't know
> where to start to make something similar.
Oooh. That is a pretty cool idea. Removes the whole problem of
scripting/faster connect/etc.
That said, let me first get my apprehensions out of the way;
How do you deal with multiple people fighting? 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?). How do you deal with
people entering and leaving an existing fight? I know turn based works
well for single player rpgs, or multiplayer strategy games; and I haven't
yet played PSO (which, if it's anything like it's predecessors, is most
likely turn based. Granted, you have a very limited interaction with
people, and they can't harm you - from what I hear.).
So, now for the nitty-gritty (anyone feel free to interject if I'm
wrong/too general). Oasis works like this
-----------------
Player types an Oasis command. (ie redit 50)
Mud sets up existing/creates new object (a room in our example),
verifies zone boundries and permissions, etc. Then, the mud
changes the player's CON state to the editing state. (CON_REDIT in
ours).
-a little about CON_ states
The mud associates a 'CON' state with every descriptor. It's just
an integer, but the actual representation is unimportant right now. What
is important is that each time you type a command, the mud uses that CON
state to determine what part of the mud program gets to interpret it. For
example, if you're in the CON_MENU, then the main-menu parsing part of the
program gets your input. If you're in CON_PLAYING, you're playing
normally (and your input goes though the command_interpreter). If you
want to add a _new_ menu interface, a good place to start is duplicating
the code for a well-established (small) CON state. Simply duplicate it
everywhere you see it in the code. Try something relatively static, like
the main menu, for starters.
-
There's also one more thing the mud does, it sets up the OLC
structure on the descriptor of the player who typed that command. This
contains a copy of the item they're working on (like, the room) - so it
can be altered without affecting anything until at the very end where it
asks 'do you want to save this <object>?'. Another part of this OLC
structure is the OLC_MODE(). This is nearly like the CON mode above.
That is, it serves the same purpose. It's used instead of CON, because
you'd have to add something between 15 and 40 new states for each Oasis
subscreen (redit/oedit/sedit/etc), and not only would that be messy, you'd
also have to add custom code for each NEW entry so the mud would realize
that someone who's in OEDIT_MAIN_MENU and OEDIT_EDIT_NAMELIST are actually
the same.
Something that'll come up that's confusing; say you want to
display a menu, and then retrieve a choice from the user. That's two
different states (be they CON or *EDIT_ types). Lets look at another
example; if a user is looking at the opening screen for oedit, then the
function oedit_disp_menu was just run, and sets
OLC_MODE(d) = OEDIT_MAIN_MENU. This is actually not about DISPLAY -
despite what you think. This refers to (DA-DA!) the input. It knows
you've already seen the main menu, now it's going to parse whatever comes
back as if you're typing a command from the menu. Sounds reasonable
right? So, if I type '1' and choose to edit the name list, the
OEDIT_MAIN_MENU section will actually be the one to DISPLAY the phrase:
"Enter keywords" - and then set my mode to OEDIT_EDIT_NAMELIST.
-----------------important bit here -------------
Just remember; submode means input parsing and output of the NEXT
mode's choices.
-------------------------------------------------
Anyway, the functional end of the OLC_MODE is identical to the CON
mode; it just chooses which part of the (olc) program gets to parse the
input (and therefore, decide what to output back). At the very end, when
the person chooses to 'save', the OLC_MODE is examined to determine which
parts of the OLC structure attached to the descriptor are actually to be
saved.
After some cleanup, it sets your CON mode back to CON_PLAYING and
you go merrily on your way.
Now, you'll have to add a bit to get your system to work. You'll
need at least one new CON state, and it wouldn't hurt to create a new
structure associated with your player for battle-related data. After all,
everyone is going to be sitting around until all combatants in any given
sortie have entered their move, so you're going to need sub-modes, like
-Main menu
-cast a spell menu
-use an item menu
-attack w/weapon
-use a skill
-perform a non-battle action (get potion from backpack, remove
cursed ring, etc)
- waiting for battle to start
Then, you'll also have to do a search each time a PC finishes
their command;
Are all other PC's involved in battle with him in the 'waiting for
battle to start' mode. If so, dispense with a round of combat (otherwise,
do nothing).
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.
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.
Hope that helps.
PjD
--
+---------------------------------------------------------------+
| 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