Three thoughts

Three thoughts

[mskala]

I've been busy with other things and not really playing or thinking about
Xconq much recently, but here are three interface thoughts, two of them
TCL/TK specific:

* If firing at specific units were to be a big part of some game, then it
would be nice if it were easier to designate specific units when there are
many of them, or nested occupant/transports, in a cell.  As it is, even at
the deepest level of zoom it's quite difficult to click precisely on one
unit if there are a lot of them in the cell.  One way to deal with this
might be for an interface to be able to give me a dialog box with a list
of units in the cell.

* In the current TCL/TK interface (well, current as of my last CVS
update), connection terrain is sometimes not drawn when at the highest
zoom level unless "grid" is turned on.  The "Lord of the Rings" game is a
good one for observing this - zoom in on a section of the map where there
are roads, and the roads suddenly disappear when you hit maximum
zoom.  They can be made to appear and disappear by turning "grid" on
and off.  And yet it seems to work correctly in the standard game
regardless of the state of "grid".

* I would really, really like to disable the automatic scrolling based on
mouse position in the TCL/TK interface, and I sure hope that "feature"
hasn't been incorporated into other interfaces.  It makes games that
require close-in zooming almost unplayable.  This will probably be my
project next time I have time to spend hacking on Xconq.  As a general
principle, I *never* want mouse position (without click) to change my
interface state, especially not in a way that's hard to reverse.  It's
especially annoying because common actions require me to move the pointer
between the map area and the menus or action buttons, and every time I do
that I have to move the pointer through the magic scroll zone and risk
getting a scroll that I didn't want.  Making the auto-scroll user-settable
would be okay, I suppose, but I'd keep the setting turned off all the time
myself.  Why can't we have scroll bars like everybody else?
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/

Re: Three thoughts

[Eric McDonald]

Hi Matthew, long time, no see,

On Fri, 20 Aug 2004 mskala@ansuz.sooke.bc.ca wrote:

> * If firing at specific units were to be a big part of some game, then it
> would be nice if it were easier to designate specific units when there are
> many of them, or nested occupant/transports, in a cell.  As it is, even at
> the deepest level of zoom it's quite difficult to click precisely on one
> unit if there are a lot of them in the cell.  One way to deal with this
> might be for an interface to be able to give me a dialog box with a list
> of units in the cell.

I think that Elijah may have also mentioned this last year, and I 
completely agree. Although I really don't want to do much Tcl/Tk 
hacking, this is something that I have been contemplating adding, 
depending on whether I let units carry armor (and weapons, 
once the necessary 'hit-chance' and 'damage' modifier tables are 
in place). Probably such a window could be brought up with the "i" 
key, since I think that is supposed to go to the next occ, IIRC.

> myself.  Why can't we have scroll bars like everybody else?

Unless I am dreaming, I think the Tcl/Tk interface may have had 
scrollbars at some point, or, at least, I thought they were 
commented out in the Tcl code.  I think Hans did improve the 
keyboard navigation in this regard a while back ago. Something 
about using the arrow keys or the numeric keypad, IIRC. You might 
want to see if you can dig up that mail; it might make your map 
navigation a little more pleasant.

Eric

Re: Three thoughts

[Andreas Bringedal]

> On Fri, 20 Aug 2004 mskala@ansuz.sooke.bc.ca wrote:
>
> > * If firing at specific units were to be a big part of some game, then it
> > would be nice if it were easier to designate specific units when there are
> > many of them, or nested occupant/transports, in a cell.  As it is, even at
> > the deepest level of zoom it's quite difficult to click precisely on one
> > unit if there are a lot of them in the cell.  One way to deal with this
> > might be for an interface to be able to give me a dialog box with a list
> > of units in the cell.

I've never understood why the interface has been so low on the priority list.  Back when I played Xconq 5.4 the interface was ok.
Today I can't bring myself to play the game anymore due to the interface and to a lesser degree the high dencity of cities.  But
since I don't program I can't really complain.  I just wanted to say that with a better interface you'd get a whole lot more players
and perhaps programmers.

Andreas

Re: Three thoughts

[Eric McDonald]

On Fri, 20 Aug 2004, Andreas Bringedal wrote:

> Today I can't bring myself to play the game anymore due to the 
>interface and to a lesser degree the high dencity of cities.  But

When you refer to the high density of cities, which game are you 
talking about? The Standard game?

Eric

Re: Three thoughts

[Andreas Bringedal]

> On Fri, 20 Aug 2004, Andreas Bringedal wrote:
>
> > Today I can't bring myself to play the game anymore due to the
> >interface and to a lesser degree the high dencity of cities.  But
>
> When you refer to the high density of cities, which game are you
> talking about? The Standard game?
>
> Eric

Yes the standard game, but also some of the others.  In one game I had seemingly half of all hexes covered with units.  It became a
chore moving the units.

A

Re: Three thoughts

[Eric McDonald]

Andreas Bringedal wrote:

> Yes the standard game, but also some of the others.  In one game I had seemingly half of all hexes covered with units.  It became a
> chore moving the units.

In the case of the Standard game, you can tweak the 
'independent-density' table in 'lib/standard.g'. These values are per 
10000 cells. If you find a set of values that you think is more 
reasonable, you could report it to the list, and either the Standard 
game could be changed or else a "Sparse Cities" variant could be 
created. The table looks like this:

(table independent-density
           (town plains 3000)
           (town (desert forest mountains) 500))

As for other games, it is true that Bellum starts out with quite a few 
units inside the country borders, but things generally thin out as time 
progresses in that game. The Advances game is perhaps the worst culprit 
in terms of acquiring more units than you actually want to deal with.

Eric

Re: Three thoughts

[Jim Kingdon]

> In the case of the Standard game, you can tweak the
> 'independent-density' table in 'lib/standard.g'. These values are per
> 10000 cells.

Hmm.  This had been 100/0, but now is it 600/100 (depending on the
terrain type).  I had always imagined more independent cities made the
game more interesting (because it gives you a reason to explore,
rather than just moving units over vast stretches of empty terrain).
But maybe I was wrong and there are downsides, like:

* Too many units to move

* Tilts the balance in favor of the human rather than the AI in human
  vs. AI games

* Makes it too easy to move bombers around the world.  Without all
  those independent towns to capture, you'd need to build bases, build
  carriers, and/or rely less on bombers.

So yes, please do try changing that parameter back to 100 and let us
know how it goes.  We could either change it back in the main game,
and/or make a variant.

2000-02-23  Stan Shebs  <shebs@shebs.cnchost.com>

	    * stdunit.g: Add more independent towns.

Index: stdunit.g
===================================================================
RCS file: /cvs/xconq/xconq/lib/stdunit.g,v
retrieving revision 1.1
retrieving revision 1.2
diff -c -r1.1 -r1.2
*** stdunit.g 28 Apr 1999 19:36:51 -0000	1.1
--- stdunit.g 23 Feb 2000 13:53:34 -0000	1.2
***************
*** 564,570 ****
    (* plains 40)
    )
  
! (table independent-density (town plains 100))
  
  (add land country-people-chance 90)
  (add plains country-people-chance 100)
--- 564,574 ----
    (* plains 40)
    )
  
! (table independent-density
!   ;; Most additional towns are in favorable terrain.
!   (town plains 600)
!   (town (desert forest mountains) 100)
!   )
  
  (add land country-people-chance 90)
  (add plains country-people-chance 100)

Re: Three thoughts

[Jim Kingdon]

> The Advances game is perhaps the worst culprit in terms of acquiring
> more units than you actually want to deal with.

Yeah, that's been my experience with Advances.  Oddly enough, one of
the games which I found tedious was a human vs. human game with Hans.
He was having quite a good time.  So I suppose there is no accounting
for taste...

I suppose the fact that he was winning didn't help :-P.

Re: Three thoughts

[Elijah Meeks]

