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 ./xcdesign.texi on 12 June 2005 -->

<TITLE>Designing Games with Xconq - Building New Games</TITLE>
</HEAD>
<BODY>
Go to the <A HREF="xcdesign_1.html">first</A>, <A HREF="xcdesign_24.html">previous</A>, <A HREF="xcdesign_26.html">next</A>, <A HREF="xcdesign_61.html">last</A> section, <A HREF="xcdesign_toc.html">table of contents</A>.
<HR>


<H2><A NAME="SEC90" HREF="xcdesign_toc.html#SEC90">Building New Games</A></H2>

<P>
There are at least three ways to make a new game design: use <I>Xconq</I>
commands to "play" a game and then save it, create and text-edit the
text files defining a game, or write and run special-purpose programs
that create games.  A combination of these techniques will likely prove
the most useful, since each alone has both strengths and weaknesses.
For instance, text editing may seem like a crude approach, but is the
only way to produce certain types of scenarios, and text editors have
many facilities (such as regular expression replacement) not directly
available in <I>Xconq</I>.  On the other hand, maintenance of the correct
transport/occupant relationships between units is hard to do while
editing text, but comes for free when using <I>Xconq</I> itself.

</P>

<UL>
<LI><A HREF="xcdesign_25.html#SEC91">Building Scenarios</A>
<LI><A HREF="xcdesign_25.html#SEC92">Designer Mode</A>
<LI><A HREF="xcdesign_25.html#SEC93">Saving Scenarios</A>
<LI><A HREF="xcdesign_25.html#SEC94">Preparing a Game for Use</A>
<LI><A HREF="xcdesign_25.html#SEC95">Installing a Game</A>
<LI><A HREF="xcdesign_25.html#SEC96">Playtesting</A>
<LI><A HREF="xcdesign_25.html#SEC97">Safety</A>
<LI><A HREF="xcdesign_25.html#SEC98">Balance</A>
<LI><A HREF="xcdesign_25.html#SEC99">Complexity</A>
<LI><A HREF="xcdesign_25.html#SEC100">Combinations</A>
</UL>



<H3><A NAME="SEC91" HREF="xcdesign_toc.html#SEC91">Building Scenarios</A></H3>

<P>
The easiest way to customize <I>Xconq</I> is to build a scenario.  A
scenario is basically a saved game from which irrelevant details, such
as the list of players, has been omitted.  Typically this will include
tweaking details, removing random irrelevant junk, and generally tuning
things.

</P>
<P>
One way to do this would just be to start a normal game, save it, and
then dig through the saved game and edit it, since the saved game is
itself a game module.  Sometimes this is easy, more likely it will be
quite hard and error-prone.  A better way is available, in the form of
"designer mode".

</P>


<H3><A NAME="SEC92" HREF="xcdesign_toc.html#SEC92">Designer Mode</A></H3>

