Sophie: xconq-7.5.0-1.20050612.5mdv2009.1 i586

xconq-7.5.0-1.20050612.5mdv2009.1.i586.rpm

<HTML>
<HEAD>
<!-- This HTML file has been created by texi2html 1.39
     from ./hacking.texi on 12 June 2005 -->

<TITLE>Hacking Xconq - Play Commands</TITLE>
</HEAD>
<BODY>
Go to the <A HREF="hacking_1.html">first</A>, <A HREF="hacking_15.html">previous</A>, <A HREF="hacking_17.html">next</A>, <A HREF="hacking_35.html">last</A> section, <A HREF="hacking_toc.html">table of contents</A>.
<HR>


<H2><A NAME="SEC16" HREF="hacking_toc.html#SEC16">Play Commands</A></H2>

<P>
There is no single correct way to support direct player control over
units.  Although keyboard commands and mouse clicks are obvious choices,
it would be very cool to allow a pen or mouse to sketch a movement plan,
or to be able to give verbal orders...

</P>
<P>
There is a common set of ASCII keyboard commands that are recommended
for all <I>Xconq</I> interfaces that use a keyboard.  These are defined in
<TT>`kernel/cmd.def'</TT>.  If you use these, <I>Xconq</I> players will be able
to switch platforms and still use familiar commands.  <TT>`cmd.def'</TT>
defines a single character, a command name, a help string, and a
function name, always in the form <CODE>do_*</CODE>.  However, <TT>`cmd.def'</TT>
does not specify arguments, return types, or behavior of those
functions, so each interface must still define its own command lookup
and calling conventions.

</P>
<P>
Many commands are common to all interfaces; their implementations
are in <TT>`kernel/cmd.c'</TT>.

</P>
<P>
If you include <TT>`cmd.def'</TT>, you must then provide definitions for all
the functions that it mentions.  You should also provide some sort of
feedback for commands that are not implemented, or that are not useful.
Players who are used to another interface will expect to be able to type
the same commands, and can get very confused if the familiar commands
neither work nor complain about not working.  One way to fill in
defaults for functions that you don't want to do yet is to use macros
ahead of the inclusion of <TT>`cmd.def'</TT>:

<PRE>
#define do_quit default_empty_do
#define do_save default_empty_do
...

#include "cmd.def"

default_empty_do()
{
	notify(a_side, "Command not implemented in this interface");
}
</PRE>

<P>
Prefixed number args should almost always be repetitions.

</P>
<P>
If already fully fueled, refuel commands should come back immediately.

</P>
<P>
A quit cmd can always take a player out of the game, but player may have
to agree to resign.  Player can also declare willingness to quit or draw
without actually doing so, then resolution requires that everybody agree.
If quitting but others continuing on, also have option of being a
spectator.  Could have notion of "leaving game without declaring entire
game a draw" for some players.
Allow for a timeout and default vote in case some voters have disappeared
mysteriously.
Must never force a player to stay in.
Add a notion of login/logout so a side can be inactive but untouchable,
possibly freezes entire game if a side is inactive.
1. if one player or no scoring
	confirm, then shut player down
	if one player, then shut game down
2. if side is considered a sure win (how to tell? is effectively a win
condition then) or all sides willing to draw
	confirm, take side out, declare a draw, shut player down
3. if all sides willing to quit
	take entire game down
4. ask about resigning - if yes,
	resign, close display, keep game running
   if no, ask if willing to quit and/or draw, send msg to other sides
Kernel support limited to must_resign_to_quit(side), similar tests.

</P>

<HR>
Go to the <A HREF="hacking_1.html">first</A>, <A HREF="hacking_15.html">previous</A>, <A HREF="hacking_17.html">next</A>, <A HREF="hacking_35.html">last</A> section, <A HREF="hacking_toc.html">table of contents</A>.
</BODY>
</HTML>