Re: CXP???

Re: CXP???

[Eric McDonald]

Elijah Meeks wrote:
> I have yet to see a unit gain experience from a
> fire-action, except in cases where the unit it's
> firing on is adjacent.

It would seem that someone was a bit sloppy with the code, and 
"recycled" the 'chance' variable for determining retreat chance, after 
using it for hit chance. So, if the defender's retreat chance is 0% (the 
default), then no combat experience is gained. This is a bug by any 
other name. I will fix it in my sources. Until you have a new Xconq 
release to play with, I would recommend that you set the 
'retreat-chance' to 1% for all units (unless you wish them have a higher 
retreat chance for other reasons); this weird hack should allow for 
combat experience to be gained.

> I think, barring seperate tables for cxp-per-attack,
> cxp-per-hit, cxp-per-defend, cxp-per-capture and
> cxp-per destruction, I say keep it all as cxp for each
> attack and keep it two-way.  You should get experience
> for surviving certain attacks but, of course, it would
> seem more realistic if you were able to tailor them.

This is what I was getting at. However, I plan on leaving things the way 
they are for the time being.

Eric

Re: CXP???

[Elijah Meeks]

> It would seem that someone was a bit sloppy with the
> code, and 
> "recycled" the 'chance' variable for determining
> retreat chance, after 
> using it for hit chance. So, if the defender's
> retreat chance is 0% (the 
> default), then no combat experience is gained. This
> is a bug by any 
> other name. I will fix it in my sources. Until you
> have a new Xconq 
> release to play with, I would recommend that you set
> the 
> 'retreat-chance' to 1% for all units (unless you
> wish them have a higher 
> retreat chance for other reasons); this weird hack
> should allow for 
> combat experience to be gained.

Ah ha.  Thanks for catching that, Eric.


		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 

Multiple Image Use

[Elijah Meeks]

I've been trying to use Hans' new feature (multiple
images for the same unit) but it doesn't seem to show
up.  At first I thought this was because I was only
looking at start-with units and that it didn't support
those units, but it doesn't seem to come into play
with created units either.  I've set up units as
(image-name "image1" "image2" "image-etc") and it only
uses image1.

Have I missed something?


		
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush

Re: Multiple Image Use

[Eric McDonald]

Elijah Meeks wrote:

> I've been trying to use Hans' new feature (multiple
> images for the same unit) but it doesn't seem to show
> up.  At first I thought this was because I was only
> looking at start-with units and that it didn't support
> those units, but it doesn't seem to come into play
> with created units either.  I've set up units as
> (image-name "image1" "image2" "image-etc") and it only
> uses image1.

Did you try:
   (image-name ("image1" "image2" "image-etc"))
?
The code looks like it might be more amenable to that.

Eric

Re: Multiple Image Use

[Elijah Meeks]

> Did you try:
>    (image-name ("image1" "image2" "image-etc"))
> ?
> The code looks like it might be more amenable to
> that.

That did it, thanks.


		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 

Standard Game Graphics

[Elijah Meeks]

Would anyone object if I changed all the unit graphics
for the standard game from the pikemen to those found
on the Trident set?



		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

Re: Standard Game Graphics

[Jim Kingdon]

> Would anyone object if I changed all the unit graphics
> for the standard game from the pikemen to those found
> on the Trident set?

I think so.  The Trident ones don't look like they'd work at low
magnification.  If you post a diff, then I can actually try it in
xconq, rather than just look at images/trident.gif and try to guess
what it would look like in a game.

I also don't see units there for all the unit types found in the
standard game, and of course it wouldn't look good at all to mix and
match.

I will note that this could be made a variant (see the existing
silhouettes variant for an example).

Re: Standard Game Graphics

[Eric McDonald]

On Wed, 1 Sep 2004, Jim Kingdon wrote:

> I think so.  

I would tend to side with Elijah on this one.

>The Trident ones don't look like they'd work at low
> magnification. 

This can be addressed by creating a custom image family using 
'imf' directives.

> I also don't see units there for all the unit types found in the
> standard game, and of course it wouldn't look good at all to mix and
> match.

One reason why the Trident images look like they might not fit in 
is because they are 44x44, whereas the standard Standard images 
are 32x32, IIRC. If one just takes the Trident marine or mountain 
troop and rescales it to 32x32, I bet it would fit in quite 
nicely.

As far as the other images (in Standard) go, I am not certain that 
they absolutely need to be replaced.

Eric

Re: Standard Game Graphics

[Elijah Meeks]

I'll put together a demo, so we can see how it looks. 
I think there are enough graphics in the trident set
to represent everything, we'll see. 


Also, there are certain graphics in Opal that seem to
come out strange, these tend to be the graphics held
in the korea.gif but referenced in opal-rules.g.  This
problem's cropped up before, it's as if XConq has
loaded the old korea.gif and refuses to acknowledge
the new one, any ideas?


		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

Re: Standard Game Graphics

[Eric McDonald]

Elijah Meeks wrote:
> I'll put together a demo, so we can see how it looks. 
> I think there are enough graphics in the trident set
> to represent everything, we'll see. 

I wasn't sure about the cities....

> Also, there are certain graphics in Opal that seem to
> come out strange, these tend to be the graphics held
> in the korea.gif but referenced in opal-rules.g.  This
> problem's cropped up before, it's as if XConq has
> loaded the old korea.gif and refuses to acknowledge
> the new one, any ideas?

No clue. Are you restarting Xconq between modifications that you make to 
'korea.gif'?

Eric

Re: Standard Game Graphics

[Jim Kingdon]

> I'll put together a demo, so we can see how it looks. 

Great.  That's clearly the next step.

Re: Standard Game Graphics

[Elijah Meeks]

