This is the mail archive of the xconq7@sourceware.cygnus.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: What to do with Xconq


  Background: played Xconq on Macs some time ago, have been getting
into it again now that it runs on 95/98/NT.  Primarily a player 
of Civ-like games, but also enjoy historical wargames.  Play 
pretty much exclusively single-player.  

At 05:48 PM 2/1/00 -0800, Stan Shebs wrote:
>While reading about and reflecting on the various games in Xconq's
>area, and playing them, I began see to see some strategic mistakes in
>the current system.
>
>* Confusion between game and game engine.  ...

  I don't think this is a serious problem with the current sorts of 
players; if we are serious about a wider "market" it may become 
more of an issue.  

>* Too many unfinished games.  Players and game designers never really
>get to see what the system might be capable of.  (``Finishing'' a game
>might mean anything from providing polished graphics to writing better
>AI support.)

  This is definitely a problem; a worse problem is that it is 
frequently not obvious which games are finished to which degree.
Perhaps some sort of code or label you can see while you choose 
your game:

* Early development [major portions of code not complete; game 
    engine may not yet support some needed functions.]

* Late development [most units, materials, sides, etc. have 
    at least a nominal, working version; game engine code supports 
    all necessary functions.]

* Alpha playtest [Game works and is playable; however, unit (& other) 
    graphics may still be temporary stand-ins, and historical 
    unit, place, etc. info (names, flags, leaders, etc.) may still 
    need work.  Play balance may still be shaky.  There is at least
    one scenario included, which involves at some point all major 
    game pieces and concepts. Information on all units, materials, 
    etc. is available somehow, although it may not be well organized.]

* Beta playtest [Game is basically finished; fine-tuning of play 
    balance and/or historical accuracy may be still needed.  There 
    is at least one "beginner" scenario and at least one "advanced"
    scenario available.  Doccumentation, including a "beginner's guide" 
    that goes with the beginner's scenario, is available.  A FAQ 
    has been started, although it may not have much depth yet. 
    There is some info about the AI.]

* Released [Game is "done".  FAQ is capable of answering most FAQs, 
    especially the stupid and obvious ones the designers never 
    realized anyone would need to ask.  Information on all units, 
    materials, etc. is readily available, including both in-game 
    numbers and what it/they represent in the real world (e.g. 
    100 42-gallon barrels of generic petroleum fuel, a platoon of 4 
    tanks, enough ammo for a battery to fire in support of "deliberate 
    defense" for 24 hours, a 12-being unit of centaurs, with light
    leather barding, broadswords, heavy bows, and iron horseshoes).
    Terrain restrictions are explained.  Procedures for manipulating
    (gathering/producing, collecting, transferring, expending) 
    materials are explained.  There is a list of map and game 
    settings that positively or negatively affect the game play 
    (e.g., fog of war, elevations, wind, etc.); and a list of ones
    that are not implemented.  There is a general description of 
    what increasing one side's advantage does for them, and some 
    suggestions for meaningful handicaps.  Any shortcomings of 
    the AI are set out (e.g., does not handle maps with >90% water, 
    is not good against more than one human player).  Any "cheats" 
    the AI gets are clearly stated.]

>* Unfinished subsystems.  Agreements, standing orders, morale, the
>list goes on.  They take up space, make the code more complicated,
>but don't do anybody any good.

  And are frustrating when you come up with an idea for a game and 
then later realize those bits don't actually work yet.  

>* Too far behind state of the art.  Gamers who know about Xconq admire
>it as an open-source game that is comparable to early 90s games, but
>then they go back to playing Starcraft.  Xconq doesn't have to match
>the latest extravaganza, but it needs to be close behind and stay
>there.  Note that that this doesn't necessarily mean graphics -
>Nethack is still very popular without fancy graphics.  (It's also much
>more complicated than Jay Fenlason's original 1984 version - gameplay
>has evolved considerably.)

  Agreed that it needs to not be too far behind, but I don't think
it is.  Turn-based strategy/builder games have not actually advanced 
that far since CivI; and some of the things that are "new" in SMAC (real 
elevations, pseudo-weather) are (at least nominally) in Xconq.  (Compare
the level of drastic change from CivI to SMAC, versus, say, Wolfenstein
3D to Quake.)

>* Genre confusion.  These days, strategy games fall into several
>subcategories - historical wargames (TOAW), complex simulations (Civ),
>real-time (*arcraft), and maybe strategic RPG (HOMM 3).  Xconq doesn't
>offer strong support for any of these genres, instead falling into a
>mushy middle of simple-ish turn-based games.

  Yes.  Xconq can do historical wargames reasonably well, to compete 