> > On Fri, 20 Aug 2004 mskala@ansuz.sooke.bc.ca
> wrote:
> >
> > > * If firing at specific units were to be a big
> part of some game, then it
> > > would be nice if it were easier to designate
> specific units when there are
> > > many of them, or nested occupant/transports, in
> a cell.  As it is, even at
> > > the deepest level of zoom it's quite difficult
> to click precisely on one
> > > unit if there are a lot of them in the cell. 
> One way to deal with this
> > > might be for an interface to be able to give me
> a dialog box with a list
> > > of units in the cell.
> 
> I've never understood why the interface has been so
> low on the priority list.  Back when I played Xconq
> 5.4 the interface was ok.
> Today I can't bring myself to play the game anymore
> due to the interface and to a lesser degree the high
> dencity of cities.  But
> since I don't program I can't really complain.  I
> just wanted to say that with a better interface
> you'd get a whole lot more players
> and perhaps programmers.


I know the feeling.  I didn't include city
improvements in Opal, even though they'd improve the
game, just because they end up making it look so
cluttered*.  And the TCL/TK interface is, let's face
it, so ugly in comparison to the Mac interface and
even the stripped down SDL interface (Which I'm still
in love with.  Really.  When I play XConq in SDL, it
looks like a *game*).

Another thing to think about is the opening screen,
which relates especially to Eric's game-image feature.
 If we could revamp that, then players would probably
have an easier time choosing games and seeing
something they like.

*This, like Eric's items, would be fixed by an
occupant dialog box.  I've tried to work with units as
items, though, and found difficulty with setting the
game up so that a unit could pick up another unit.  It
seems like I have to give Item units ACP and movement,
which is an annoyance to the AI and player and uglier
gameplay.  Anyone have any suggestions?  I'd love an
item-demo.g and, of course, if Eric throws in static
improvements, I can rewrite Cast Iron Life, and even
change the experience system in AWLS so that a unit
carries an Experience unit that provides bonuses,
rather than have five different units for each
experience level.  But that would probably necessitate
an AI-recommendation table for building and and and...
 Ah, being a needy XConq designer sure is the life.




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

Re: Three thoughts

[Eric McDonald]

On Fri, 20 Aug 2004, Elijah Meeks wrote:

> Another thing to think about is the opening screen,
> which relates especially to Eric's game-image feature.

I think Hans might have done that, actually.

> *This, like Eric's items, would be fixed by an
> occupant dialog box.  I've tried to work with units as
> items, though, and found difficulty with setting the
> game up so that a unit could pick up another unit.  

I think that is another area that needs some work.

>It
> seems like I have to give Item units ACP and movement,
> which is an annoyance to the AI and player and uglier
> gameplay.  Anyone have any suggestions?  

I'd see what Matthew Skala came up with. He was working on "cow 
patties" for a while.

>I'd love an
> item-demo.g and, of course, if Eric throws in static
> improvements, I can rewrite Cast Iron Life, and even
> change the experience system in AWLS so that a unit
> carries an Experience unit that provides bonuses,
> rather than have five different units for each
> experience level.  

Interesting idea. I hadn't thought of it this way. I guess you're 
saying that you have some interest in some new modifier tables 
('occupant-adds-hit-chance', 'occupant-adds-damage', 
'occupant-multiplies-hit-chance', etc...)?

Eric

Re: Three thoughts

[mskala]

On Fri, 20 Aug 2004, Eric McDonald wrote:
> > seems like I have to give Item units ACP and movement,
> > which is an annoyance to the AI and player and uglier
> > gameplay.  Anyone have any suggestions?  
> 
> I'd see what Matthew Skala came up with. He was working on "cow 
> patties" for a while.

I couldn't get it to work.  Like Elijah, I found that I had to give the
"item" units some ACP and movement capabilities, but that still didn't
allow me to get the kind of behaviour I really wanted.  As I think I
mentioned at the time, I had a lot of trouble preventing the item units
from constantly waking up and demanding the user's attention even when the
user didn't want them to do anything but sit there.  I also wanted my item
units to be indestructible - so they'd end up just sitting on the ground
if their transport was destroyed for *any* reason - and it proved tricky
to cover all the cases for that.

When the fancy wrecking behaviour started to be defined, I realised that
if I changed my game concept a little I could use fancy wrecking instead
of item objects (basically, have one unit type for "has item" and one for 
"doesn't have item", although it also meant changing my vision of what
that signified), and produce a more fun result.  Wrecking seemed to be in
a lot of flux and then my workload at school started to ramp up and so I
decided to leave that project alone for a while, hoping that by the time I
got back to it the fancy wrecking behaviour would have gelled into
something I could use.
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/

Re: Three thoughts

[Eric McDonald]

mskala@ansuz.sooke.bc.ca wrote:

> On Fri, 20 Aug 2004, Eric McDonald wrote:

> When the fancy wrecking behaviour started to be defined, I realised that
> if I changed my game concept a little I could use fancy wrecking instead
> of item objects (basically, have one unit type for "has item" and one for 
> "doesn't have item", although it also meant changing my vision of what
> that signified), and produce a more fun result.  Wrecking seemed to be in
> a lot of flux and then my workload at school started to ramp up and so I
> decided to leave that project alone for a while, hoping that by the time I
> got back to it the fancy wrecking behaviour would have gelled into
> something I could use.

Do you find the wrecking and 'change-type' behavior to now be suitable 
for your needs, or is an ingredient still missing?

(Also, I think you were the one who requested the 'remove-list' (as 
opposed to 'remove') capability, IIRC. That capability now exists in Xconq.)

Eric

Re: Three thoughts

[mskala]

On Fri, 20 Aug 2004, Eric McDonald wrote:
> Do you find the wrecking and 'change-type' behavior to now be suitable 
> for your needs, or is an ingredient still missing?

Well, I haven't really decided yet exactly how I want to use the new
features, and until I do, I won't really know if they do what I want, but
my impression is that they'll probably be more than sufficient.

> (Also, I think you were the one who requested the 'remove-list' (as 
> opposed to 'remove') capability, IIRC. That capability now exists in Xconq.)

Yes - thanks.
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/

Re: Three thoughts

[Hans Ronne]

>* If firing at specific units were to be a big part of some game, then it
>would be nice if it were easier to designate specific units when there are
>many of them, or nested occupant/transports, in a cell.  As it is, even at
>the deepest level of zoom it's quite difficult to click precisely on one
>unit if there are a lot of them in the cell.

Firing at selected units is impossible unless you are using the Mac
interface. See my post "The selective fire-at command". Fixing the tcltk
interface so that you can do selective fire-at is on my todo list. It has
never been possible to target occupants directly in Xconq, though I believe
I suggested earlier this year that we should consider making it possible.
As for selecting units in general, I never had any problems at the highest
zoom level. What game are you playing, and how many units are there in the
cell?

>* In the current TCL/TK interface (well, current as of my last CVS
>update), connection terrain is sometimes not drawn when at the highest
>zoom level unless "grid" is turned on.

I'll look into this when I have time. Graphics at the highest zoom level is
not fully developed in any of the interfaces, so there are various glitches.

>getting a scroll that I didn't want.  Making the auto-scroll user-settable
>would be okay, I suppose, but I'd keep the setting turned off all the time
>myself.  Why can't we have scroll bars like everybody else?

Maybe you should get a Mac :-). Not only does it have selective fire-at,
but this other feature that you are asking for (scrollbars that you can
turn on or off) is also available in the Mac interface. Not that I ever use
them. A better alternative to scrollbars is scrolling of the map using the
arrow keys. I ported that feature from the Mac interface to the tcltk
interface some time ago. If you use Windows, you can also scroll diagonally
by using numbers 1-9 on the numeric keypad. For some reason, I couldn't get
the numeric keypad to work properly under Linux, though.

Hans

Item Units

[Elijah Meeks]