<P>
There are two ways to get into designer mode; one is to start up a game
with the appropriate option (<CODE>-design</CODE> under Unix), which makes
every player with a display a designer, the other is to switch on a flag
after the game has started.  Being a designer is a property of a side,
so in theory a game could have a designer and several other human
players, or even multiple designers (this might be useful in having
assistants to help with the construction of large scenarios, or just to
have displays open to each side's view of the scenario).  AIs
effectively sit out the game while designers are present.

</P>
<P>
Designer mode enables an additional set of commands on the menu or map
control panel, as well as removing some restrictions on the use of
normal commands.  It also enables more elaborate game saving machinery,
so you can save only the parts of a game that you want to make into a
scenario.

</P>
<P>
Modifications to normal commands include the permission to look at and
do any command on any unit, including independents and units belonging
to other sides.  For instance, any unit can be renamed at any time by
any designer in the game.  The modications include the following:

</P>

<UL>
<LI>

Move commands can put any unit at any destination instantly.

<LI>

Any unit can be put on any side.

<LI>

Any unit can be disbanded instantly.

<LI>

Any terrain can changed to any type.
</UL>

<P>
Some interfaces may also provide additional tool palettes and the like.

</P>


<H3><A NAME="SEC93" HREF="xcdesign_toc.html#SEC93">Saving Scenarios</A></H3>

<P>
If you're not in designer mode, then saving the game will save
absolutely everything.  In designer mode, the interface should ask you
what parts of the game you want to save, and what to name the module.

</P>
<P>
If you don't save everything, then you should start up another game just
to confirm that you got what you wanted, <I>before</I> shutting down the
<I>Xconq</I> that you're designing with.  Sometimes you won't have saved
what you thought you did...  It's also a good idea to keep a backup copy
of data, especially the indecipherable area layers; use the nesting
comments <CODE> #| |# </CODE> around the old stuff, only delete when you're
sure it's no longer of interest.

</P>


<H3><A NAME="SEC94" HREF="xcdesign_toc.html#SEC94">Preparing a Game for Use</A></H3>

<P>
Once you've constructed a game, you should bring it to a state where it
can be given to other <I>Xconq</I> players.  I recommend copying a standard
software release strategy.  This means documenting how to play the game,
documenting how it works internally, removing unused junk and dubious
features, simplifying where possible, resolving open issues if possible,
documenting them as known problems if not.  This gets you to the point
of having an "alpha" or "beta" version (the terms are not precise!).
These can be given to other people for testing, but should be clearly
identified as test versions, because your testers may pass copies along
to others without you knowing about it.  After some playtesting (see
below), edit your game into its final form, call it 1.0 and release it
to the world!

</P>
<P>
After you release your game, you may get some feedback about
unanticipated problems.  When you resolve these, and want to make a new
release, be sure to give it a distinct version number.  This will be
important to deciding whether subsequent complaints are about your new
release or some older one.  If you always put the version number into
the <CODE>version</CODE> property of the <CODE>game-module</CODE> form, then it will
be displayed to players when they ask for help on the game.

</P>


<H3><A NAME="SEC95" HREF="xcdesign_toc.html#SEC95">Installing a Game</A></H3>

<P>
Once the scenario is constructed and saved, you can install it in the
library and otherwise do as you like with it.  See the interface
documents for platform-specific installation details; in general, just
copying the files into the <CODE>lib</CODE> directory will suffice.

</P>


<H3><A NAME="SEC96" HREF="xcdesign_toc.html#SEC96">Playtesting</A></H3>

<P>
Playtesting is extremely important, even for simple game!  You should
try as many combinations of startup options as possible - for instance,
the combo of two humans and one machine might reveal a peculiarity that
is not observed in a two-person game.  You can solve many problems by
adding more restrictions.  Since the scenario is your concept, you are
free to make whatever decisions are necessary to realize that concept;
if somebody complains, they are free to make their own designs.

</P>
<P>
Playtesting is the time when you may have to sacrifice realism and
favorite theories for playability.  Listen to and watch yourself and
your testers as the game is played.  For instance, you might have
included a city out in the boonies, but in the game it never does
anybody much good, while still requiring some amount of attention
regularly.  Lose it.

</P>
<P>
Game startup can be confusing to players if they all start out with lots
of units needing to be told what to do.  One solution is to put most
units on automatic behaviors that expire in a turn or two, so that
novices gradually hear from all the units, while experts can still
override right from the outset.  Another approach is to make units
independent and allow them to be captured early on.  Still another
approach is to make units come in as reinforcements at preset times and
locations.  Since players will form their strongest impressions of a
game based on its appearance at startup, attention to this will pay off.

</P>


<H3><A NAME="SEC97" HREF="xcdesign_toc.html#SEC97">Safety</A></H3>

<P>
While generally safe -- <I>Xconq</I> shouldn't crash while you are
designing nor upon starting up your scenario -- you can do silly things,
like loading a submarine with battleships as passengers.  <I>Xconq</I>
won't complain, but it may behave very strangely.  For instance, a unit
might be able to travel with a transport and leave it, but not be able
to get back on again.

</P>
<P>
One way to test a game is to remove all the scorekeepers and make all
the players be AI-controlled.  The AI code will then act totally
randomly, thus exercising parts of your design that you may not have
thought much about.  A convenient way to try out various scorekeepers is
to put them in variants, then select them upon startup.

</P>


<H3><A NAME="SEC98" HREF="xcdesign_toc.html#SEC98">Balance</A></H3>

<P>
Game design often involves subtle questions of balance which
will only be revealed by repeated play of the game.

</P>
<P>
Although as many of the game parameters as possible are checked, there
is plenty of room for subtle loopholes.  You should think carefully
about the consequences of each parameter, being particularly sensitive
to degenerate winning strategies.  Most common are units that are too
powerful, too fast, or are built so quickly that they overwhelm any
opposition.  Players should always be a little "hungry"; not able to
get quite as many units or as much material as they would really like.

</P>


<H3><A NAME="SEC99" HREF="xcdesign_toc.html#SEC99">Complexity</A></H3>

<P>
Although GDL is a powerful language, you should avoid designing a game
that is too complex to be humanly playable.  A single game can literally
define millions of different parameters, each with a range including 100
to 10,000 distinct values.  It is clearly possible to spend many years
exploring just a single set of these!  For more playable and enjoyable
games, either pick a single thing to treat in detail, or else do
everything in a simplified way.  For instance, if you want elaborate
movement and combat rules, avoid or even eliminate materials and
associated material handling rules.

</P>
<P>
Another thing to keep in mind is that the introduction of a new type may
have far-reaching consequences. For instance, an additional unit type
will need its interactions with <I>all</I> other unit types defined, as
well as with terrain and materials, and those new interactions may in
turn affect others.  One approach is to introduce a new type as a slight
modification of an existing type, then to share most of the definitions.
Another thing you can do is to put complexity into the variants, so
players with a taste for punishment can indulge themselves, while
leaving the basic game as more of a fun thing.

</P>


<H3><A NAME="SEC100" HREF="xcdesign_toc.html#SEC100">Combinations</A></H3>

<P>
Many of the 700-plus game parameters were chosen for their ability to
combine in interesting ways, rather than for obvious usefulness.  For
instance, construction in a city can by default generate an infinite
stream of units.  But suppose you want to put a limit on the numbers of
that type of unit?  One way is to define a material that is essential
for construction of that type, let the builder have an initial supply,
but provide no way to get more of that material.  When it runs out, no
more units!

</P>
<P>
Another trick is to motivate an activity by making it a prerequisite to
the basic builtin goal of defeating the other player.  The age of
discovery worked this way.  The kings of that time weren't interested in
new lands <I>per se</I>; they wanted exploitable possessions, that could be
used to get gold, to buy armies big enough to defeat their neighbors.
You could describe this situation almost exactly, by making gold a
material, obtainable only by the discovery and capture of independent
gold mine units, which are thinly scattered over the world and can be
found only by careful exploration.

</P>
<P>
Be inventive!  Studying the predefined games should suggest many tricks;
the "Tricks and Techniques" section below describes even more.  Be
sure to document the trick carefully, or the next time you work on the
game, you might break it, resulting in unhappy players wondering why
their usual strategies don't work anymore.

</P>
<HR>
Go to the <A HREF="xcdesign_1.html">first</A>, <A HREF="xcdesign_24.html">previous</A>, <A HREF="xcdesign_26.html">next</A>, <A HREF="xcdesign_61.html">last</A> section, <A HREF="xcdesign_toc.html">table of contents</A>.
</BODY>
</HTML>