with Steel Panthers, Gettysburg, Horse & Musket, etc., but there 
are few well-developed games that take advantage of this.  Support
for Civ-like games has recently evolved, although it seems shaky
yet.  It doesn't do Warcraft, Command & Conquer, etc. well, but 
personally I don't care.  <soapbox> If you have to click and 
act in real time, it's a tactical game, not a strategy game; 
there are no real-time-strategy games on the market, everything
falsely described as RTS is actually RTT. </soapbox>  Strategic
RPG is possible, but weak; something like "Age of Wonders gone 
RPG" would probably work if someone put the work into it; 
how about something Darklands-like?  One of my favorite games, 
with little like it out these days.  

>* Uninteresting games.  As someone here commented a while back, too
>many of the games in the library are experiments or demos.  They're
>not very engaging - I myself go through the motions of testing them,
>but I don't find myself wanting to play them all the way to the end.

  See above re: labels.  I've gone through a bunch of the games at
one time or another, and it's not clear which ones are unfinished, 
which ones are merely poorly documented and difficult to use, and 
which ones are just bad; the end result (quitting to do something 
else) is similar, though.  

>One *non*-problem is the lack of publicity.  At one point I thought
>that was the problem, and spent some time advertising Xconq more.  And
>indeed, more people visited the website and downloaded the game.
>However, these seem to have been mostly one-time visits - there's been
>very little followup or feedback.  If you consider the mistakes just
>listed, it's easy to see how the avid gamer would look around Xconq a
>bit and then lose interest.  So given the existing problems, publicity
>is not an issue, and indeed may be a bad idea if people form a poor
>impression of Xconq.

  I think part of the problem is the somewhat arcane user interface, 
nearly-nonexistent user docs *for the games*, combined with the labeling 
and unfinished games issues; someone gets a copy, tries out a game, 
gets frustrated fighting the interface and with units that don't 
do what they expect, and just gives up and deletes it.  

>How to fix
...
>* Define the game/engine separation better.  Building different
>programs is probably going overboard, but for instance one could
>imagine that the new game choice sets the entire look-and-feel of the
>game, not just units and terrain.

  This doesn't bother me much, although it would be a neat idea 
(wood and scroll look for fantasy, Star Trekish panels for SF games, 
etc.)  Unless implemented with real differences (i.e., command lag, 
fog of war, etc. tied into interface), is "eye candy", pretty but
irrelevant.  

>* Use GDL more to enable and disable code modules that have been coded
>for specific games or classes of games.  This is starting to happen a
>little bit, because the idea of factoring everything in general ways
>was already breaking down.

  Not a code guru, but seems reasonable.  If a game doesn't need 
materials, weather, etc., it shouldn't have to handle the overhead.  

>* Do more graphics.  The only games for which players don't care much
>about graphics are the established old-time Unix games (Nethack) and
>some very specialized historical wargames.  In both of these cases the
>gameplay is very deep, with years of refinement having gone into the
>rules (the opposite of the thrown-together-over-the-weekend Xconq
>module!)  The current state of the art is 3D in various forms; that's
>not necessary, but something on the order of CivCTP or RRT2 would be
>good; isometric, 8- to 16-bit color, canned animations of rendered 3D
>models.  This is closer than it seems; there is already a prototype
>isometric display in Xconq for instance.

  I strongly disagree.  The work needed to produce 3D or pseudo-3D 
icons is considerable, and would be a strong barrier to game 
development.  Far too many current games made this mistake; 
people are grumbling about SMAC's and Civ:CTP's choices.  Support
for unit facing would be helpful for some games, but little pictures
of guys walking about the map is not what these games are about.  
Consider: this is *strategy*; the analog is to generals looking 
at a map; the U.S. military is spending considerable effort on 
reducing the complex, busy look of modern combat to easy-to-recognize, 
clear, information-carrying symbols.  A set of clear icons with useful
inherent info content is far more helpful than a bunch of muddy little
pictures that took weeks to render, time that could have gone into 
the AI, the economic or diplomatic models, etc.  

...
>* Add the capability to do real RTS games.  The machinery is 99%
>there, would be easy to finish the job.

  IMO, the world doesn't need another clickfest oriented pseudo-
strategy game based on the "tension" between a fast rush of a cheap 
unit versus building an unstoppable one; even if it did, Xconq 
is not the entity that should be serving that need.

>* Focus on a handful of game modules, and finish them.  One or two in
>each Xconq-supported genre should be enough.  Do the graphics, make
>the AI good, etc.

  Yes.  And document, document, document.  