[-- Attachment #1: Type: text/plain, Size: 870 bytes --]

Okay, so here's the updated standard.g, which includes
a new 'Trident' option, so you can see the graphics in
action.  I found a freeciv pack with cities, which I
added to korea.gif, and I think they'll serve as good
replacements for bases, towns and cities.  I think,
but I don't know, because even with the proper imf
references, all I see are the generic gray chips (The
old graphics from korea.gif, in whose place I added
the new neotrident images).  So, I created a new gif,
neo-trident.gif, that has these three images, and
referenced that instead of korea.gif and it worked
just fine.

You'll need neo-trident.gif, which I'm going to send
to Jim and Eric and anyone else who wants it.  I think
the game looks better.




		
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush

[-- Attachment #2: standard.g --]
[-- Type: application/octet-stream, Size: 8352 bytes --]

(game-module "standard"
  (title "Standard Game")
  (version "7.3+")
  (blurb "The standard Xconq game, loosely based on WW II ca 1945.")
  (instructions "Take over the world before you get taken over!")
  (variants
    (world-seen false)
    (see-all false)
    (world-size (60 30 360))
    (sequential false)
    ("Mostly Land" mostly-land
      "Generate a world that is mostly (80%) land."
      (true
        ;; Adjust so that sea is 20% instead of 70% of the world.
        (add sea alt-percentile-max 20)
        (add shallows alt-percentile-min 20)
        (add shallows alt-percentile-max 21)
        (add swamp alt-percentile-min 21)
        (add swamp alt-percentile-max 23)
        (add (desert plains forest) alt-percentile-min 21)
        ))
    ("All Land" all-land
      "Generate a world that is all different types of land."
      (true
        ;; Adjust sea and shallows out of existence, let swamp take all the low spots.
        (add sea alt-percentile-min 0)
        (add sea alt-percentile-max 0)
        (add shallows alt-percentile-min 0)
        (add shallows alt-percentile-max 0)
        (add swamp alt-percentile-min 0)
        (add swamp alt-percentile-max 2)
        (add swamp wet-percentile-min 0)
        (add swamp wet-percentile-max 100)
        (add (desert plains forest) alt-percentile-min 2)
        ;; Counterproductive to try to set up near water.
		(add sea country-terrain-min 0)
        ))
    ("Ice-Age" ice-age
      "Generate a world that has normal amounts of water but almost all land is ice."
      (true
        (add swamp alt-percentile-min 69)
        (add swamp alt-percentile-max 70)
        (add (desert plains forest) alt-percentile-max 74)
        (add mountains alt-percentile-min 74)
        (add mountains alt-percentile-max 78)
        (add ice alt-percentile-min 78)
        (add ice alt-percentile-max 100)
	(set edge-terrain swamp)

        ;; Try to make it so there is room for countries.  It still is harder
	;; to meet the constraints in a many-player game than the non-iceage
	;; variant, but there may be only so much we can/should do.
        (set country-radius-min 1)
        (add (sea plains) country-terrain-min (1 3))
        (table favored-terrain add (@ plains 20))
        ;; To get a somewhat similar number of towns per land, need more
        ;; towns per plains/desert/forest/mountains.
	(table independent-density
	  (town plains 3000)
	  (town (desert forest mountains) 500))
	;; In keeping with the ice-age theme change desert to tundra
	;; (with no change in properties).
	(imf "civ-tundra" ((1 1) 214 255 231))
	(imf "civ-tundra" ((44 48) (x 2 46 0) (file "civt44x48.gif" 186 152)))
	(add desert image-name "civ-tundra")
	(add desert help "Desert (tundra) is fairly flat but less hospitable than plains")

	;; Now pick arctic country names.
	(set side-library '(
	  (50 (noun "Norwegian") (emblem-name "flag-norway")
	    (unit-namers ((town city) norwegian-place-names)))
	  (50 (noun "Swede") (adjective "Swedish") (emblem-name "flag-sweden")
	    (unit-namers ((town city) swedish-place-names)))
	  (50 (noun "Finn") (adjective "Finnish") (emblem-name "flag-finland")
	    (unit-namers ((town city) finnish-place-names)))
	  (50 (noun "Icelander") (adjective "Icelandic") (emblem-name "flag-iceland")
	    (unit-namers ((town city) icelandic-place-names)))
	  (50 (noun "Canadian") (emblem-name "flag-canada")
	    (unit-namers ((town city) canadian-place-names)))
	  (50 (noun "Russian") (emblem-name "flag-russia")
	    (unit-namers ((town city) russian-place-names)))
	  (50 (noun "Mongol") (adjective "Mongolian")
	    (emblem-name "flag-mongolia")
	    (unit-namers ((town city) mongolian-place-names)))
	  (50 (noun "Nepalese") (emblem-name "flag-nepal")
	    (unit-namers ((town city) nepalese-place-names)))
	  (50 (noun "Afghan") (emblem-name "flag-afghanistan")
	    (unit-namers ((town city) afghan-place-names)))
	  (50 (noun "Chilean") (emblem-name "flag-chile")
	    (unit-namers ((town city) chilean-place-names)))

	  ;; Not sure this image really works for a flag.
	  ;; (50 (noun "Viking") (emblem-name "heroes-viking") ...)
	  ;; (imf "heroes-viking" ((44 44) (file "heroes.gif" 140 354)))
	  ;; Also would like: Tibet, Inuits, Aleutians
	  ))
        ))
    ("Large Countries" large
     "Grow each starting country to take as much land as possible."
     (true
       ;; This is the same as country separation.
       (set country-radius-max 48)
       (add (town city) unit-growth-chance (100 20))
       (add (town city) independent-growth-chance (20 0))
       ))
    ("Noisy" noisy
     (true
       (set action-movies '(
         (move (sound "pop"))
         ))

       (set event-movies '(
         (side-lost (sound "thunder"))
         (unit-captured (sound "chirr"))
         (unit-completed (sound "chirr"))
         (unit-moved (sound "pop-2"))
         ))
       ))
    ("Silhouettes" silhouettes
     "Use silhouettes for unit display instead of color images."
     (true
       ;; No capability for alternate image sets, so do it the hard way.
       (add infantry image-name "soldiers-s")
       (add armor image-name "tank-s")
       (add fighter image-name "fighter-s")
       (add bomber image-name "4e-s")
       (add destroyer image-name "dd-s")
       (add submarine image-name "sub-s")
       (add troop-transport image-name "ap-s")
       (add carrier image-name "cv-s")
       (add battleship image-name "bb-s")
       (add nuclear-bomb image-name "bomb-s")
       (add base image-name "airbase-s")
       (add town image-name "town20-s")
       (add city image-name "city20-s")
       ))

    ("Trident" trident
     "Use freeciv graphics." 
     (true
       ;; No capability for alternate image sets, so do it the hard way.
       (add infantry image-name "trident-riflemen")
       (add armor image-name "trident-armor")
       (add fighter image-name "trident-fighter")
       (add bomber image-name "trident-bomber")
       (add destroyer image-name "trident-destroyer")
       (add submarine image-name "trident-submarine")
       (add troop-transport image-name "trident-transport")
       (add carrier image-name "trident-carrier")
       (add battleship image-name "trident-battleship")
       (add nuclear-bomb image-name "trident-nuclear-missile")
       (add base image-name "nt-city-white-small")
       (add town image-name "nt-town-gray-medium")
       (add city image-name "nt-city-gray-large")

	 (imf "nt-city-gray-large"  ((32 32) (file "neo-trident.gif" std 0 0)))
	 (imf "nt-town-gray-medium"  ((32 32) (file "neo-trident.gif" std 0 1)))
	 (imf "nt-city-white-small"  ((32 32) (file "neo-trident.gif" std 0 2)))

       ))

    )
  )

(include "stdunit")

(include "nat-names")

(include "town-names")

(include "ng-features")

(add B namer "junky")

(add (T @) namer "random-town-names")

(set default-namer "random-town-names")

(set feature-types '(continents islands seas lakes bays
			    (desert 10)(forest 10)(mountains 5) peaks))

(set feature-namers
  '((islands generic-island-names) (lakes generic-lake-names) (bays generic-bay-names)
  	(seas generic-sea-names) (continents generic-continent-names)
  	(desert generic-desert-names) (forest generic-forest-names)
  	(mountains generic-mountain-names)))

(set advantage-min 1)
(set advantage-default 1)
(set advantage-max 15)

(scorekeeper
  (title "")
  (do last-side-wins)
  )

(set scorefile-name "standard.xcq")