(Figured it deserved it's own thread)

Eric, you'd mentioned additional tables and we've
talked about the cow patties.  It seems like the
framework's in place for items, just add a fifth entry
to the ferry-on-entry/departure tables that's "Full"
(Or something similar).  I'd thought, when I first
worked with items as occupants, that "over-all"
would've worked, but it didn't.  "Full" would mean
that the transport paid all necessary ACP costs for
the occupant to move into the hex and load onto the
unit.

Problems:  

The AI, of course, would likely not get that these
units were useful, and would probably pick them up and
drop them at random.  An initial workaround would be
to set the ferry-on-entry to "Full" and the
ferry-on-departure to over-nothing, which means that
once the AI orders a legitimate unit to pick up an
item, it's stuck with it.  Not the best solution, of
course, but it would work.

I'd like to introduce three item types in Opal: 
Weapon, Armor and Gear.  They'd come in two flavors,
fine and magical.  So far, so good (Heck, only six new
units, I'll never reach 1000 like this).  But we've
all seen how a unit looks with three occupants,
especially when it occupies a cell with another unit
or two.  Without an occupant dialog box, it'd just be
too cluttered.

Building each magic sword by hand is also a pain.  So
I'd love to see initial-occupant and
occupant-when-created tables that call for, in the
case of the former, a unit placed with said occupant
and, in the case of the latter, an extra build to
produce, if the builder is able, the additional
occupants.  The tables would be percentage based,
especially useful with the initial-occupant table,
because then some of your swordsmen might start with
fine weapons or magic armor, adding a little
randomness to the game.  If the percentage is higher
than 100, it would indicate more than one occupant, so
that, say, a huge city could be set at:

(initial-occupant
   (hugecity magicsword 350)
)

And would always start with three magic swords with a
50% chance of a fourth.


Tablewise, occupant-adds-hit-chance/fire-hit-chance,
occupant-adds-acp, occupant-adds-damage and
occupant-adds-hp would be a great start.

And neural nets, and 3D units, and a fully 3D globe,
and XBox support, and and and...


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

Re: Item Units

[Eric McDonald]

Elijah Meeks wrote:

> It seems like the
> framework's in place for items, just add a fifth entry
> to the ferry-on-entry/departure tables that's "Full"
> (Or something similar).  I'd thought, when I first
> worked with items as occupants, that "over-all"
> would've worked, but it didn't.  "Full" would mean
> that the transport paid all necessary ACP costs for
> the occupant to move into the hex and load onto the
> unit.

I think one problem with cow patties is that ideally one would like them 
to be actionless, and hence they could not be selected as active units. 
So, having a transport offer to pay for everything would not do much 
good for items that cannot even be selected as actors.

A dedicated pickup/get command like most good dungeon games have would 
be nice.

Another possibility would be to get Xconq's control range stuff working 
(if it's not already; I haven't experimented with it, but there does 
appear to be some support for it in the code). Then set the control 
range of regular units to be something like 1 or 2 cells for item units. 
Thus the item units would only be able to act (i.e., move) in the 
presence of a regular unit.

> The AI, of course, would likely not get that these
> units were useful, and would probably pick them up and
> drop them at random. 

One thing that I have tried before, but with only partial success, was 
to set the 'ai-peace-garrison' of mobile transports, such as carriers, 
close to their occupancy max, and then set the 'ai-war-garrison' to 0.

In the case of item units, I would guess that both garrisons should be 
at the occupancy max to encourage the AI to retain the items at all times.

> I'd like to introduce three item types in Opal: 
> Weapon, Armor and Gear.  

I'm looking at Weapons and Armor for Wreckreation. Armor could already 
be done since the 'protection' (should really be called 'vulnerability') 
table already exists.

> So far, so good (Heck, only six new
> units, I'll never reach 1000 like this).  

Yeah, no kidding. And I thought it was 10000 in order to win the magic 
donut.

>But we've
> all seen how a unit looks with three occupants,
> especially when it occupies a cell with another unit
> or two.  Without an occupant dialog box, it'd just be
> too cluttered.

IIRC, you suggested this when we were disucssing options for Cast Iron 
Life last year. I think it is a good idea. I have been quite tempted to 
try implementing it in the Tcl/Tk interface. I think I would improve 
formation selection first, before attempting that, since the improved 
formation selection stuff is likely easier.

> Building each magic sword by hand is also a pain.  So
> I'd love to see initial-occupant and
> occupant-when-created tables that call for, 

Yeah, the 'initial-occupant' idea has been at the back of my mind as 
well, and out of the same needs that you mention. It seems that you 
thought about it more than me though, since I didn't think of the 
randomness aspect.

Hans just recently implemented part of another idea I had: units under 
construction being tougher than 1 HP. Had I implemented it, I would have 
redirected damage to CP instead of HP, and set up a HP-to-CP conversion 
ratio table. However, since he implemented it with a static HP value; I 
may still have the opportunity to do something more dynamic (scalable) 
like I had originally intended. The two solutions can probably exist 
side by side (though mutuall exclusive), if done right.

> Tablewise, occupant-adds-hit-chance/fire-hit-chance,
> occupant-adds-acp, occupant-adds-damage and
> occupant-adds-hp would be a great start.

You've already got 'occupant-adds-acp' and 'occupant-multiplies-acp'. I 
added those a while back ago. I think there is a fairly good chance that 
I will want to add 'occupant-adds-hit-chance', 
'occupant-adds-fire-hit-chance', and 'occupant-adds-damage', and their 
multiplicative counterparts. I hadn't thought of the HP one.

> And neural nets, and 3D units, and a fully 3D globe,
> and XBox support, and and and...

That "and and..." is becoming a trademark of yours. :-)

Thanks for the thoughts. I hope to address at least some of them in the 
next month or so, but knowing how I always get sidetracked, I should 
stop quoting timelines.

Eric

Re: Item Units

[Lincoln Peters]

On Sat, 2004-08-21 at 23:39, Eric McDonald wrote:
> I think one problem with cow patties is that ideally one would like them 
> to be actionless, and hence they could not be selected as active units. 
> So, having a transport offer to pay for everything would not do much 
> good for items that cannot even be selected as actors.
> 
> A dedicated pickup/get command like most good dungeon games have would 
> be nice.

In many respects, these "cow patty" units could be treated like
facilities, so if someone implemented an easy way to pick up *and drop*
such units, you might have something useful.

On the other hand, the AI's understanding of facilities is a solid
"brain-dead"; I honestly think that the AI will need to be radically
re-engineered before it will ever truly understand facilities.

> 
> Another possibility would be to get Xconq's control range stuff working 
> (if it's not already; I haven't experimented with it, but there does 
> appear to be some support for it in the code). Then set the control 
> range of regular units to be something like 1 or 2 cells for item units. 
> Thus the item units would only be able to act (i.e., move) in the 
> presence of a regular unit.

I experimented with control-range in a game module involving
necromancers and undead armies.  The idea was that undead units would be
helpless if they were more than 16 cells away from the necromancer,
except for vampires and liches, which can function normally up to 24
cells away and can relay orders.

It seemed to work decently, but it was around the time that the
pathfinding code was radically re-engineered (and later radically
un-re-engineered), so I ran into a bunch of problems that may have been
totally unrelated to the control code and eventually lost interest in
it.  Maybe I should take another look at it.

(This module might make a good addition to the library, but its premise
*is* rather twisted.)

> > I'd like to introduce three item types in Opal: 
> > Weapon, Armor and Gear.  
> 
> I'm looking at Weapons and Armor for Wreckreation. Armor could already 
> be done since the 'protection' (should really be called 'vulnerability') 
> table already exists.

I tried to implement armor in a game module I wrote a while ago (the
game module was never interesting enough to add to the library).  I
discovered that I could not provide more than one kind or armor without
running into the following dilemma about how the armor "occupies" the
knight:

1. If I use unit-capacity-x, I can prevent a knight from wearing two
suits of plate armor, but I can't prevent a knight from wearing a suit
of chainmail over a suit of full plate.  (If I was to allow a knight to
wear two suits of armor simultaneously, I'd want to find a way to adjust
their ACP's and hit chances accordingly.)

2. If I use generic capacity, I can ensure that a knight can wear one
and only one suit of armor, but I lose the ability to do anything
similar with other items (different kinds of shields, helmets, magic
rings...).  I would have to make various kinds of armor, shields, rings,
etc. fit in generic capacity; therefore a knight could wear one suit of
plate armor normally, and one on his finger in place of a ring of
protection (now *that's* a silly mental image).

> 
> > So far, so good (Heck, only six new
> > units, I'll never reach 1000 like this).  
> 
> Yeah, no kidding. And I thought it was 10000 in order to win the magic 
> donut.

I guess I need to get back to work on knights.g!

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

A quarrel is quickly settled when deserted by one party; there is no battle
unless there be two.  -- Seneca

Re: Item Units

[Eric McDonald]

Lincoln Peters wrote:

> I experimented with control-range in a game module involving
> necromancers and undead armies.  The idea was that undead units would be
> helpless if they were more than 16 cells away from the necromancer,
> except for vampires and liches, which can function normally up to 24
> cells away and can relay orders.
> 
> It seemed to work decently, but it was around the time that the
> pathfinding code was radically re-engineered (and later radically
> un-re-engineered), so I ran into a bunch of problems that may have been
> totally unrelated to the control code and eventually lost interest in
> it.  Maybe I should take another look at it.

Yes. I bet it will turn up some bugs. Depends on how well the 
actor/agent (unit/unit2) separation has been honored and enforced in the 
kernel action code.... Actors are units which have ACP's and are doing 
the controlling, whereas agents are being controlled and using the 
actor's ACP's. Or, at least, that is my understanding of the code.

> I tried to implement armor in a game module I wrote a while ago (the
> game module was never interesting enough to add to the library).  I
> discovered that I could not provide more than one kind or armor without
> running into the following dilemma about how the armor "occupies" the
> knight:
> 
> 1. If I use unit-capacity-x, I can prevent a knight from wearing two
> suits of plate armor, but I can't prevent a knight from wearing a suit
> of chainmail over a suit of full plate.  (If I was to allow a knight to
> wear two suits of armor simultaneously, I'd want to find a way to adjust
> their ACP's and hit chances accordingly.)

Encumberment should be able to be modelled with the 'occupant-adds-acp' 
table. I am thinking that I forgot to test it with negative values, but 
did deliberately set it up allowing values between TABLO (-32768) and 
TABHI (32767), and so it should be able to be used to model negative 
effects on ACP as well as positive ones.

> 2. If I use generic capacity, I can ensure that a knight can wear one
> and only one suit of armor, but I lose the ability to do anything
> similar with other items (different kinds of shields, helmets, magic
> rings...).  I would have to make various kinds of armor, shields, rings,
> etc. fit in generic capacity; therefore a knight could wear one suit of
> plate armor normally, and one on his finger in place of a ring of
> protection (now *that's* a silly mental image).

Don't forget the 'occupant-max' table. You can set the total capacity 
high, and then limit certain types using 'occupant-max'.

One exercise you can do is:
Sit down and draw a square, say a 5x5 square, representing the unit's 
total capacity. Then, place, say, a 3x3 square inside the larger square, 
and let it represent the "armor slot". Then, lay out other squares and 
rectangles representing other contents the unit may have. You can, of 
course, use rectangles for your container instead of squares.

After this, you have a crude visualization of your space consumption, 
and can fill out the various tables accordingly.

>>Yeah, no kidding. And I thought it was 10000 in order to win the magic 
>>donut.
> 
> I guess I need to get back to work on knights.g!

I thought it was 'red-wizard.g' now. But, whatever it is called, I think 
it did have promise last time I looked at it.

> A quarrel is quickly settled when deserted by one party; there is no battle
> unless there be two.  -- Seneca

Quite true.
(Publilius Syrus is still my favorite Roman author of such sayings, but 
Seneca isn't too bad either.)

Eric

Re: Item Units

[Lincoln Peters]

On Mon, 2004-08-23 at 19:09, Eric McDonald wrote:
> Lincoln Peters wrote:
> 
> > I experimented with control-range in a game module involving
> > necromancers and undead armies.  The idea was that undead units would be
> > helpless if they were more than 16 cells away from the necromancer,
> > except for vampires and liches, which can function normally up to 24
> > cells away and can relay orders.
> > 
> > It seemed to work decently, but it was around the time that the
> > pathfinding code was radically re-engineered (and later radically
> > un-re-engineered), so I ran into a bunch of problems that may have been
> > totally unrelated to the control code and eventually lost interest in
> > it.  Maybe I should take another look at it.
> 
> Yes. I bet it will turn up some bugs. Depends on how well the 
> actor/agent (unit/unit2) separation has been honored and enforced in the 
> kernel action code.... Actors are units which have ACP's and are doing 
> the controlling, whereas agents are being controlled and using the 
> actor's ACP's. Or, at least, that is my understanding of the code.

The way it seemed to be working was that agents had their own ACP's, but
they stopped working if they moved too far away from the actor.  I
didn't notice anything about agents using an actor's ACP's, although
that wouldn't have made sense for this game.

One thing that surprised me was that if an agent went out of range, it
became not just impossible to make it act, it became impossible to
select it at all!  I don't know if this is how it's supposed to work.

> 
> Encumberment should be able to be modelled with the 'occupant-adds-acp' 
> table. I am thinking that I forgot to test it with negative values, but 
> did deliberately set it up allowing values between TABLO (-32768) and 
> TABHI (32767), and so it should be able to be used to model negative 
> effects on ACP as well as positive ones.

True, but I had hoped that I could prevent a knight from wearing two
suits of armor at all, thus avoiding this whole issue.  Although I might
want to set up a game to allow knights in light armor to move faster
than knights in heavy armor...

Maybe I've got another idea to experiment with in 'knights.g' (or
whatever I end up calling it once it's finished).

> 
> > 2. If I use generic capacity, I can ensure that a knight can wear one
> > and only one suit of armor, but I lose the ability to do anything
> > similar with other items (different kinds of shields, helmets, magic
> > rings...).  I would have to make various kinds of armor, shields, rings,
> > etc. fit in generic capacity; therefore a knight could wear one suit of
> > plate armor normally, and one on his finger in place of a ring of
> > protection (now *that's* a silly mental image).
> 
> Don't forget the 'occupant-max' table. You can set the total capacity 
> high, and then limit certain types using 'occupant-max'.

But can you limit groups of units, so that a knight can only wear one
suit of armor even if I define multiple kinds of armor?

> 
> One exercise you can do is:
> Sit down and draw a square, say a 5x5 square, representing the unit's 
> total capacity. Then, place, say, a 3x3 square inside the larger square, 
> and let it represent the "armor slot". Then, lay out other squares and 
> rectangles representing other contents the unit may have. You can, of 
> course, use rectangles for your container instead of squares.
> 
> After this, you have a crude visualization of your space consumption, 
> and can fill out the various tables accordingly.

That had not occurred to me.  However, I notice one possible exploit in
this solution:

Suppose that a knight's generic capacity is 24.  A suit of armor is size
13, a shield is size 6, and a helmet is size 5.  If a knight has no
armor, he can carry 4 shields instead!


Perhaps I could prevent this if unit capacity could be represented in
two or more dimensions, but it would still be awkward and prone to
error.

> 
> >>Yeah, no kidding. And I thought it was 10000 in order to win the magic 
> >>donut.
> > 
> > I guess I need to get back to work on knights.g!
> 
> I thought it was 'red-wizard.g' now. But, whatever it is called, I think 
> it did have promise last time I looked at it.

I've been re-naming it every time I decide to radically re-engineer it,
so that (hopefully) I can re-trace my steps if some weird bug crops up. 
The current incarnation is called 'knightmare.g'.

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

Keep your eyes wide open before marriage, half shut afterwards.
		-- Benjamin Franklin

Re: Item Units

[Eric McDonald]

Lincoln Peters wrote:

>>Yes. I bet it will turn up some bugs. Depends on how well the 
>>actor/agent (unit/unit2) separation has been honored and enforced in the 
>>kernel action code.... Actors are units which have ACP's and are doing 
>>the controlling, whereas agents are being controlled and using the 
>>actor's ACP's. Or, at least, that is my understanding of the code.
> 
> The way it seemed to be working was that agents had their own ACP's, but
> they stopped working if they moved too far away from the actor.  

Right. I had gathered that from the code.

>I
> didn't notice anything about agents using an actor's ACP's, although
> that wouldn't have made sense for this game.

I don't think there is any GDL support for this particular aspect, and I 
don't remember seeing much in the action-related code that would check 
any GDL props or tables before deciding that 'unit' and 'unit2' are not 
the same. I was just mentioning this as another aspect if "control" was 
fully implemented.

> One thing that surprised me was that if an agent went out of range, it
> became not just impossible to make it act, it became impossible to
> select it at all!  I don't know if this is how it's supposed to work.

One should still be able to survey it, but I would expect that one could 
not select it for action.

> True, but I had hoped that I could prevent a knight from wearing two
> suits of armor at all, thus avoiding this whole issue. 

I see. I thought you were just wondering whether there was an 
encumberment mechanism.

> Although I might
> want to set up a game to allow knights in light armor to move faster
> than knights in heavy armor...

Thought so. :-)

> But can you limit groups of units, so that a knight can only wear one
> suit of armor even if I define multiple kinds of armor?

Only through size (which is why I suggested a large square for it). This 
does break down somewhat with smaller items. One possible workaround, 
though quite hackish, would be to create container units that the unit 
carries. So you would have a "gloves and gauntlets" container which 
could only carry one instance of any of your assorted gloves and 
gauntlets types. And likewise for the other groups. This does create 
another layer of containment, which when coupled with the current Tcl/Tk 
interface, could be messy to navigate (per our earlier discussion).

> That had not occurred to me.  However, I notice one possible exploit in
> this solution:
> 
> Suppose that a knight's generic capacity is 24.  A suit of armor is size
> 13, a shield is size 6, and a helmet is size 5.  If a knight has no
> armor, he can carry 4 shields instead!

If you have only one shield type, then you can limit it with 
'occupant-max'. If you have more than one shield type defined, then, 
yes, this does break down. However, see my "container units" suggestion.

I think, in the long run, the concept of "unit class" would be useful in 
areas:
(1) This whole capacity restriction mess that we jsut discussed. The 
mess also appears with 'unit-capacity-x'. Consider a city unit which has 
exclusive capacity for 4 aircraft (it has an airfield, say). With the 
currently available, Xconq tools, you have no way of saying that only up 
to 4 aircraft of possibly varying types can be placed in the airfield. 
If you attempt to limit each type to 4 and you have 4 types then you 
would end up with the possibility of 16 aircraft in the airfield, 4 from 
each type.
(2) Creating hierarchies in the help system, which would not only be 
useful for guiding a player to groups of related units, but would also 
help quell the tendency for oversized "Unit Types" sections in the menus 
as you and Elijah race onwards towards the 10000 unit mark.

Eric

Re: Three thoughts

[mskala]

On Sun, 22 Aug 2004, Hans Ronne wrote:
> As for selecting units in general, I never had any problems at the highest
> zoom level. What game are you playing, and how many units are there in the
> cell?

I noticed the problem most in my game with the item units, because there I
had some units with as many as 25 occupants that sometimes were occupants
themselves.  It becomes an issue even in the standard game with smaller
numbers of occupants, though.  Try putting a bomber (loaded with a unit of
infantry) on a carrier that also has some fighters on it, and sailing
some other ship into the cell.  The infantry shrinks below the visibility
threshold even on maximum zoom.  Or, worse yet, try sailing the carrier
into a port that also has a few other units in it.

> them. A better alternative to scrollbars is scrolling of the map using the
> arrow keys. I ported that feature from the Mac interface to the tcltk

It isn't really the scroll bars I'd like to turn on or off, but the
automatic scrolling based on mouse position.  Arrow keys or scroll bars
each serve the purpose better.  I slightly prefer scroll bars for
consistency with other software, and because then scrolling can be done
with the mouse alone, but I'd be happy to just have the auto-scroll
removed without being replaced at all.  We still have the clickable world
map in the corner, which is what I usually use in the current TCL/TK
interface.
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/

Re: Three thoughts

[Hans Ronne]

>On Sun, 22 Aug 2004, Hans Ronne wrote:
>> As for selecting units in general, I never had any problems at the highest
>> zoom level. What game are you playing, and how many units are there in the
>> cell?
>
>I noticed the problem most in my game with the item units, because there I
>had some units with as many as 25 occupants that sometimes were occupants
>themselves.  It becomes an issue even in the standard game with smaller
>numbers of occupants, though.

I see. One thing that might solve this problem, if I may bring up the Mac
interface again, is to implement unit closeups. This is how you navigate
within the stack on the Mac: right-click on a unit to bring up a small
floating window with unit info plus one image of each occupant. Right-click
on any of these images to bring up a closeup of the occupant. And so on.
There is also a clickable image of the transport in each occupant closeup,
so you can navigate quickly up and down in the stack. The frontmost closeup
automatically becomes the current unit for commands etc.

Porting this to the tcltk interface is something that I have wanted to do
for a long time, but it is easier said than done. The main problem is the
lack of support for floating windows in tcltk.

>> them. A better alternative to scrollbars is scrolling of the map using the
>> arrow keys. I ported that feature from the Mac interface to the tcltk
>
>It isn't really the scroll bars I'd like to turn on or off, but the
>automatic scrolling based on mouse position.

OK. Making that a user preference shouldn't be too difficult. I'm about to
leave for a trip, but I'll look into it when I'm back.

Hans

Re: Three thoughts

[Lincoln Peters]

On Sun, 2004-08-22 at 07:01, Hans Ronne wrote:
> >I noticed the problem most in my game with the item units, because there I
> >had some units with as many as 25 occupants that sometimes were occupants
> >themselves.  It becomes an issue even in the standard game with smaller
> >numbers of occupants, though.
> 
> I see. One thing that might solve this problem, if I may bring up the Mac
> interface again, is to implement unit closeups. This is how you navigate
> within the stack on the Mac: right-click on a unit to bring up a small
> floating window with unit info plus one image of each occupant. Right-click
> on any of these images to bring up a closeup of the occupant. And so on.
> There is also a clickable image of the transport in each occupant closeup,
> so you can navigate quickly up and down in the stack. The frontmost closeup
> automatically becomes the current unit for commands etc.

Here's a rather crazy possible solution: Would it be possible to use
TclTk *and* another toolkit, such as GTK+, simultaneously?  That might
allow us to not only use GTK+ to implement new features, but also to
"phase out" the TclTk code (since nobody seems to like TclTk anymore)
and replace it with GTK+ code.

If I remember correctly, a few people have complained that it is often
difficult to debug TclTk code, various quirks make it difficult to
create certain keybindings, and it's just plain ugly.  While GTK+ would
still result in a game that looks like an Office app, it should be
easier to debug (no useless "Error reading tcl" errors) and more
versatile.  Not to mention that GTK+ contains everything you need to
make an application accessible to people with disabilities (might be fun
just to make Xconq able to respond appropriately if you were to bark
orders at it via a speech recognition engine).  And I don't think it
would be a step backward from the existing TclTk interface if the
interface was re-implemented in GTK+ and ended up looking like an Office
app.

I've put together an example of what a "close-up" dialog might look like
if implemented in GTK+, and I've posted it here:

http://homepage.mac.com/lmpeters/cell-closeup.png

(The icons are generic icons from the GTK+/GNOME library.  Just pretend
that they look like unit images from the Standard game.)

The situation illustrated here is the city Sausalito and a fighter
flying overhead.  Within the city are infantry, armor, a bomber, a
battleship, and a carrier.  Furthermore, within the carrier are three
fighters and another bomber.  This would be almost completely
unmanageable without a close-up dialog like this one.

I envision the closeup dialog as something you could summon with a
special mouse click (perhaps Alt-click or click with the middle button),
and then use any time you need to click on a unit (choosing a unit to
give orders to, board, attack, fire at, etc.).

> Porting this to the tcltk interface is something that I have wanted to do
> for a long time, but it is easier said than done. The main problem is the
> lack of support for floating windows in tcltk.

I'll add this to the list of reason not to like TclTk.  I guess you
could implement a close-up dialog like I illustrated above in TclTk, but
it sounds like it would be more work.

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

It is contrary to reasoning to say that there is a vacuum or space in
which there is absolutely nothing.
		-- Descartes

Re: Three thoughts

[Jim Kingdon]

> http://homepage.mac.com/lmpeters/cell-closeup.png

Although I think people should certainly be encouraged to experiment,
and maybe if I tried the Mac interface I'd change my mind, but I do
want to register non-enthusiasm for closeup dialogs.

Sure, you can come up with a way to show what is in a cell which is
deeply nested.  But is it visually appealing?  Does it mean you are
always having to click or hit a key to expand/unexpand a unit?  Do you
have to go up and town the tree of occupancy just to find what you
want to know?

If the solution isn't a fancy "occupants navigator", then perhaps the
solution is just change the game designs to reduce the problem.  For
example, one reason that the standard game only allows 16 units in one
cell is to make them easy to draw and see.  The standard game is
lacking any such mitigation for the "infantry in a bomber in a carrier
in a town" problem, however.  I wonder what it would do to playability
if a town/city could only hold 8 units?

Re: Three thoughts

[Elijah Meeks]

> If the solution isn't a fancy "occupants navigator",
> then perhaps the
> solution is just change the game designs to reduce
> the problem.  For
> example, one reason that the standard game only
> allows 16 units in one
> cell is to make them easy to draw and see.  The
> standard game is
> lacking any such mitigation for the "infantry in a
> bomber in a carrier
> in a town" problem, however.  I wonder what it would
> do to playability
> if a town/city could only hold 8 units?

I generally agree with this, and it's why I've fallen
into using a four unit limit per cell with my designs.
 Still, even a game like civilization uses a seperate
status window for cities, which near the end of the
game would have dozens of what XConq considers units. 
So, if a designer wants to create a civ-like game
that's visually appealing, we need some way to hide
the ancillary units, which in general aren't combat
units but rather units that somehow affect a 'mother'
unit (Improvements in Civ/MOO/MOM, items in the case
of fantasy/RPG-style games).

Speaking of items, I'd like to add random piles of
gold to Opal.  I can do this in a way by making
advanced 'Random Pile of Gold' units with an initial
supply of 'gold' material that gives to the treasury,
so that when a player captures the unit, the gold is
tossed into their treasury (The independant side
defaults to not using the treasury, so the gold isn't
looted by greedy iplayers).  This is, however, a
cumbersome procedure, and I was wondering as to the
feasibility of an capture-gives-material table.




		
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

Re: Three thoughts

[Eric McDonald]

On Sun, 22 Aug 2004, Elijah Meeks wrote:

> looted by greedy iplayers).  This is, however, a
> cumbersome procedure, and I was wondering as to the
> feasibility of an capture-gives-material table.

Almost anything is possible. The question is when it will actually 
get done.

Wrt this table, were you thinking in terms of specific quantities 
of certain materials being yielded up by the captured unit, or 
percentages of all materials being yielded up depending on who 
does the capturing and who is being captured?

Eric

Re: Three thoughts

[Elijah Meeks]

> Wrt this table, were you thinking in terms of
> specific quantities 
> of certain materials being yielded up by the
> captured unit, or 
> percentages of all materials being yielded up
> depending on who 
> does the capturing and who is being captured?

Simply material and quantity if the unit is captured. 
What I'll do is set a seed unit so that the player
destroys it and captures its wrecked-type, like so:

(unit gold-chest (image "ang-chest-iron-small")
(wrecked-type goldpile))

(table material-if-captured
   (goldpile gold 50)
)

This way I can set a timer on the pile o' gold so that
it evaporates after capture, to keep the map clean.  I
suppose I'd have to set its capture on the
'independent-capture-chance' table, so that it can
only be captured when independent, because otherwise
you run the risk of other sides capturing the pile of
gold (And thus gaining free materials) before it
evaporates.

The better option may be a 'material-looted-chance'
(or some, better-named table) that sets the
possibility of gaining material from a unit you've
destroyed.  In this case, I'd simply set the goldpile
unit to have x gold (Or an initial-supply, for random
setups) and the table to:

(table material-looted-chance
   (goldpile gold 100)
)

I don't know which would be easier.

Elijah


		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 

Unit-Image Bug

[Elijah Meeks]

Just downloaded Hans' latest build and I've noticed
that units no longer change their image when they
auto-upgrade into a new unit or wreck-type into a new
unit.  I have a feeling this is related to Hans' new
code to give individual units their own images.

Elijah


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

Re: Unit-Image Bug

[Eric McDonald]

Elijah Meeks wrote:

> Just downloaded Hans' latest build and I've noticed
> that units no longer change their image when they
> auto-upgrade into a new unit or wreck-type into a new
> unit.  I have a feeling this is related to Hans' new
> code to give individual units their own images.

I put a fix for that bug into the CVS repository last Saturday.

Eric

Re: Three thoughts

[Eric McDonald]

On Sun, 22 Aug 2004, Lincoln Peters wrote:

> Here's a rather crazy possible solution: Would it be possible to use
> TclTk *and* another toolkit, such as GTK+, simultaneously?  That might
> allow us to not only use GTK+ to implement new features, but also to
> "phase out" the TclTk code (since nobody seems to like TclTk anymore)
> and replace it with GTK+ code.

I think it would be possible, but probably would be rather 
hackish. Both Tk and GTK+ have their own window hierarchies, and 
that would require a fair amount of bookkeeping on Xconq's part, 
to make sure that focus gets restored after a window closes, 
etc....

Also, the "widget styles" of the two toolkits are a bit different 
and so the resulting UI would end up looking like Frankenstein, I 
think.

Your idea does have the merits you suggest, though. 
Interesting....

> The situation illustrated here is the city Sausalito and a fighter
> flying overhead.  Within the city are infantry, armor, a bomber, a
> battleship, and a carrier.  

If the ship types corresponded to U.S. Navy naming conventions, I 
think you would have two carriers and zero battleships. Not that 
it really matters....

The closup view window that you propose is an interesting idea, 
but I agree that we should try to avoid extra work to fish out an 
unit, if possible (as someone mentioned in a later message in 
this thread).  One idea that I thought of would be magnify the 
icon of an unit if the cursor passes over it in a manner similar 
to that little bar of icons at the bottom of the MacOS X 
interface (IIRC). Or maybe that magnification should only happen 
when a modifier key is being pressed when the mouse passes over 
the unit, so that the magnified view does not normally get in the 
way of other units in the same hex (and possibly surrounding 
hexes).

Eric

Re: Three thoughts

[Lincoln Peters]

On Mon, 2004-08-23 at 09:40, Eric McDonald wrote:
> On Sun, 22 Aug 2004, Lincoln Peters wrote:
> 
> > Here's a rather crazy possible solution: Would it be possible to use
> > TclTk *and* another toolkit, such as GTK+, simultaneously?  That might
> > allow us to not only use GTK+ to implement new features, but also to
> > "phase out" the TclTk code (since nobody seems to like TclTk anymore)
> > and replace it with GTK+ code.
> 
> I think it would be possible, but probably would be rather 
> hackish. Both Tk and GTK+ have their own window hierarchies, and 
> that would require a fair amount of bookkeeping on Xconq's part, 
> to make sure that focus gets restored after a window closes, 
> etc....
> 
> Also, the "widget styles" of the two toolkits are a bit different 
> and so the resulting UI would end up looking like Frankenstein, I 
> think.

I'm not familiar with TclTk's (Tk's?) "widget style".  Does it work
based on a grid, where widgets are positioned by coordinates rather than
through the use of containers (horizontal and vertical boxes, tables,
etc.; as per GTK+)?  From the references I can find on the Web, it looks
like Tk can use containers in a manner similar to GTK+, but it has only
had that feature since version 8.4.

Would Xconq look any worse if it used Tk code and GTK+ code
simultaneously than it looks now?  As I see it right now, we have three
possibilities:

Current TclTk interface:	ugly and unintuitive
Proposed GTK+ interface:	more intuitive than TclTk, but would look like
an Office app
In-development SDL interface:	looks cool, more intuitive than TclTk, but
more work to develop than the first two

Over the long term, it might be worthwhile to try to develop a common UI
based on SDL and GTK+/GNOME, since SDL could provide a more game-like
(i.e. less Office-app-like) interface and GTK+ could provide a bunch of
features where it doesn't particularly matter if they look like they
belong in an Office app.  For example, I think it would be fairly simple
to implement the Xconq "Welcome" screen using a GNOME Druid.

> 
> Your idea does have the merits you suggest, though. 
> Interesting....

There might be a few hardcore strategy gamers who would appreciate being
able to use Mono to link Xconq to a spreadsheet application and do some
intensive data analysis on games like advances.g (e.g. track production,
technology, offensive/defensive power, over time).  Of course, there are
a *lot* of other things to deal with before worrying about spreadsheet
applications!

Perhaps it would be possible to avoid the "hackish" aspect of using
TclTk and GTK+ simultaneously by completely switching from TclTk to GTK+
in one fell swoop, but that idea is probably even more scary for most
developers.  The closest I'd expect us to reasonably come to that
scenario would be to implement GTK+ as a separate interface and then
label the TclTk interface as a "legacy" interface.

> 
> > The situation illustrated here is the city Sausalito and a fighter
> > flying overhead.  Within the city are infantry, armor, a bomber, a
> > battleship, and a carrier.  
> 
> If the ship types corresponded to U.S. Navy naming conventions, I 
> think you would have two carriers and zero battleships. Not that 
> it really matters....

Honestly, I just used the names of the first two ships from "Star Trek"
that I could think of.  Last night, a local TV station ran "Star Trek
IV: The Voyage Home"

> 
> The closup view window that you propose is an interesting idea, 
> but I agree that we should try to avoid extra work to fish out an 
> unit, if possible (as someone mentioned in a later message in 
> this thread).  One idea that I thought of would be magnify the 
> icon of an unit if the cursor passes over it in a manner similar 
> to that little bar of icons at the bottom of the MacOS X 
> interface (IIRC). Or maybe that magnification should only happen 
> when a modifier key is being pressed when the mouse passes over 
> the unit, so that the magnified view does not normally get in the 
> way of other units in the same hex (and possibly surrounding 
> hexes).

Magnification as per the MacOS X dock would be a possibility, but an
awkward one.  Unless you have an intuitive way for the user to indicate
when to zoom and when not to zoom, the user might be rather surprised
when the mouse hovers over a cell and one unit suddenly gets bigger
while the others get smaller.  Of course, if you don't want to shrink
the unit images, you'd probably have to shrink the neighboring hexes...

In conclusion, this kind of zooming is probably more work than you had
in mind.

Another possibility might be to make the close-up dialog be a separate
window that displays each unit in the same arrangement as on the main
screen, but it draws every unit in the cell at the same size.  Something
like:

http://homepage.mac.com/lmpeters/cell_closeup2.png

(As before, I'm limited to the GTK+/GNOME stock icons, none of which
look like an Xconq unit, unless I write some actual UI code.)

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

"Conversion, fastidious Goddess, loves blood better than brick, and feasts
most subtly on the human will."
-- Virginia Woolf, "Mrs. Dalloway"

Re: Three thoughts

[Eric McDonald]

Lincoln Peters wrote:

>>Also, the "widget styles" of the two toolkits are a bit different 
>>and so the resulting UI would end up looking like Frankenstein, I 
>>think.
> 
> I'm not familiar with TclTk's (Tk's?) "widget style".  

You're reading too much into what I meant by "widget style" (which was 
in parentheses for a reason). Perhaps another way to put it is simply, 
look-n-feel.

> Over the long term, it might be worthwhile to try to develop a common UI
> based on SDL and GTK+/GNOME, since SDL could provide a more game-like
> (i.e. less Office-app-like) interface and GTK+ could provide a bunch of
> features where it doesn't particularly matter if they look like they
> belong in an Office app.  

Well, it was not too long ago that I revived this suggestion (having 
first made it during the Great Flame War of November 2003), and some of 
those who read it infused assumptions into its implications, such as 
that I would recommend using GTK components without "redecorating" them 
to fit their environment. It took a while to untangle that thread, and I 
would rather not go there again any time soon.

> There might be a few hardcore strategy gamers who would appreciate being
> able to use Mono to link Xconq to a spreadsheet application and do some
> intensive data analysis on games like advances.g (e.g. track production,
> technology, offensive/defensive power, over time). 

These are some of the benefits that crossed my mind as well when we last 
discussed this (last year).

> Perhaps it would be possible to avoid the "hackish" aspect of using
> TclTk and GTK+ simultaneously by completely switching from TclTk to GTK+
> in one fell swoop, but that idea is probably even more scary for most
> developers.  The closest I'd expect us to reasonably come to that
> scenario would be to implement GTK+ as a separate interface and then
> label the TclTk interface as a "legacy" interface.

I have thought about this on and off in the past few weeks. After 
reviewing the SDL API and GTK API, and looking at the existing SDL code, 
I think that I am going to give SDL a try first. (After reading portions 
of both API's yesterday, I actually did sit down and fix some bugs in 
the SDL app.)

>>The closup view window that you propose is an interesting idea, 
>>but I agree that we should try to avoid extra work to fish out an 
>>unit, if possible (as someone mentioned in a later message in 
>>this thread).  One idea that I thought of would be magnify the 
>>icon of an unit if the cursor passes over it in a manner similar 
>>to that little bar of icons at the bottom of the MacOS X 
>>interface (IIRC). Or maybe that magnification should only happen 
>>when a modifier key is being pressed when the mouse passes over 
>>the unit, so that the magnified view does not normally get in the 
>>way of other units in the same hex (and possibly surrounding 
>>hexes).
> 
> 
> Unless you have an intuitive way for the user to indicate
> when to zoom and when not to zoom, 

See my suggestion above about pressing a modifier key.

>the user might be rather surprised
> when the mouse hovers over a cell and one unit suddenly gets bigger
> while the others get smaller.  

Well, I never suggested that other get smaller....
Does the MacOS X icon bar have that property?

I was just thinking in terms of making one image larger than the others, 
and then partially or totally obscuring its neighbors for the duration 
of the magnification.

> In conclusion, this kind of zooming is probably more work than you had
> in mind.

I didn't have any amount of work in mind. It was just a suggestion. But, 
now that you mention it, I am not sure that it would be so much work.

> Another possibility might be to make the close-up dialog be a separate
> window that displays each unit in the same arrangement as on the main
> screen, but it draws every unit in the cell at the same size.  

I think that is what Elijah and Matthew were suggesting (or something 
similar), and it is certainly what I had in mind until the "icon 
magnification" idea occurred to me.

> http://homepage.mac.com/lmpeters/cell_closeup2.png

404.

Eric

Re: Three thoughts

[Lincoln Peters]

On Mon, 2004-08-23 at 18:42, Eric McDonald wrote:
> Lincoln Peters wrote:
> 
> > 
> > I'm not familiar with TclTk's (Tk's?) "widget style".  
> 
> You're reading too much into what I meant by "widget style" (which was 
> in parentheses for a reason). Perhaps another way to put it is simply, 
> look-n-feel.

Okay.  I can see quite clearly how TclTk and GTK+ differ in look-n-feel.

> 
> > Over the long term, it might be worthwhile to try to develop a common UI
> > based on SDL and GTK+/GNOME, since SDL could provide a more game-like
> > (i.e. less Office-app-like) interface and GTK+ could provide a bunch of
> > features where it doesn't particularly matter if they look like they
> > belong in an Office app.  
> 
> Well, it was not too long ago that I revived this suggestion (having 
> first made it during the Great Flame War of November 2003), and some of 
> those who read it infused assumptions into its implications, such as 
> that I would recommend using GTK components without "redecorating" them 
> to fit their environment. It took a while to untangle that thread, and I 
> would rather not go there again any time soon.

Understood.  I suppose that I started thinking about this stuff again
after I saw a computer at Novell's booth at LinuxWorld where they were
showing off what you can do with Mono (Novell merged with Ximian a while
ago).

> >>The closup view window that you propose is an interesting idea, 
> >>but I agree that we should try to avoid extra work to fish out an 
> >>unit, if possible (as someone mentioned in a later message in 
> >>this thread).  One idea that I thought of would be magnify the 
> >>icon of an unit if the cursor passes over it in a manner similar 
> >>to that little bar of icons at the bottom of the MacOS X 
> >>interface (IIRC). Or maybe that magnification should only happen 
> >>when a modifier key is being pressed when the mouse passes over 
> >>the unit, so that the magnified view does not normally get in the 
> >>way of other units in the same hex (and possibly surrounding 
> >>hexes).
> > 
> > 
> > Unless you have an intuitive way for the user to indicate
> > when to zoom and when not to zoom, 
> 
> See my suggestion above about pressing a modifier key.

Somehow I didn't see the suggestion about a modifier key earlier.  Maybe
I've been staring at my computer screen too long.

> 
> >the user might be rather surprised
> > when the mouse hovers over a cell and one unit suddenly gets bigger
> > while the others get smaller.  
> 
> Well, I never suggested that other get smaller....
> Does the MacOS X icon bar have that property?

No, but I imagine that if the size of the cell doesn't change, you'd
have to shrink the other units to accommodate the enlarged unit image
unless you were willing to obscure units by placing them underneath the
enlarged unit image (which it looks like was what you have in mind).

I guess that you could enlarge the entire grid so that every unit image
fits on the screen at a reasonable size, but that could easily result in
the most unmanageable map ever.  Although I suppose that if there was an
easy way to toggle between that view and the "normal" view, the only
disadvantage would be the CPU load (which wouldn't be too bad except on
old hardware).

> 
> I was just thinking in terms of making one image larger than the others, 
> and then partially or totally obscuring its neighbors for the duration 
> of the magnification.

I noticed that the SDL interface blows up the selected unit to fill the
entire cell even if other units occupy the cell.  I find it to be rather
awkward, as it makes it hard to reach units underneath it (I often can't
figure out where to click to select another unit in the same cell unless
I de-select the current unit first.  And sometimes it looks weird when
several tiny unit images appear underneath a big unit image.

> 
> > In conclusion, this kind of zooming is probably more work than you had
> > in mind.
> 
> I didn't have any amount of work in mind. It was just a suggestion. But, 
> now that you mention it, I am not sure that it would be so much work.

Actually, it does sound like the simplest solution.

> 
> > Another possibility might be to make the close-up dialog be a separate
> > window that displays each unit in the same arrangement as on the main
> > screen, but it draws every unit in the cell at the same size.  
> 
> I think that is what Elijah and Matthew were suggesting (or something 
> similar), and it is certainly what I had in mind until the "icon 
> magnification" idea occurred to me.

I'm not sure which solution would work better.  It might be necessary to
implement both solutions and see which holds up better in practice.

Maybe it will help to look at the corrected URL, below.

> 
> > http://homepage.mac.com/lmpeters/cell_closeup2.png
> 
> 404.

Sorry; typo.

http://homepage.mac.com/lmpeters/cell-closeup2.png

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

It's a very *__\b\bUN*lucky week in which to be took dead.
		-- Churchy La Femme

Re: Three thoughts

[Eric McDonald]

On Mon, 23 Aug 2004, Lincoln Peters wrote:

> > Well, I never suggested that other get smaller....
> > Does the MacOS X icon bar have that property?
> 
> No, but I imagine that if the size of the cell doesn't change, you'd
> have to shrink the other units to accommodate the enlarged unit image
> unless you were willing to obscure units by placing them underneath the
> enlarged unit image (which it looks like was what you have in mind).

Right.

> I noticed that the SDL interface blows up the selected unit to fill the
> entire cell even if other units occupy the cell.  I find it to be rather
> awkward, 

As do I. I think a more traditional selection rectangle might be 
desirable. If one wants to see a full-sized "portrait" of the 
selected unit, it can be provided in the unit information panel.

> I de-select the current unit first.  And sometimes it looks weird when
> several tiny unit images appear underneath a big unit image.

Agreed. At first I thought I was witnessing a bug, until I 
realized what was going on.

> I'm not sure which solution would work better.  It might be necessary to
> implement both solutions and see which holds up better in practice.

That might be not be a bad idea. But, I am not going to volunteer 
to write both solutions.

> http://homepage.mac.com/lmpeters/cell-closeup2.png

Interesting....

Eric

Re: Three thoughts

[Jim Kingdon]

> I noticed that the SDL interface blows up the selected unit to fill the
> entire cell even if other units occupy the cell.  I find it to be rather
> awkward, 

Well, I haven't actually played it, but I like it as an idea.

It lets you see the details on each unit (by selecting them in turn),
without the extra step of popping up a window.

Re: Three thoughts

[Lincoln Peters]

On Tue, 2004-08-24 at 21:58, Jim Kingdon wrote:
> > I noticed that the SDL interface blows up the selected unit to fill the
> > entire cell even if other units occupy the cell.  I find it to be rather
> > awkward, 
> 
> Well, I haven't actually played it, but I like it as an idea.

The problem is that it doesn't do anything about the units that are
still drawn underneath the selected unit.  Unless those units are either
hidden or otherwise obscured (maybe by making them semi-transparent), it
really does look ugly when a lot of units, some overlapping, are in one
cell.

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

To Perl, or not to Perl, that is the kvetching.
             -- Larry Wall in <199801200310.TAA11670@wall.org>

Re: Three thoughts

[Jim Kingdon]

> The problem is that it doesn't do anything about the units that are
> still drawn underneath the selected unit.  Unless those units are either
> hidden or otherwise obscured (maybe by making them semi-transparent), it
> really does look ugly when a lot of units, some overlapping, are in one
> cell.

Ah, OK.  I think the job may have been half-done.

If I understood the design correctly, the idea was that the
non-selected units would become very small and be arranged around the
outside of the cell.  So to try to render it in ASCII art:

   i  i  b  f

   c  IIIII f
        I
   c    I   f
        I
   d  IIIII f

   d  d  f  f

where the big "I" is the selected unit, and the "i", "i", etc are the
non-selected units.

At least, I think that is one of the ideas that Stan had been playing
with.

Re: Three thoughts

[Eric McDonald]

On Wed, 25 Aug 2004, Jim Kingdon wrote:

> If I understood the design correctly, the idea was that the
> non-selected units would become very small and be arranged around the
> outside of the cell.  

When you say around the outside of the cell, do you 
still mean inside the cell perimeter or outside of it? I think 
that outside the cell perimeter could create quite a bit of 
confusion about which cell an unit is actually in.

>So to try to render it in ASCII art:

Couldn't draw a hexagon? ;-)

> where the big "I" is the selected unit, and the "i", "i", etc are the
> non-selected units.

I can think of some potential issues with this:
(1) Scaling images to non-standard sizes would likely be 
necessary to accomodate the suggested scheme.
(2) In the case of units that are using large icons, if one is 
blown up to normal size (44x44), then there is no room left in the 
cell (assuming that you mean to place the others inside the cell 
perimeter). So, either one would need to scale to a non-standard 
size or else half-size (22x22). In the case that only 3 other 
units were in the cell to start with, there would be no gain; 
rather, the selected unit would be centered in the cell, and 
the other 3 images would be scaled down. I see information being 
lost in this case.
(3) Scaling down the images of other units would likely degrade 
their identifiability as certain types, which would cause problems 
(or, at least, squinting) if a player went to select another unit 
in the same cell.

(All 3 of the above arguments also apply to why I don't think 
shrinking neighboring units when dealing with unit closeups is a 
good idea either.)

I still think that putting a "portrait" of the selected unit in 
the unit info window would be better. But, that's just my 
opinion....

Eric

Re: Three thoughts

[Jim Kingdon]

> When you say around the outside of the cell, do you 
> still mean inside the cell perimeter or outside of it?

Probably inside, although I don't know whether the feature was ever
thought through in that much detail.

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

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

> I still think that putting a "portrait" of the selected unit in 
> the unit info window would be better. But, that's just my 
> opinion....

Well, yes, the unit info window is useful in tcltk as it stands now,
and making it more graphical/informative is certainly one way to
approach this problem.

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.  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.  What
if the top half were for the selected unit and the bottom half were
for the others?  With scaling and drawing otherwise the same as now.

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.