Sophie

Sophie

distrib > Mandriva > 2010.0 > i586 > media > contrib-release > by-pkgid > 74fbd0eb33bb08f719b79951bc4e329e > files > 18

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 - Introduction</TITLE>
</HEAD>
<BODY>
Go to the first, previous, <A HREF="hacking_2.html">next</A>, <A HREF="hacking_35.html">last</A> section, <A HREF="hacking_toc.html">table of contents</A>.
<HR>

<P>
Hacking Xconq
<P>
The School for Strategy
<P>
Version 7.4
<P>
December 2000
<P>
Stanley T. Shebs
Copyright (C) 1987-1989, 1991-2000
Stanley T. Shebs

</P>
<P>
Permission is granted to make and distribute verbatim copies of
this manual provided the copyright notice and this permission notice
are preserved on all copies.

</P>
<P>
Permission is granted to copy and distribute modified versions of this
manual under the conditions for verbatim copying, provided also that the
section entitled "GNU General Public License" is
included exactly as in the original, and provided that the entire
resulting derived work is distributed under the terms of a permission
notice identical to this one.

</P>
<P>
Permission is granted to copy and distribute translations of this manual
into another language, under the above conditions for modified versions,
except that the section entitled "GNU General Public License",
and this permission notice, may be included in translations
approved by the Free Software Foundation instead of in the original
English.

</P>



<H1><A NAME="SEC1" HREF="hacking_toc.html#SEC1">Introduction</A></H1>

<P>
This manual describes the internal architecture of <I>Xconq</I>, and
provides information and guidelines for modifying the sources.  You
should know what you are doing; <I>Xconq</I> is designed to be modifiable,
but it is not simple code.  In the past, people have found it easy to
make changes, but much harder to make them correctly!

</P>
<P>
First, the overall goals of <I>Xconq</I>.  <I>Xconq</I> cannot and does not
attempt to be all things to all people; instead it focusses on a very
particular class of game, namely map/overhead-view strategy games.  This
has become a rather well-worn genre of game, but the field is still open
for innovation; <I>Xconq</I>'s main contribution is that it allows the
construction of many different games in this genre, without requiring
low-level programming.

</P>
<P>
These are the specific goals for <I>Xconq</I>:

</P>
<DL COMPACT>

<DT><B>Portability</B>
<DD>
<I>Xconq</I> should be able to run on a wide variety of machines.  However,
new versions need not restricted by the limits of old systems.

<DT><B>AI</B>
<DD>
It should be possible for a game AI to play any side in any game.

<DT><B>Networking</B>
<DD>
It should be possible for any player on the net to play any side.

<DT><B>Scale</B>
<DD>
<I>Xconq</I> should work well for games of strategic and operational
maneuver based on a 2D surface.  It does not need to work well for
tactical games, adventure games, space games, or anything requiring full
3D.  (This doesn't mean that it should be excluded from those types
of games, just that they are not required to be possible.)

<I>Xconq</I> should be able to handle very large games.

<DT><B>Game Design</B>
<DD>
The designer should be able to use GDL to build any strategic-level game
desired.  There should be multiple computational models available to the
designer, such as different algorithms combat resolution.

<DT><B>Graphics</B>
<DD>
It should be possible to use graphics of a high quality, but it should
not be required to produce a playable game.  The designer should be able
to adjust all aspects of a game's appearance.

<DT><B>Play Action</B>
<DD>
It should be possible to design both turn-based and real-time games, the
choice being left to the game designer.  It should also be possible to
design both simple easy-to-play games and complex detailed games.

</DL>

<P>
<I>Xconq</I> is designed to be portable to different types of user
interfaces.  It is based on a kernel-interface architecture, where the
semantics of the game, as documented in the preceding chapters, is part
of the kernel, while the main program and player interaction are
specific to each system.

</P>
<P>
<I>Xconq</I> is also designed to allow the addition of new AIs.  The
default <CODE>"mplayer"</CODE> AI, while it is flexible and will attempt to
play any side in any game, does not have the depth that is often
important to success in a game.  Its position is that of a generic AI
program that can learn to play any game, given only the rules; while
such a program might figure out how to win at tic-tac-toe or checkers,
it is not going to be particularly good at the subtleties of go or
chess.

</P>
<P>
The <I>Xconq</I> GDL is also extensible.  This is useful when the basic GDL
does not provide some feature that is essential to a game.  It is
fairly easy to add new global variables, properties, and tables.

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