Miscellaneous Things

Miscellaneous Things

[Elijah Meeks]

hey guys, in the spirit of not wanting to post three
seperate topics, and thereby begin a number of
convoluted discussions under the same heading, I'd
like to ask and offer a couple things:

1)  I know there's a sort of terrain slide that's
allowed for units, can this be set to multiple hexes? 
I'd like to allow air units to fly over water hexes
but not to end their turn on them.

2)  Would it be useful to start an Xconq sourceforge
project?  Not for the program per se, which seems to
do fine here, but more for designers and players.  I
think the forums and the exposure would be worthwhile.
 We could set it to coincide with 7.5, perhaps.  Good
idea, bad idea? 


__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

Re: Miscellaneous Things

[Eric McDonald]

Hi Elijah, others,

On Wed, 3 Dec 2003, Elijah Meeks wrote:

> I'd like to allow air units to fly over water hexes
> but not to end their turn on them.

Slides only work for borders, AFAIK.

> 2)  Would it be useful to start an Xconq sourceforge
> project?

I thought there was one when I looked a few months ago, but now I 
don't see it. Maybe I was dreaming. But Stan is registered with 
Sourceforge (and I thought he was listed as the Xconq contact 
person when I thought I saw the project), so at least I wasn't 
dreaming that part.

>  Not for the program per se, which seems to
> do fine here, but more for designers and players.  I
> think the forums and the exposure would be worthwhile.
>  We could set it to coincide with 7.5, perhaps.  Good
> idea, bad idea? 

I personally think this may be a good idea. The reason I looked at 
SF was to see about expanding Xconq's presence....

Eric

Re: Miscellaneous Things

[Bruno Boettcher]

On Wed, Dec 03, 2003 at 02:24:35PM -0800, Elijah Meeks wrote:
> hey guys, in the spirit of not wanting to post three
> seperate topics, and thereby begin a number of
> convoluted discussions under the same heading, I'd
:D

> 2)  Would it be useful to start an Xconq sourceforge
> project?  Not for the program per se, which seems to
> do fine here, but more for designers and players.  I
> think the forums and the exposure would be worthwhile.
>  We could set it to coincide with 7.5, perhaps.  Good
> idea, bad idea? 
hmmm, i must say that i got really weary of SF and moved all the
projects i am in onto savannah.....
the rights SF claims over the code stored there got way too bizzarre and
dangerous to me, thus if xconq makes some move into some source foundry
i would greatly prefer the move to a real free one like savannah...

my 0.2 cent though ;)

-- 
ciao bboett
==============================================================
bboett@adlp.org
http://inforezo.u-strasbg.fr/~bboett
===============================================================

Re: Miscellaneous Things

[Eric McDonald]

Hi Bruno, others,

On Thu, 4 Dec 2003, Bruno Boettcher wrote:

> hmmm, i must say that i got really weary of SF and moved all the
> projects i am in onto savannah.....
> the rights SF claims over the code stored there got way too bizzarre and
> dangerous to me, thus if xconq makes some move into some source foundry
> i would greatly prefer the move to a real free one like savannah...

I wasn't thinking in terms of moving. I personally am fairly happy 
with the Redhat hosting (except that I still need to figure out 
why I don't have edit permissions on the gnatsweb database). But I 
see no reason why Xconq cannot have multiple points of presence, 
perhaps with different roles as Elijah suggested.

Savannah sounds fine. Except when was the last time Sourceforge or 
sources.redhat.com was compromised? :-)
  http://savannah.gnu.org/statement.html

Eric

Re: Miscellaneous Things

[Stan Shebs]

Elijah Meeks wrote:

>
>2)  Would it be useful to start an Xconq sourceforge
>project?  Not for the program per se, which seems to
>do fine here, but more for designers and players.  I
>think the forums and the exposure would be worthwhile.
> We could set it to coincide with 7.5, perhaps.  Good
>idea, bad idea? 
>
Sourceforge is not that reliable; we actually get better quality of
service by relying on Red Hat's generosity in hosting this.

The most important way to get visibility is to "release early and often".
7.5 doesn't have to be perfect, because only 5% of the audience will
take note of the announce anyway; but 10% will notice the 7.5.1
message, having been primed by the 7.5 release, and so forth. Since
there hasn't been a release in a long time, most people will assume
Xconq is a dead project and not even look to see what's up with it.

This is as good a place as any to talk about release philosophy; make
it doesn't crash instantly on any platform you plan to release for, and
that you can play a game through to the end, put up binary and source
tarballs, and post messages to freshmeat, Usenet, Linux game tome,
etc. and you're done. There's no special magic involved, and if some
people hit a bug, there's the excuse for 7.5.1... :-)

Stan

Release philosophy (was: Re: Miscellaneous Things)

[Lincoln Peters]

On Thu, 2003-12-04 at 18:04, Stan Shebs wrote:
> The most important way to get visibility is to "release early and often".
> 7.5 doesn't have to be perfect, because only 5% of the audience will
> take note of the announce anyway; but 10% will notice the 7.5.1
> message, having been primed by the 7.5 release, and so forth. Since
> there hasn't been a release in a long time, most people will assume
> Xconq is a dead project and not even look to see what's up with it.