;; Leave see-terrain-if-captured to zero.  This is so that exploration
;; does not cease early in the game.  Alternatives might be to 
;; make all hexes within a fixed or randomly determined radius
;; from the captured unit visible, or even a make-terrain like
;; algorithm that generates one single random sized area of visible hexes
;; that nucleates at the captured unit.  Some terrain info will leak
;; out via see-others-if-captured - that's a more appropriate quantity
;; than the all-or-nothing see-terrain-if-captured.

(table see-others-if-captured
  (ship ship 50)
  (base u* 10)
  (town u* 15)
  (city u* 100)
  )

(add places already-seen 100)
(add places already-seen-independent 100)

Re: Standard Game Graphics

[Eric McDonald]

Elijah Meeks wrote:

> You'll need neo-trident.gif, which I'm going to send
> to Jim and Eric and anyone else who wants it.  I think
> the game looks better.

Looks good. Personally, I would prefer if your 'Trident' variant was 
made into the default, and the old graphics were made into some sort of 
oldtimers variant. I mean, I think a major point of this exercise was to 
help Xconq present a more polished image to new players, and your new 
graphics do that much better than the old ones. But, that's just my 
opinion; I guess we'll have to see what others say. (I suppose some 
people have been looking at the old graphics for so long that anything 
new will seem alien and objectionable....)

Eric

Re: Standard Game Graphics

[Elijah Meeks]

> Looks good. Personally, I would prefer if your
> 'Trident' variant was 
> made into the default, and the old graphics were
> made into some sort of 
> oldtimers variant. I mean, I think a major point of
> this exercise was to 
> help Xconq present a more polished image to new
> players, and your new 
> graphics do that much better than the old ones. But,
> that's just my 
> opinion; I guess we'll have to see what others say.
> (I suppose some 
> people have been looking at the old graphics for so
> long that anything 
> new will seem alien and objectionable....)

I agree that it should be the default, but I also
agree that it should be a group decision.  The one
problem, which I believe Jim pointed out and proved
true, is that it doesn't look so good at the 16
unit/hex resolution.  You can tell the difference
between units because there are pretty good primary
color distinctions (Infantry brown, armor green,
fighter gray) but it's pretty ugly.

The two solutions I see are:

1.  Make specific imf 4 4 definitions that reference
the old silhouettes, because they're more recognizable
at that resolution. 

2.  Set unit limits per hex at four, which is the max
amount of Trident units in a hex that are still
recognizable and look decent.  I like this both from
the graphical viewpoint and the gameplay viewpoint,
simply because I think more than four units in a hex
is unweildy.  You still have problems with cities and
transports, but that'll be solved next week, when
Eric's Occupant Dialog Box Fix is out...  Right,
Eric?*

I think it's obvious that I prefer solution 2.  And I
still think we need a forum.  And a better webpage
(Christ, I've been here for two years and I still have
a hard time finding the right link for downloads or
mailing lists or manuals and everytime I see the XConq
website, I think, "1992?").  And neural nets.  And
fully 3D units.  And salaries for game designers.  And
groupies.  And an XConq Company Cruise.  And and
and...






		
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush

Re: Standard Game Graphics

[Jim Kingdon]

> I suppose some people have been looking at the old graphics for so
> long that anything new will seem alien and objectionable....

Well, sure, and I'm trying to separate the familiarity effect from the
real pros and cons.

* The bomber and fighter look fairly similar to each other, especially
  when they are incomplete units (there is no color difference in this
  case).

* The infantry doesn't show up all that well against the forest
  terrain.

As for not being easy to distinguish when they are small, yes, that
seems true.

For my own play, as long as it is a variant I'm sure I can figure out
which one I like and pick it.  But for people who don't play as much
xconq, or are trying it anew, the decision we make is more important.
On the one hand, I'm tempted to say try the trident images at least
for a while, and see how they stand the test of time.  That way at
least it doesn't seem as if xconq is permanently and unalterably
ossified.  But my other impulse is to make the trident images a
variant for a while and see if they get a following (that way, perhaps
avoiding a mistake which might make xconq look bad, and giving a
chance to notice/solve problems).

> 1.  Make specific imf 4 4 definitions that reference
> the old silhouettes

But then the shape would vary at different sizes.  I think you'd want
to concoct new 4x4's which are silhouette-like, but whose shapes are
more similar to the larger versions.

> 2.  Set unit limits per hex at four

Doesn't seem like a small change (either from the gameplay point of
view, or the occupant point of view, or whatever).  It might be a good
idea - it just seems like it would take a while to get this right.

In an unrelated matter, the help screens don't seem to list the fact
that only cities (not towns) can develop nukes in the standard game.
This would be acp-to-develop and tech-to-develop.

Re: Standard Game Graphics

[Jim Kingdon]

> And a better webpage (Christ, I've been here for two years and I still
> have a hard time finding the right link for downloads or mailing lists
> or manuals and everytime I see the XConq website, I think, "1992?").

Diffs to the website are welcome (you can get everything from htdocs
in CVS).  This is easier to fix than a forum, because it doesn't
require installing any new software or anything.

Changing the Standard Game

[Elijah Meeks]

I think the 4 unit per hex limit is a major change,
but I think it'd make for a better game.  I believe,
and maybe I'm in the minority here, in sort of a
French Chef ideal of game design.  That is, looking
good is an important aspect of gameplay.  I'm no
FPS-junkie but I've never played the standard game
because it looked like something I'd never have loaded
on my Commodore 64.  But (Shameless Plug Warning)
after updating the graphics I found it was a fun
little game.  Much quicker than (Shameless Plug
Warning) fine games like Bellum or AWLS.  

A four-unit per hex limit, while altering a major
gameplay aspect from the old style, would improve the
visual quality of the game immeasurably, regardless of
whether we believe it would be a pure gameplay
improvement.  For most of the people who pop on here
and post once or twice, this game IS XConq, and I
think it would be a better first impression with
Trident graphics and 4/hex limits.  There's already
one 'Classic' XConq, from ver. 5, so maybe the current
Standard game could become 'Classic pre7.5' on the
game list, and the Trident/4hex would be the new
'Standard Game'.

After all, the players we can expect to look for such
a 'Classic pre7.5' game on the games list are
precisely the players who would want to play it, while
the ones we'd expect to only try out the 'Standard'
game are newbies, hence people less concerned about
its resemblance to the old XConq Standard game and for
whom it's more important that we show what XConq 7.5
can do.  If they get into it, then they're welcome to
start a retro movement and only play the pre7.5 or
even ver5 or only in curses or on LED lights or
punchcard or whatever.

> Diffs to the website are welcome (you can get
> everything from htdocs
> in CVS).  This is easier to fix than a forum,
> because it doesn't
> require installing any new software or anything.
> 

If I changed the website (I reference my one site:
castironlife.sf.net) it would be a sidegrade from
Looks Old to Looks Crappy.  I'm just hoping a
friendly, brilliant, lurking web designer is reading
this...




		
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush

Re: Changing the Standard Game

[Eric McDonald]

On Thu, 2 Sep 2004, Elijah Meeks wrote:

> and maybe I'm in the minority here, in sort of a
> French Chef ideal of game design.  

As long as I don't have to pay $15 for a two-bite-and-its-gone 
appetizer.

> little game.  Much quicker than (Shameless Plug
> Warning) fine games like Bellum or AWLS.  

I'm not sure that Bellum belongs in the "fine games" category. 
More like "unfinished development" / "early experiment"....

