Re: [IDEA] Turn Based Combat

From: Peter Ajamian (peter@pajamian.dhs.org)
Date: 03/16/01


Michael Gesner wrote:
>
> Well... I guess I should throw in my two cents...  One thing that has
> worked well for us in RD for reading our scoreboard in multiplayer games
> (in fact in paging altogether) is to queue tells and messages so that a
> player who is paging will not miss them.

Well, actually all I did in RD was to set it up so that any output
recieved whiel paging is simply added to the end of the paging text
(well, maybe not so simply, but I pulled it off).  The actual reason I
ended up doing this was because I had fixed the pager to erase the
prompt line when displaying the next page (via ANSI escape sequences)
thus showing the text being paged uninterrupted.  This would, of course,
be messed up if other messages were shown in-between pages so I needed a
way to control this.  Adding the messages to the end of the paged text
was my solution.  This has a downside, though, where if a player quits
out of the pager he will miss any messages he might have recieved while
paging.  I actually have a solution to this (which I'll probably be
implementing in RD sometime soon) which will go as follows...

Condition:  Player is paging text.

Complication:  page_string() is called on the player for some additional
text (this won't happen in stock, but we have modifications which might
allow for that).

Current resolution:  New text to be paged is added to the end of old
text as follows:  CREATE() a new dynamic memory buffer large enough for
both and strcpy both buffers into it.  If either buffer is marked for
deletion when finished paging then free() it.  Re-paginate the buffer
but keep the current page the same.

New resolution:  Stash the new text to be paged away in a separate
buffer and then page it when the player is finished paging the original
text.  Use a linked list for these with a char * for the buffer, a
boolean value to indicate if it's static or dynamic, and a *next.

Second complication:  Player recieves text by the standard act() or
send_to_char() or SEND_TO_Q(), etc.  This would normally interrupt the
players paging which can be annoying.

Current resolution:  Same as for adding new text via page_string().

New resolution:  Stash this in a separate, dynamically growing char *.
Add new messages to the end.  Page this when all other paging is
finished.

> If you want to have talk between players in combat... then you can add a
> "taunt" to your menu system... the player will effectively taunt the other
> player... whether its simple chat, or really meant to annoy... the command
> would serve its purpose.

I would say, block tells, whispers, etc, but not says or emotes, etc.
Also it would seem that (and forgive me if this is already the case)
some socials should act differently when the player is in combat, or not
work at all.  The taunt command could be just a regular social which
works in or out of combat (a player may want to taunt someone to draw
them into battle or for any number of other reasons).

> Getting back to the idea of clearing the screen... I suppose this is
> plausible...

It's very simple, Oasis has an option to do it which is enabled by
changing a single #define somewhere.  All that needs to be done is to
send an ANSI escape code to the terminal.

> make a short menu..
>
> something like
>
> (1. Attack, 2. Defend, 3. Flee)
> >
>
> And attach it above the prompt.

Another good idea, it can work on the exact same system as the regular
menu and have an option to switch to long menu (the same option in the
long menu will switch to the short).  A simple PRF_ flag will save this
setting.

> Another thing that might be a good idea to implement, would be a help
> system contained within the combat menu itself.  Rather than putting the
> help in the "help" file, you can add a menu option for help on the commands
> themselves.  We have a help system for our OLC contained within each editor

Well, currently within medit and oedit.  The other editors are on the
to-do list *grin*.

> so that terraformers can quickly get the information they need on whatever
> menu option they do not understand.

Yep the oedit one even knows all the different object types and displays
the correct help for the different vals according to what the object
type is.

> Michael Gesner
> Lodaren of Rhu-Dina'ar
> rhudin.newvisiongames.net 7777

Peter Ajamian
Allanon of Rhu-Dina'ar
::Points up to Mike's sig for the rest::

--
   +---------------------------------------------------------------+
   | 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