How about if, as soon as all of the serious bugs such as instant crashes
are fixed, we put out a release candidate (7.5rc1)?  Then we can wait
for anyone to report additional bugs, and we fix them, put out a new
release candidate (7.5rc2), etc.?  Then when a release candidate has
been out for a while (maybe a week or two) with no new bug reports, we
release 7.5.

Many open-source projects, such as OpenOffice.org, work this way, and it
seems to work very nicely for them.  And if nothing else, it becomes
clear to anyone who's paying attention that Xconq is *not* a dead
project.

Of course, I don't think that anyone wants to put out anything, even a
release candidate, while there are still major bugs that need to be
fixed.


Lincoln Peters <sampln@sbcglobal.net>

Re: Release philosophy (was: Re: Miscellaneous Things)

[Eric McDonald]

Hi Lincoln, Stan,

On Thu, 4 Dec 2003, Lincoln Peters wrote:

> On Thu, 2003-12-04 at 18:04, Stan Shebs wrote:
> > The most important way to get visibility is to "release early and often".
> > 7.5 doesn't have to be perfect, because only 5% of the audience will
> > take note of the announce anyway; but 10% will notice the 7.5.1
> > message, having been primed by the 7.5 release, and so forth. Since
> > there hasn't been a release in a long time, most people will assume
> > Xconq is a dead project and not even look to see what's up with it.
> 
> How about if, as soon as all of the serious bugs such as instant crashes
> are fixed, we put out a release candidate (7.5rc1)?  Then we can wait
> for anyone to report additional bugs, and we fix them, put out a new
> release candidate (7.5rc2), etc.?  Then when a release candidate has
> been out for a while (maybe a week or two) with no new bug reports, we
> release 7.5.

I feel the same can be accomplished by packaging known good CVS 
snapshots. Perhaps the only thing missing from the picture is to 
announce the availability of the these snapshots.

I personally think we should release 7.5 when it's ready. Maybe 
the documentation doesn't need to be brought entirely up to date 
before a release. But I don't think there should be any 
regressions from 7.4.1 as far as "make check" is concerned. And we 
are still getting closer to having much more intelligent transport 
behavior; I would want to wait until that improvement is in and 
working properl; it would be a boost to AI play, IMO.

> seems to work very nicely for them.  And if nothing else, it becomes
> clear to anyone who's paying attention that Xconq is *not* a dead
> project.

Perhaps it would not appear dead anymore, but it could earn a 
reputation as being quite buggy and needing lots of work.

Eric

Re: Miscellaneous Things

[Hans Ronne]

>This is as good a place as any to talk about release philosophy; make
>it doesn't crash instantly on any platform you plan to release for, and
>that you can play a game through to the end

I would add no synch errors in the network game (which is what we have been
wrestling with the last two weeks). Of course, if we had implemented a
feature freeze and not added Peter's new path-finding code we wouldn't have
had synch errors in the first place. But after testing the new code, I
thought it was too good to pass up in 7.5. It makes a huge difference both
for AI and manual play.

The fix I checked in yesterday stops the synch errors but it is a hack that
has other bad consequences. I would rather wait for a real fix from Peter,
who wrote the code.

Hans

Re: Release philosophy (was: Re: Miscellaneous Things)

[Hans Ronne]

>> How about if, as soon as all of the serious bugs such as instant crashes
>> are fixed, we put out a release candidate (7.5rc1)?  Then we can wait
>> for anyone to report additional bugs, and we fix them, put out a new
>> release candidate (7.5rc2), etc.?  Then when a release candidate has
>> been out for a while (maybe a week or two) with no new bug reports, we
>> release 7.5.
>
>I feel the same can be accomplished by packaging known good CVS
>snapshots. Perhaps the only thing missing from the picture is to
>announce the availability of the these snapshots.
>
>I personally think we should release 7.5 when it's ready. Maybe
>the documentation doesn't need to be brought entirely up to date
>before a release. But I don't think there should be any
>regressions from 7.4.1 as far as "make check" is concerned. And we
>are still getting closer to having much more intelligent transport
>behavior; I would want to wait until that improvement is in and
>working properl; it would be a boost to AI play, IMO.
>
>> seems to work very nicely for them.  And if nothing else, it becomes
>> clear to anyone who's paying attention that Xconq is *not* a dead
>> project.
>
>Perhaps it would not appear dead anymore, but it could earn a
>reputation as being quite buggy and needing lots of work.

I agree with Eric. Let's not rush things when we are almost done. Lincoln
has a good point, however, in that more snapshots/release candidates are
needed in the final phase before a release. I think Eric's Windows
Installers and rpm packages can do this job, but they could perhaps be more
frequent.

As for the Mac, I had already prepared complete packages two weeks ago, but
when the synch error hit us I postponed their release for precisely the
reason stated by Eric: that it could earn Xconq a reputation as being buggy
and unfinished. With the synch error now being fixed, even though it is
only a temporary hack, I will give this another try.