I should probably get around to actually giving it official 
"unfinished" status one of these days.

> improvement.  For most of the people who pop on here
> and post once or twice, this game IS XConq, 

I agree.

> Trident graphics and 4/hex limits.  There's already
> one 'Classic' XConq, from ver. 5, so maybe the current
> Standard game could become 'Classic pre7.5' on the
> game list, and the Trident/4hex would be the new
> 'Standard Game'.

This sounds like it could be a reasonable solution.

> can do.  If they get into it, then they're welcome to
> start a retro movement and only play the pre7.5 or
> even ver5 or only in curses or on LED lights or
> punchcard or whatever.

Moving right along on the PDP-11 port for Xconq....

> Looks Old to Looks Crappy.  I'm just hoping a
> friendly, brilliant, lurking web designer is reading
> this...

Build a better Standard game and they will come?

Eric

Re: Changing the Standard Game

[Lincoln Peters]

On Thu, 2004-09-02 at 23:10, Elijah Meeks wrote:
> For most of the people who pop on here
> and post once or twice, this game IS XConq

A better interface (specifically a better "Welcome" screen) might make
it clearer to most players that Xconq is not just one game (important
for those who enjoy strategy games that are based on something other
than World War II).  I can envision a "Welcome" screen that looks like
the following (which, as usual, I designed with Glade without having to
write any code):

http://homepage.mac.com/lmpeters/welcome1.png
http://homepage.mac.com/lmpeters/welcome2.png
http://homepage.mac.com/lmpeters/welcome3.png
http://homepage.mac.com/lmpeters/welcome4.png
http://homepage.mac.com/lmpeters/welcome5.png
http://homepage.mac.com/lmpeters/welcome6.png

What I did here was use a GNOME "Druid" to produce a setup window with
multiple pages (known to Windows users as a "Wizard"), much like the
existing "Welcome" screen for the TclTk interface but with a layout that
(I think) is more visually appealing.

Furthermore, as soon as you click "Apply", you could theoretically jump
to the existing SDL interface and thus leave behind anything that even
remotely resembles an Office app.

---
Lincoln Peters
<sampln@sbcglobal.net>

Your good nature will bring you unbounded happiness.

Re: Changing the Standard Game

[Eric McDonald]

Lincoln Peters wrote:

> On Thu, 2004-09-02 at 23:10, Elijah Meeks wrote:
> 
>>For most of the people who pop on here
>>and post once or twice, this game IS XConq
> 
> 
> A better interface (specifically a better "Welcome" screen) might make
> it clearer to most players that Xconq is not just one game (important
> for those who enjoy strategy games that are based on something other
> than World War II).  

Well, I think that part of the problem might be simply that when you 
call one game the "standard" game, it implies that the others are either 
substandard or offshoots of it.

When I first tried out Xconq back in 1999 or 2000, this was one of the 
things that kept me away from the other games. And I barely did more 
than open a few of the others before I abandoned Xconq then because the 
UI was not very good. Even when I came back to it in the middle of 2003, 
I started playing the Standard game on the Tcl/Tk interface, because I 
assumed (possibly correctly) that the Standard game would give me the 
best playing experience. There is this perception that the Standard game 
is brought to you by "the developers", whereas the other games are just 
made by "other people", if you know what I mean....

>I can envision a "Welcome" screen that looks like
> the following (which, as usual, I designed with Glade without having to
> write any code):

Of course, code would still have to be added for event handlers for the 
various UI elements, so that a click on, say, a radio button will 
translate into the proper Xconq internals being updated.

> http://homepage.mac.com/lmpeters/welcome1.png
> http://homepage.mac.com/lmpeters/welcome2.png
> http://homepage.mac.com/lmpeters/welcome3.png
> http://homepage.mac.com/lmpeters/welcome4.png
> http://homepage.mac.com/lmpeters/welcome5.png
> http://homepage.mac.com/lmpeters/welcome6.png

Looks interesting.

> Furthermore, as soon as you click "Apply", you could theoretically jump
> to the existing SDL interface and thus leave behind anything that even
> remotely resembles an Office app.

I would suggest the "Apply" button be relabelled to "Accept" or "Start 
Game".

What you propose is interesting. This would certainly save time in the 
development of the startup screens, a task I have only half been looking 
forward to. The tradeoff is that the Windows installer would get quite a 
bit larger, because we cannot reasonably assume that a Windows user 
would have the GDK, GTK+, Pango, etc. libraries on his/her system.

Eric

Feature Request: Advance Prohibits Advance

[Elijah Meeks]

As it stands, there's no way to simulate different
tech paths.  I'd like to have a way to shut off
advances if certain advances are researched, so that
sides can choose different directions to take.  For
example, if we have two spacefaring societies, we can
have two techs, one being Ground War Focus and the
other Stellar War Focus.  The side that pics Ground
War Focus spends less on developing AT-ATs and
Battlemechs and more for its Cordships and A-Wing
Starfighters while the other side has to pay extra to
develop its hovertanks but manages to design
galaxy-class starships and battlestars at a faster
rate.




	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

Re: Feature Request: Advance Prohibits Advance

[Eric McDonald]

Elijah Meeks wrote:

> As it stands, there's no way to simulate different
> tech paths.  I'd like to have a way to shut off
> advances if certain advances are researched, so that
> sides can choose different directions to take.  For
> example, if we have two spacefaring societies, we can
> have two techs, one being Ground War Focus and the
> other Stellar War Focus.  The side that pics Ground
> War Focus spends less on developing AT-ATs and
> Battlemechs and more for its Cordships and A-Wing
> Starfighters while the other side has to pay extra to
> develop its hovertanks but manages to design
> galaxy-class starships and battlestars at a faster
> rate.

I'm wondering what the best way to model this is. I think that maybe 
instead of advances totally shutting out other advances, that maybe we 
should think about something like 'advance-adds-rp-requirement' and 
'advance-multiplies-rp-requirement' advance-vs-advance tables. This 
would allow for a game designer to make researching certain advances 
arbitrarily more difficult (or easier). This way a "Ground War Focus" 
civilization could _eventually_ research the "Space War Focus" line and 
thereby get good at both, and vice versa.

The ability to make researching advances easier is also interesting, 
because, for example, in a Civ-like game, after researching "Formal 
Logic" and "Empirical Science", a civilization might be able to make a 
whole slew of scientific and technological advances much more rapidly 
than it would otherwise.

Taken to extremes, the proposed tables could shut off advances by 
boosting the RP requirement to some very large number (relative 
infinity?), or make gaining an advance trivial by multiplying its RP 
requirement by 0%.

I'll think about it some more. I haven't dealt much with the advances 
aspect of Xconq before. If it's an easy feature to add (and test), I 
might go ahead and add it in the near future.

Eric

Re: Feature Request: Advance Prohibits Advance

[mskala]

Can't we make some advances require particular materials?  I think we
already can, and if not, that would be easy to add.  Then we could easily
do both behaviours.  For "you may only have one of these advances",
there's a material of which you only get a little bit, and you need all of
it to do either advance.  Once you have done one, you can't do the other.  
For "it's very hard, but possible, to do both of these advances", it's a
similar story, but you can eventually with a lot of work gain more of the
special material.
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/

