Re: What to do with Xconq

[Stan Shebs <shebs at shebs dot cnchost dot com>]

Hans Ronne wrote:

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

Yeah.  The theory of including both is that one might want a randomly
generated game using only the base module, but there are also scenarios;
but thinking about it, the player mentally chooses the game rules first
and *then* a scenario.  In other words, the New Game list should consist
of only base modules, the player chooses one, then gets a list of scenarios
plus "random game".

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

Perhaps two flavors of list?  The "suitable for all ages" list and the
"hardcore only" list...

> [...] 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? 

Depends on the distributor - their CDs are now running out of room to
hold just the basic utilities, games are often the first casualties.
A game would have to be popular already for a distributor to want to
take up what is now precious CD space.

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

That's why they say "release early and often".  But this is counter to the
idea that the library games should be completed... :-(

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

I'm still not convinced about this one - in some cases I still don't have
any idea what effect the options would have!  Seems more like an advanced
user/experimenter option.

> [...] In short, I think the Xconq hex grid is better than
> any other competing solutions, including Civ1 and Civ2.

OK.

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

I think we're pretty much in agreement here - what you've done in the Mac
interface anticipates what I'd like to do in general, but (at least by
default) simplified even further, so there's not much window manipulation
to do.

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

It's worth working on, but I'm not convinced it's the most important - the
network code has been in there for three years, and the improved network
game setup has been in for some months now, but I've had almost no feedback
from anybody who's tried it, and when I solicited people for test games a
while back, I got zero responses.  Networking is the one thing that I can't
completely test and debug by myself, and yet nobody else seems much interested
in it...

Stan