>* Design a "featured game" that is unique to Xconq.  It should be
>complex enough and deep enough to interest the jaded Starcraft or Civ
>player, and stress the engine's abilities.  I was tinkering with a
>"new standard" game last summer that features modern military
>strategy, but that's still too timid.  I'm now thinking of a campaign
>series, perhaps where you start out directing battles, and progress
>through scenarios on successively larger scales, or perhaps an SF
>game where you go from planet to planet.  What kind of a strategy
>game would capture *your* imagination and keep you at the machine
>all night?

Some brainstormed ideas:

* Master of Magic done better, with user-definable units; eg, if 
you have some wolves, and some goblins, and some scimitars, you 
can train yourself up some goblin wolfriders.  Races, equipment, 
etc. would effectively all be materials; units would have abilities
based on the materials used to construct them.  User-definable 
spells would be even cooler; perhaps an approach like Champions / 
Hero System (the paper RPG), with power effects, special effects,
enhancements, and limitations.  (E.g, you decide to research a 
"Pilum of Ravening Flame" spell; you collect/build/assemble an 
Energy Strike power effect, a Flame special effect, an Armor-Piercing
enhancement, and a Short-Ranged limitation.  You can then have 
your cities start turning out wands with the spell, and then 
start giving them to your units.)  Some sort of "overland" magic
system would also be needed; this could have uses in other games
for things like off-board artillery (traditional, air, space) support, 
"special powers" given certain (or all) sides (Xconq Cosmic Encounters?), 
political effects (the "imperial favor" for Xconq Legends of the 
Five Rings, "papal condemnation gives -1 moral to side X"), 
and other things that affect the battle but are not present on the map.

* Children's strategy; a fairly untapped market.  *Not* just some
game dumbed down to uselessness, but a full-blown strategy game 
designed to appeal to younger fans who don't have a background 
in cardboard-counter or miniatures wargames.  (Hmm, horrible 
though; will the game support, say, 152 materials?  And can 
a result of combat be the changing of one sort of material to 
another?  Pokemon Empires could be doable... :)

* Something like Ogre/GEV, where you have the ability to spend 
points out of a unit mix to pick your forces, and one or more 
sides gets to pre-place them on the map.  (In fact, something
very much like Ogre/GEV would be a pretty good choice for Xconq.)

* A multi-scale game, where players could "zoom in" on critical 
battles and handle them on a new map.  Similar to the way 
combat works in MoM, MoO/MoO2, etc., but with more adjustability, 
and possibly multiple zoom levels.  For instance, you could be 
playing a WWII game as the Allies; at the top level, you move a 
stack of transports and escorts across the channel and into France.
You (or the German player/AI) choose to zoom into the crucial 
hex; the over-game pauses, and a new map representing Normandy 
comes up.  Here the pieces represent companies rather than divisions, 
individual capital ships rather than task forces.  You choose 
to zoom again onto Omaha beach, and the new map has appropriate 
terrain, and counters are now individual landing craft, tanks, 
and platoons.  Special terrain could be stored explicitly, but
most terrain would be generated semi-randomly (but repeatably, 
so with a seed somewhere) based on the "over" hex, and perhaps 
it's neighbors.  (E.g. a dense-woods hex surrounded by more of 
the same would generate most of the sub-hexes as dense woods; 
one bordered to the north by a mountain hex and the south by 
a plains hex would have a gradation of plains, light woods, 
dense woods, hills, and some mountains.)  A river through the 
hex would not only generate river in some appropriate sub-hexes, 
but perhaps some small tributaries, unless it was next to an 
ocean, in which case it might generate a delta.  This could
also be a good way of generating semi-random maps; design 
an over-map one level higher than you intend to use, with 
a few hexes of appropriate terrain, and let it expand into
the map you use.  Perhaps even a system where sides got 
to pick and place over-map hexes in the pregame (cavalry 
heavy armies might pick plains hexes, while a force mostly
composed of infantry skirmishers would place more woods 
hexes).  In a game that allowed unit bidding or purchasing, 
over-hexes could be part of that system as well.  


As for what I can do, I'm not a particularly good coder, especially
when it comes down to nitty-gritty hardware stuff.  
I'm reasonably good at game design, and play balancing/testing (I 
do a lot of playtesting for pen-and-paper RPGs like GURPS); I 
have some background in HCI (Human-Computer Interaction) 
and multimedia interface design.  

** James **
-- 
James R. Dunson (jdunson@vt.edu)
Network Administrator, Center for Wireless Telecommunications
436 Whittemore Hall, Virginia Tech     http://www.cwt.vt.edu/

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]