Re: Feature Request: Advance Prohibits Advance

[Eric McDonald]

mskala@ansuz.sooke.bc.ca wrote:

> Can't we make some advances require particular materials?  I think we
> already can, and if not, that would be easy to add.  Then we could easily
> do both behaviours.  For "you may only have one of these advances",
> there's a material of which you only get a little bit, and you need all of
> it to do either advance.  Once you have done one, you can't do the other.  
> For "it's very hard, but possible, to do both of these advances", it's a
> similar story, but you can eventually with a lot of work gain more of the
> special material.

 From kernel/table.def:
DEF_AM_TABLE("advance-consumption-per-rp", am_consumption_per_rp,
         "amount of material consumed to add one research point to this 
advance",        amconsumptionperrp, constamconsumptionperrp, 0, 0, 
TABHI, TABINT)

If I understand what you're saying, you're suggesting that each side 
should have a finite quantity of a certain material in its treasury, and 
that material can only be used to research one, and no more than one, 
advance. The chosen advance then sets the tone for which other advances 
can be reserached (through the 'advance-needed-to-research' table).

Eric

Re: Feature Request: Advance Prohibits Advance

[mskala]

On Sun, 5 Sep 2004, Eric McDonald wrote:
> If I understand what you're saying, you're suggesting that each side 
> should have a finite quantity of a certain material in its treasury, and 
> that material can only be used to research one, and no more than one, 
> advance. The chosen advance then sets the tone for which other advances 
> can be reserached (through the 'advance-needed-to-research' table).

Right.  With some variations, I think that kind of approach can produce
most of the same behaviours as each of the proposed new features, and it
already should work with the existing code.  One way it might fall down
would be if there are a LOT of independent commitments the side may make -
ground or space battles AND opening boiled eggs at the big or the little
end AND less filling or tastes great AND matter or antimatter-based
warheads AND (and so on).  In that case it might end up requiring one new
material type for each choice, which could be a problem.
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/

Re: Feature Request: Advance Prohibits Advance

[Elijah Meeks]

--- mskala@ansuz.sooke.bc.ca wrote:

> Can't we make some advances require particular
> materials?  I think we
> already can, and if not, that would be easy to add. 
> Then we could easily
> do both behaviours.  For "you may only have one of
> these advances",
> there's a material of which you only get a little
> bit, and you need all of
> it to do either advance.  Once you have done one,
> you can't do the other.  
> For "it's very hard, but possible, to do both of
> these advances", it's a
> similar story, but you can eventually with a lot of
> work gain more of the
> special material.

I attempted something like this with AWLS, in that
hi-tech units produced more tech points specifically
for researching the next tech (i.e. level-1 Carriers
produced level-2 Carrier tech points).  The problem is
that, if the AI isn't researching Level-2 Carriers,
then the research points just pile up unused.  This
wouldn't be too much of a problem, because they'd
eventually be spent when that tech was researched, but
on top of this comes the lack of a generic tech
source, so now you can only research Level-2 Carriers
with level-2 carrier tech.






		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 

Re: Feature Request: Advance Prohibits Advance

[Elijah Meeks]

> The ability to make researching advances easier is
> also interesting, 
> because, for example, in a Civ-like game, after
> researching "Formal 
> Logic" and "Empirical Science", a civilization might
> be able to make a 
> whole slew of scientific and technological advances
> much more rapidly 
> than it would otherwise.
> 
> Taken to extremes, the proposed tables could shut
> off advances by 
> boosting the RP requirement to some very large
> number (relative 
> infinity?), or make gaining an advance trivial by
> multiplying its RP 
> requirement by 0%.
> 
> I'll think about it some more. I haven't dealt much
> with the advances 
> aspect of Xconq before. If it's an easy feature to
> add (and test), I 
> might go ahead and add it in the near future.

This is a good and much more feature-rich solution,
but there are two issues:

1) It's more complicated.  Not having seen the code, I
don't know how much, but a simple shut-off switch
would, I think be straightforward.  It would also
allow the game designer to simulate much of what
you're talking about, he'd just have to create a few
more techs, so that you're getting the same tech, only
cheaper, or you have to buy an extra 'Prelim' tech
before to open up the full, which is the closest thing
I can get to simulating something like this using GDL
now (Except I have to manually set the focus of one
group by using what I call limiters.  You can see this
in opal-rules.g, just search for 'limit')

2) The AI doesn't choose research very well.  Really,
this is for the AI, because a player will probably
focus, anyway, while the AI will choose its research
haphazardly and I wouldn't be surprised to see it
short-circuiting by researching an almost-infinite-rp
tech.

Of course, if I'm wrong about these points, which is a
decent possibility given my lack of familiarity with
the research or AI code, then by all means I'd prefer
a more featured implementation.






		
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush

Re: Feature Request: Advance Prohibits Advance

[Eric McDonald]

Elijah Meeks wrote:

> 1) It's more complicated.  Not having seen the code, I
> don't know how much, but a simple shut-off switch
> would, I think be straightforward.  

You are possibly right in this regard. I'll think some more about it.

>It would also
> allow the game designer to simulate much of what
> you're talking about, he'd just have to create a few
> more techs, so that you're getting the same tech, only
> cheaper,

I see. So are you going to race Lincoln to 10000 advances to win an 
additional donut? :-)

> 2) The AI doesn't choose research very well.  Really,
> this is for the AI, because a player will probably
> focus, anyway, while the AI will choose its research
> haphazardly and I wouldn't be surprised to see it
> short-circuiting by researching an almost-infinite-rp
> tech.

Ah ha. Trying to make the AI look like it has a brain? That is also the 
mark of a seasoned Xconq developer.

> Of course, if I'm wrong about these points, which is a
> decent possibility given my lack of familiarity with
> the research or AI code, then by all means I'd prefer
> a more featured implementation.

No. I think you made valid points. You are the one actually using 
advances. Like I said, I have barely touched the stuff. I'll think some 
more about it.

But, right now, I am about to add support for prefix args to the SDL 
interface.

Eric

Re: Feature Request: Advance Prohibits Advance

[mskala]

On Sun, 5 Sep 2004, Eric McDonald wrote:
> The ability to make researching advances easier is also interesting, 
> because, for example, in a Civ-like game, after researching "Formal 
> Logic" and "Empirical Science", a civilization might be able to make a 
> whole slew of scientific and technological advances much more rapidly 
> than it would otherwise.

