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


>* Confusion between game and game engine.  Xconq the program is really
>an engine for strategy games.  Game modules are the games.  Valve
>doesn't call their effort "the Half-Life module for Quake" - it's a
>game in its own right.  By being forced into the framework of a single
>generic program, the games lose some of their identity and interest,
>while the C/tcl-level programming gets harder and harder, to the point
>that interested programmers can't figure out how to work on it.

I don't think the many game modules is a problem. It is instead one of the
best features of Xconq.  One thing which is confusing, however, is the
distinction between base modules (Ancient Greece) and game modules
(Peloponnesian War), both of which appear in the New Game list. Perhaps one
could simplify things a bit here.

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

Getting rid of unplayable prototypes is of course a good idea, at least in
the final distributions. However, I think it is just as important to update
the New Games list with games that are playable, if not finished. I think
many casual players do not even realize that there are many interesting
things in the lib folder which do not show up in the New Games list.

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

This was a problem before, but your recent work with the terrain and unit
images have improved things a lot. I don't think Xconq needs more fance
graphics than this. It will make a big difference, however, when all units
have nice color images, which is not yet the case.

>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'm not sure. Lack of publicity (or availability or whatever) could still
be the problem. When you install LinuxPPC, a number of completely
uninteresting "x" games are included, but not Xconq. Couldn't one convince
distributors like RedHat to include it? As for the Mac community, one could
do like the shareware authors do, i.e. submit a new version to info-mac
every few months if not weeks. This raises interest and makes people aware
of the fact that the game exists and is under active development. Most
info-mac users just check out This Week's Additions on a regular basis, and
do not dig around in the archive for old stuff.

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

I agree. As you know, this is what I did at first for some of my new code.
However, I think a better and more flexible solution is to make all code
playable in all games, and then let the player decide what code to run in
each game. This is what I tried to achieve with the new setup dialog stuff.
The point is that it takes a lot of testing to figure out which old games
will work well with a piece of new code, something which the user community
is in a better position to do.

This does of course make things more complicated during startup, but I
think that is OK. Civ2 has a lot of startup options, too, but it does not
make the game more difficult to play once you are done with the dialogs.

>* 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 disagree. See James Dunson's comments on this, which I think are to the
point ("little pictures of guys walking about the map is not what these
games are about"). As for the isometric view in Civ2, I always hated it and
wished I could turn it off. Overhead views are much easier to work with, as
Ari Rabkin pointed out. In short, I think the Xconq hex grid is better than
any other competing solutions, including Civ1 and Civ2.

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

Not sure what you mean here. Multiple map windows is a nice feature in the
Mac interface that I never use. The reason is that with enough memory
(which most computers have these days) you can just increase the offscreen
buffers until the map covers the whole world. It is then possible to jump
anywhere in an instant by clicking in the world map, which makes multiple
maps redundant.

The optimal layout in my opinion is therefore a large map that covers the
entire sceeen, with the rest of the world included offscreen. Other windows
should appear only when you need them, or float on the map (in which case
they should be as small as possible in order not to obscure the map). They
should also be movable. This is what I tried to achieve with the new
floating window code in the mac interface.

A problem in the paned X11 and Tcltk versions, as I see it,  is the wasted
space, which makes the map much too small for my liking, even on a big
screen. I therefore think it would be a major improvement if you could turn
off all panes except the map when you don't want them. Alternatively, some
of them should float on top of the map, if this is possible.

Yet another possible solution would be to be able to toggle between two
screens, one which contains only the map (and perhaps the world map in a
corner), and one which contains all the other panes and stuff.

On a related note, I have been thinking about implementing a dock for the
floating windows similar to the one found at the bottom of the main window
in Netscape. I think this could be a practical way of keeping track of all
the windows, which is the biggest problem with the mac solution.

>What does everybody think?

I think the most important thing, as Bob Carragher and Martin Burke already
pointed out, is to get the network game to work, and on all platforms. That
would really boost interest in Xconq.

Hans

Hans Ronne

hronne@pp.sbbs.se



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