Hans

Re: Release philosophy (was: Re: Miscellaneous Things)

[Eric McDonald]

Hi Hans et al.,

On Sat, 6 Dec 2003, Hans Ronne wrote:

> has a good point, however, in that more snapshots/release candidates are
> needed in the final phase before a release. I think Eric's Windows
> Installers and rpm packages can do this job, but they could perhaps be more
> frequent.

I agree about the frequency. I have been waffling back and forth 
about whether to wait for the rest of the path-related changes, 
but since that might be awhile, I am hoping to release tonight or 
else tomorrow. Since the last release, we have at least two major 
improvements: your fixes of the module loading code and a new 
version of the pathing code (with desync fix :-). I am hoping to 
get Unix and Windows file naming over to the new nomenclature 
which we agreed upon. I have this mostly done; just need to test 
and to figure out how I want to handle old prefs files. Also, I 
guess we have a bunch of new game modules that people might want 
to play (thanks Lincoln and Elijah)....

I probably should have released after you took care of that module 
loading stuff....

Wrt to RPM's: I think I am going to split xconq.spec into 
xconq.spec and xconq_cvs.spec (or xconq-cvs.spec, whatever the 
generally accepted RPM naming convention is as far as CVS 
snapshots are concerned; I have not researched this yet). The 
xconq_cvs RPM's would be versioned by date, and the release RPM's 
would be versioned by, __well, by version.

Also, I think I am going to release just a plain tarball and/or 
zip file of the Xconq files minus any binaries. This may be useful 
to some people. Probably means that I should take a look at the 
'dist' target in the top-level makefile....

  So much to do, so little time,
  Regards,
    Eric

Scalable Players on Set Games

[Elijah Meeks]

Would it be possible to have a setting for gameplay
that collapse control of certain units onto less
players than are available for a game?  I ask this
because I'm going to write 2, 3 and 4 player versions
of Korea 2006 (It's got 5 playable sides), which, for
example in the 2-player, simply involves throwing all
the units in China/N. Korea into ChiKo and US/South
Korea/Japan under a USSoJa player.  Now, if I want
differentiation, I need to subdivide units into "South
Korean Army" and "US Carrier Group", which isn't so
much of a problem (I love making more units, one day
I'm going to run into the new unit limit, it's like
32,000, isn't it?) but I wonder how easy it would be
to implement a "Dynamic-Sides" option, that would base
the control of units on the number of players
attaching to a game.  I ask this because it's easier
to get one friend to play a game than four, and maybe
this would make certain multiplayer games more fun for
smaller groups.


__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

Re: Scalable Players on Set Games

[Hans Ronne]

>Would it be possible to have a setting for gameplay
>that collapse control of certain units onto less
>players than are available for a game?  I ask this
>because I'm going to write 2, 3 and 4 player versions
>of Korea 2006 (It's got 5 playable sides), which, for
>example in the 2-player, simply involves throwing all
>the units in China/N. Korea into ChiKo and US/South
>Korea/Japan under a USSoJa player.  Now, if I want
>differentiation, I need to subdivide units into "South
>Korean Army" and "US Carrier Group", which isn't so
>much of a problem (I love making more units, one day
>I'm going to run into the new unit limit, it's like
>32,000, isn't it?) but I wonder how easy it would be
>to implement a "Dynamic-Sides" option, that would base
>the control of units on the number of players
>attaching to a game.  I ask this because it's easier
>to get one friend to play a game than four, and maybe
>this would make certain multiplayer games more fun for
>smaller groups.

It could be done, but not easily. For one thing, it would require a lot of
new interface code (extra buttons in the player setup dialog etc).

What you can do already now is to change the number of human players in an
ongoing game, and have the AI run whatever sides are left. So you can start
a game with 5 players, save it, and resume it with only two players. See my
two posts on how to save network games:

http://sources.redhat.com/ml/xconq7/2003/msg00930.html
http://sources.redhat.com/ml/xconq7/2003/msg00931.html

Hans

P.S. I am almost done with a major revision of the save game and module
loading code. It will soon be much easier to save and restore network
games. No email will be needed any longer.

Re: Scalable Players on Set Games

[Eric McDonald]

Hi Elijah, Hans, others,

On Tue, 9 Dec 2003, Hans Ronne wrote:

> >to implement a "Dynamic-Sides" option, that would base
> >the control of units on the number of players
> >attaching to a game.  I ask this because it's easier
> >to get one friend to play a game than four, and maybe
> >this would make certain multiplayer games more fun for
> >smaller groups.

Another possibility would be to come up with different variants 
that set different side libraries and different side classes for 
the units depending on the number of players you have.

So in the case of China and N. Korea, you could make sure that all 
units belonging to China and N. Korea have the same side class, 
and then define a corresponding side. And you could call the 
variant that does this something like "2 Players", perhaps? So on 
and so forth....

Since variant options are evaluated before sides during game 
setup, I think this should work, but I have not tested it.

Eric