I looked it up in the manual, and it turns out there's an
advance-consumption-per-rp table which (assuming it's implemented) does
more or less what I thought would be necessary.  To force the side to
choose ground or space battles, you have an advance for each which
requires a point of "research commitment", and you only get one point of
that, so you have to choose one or the other.  To force choosing one or
the other first, but eventually allow them both, make it require 100
points of research commitment, give the side 100 points, but then make it
hard to produce additional points... so they can eventually make another
100 and take the other path, but it'll take a while.

The "advances speed up other advances" thing could also be done easily
with materials.... having "Formal Logic" increases your production of
"journal papers", which are needed for other advances.
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/

Re: Feature Request: Advance Prohibits Advance

[Eric McDonald]

mskala@ansuz.sooke.bc.ca wrote:

> On Sun, 5 Sep 2004, Eric McDonald wrote:

> I looked it up in the manual, and it turns out there's an
> advance-consumption-per-rp table which (assuming it's implemented) does
> more or less what I thought would be necessary.  To force the side to
> choose ground or space battles, you have an advance for each which
> requires a point of "research commitment", and you only get one point of
> that, so you have to choose one or the other.  To force choosing one or
> the other first, but eventually allow them both, make it require 100
> points of research commitment, give the side 100 points, but then make it
> hard to produce additional points... so they can eventually make another
> 100 and take the other path, but it'll take a while.

This is an interesting thought. Among other things, it shows me that you 
  are fit to be considered a "seasoned" Xconq game designer, because of 
demonstrated aptitude at twisting existing features to mimic 
non-existent features. :-)

> The "advances speed up other advances" thing could also be done easily
> with materials.... having "Formal Logic" increases your production of
> "journal papers", which are needed for other advances.

Depends on which journal, and who the author(s) and referee were. For 
some, I think formal logic serves as a detriment....

Eric

Re: Feature Request: Advance Prohibits Advance

[Lincoln Peters]

On Sat, 2004-09-04 at 18:48, Elijah Meeks wrote:
> As it stands, there's no way to simulate different
> tech paths.  I'd like to have a way to shut off
> advances if certain advances are researched, so that
> sides can choose different directions to take.  For
> example, if we have two spacefaring societies, we can
> have two techs, one being Ground War Focus and the
> other Stellar War Focus.  The side that pics Ground
> War Focus spends less on developing AT-ATs and
> Battlemechs and more for its Cordships and A-Wing
> Starfighters while the other side has to pay extra to
> develop its hovertanks but manages to design
> galaxy-class starships and battlestars at a faster
> rate.

You could probably get the same effect (or at least a very similar one)
by making research dependent on multiple materials, which are in turn
dependent on specific "gateway" advances.

Suppose that you want to create a game based on the (admittedly very
weird) movie "Wizards" by Ralph Bashki.  Your big choice for research is
whether to focus on technological marvels (tanks, stealth bombers, etc.)
or magical marvels (magic weapons, scrying devices, etc.).  You could
handle this by using three materials: base-ideas, tech-ideas, and
arcane-ideas.  All advances require base-ideas, which therefore would be
fairly common.  Technological advances require a significant number of
tech-ideas in addition to base-ideas, and the "Tech focus" advance would
double (or more) the production of tech-ideas.  Similarly, magical
advances require a significant number of arcane-ideas in addition to
base-ideas, and the "Arcane focus" advance would double (or more) the
production of arcane-ideas.

Basically, "Tech focus" and "Arcane focus" would use the
advance-multiplies-production table to increase the production of
tech-ideas and arcane-ideas, respectively.  You could even make "Tech
focus" reduce production of arcane-ideas, or make "Arcane Focus" reduce
production of tech-ideas, by setting an advance-multiplies-production
value less than 1.

This would make it possible for a side to focus on one line of advances
or another, or to generalize and gain both at a slower rate.  It would
also allow a side to focus on one line while picking up an occasional
advance on the other line of research (thus allowing, for example, a
wizard to quickly end a battle with another wizard by pulling out a
handgun and shooting him).

---
Lincoln Peters
<sampln@sbcglobal.net>

A soft answer turneth away wrath; but grievous words stir up anger.
		-- Proverbs 15:1

Re: Feature Request: Advance Prohibits Advance

[Elijah Meeks]

> This would make it possible for a side to focus on
> one line of advances
> or another, or to generalize and gain both at a
> slower rate.  It would
> also allow a side to focus on one line while picking
> up an occasional
> advance on the other line of research (thus
> allowing, for example, a
> wizard to quickly end a battle with another wizard
> by pulling out a
> handgun and shooting him).

Points for referencing the weirdest cartoon of the
last half-century.  Do you plan on creating
rocknrule.g after that?

The problem here is when the AI decides to research
Arcane Focus and then wastes it's points researching
overly expensive Technology rather than the more
efficient Magic.  I overcame this problem in Opal
(Where the AI would research every magic type rather
than, as I'd hoped, just one or two) by manually
shutting off all but two 'Schools of Magic'. 
Otherwise, it shows remarkably poor choice in its
research selections.  That's why I'd like firm a
shut-off like advance-prohibits-advance.



		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 

Re: Feature Request: Advance Prohibits Advance

[Jim Kingdon]

> The problem here is when the AI decides to research
> Arcane Focus and then wastes it's points researching
> overly expensive Technology rather than the more
> efficient Magic.  . . . That's why I'd like firm a
> shut-off like advance-prohibits-advance.

Maybe a shut-off which affects the AI, not the referee code.  Similar
to what we've been talking about in general - ways to manually hint
the AI in cases where it isn't (yet?) smart enough to figure out the
situation for itself.

Re: Feature Request: Advance Prohibits Advance

[Eric McDonald]

Jim Kingdon wrote:

> Maybe a shut-off which affects the AI, not the referee code.

Good idea. I'll see what Lincoln does first. If it looks like the AI 
could still use a nudge, I'll try to find time to implement 
'ai-advance-prohibits-advance'. It can probably be added to the advance 
autopicker code fairly easily.

Eric

Re: Feature Request: Advance Prohibits Advance

[Lincoln Peters]

On Sun, 2004-09-05 at 10:01, Elijah Meeks wrote:
> Points for referencing the weirdest cartoon of the
> last half-century.  Do you plan on creating
> rocknrule.g after that?

That's one I don't think I've seen.

> 
> The problem here is when the AI decides to research
> Arcane Focus and then wastes it's points researching
> overly expensive Technology rather than the more
> efficient Magic.  I overcame this problem in Opal
> (Where the AI would research every magic type rather
> than, as I'd hoped, just one or two) by manually
> shutting off all but two 'Schools of Magic'. 
> Otherwise, it shows remarkably poor choice in its
> research selections.  That's why I'd like firm a
> shut-off like advance-prohibits-advance.

I think that what we need here is a better AI.  It should not be too
difficult to at least improve the code that picks advances.  I'll look
into it.

---
Lincoln Peters
<sampln@sbcglobal.net>

TAPPING?  You POLITICIANS!  Don't you realize that the END of the "Wash
Cycle" is a TREASURED MOMENT for most people?!

Re: Feature Request: Advance Prohibits Advance

[Elijah Meeks]

> 
> That's one I don't think I've seen.
> 

Rock and Rule, from the imbd (
http://us.imdb.com/title/tt0086203/ ):

A malevolent rock star kidnaps a female singer to
force her to participate in the summoning of a demon
and her band must help her stop him.

Out of print, thankfully...

> I think that what we need here is a better AI.  

Yes.  But until then, if we implement one little
table, I can engineer a bit of improvement with the
current AI.  It seems like the cost:benefit ratio for
such a table would be pretty darned high.





		
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail

Re: Changing the Standard Game

[Lincoln Peters]

On Sat, 2004-09-04 at 10:45, Eric McDonald wrote:
> Well, I think that part of the problem might be simply that when you 
> call one game the "standard" game, it implies that the others are either 
> substandard or offshoots of it.

Perhaps, then, we should change the name of the Standard game to the
Default game, or something else that doesn't imply that other Xconq
games are sub-standard.  At least, if _I_ saw that the first choice on
the list was called the "Default game," I wouldn't be as inclined to
doubt the quality of the other games.

Or maybe it needs a more descriptive name.

> 
> When I first tried out Xconq back in 1999 or 2000, this was one of the 
> things that kept me away from the other games. And I barely did more 
> than open a few of the others before I abandoned Xconq then because the 
> UI was not very good.

Even more reason to build a better UI, although I think we all agree
that bug-fixing usually takes precedence over UI building.

> 
> >I can envision a "Welcome" screen that looks like
> > the following (which, as usual, I designed with Glade without having to
> > write any code):
> 
> Of course, code would still have to be added for event handlers for the 
> various UI elements, so that a click on, say, a radio button will 
> translate into the proper Xconq internals being updated.

Of course.  Right now, I'm just trying to figure out what the interface
should look like.

> > Furthermore, as soon as you click "Apply", you could theoretically jump
> > to the existing SDL interface and thus leave behind anything that even
> > remotely resembles an Office app.
> 
> I would suggest the "Apply" button be relabelled to "Accept" or "Start 
> Game".

I'm pretty sure that there's a way to do that, but I'd have to write
actual code (Glade won't let me change the labels of buttons when the
buttons are part of a Druid widget).

> 
> What you propose is interesting. This would certainly save time in the 
> development of the startup screens, a task I have only half been looking 
> forward to. The tradeoff is that the Windows installer would get quite a 
> bit larger, because we cannot reasonably assume that a Windows user 
> would have the GDK, GTK+, Pango, etc. libraries on his/her system.

I'll have to study the Mono framework, but it might be possible to
implement one UI that runs on both Linux and Windows with minimal
platform-specific code or dependencies.  It also looks like Novell (the
company that now owns Ximian) is working on a Mono implementation for
MacOS X, which might simplify things further (but not until there is a
Mono-based interface that is actually better than the existing MacOS
interface).

If I remember correctly from that talk I attended back in 2002, the
biggest stumbling block that the Mono project encountered at the time
was the difference in widget styles (coordinate-based vs. hierarchical,
although I don't think he used those exact words).  However, since
they've finally released Mono 1.0, I would assume that they found a
solution to that problem.

Based on their FAQ, it looks like an application written for Mono/.NET
should work fine on UNIX/Linux or Windows with no difficulty as long as
it is a "100% .NET application" (essentially it is fully compliant with
the .NET standard and contains no platform-specific code).  Although I
have no idea how much work it would take to convert Xconq into a "100%
.NET application," and I don't think any of us want to find out (at
least not until post-7.5).


And, of course, there's the possibility of drastically simplifying
network games by implementing ZeroConf/Rendezvous (to make Xconq LAN
parties easier to set up) and/or an Xconq game server (maybe just a
modified IRC server to put Xconq players in contact with each other). 
Although that would almost certainly cause the appearance of Page 4 to
change somewhat, and it's not something I'd consider a high priority.


(Yes, I remember that the idea of using Mono was originally floated in
the midst of last year's great flame war, but I think that it's an idea
worth taking seriously, even if it was originally accompanied by a lot
of hot air.)

---
Lincoln Peters
<sampln@sbcglobal.net>

"Kill the Wabbit, Kill the Wabbit, Kill the Wabbit!"
-- Looney Tunes, "What's Opera Doc?" (1957, Chuck Jones)

Re: Changing the Standard Game

[Eric McDonald]

Lincoln Peters wrote:

> On Sat, 2004-09-04 at 10:45, Eric McDonald wrote:

> Perhaps, then, we should change the name of the Standard game to the
> Default game, or something else that doesn't imply that other Xconq
> games are sub-standard.  

I think that "Default Game" is a reasonable name. Especially since that 
is the default game that gets loaded by interface that don't bring up a 
game selector, such as Curses and SDL presently.

>>When I first tried out Xconq back in 1999 or 2000, this was one of the 
>>things that kept me away from the other games. And I barely did more 
>>than open a few of the others before I abandoned Xconq then because the 
>>UI was not very good.
> 
> Even more reason to build a better UI, although I think we all agree
> that bug-fixing usually takes precedence over UI building.

It depends largely on the severity of the bugs.

To be honest, I have reached a frustration point regarding the lack of a 
good UI for Linux and Windows. We were told that the 7.5 release was 
"imminent" a year and half ago. Even though I have worked on this 
project for over a year now, I still have no idea when the 7.5 release 
is going to be. Up until recently, I have restrained myself from taking 
on any big projects (such as UI building) because I didn't want to have 
7.5 announced while I was in the middle of one, and I certainly did not 
want to hold up a release on account of my work. At this point, I don't 
really care. If someone announces that the Macconq 7.5 release is 
looming, I'll just fork the sources and continue my work on the SDL 
interface; I've already got more than one foot pointed in that direction 
as it is (for other reasons).

I am aware that there are some network bugs out there that need to be 
fixed. I consider the network setup bug (not more than 2 sides can join 
properly) to be something that Hans should look at it, since he is the 
last person to have mucked with that sort of stuff. I will eventually 
take care of it, if he doesn't, but that is not my focus right now.

> I'm pretty sure that there's a way to do that, but I'd have to write
> actual code (Glade won't let me change the labels of buttons when the
> buttons are part of a Druid widget).

I see. I think the prototyping work you are doing is useful, but I 
imagine that it would not take too much work just to generate all of the 
UI elements from code (once we settle on what it should look like from 
the prototypes). This would give us the possibility of a more dynamic 
layout.

Eric

Re: Changing the Standard Game

[Jim Kingdon]

> I still have no idea when the 7.5 release is going to be. Up until
> recently, I have restrained myself from taking on any big projects
> (such as UI building) because I didn't want to have 7.5 announced
> while I was in the middle of one, and I certainly did not want to hold
> up a release on account of my work.

Experience in other projects seems to be that the whole business of
branching/freezing/etc doesn't work particularly well, and you are
better off making sure that the mainline is always in good shape.

For example, see http://lwn.net/Articles/95312/

Now, we could use better ways of keeping the mainline sane than we
have now.  My pet solution is automated tests, but since I'm not
writing much xconq code (or tests) these days, that doesn't count for
as much as what the more active developers do.  Another way is to
publish and encourage public testing of big, or risky, changes before
checking them in.  We're low on testers in general, which is the big
risk factor with that one.

As for wanting to keep working on SDL, if you are talking about code
which is specific to SDL, I can't think of any reason to be at all
reluctant to touch it on account of a supposedly-imminent 7.5 release.
If it is non-SDL code, well, maybe then there's more of an issue.  But
the idea of stabilizing the SDL code by not hacking on it doesn't
really make sense, given how much is missing in the current SDL code.

> I am aware that there are some network bugs out there that need to
> be fixed.

Yeah, and I wonder if there is a better way to find these than "find
another human who wants to play a network game and get a few turns in
and get a loss of sync".  AI vs AI network games are the traditional
method, and perhaps the current problem is just that no one has tried
one lately.  Writing some kind of monkey tester might be another way
(which generates random events, hopefully hitting corner cases which
the AI happens not to hit).  Finding a way to run these tests
(whatever they are) more quickly/automatically would be a big step up.

Re: Changing the Standard Game

[Jim Kingdon]

> I started playing the Standard game on the Tcl/Tk interface, because I 
> assumed (possibly correctly) that the Standard game would give me the 
> best playing experience.

My experience has been that the Standard game is the most playable of
the ones I've tried.

I wouldn't object to calling it Default game.

But it does seem worthwhile to steer new users towards it, unless
someone can tell me which other game we'd steer them towards.

Re: Changing the Standard Game

[Elijah Meeks]

> But it does seem worthwhile to steer new users
> towards it, unless
> someone can tell me which other game we'd steer them
> towards.
> 

Yeah, but with THOSE graphics?  It's just so... ugly.


	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

Re: Changing the Standard Game

[Eric McDonald]

Jim Kingdon wrote:

> My experience has been that the Standard game is the most playable of
> the ones I've tried.

I would agree. But, I haven't sat down to play a full game of Opal, 
AWLS, or Bolodd lately, so I don't know if this is still true or not.

> I wouldn't object to calling it Default game.

Good. I think I will make the change then, unless Stan magically appears 
and says otherwise.

> But it does seem worthwhile to steer new users towards it, unless
> someone can tell me which other game we'd steer them towards.

Agreed. I think that only the title needs to be changed. The module name 
(which is treated specially: placed second in the games list) can remain 
the same.

Eric

Re: Standard Game Graphics

[Eric McDonald]

On Thu, 2 Sep 2004, Elijah Meeks wrote:

> agree that it should be a group decision.  The one
> problem, which I believe Jim pointed out and proved
> true, is that it doesn't look so good at the 16
> unit/hex resolution.  

Jim brought up a valid point, and I suggested a custom image 
family (i.e., one that specifies alternate graphics at lower 
resolutions) as a way to deal with it.

> 1.  Make specific imf 4 4 definitions that reference
> the old silhouettes, because they're more recognizable
> at that resolution. 

This might work.

> 2.  Set unit limits per hex at four, which is the max
> amount of Trident units in a hex that are still
> recognizable and look decent.  

This could severely alter gameplay. I would lean more towards 
option 1 than option 2.

> Eric's Occupant Dialog Box Fix is out...  Right,
> Eric?*

We'll see. :-)
I am still getting accustomed to working on the SDL interface, and 
building up various tools to help me hack on it more easily. I 
haven't yet shifted into high productivity mode with it.

Also, I think I am going to try the unit magnification approach 
first, before resorting to a dialog box.

> still think we need a forum.  And a better webpage

Can't argue with that.

> And salaries for game designers.  And

If you can get me a salary to work on Xconq or some derivative 
thereof, that would be great. :-)

Eric

Re: Three thoughts

[Eric McDonald]

On Thu, 26 Aug 2004, Jim Kingdon wrote:

> > (1) Scaling images to non-standard sizes would likely be 
> > necessary to accomodate the suggested scheme.
> 
> Or playing with the size of the hexes, or re-working the bigicons
> feature, or something.  There are plenty of details that would need to
> worked out.  But first one needs to think through whether the concept
> seems promising in general.

Agreed. Certainly, the concept is an interesting one, especially 
if one ignores the small number of scaling bins in use and assumes 
an "infinite" number of them instead.

> > (3) Scaling down the images of other units would likely degrade 
> > their identifiability as certain types
> 
> The smallest image currently in use is about a 4x4?  It is pretty
> small.  I don't imagine you'd go smaller than that.

Agreed. But then what? If space constraints were to force one to 
go smaller, then what? Would this feature be selectively 
implemented to only work at high view powers, and be disabled for 
ones lower than the default one currently in use?

> But it is also worthwhile thinking about whether there is some way to
> provide some of the information with having to look back and forth to
> a window which is off to the side.  

I agree. That is why I think some sort of selection rectangle 
("crawling ants", blinking square, etc...) around the selected 
unit is a good idea. At small scales, it may be necessary to 
flash the entire unit icon to make it stand out from the crowd.

>Maybe it isn't center and edges,
> maybe it is top and bottom.  In the tcltk interface now, the top half
> is for the transport and the bottom half is for the occupants. 

Right. I had wondered about this approach as well. However, do we 
want to confuse paradigms? Top-bottom presently indicates 
transport-occupant; do we want to overload this for 
selected-unselected as well?

> With scaling and drawing otherwise the same as now.

I agree that it does have that benefit.

Eric

CXP???

[Elijah Meeks]

Okay, so you don't get cxp from ranged attacks, unless
the ranged attack is performed against a unit in the
hex adjacent?  And you only get cxp if the attack
misses??  I finally took a good look at cxp, after
assuming that I wasn't paying attention before, but
now that I have, it looks screwy.  Does anyone have
any firm rules on how cxp works and whether or not
it's supposed to work like this?  It seems haphazard.




		
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush

Re: CXP???

[Lincoln Peters]

On Thu, 2004-08-26 at 12:12, Elijah Meeks wrote:
> Okay, so you don't get cxp from ranged attacks, unless
> the ranged attack is performed against a unit in the
> hex adjacent?  And you only get cxp if the attack
> misses??  I finally took a good look at cxp, after
> assuming that I wasn't paying attention before, but
> now that I have, it looks screwy.  Does anyone have
> any firm rules on how cxp works and whether or not
> it's supposed to work like this?  It seems haphazard.

The behavior you describe certainly sounds wrong to me.  Since so few
games use CXP, I'm not surprised that there are undicovered bugs in the
code.

---
Lincoln Peters
<sampln@sbcglobal.net>

Tell me what to think!!!

Re: CXP???

[Eric McDonald]

Elijah Meeks wrote:

> Okay, so you don't get cxp from ranged attacks, unless
> the ranged attack is performed against a unit in the
> hex adjacent?  And you only get cxp if the attack
> misses??  I finally took a good look at cxp, after
> assuming that I wasn't paying attention before, but
> now that I have, it looks screwy.  Does anyone have
> any firm rules on how cxp works and whether or not
> it's supposed to work like this?  It seems haphazard.

You may have found a bug, depending on one's interpretation of when cXP 
should be awarded.

The following exists at the end of 'attempt_to_capture_unit':

         if (chance > 0) {
             if (atker->cxp < u_cxp_max(a))
               atker->cxp += uu_cxp_per_capture(a, o);
             /* (should not increment if side just changed?) */
             if (other->cxp < u_cxp_max(o))
               other->cxp += uu_cxp_per_capture(o, a);
         }

The "problem" is that experience is always being gained whenever 
'chance' is greater than 0, even if the capture is determined to have 
failed. The misses that you are seeing are also attempted captures 
(restricted to range <= 1), which is why combat experience is being 
"incorrectly" gained.

The other way to gain experience is with model 0 attacks and fires. 
However, looking at this code makes me realize that it may also be 
buggy, again depending on one's interpretation of combat experience.

The question here is: should failed attempts gain as much experience as 
successful attempts?

Eric

P.S. It should be noted that the defender can gain cXP just being 
attacked or fired upon, and it gains the same amount as if it was the 
attacker. Defenders also gain experience from being captured and 
resisting capture (as seen in the above code). Both of these cases seem 
a bit odd to me.