What to do with Xconq

[James McCann]

By way of background, I am a (former) board wargamer and computer
programmer.  While xconq is tantalizing and seems to have wonderful
possibilities, I have not been able to "get into" the game the way
I have quake 2 (most recently), warcraft & warcraft 2, and many others
going back through the years.  

> 
> * 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 a problem.  I think that finished fully documented games should
be easy to find, and the multitude of unfinished, unplayable and 
otherwise useless stuff should be put somewhere else and labelled.

> 
> * 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.)
> 

I think this is important.  Even though there are many on this list who
don't find graphics to be very important, for wide acceptance these
must be of  a consistently high quality.

> 
> * 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 my comments above.

> 
> 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 is a good idea, you could use the idea of skins and have reusable
unit libraries & whatnot, and you could require new scenarios either 
provide high quality graphics or use an existing set.

> 
> * 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 think it would be good to have an isometric view, someone pointed out
and I agree that an overhead view is easier, and it is more informative,
but I think that "eye candy" is important.  This could be a display 
option.

> * Adopt more standard game graphics conventions.  While there are
> arguments for using multiple OS-specific windows, it goes against both
> principle and tradition.  The principle is that the suspension of
> disbelief doesn't happen if cookie-cutter dialogs and window panes are
> always popping up, and the existence of the tradition should be
> obvious to anyone that has played computer games for a few years.  In
> practice, this means that the tcl/tk interface hasn't been such a good
> idea, although it's handy for game design.  My current front runner
> idea is to use SDL to run the main window(s), and add some GDL
> mechanism to specify the graphics sets to use.
> 

I hate tcl/tk (actually I love being able to throw an interface together
w/ a handful of commands but tcl is the most horrid language ever 
written.  Ugh) and I think you should use a straight SDL and develop 
a native GUI which would be the same across all platforms.  I think
that is what is expected in games these days.

> * Merge interface code.  The multiple-interface design is good, but
> the work of maintaining multiple GUIs is very time-consuming, and they
> end up with different sets of features.  An SDL + tcl/tk combo would
> work on all platforms of interest, and perform better as well.
> 
> * Add the capability to do real RTS games.  The machinery is 99%
> there, would be easy to finish the job.
> 

Not sure I agree w/ this, but if it doesn't detract from other efforts
why not. 

> * 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!

> * 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?
> 
How about a 2 scale campaign game where all battles are fought at 
a tactical level and strategic movement, resupply etc. take place
at a much higher level.   I have always thought that the coolest
computer wargame would be multi-scale and would have lots of people,
each w/ distinct roles.  Like SPI's monster game "Campaign in North
Africa" w/ (iirc) 3 people per side, 9 hex maps and tons of paperwork.
We never did play the game, we just kind of boggled at the complexity
of the whole thing.  W/ a computer to take care of the tedium of
bookkeeping it would be much more enjoyable.  Perhaps xconq "clans"
would pop up and battle out WWII.  


James McCann