colossus-developers Mailing List for Colossus (Page 226)

Hello,

would you be interested in a new website? I could create a simple 
website using my program XWeb (http://xweb.sf.net), which is IMHO pretty 
easy to use once it is set up. The input is typically XHTML, so there 
would be not much difference. Ans since I am going to update/create some 
websites in the next days anyway I could hack a quick version for 
Colossus in less than an hour. Just tell me your ideas for structure and 
content and I give it a shot.

  Peter

Hello again,

sorry for starting ranting so early, but after trying to find the 
control flow from a resolve engagement click up to the end of the battle 
I encountered severe problems due to the design of the code. I really 
didn't expect that I had to check the flow through a large number of 
indirections, including _through_ dialogs. This is code that screams for 
a refactoring session IMHO.

Just as example the control flow for a fight from 
MasterBoard::actOnLegion, indented to show the callstack:
MasterBoard::actOnLegion
  Client::doFight
    Client::engage
      Server::engage
        Game::engage
          Game::engage2
            Server::askConcede
              Client::askConcede
                Concede::concede

Then via action listener:
                  Client::answerConcede
                    Server::doNotConcede
                      Game::doNotConcede
                        Game::engage3
                          Server::twoNegogiate
                            Client::askNegogiate

Then we get a Negogiate object where we pass the action listener again 
and get to:
                              Negotiate::cleanup
                                Client::negotiateCallback
                                  Client::fight
                                    Server::fight
                                      Game::fight

which finally starts the battle using a method called Battle::init which 
in fact does the whole battle. I don't really want to continue this 
until it gets back, I assume the Battle object calls most of the above 
ones again. Since all calls to other objects are at the tail of the 
methods there won't be much interesting to see.

What are problems here? Firstly this is not OO at all -- there is no 
encapsulation, all objects are dependend on all others. Even the dialogs 
know about the higher level objects and instead of returning a result 
value which can be evaluated on a higher level they call objects they 
shouldn't know about. This results not only in code that is damn hard to 
read (who expect a fight to happen in Client::askConcede or 
Negotiate::cleanup?), but also hard to change since easy to break. The 
delegation methods through Client and Server to Game only make the 
callstack deeper but don't fix the problem.

How should it look like? I am not yet sure since I don't understand the 
distinction of Server and Game. My first idea was that Server should be 
the controller and Game the model, but actually most of the interesting 
stuff is controlled in Game, not Server.  If we assume Server is the 
controller, I would think of something like this:

MasterBoard::actOnLegion
  Client::resolveEngagement
    Server::resolveEngagement
      Client::askConcede
        Concede::concede (returns some pseudo-enum)
      Client::negotiate
        Negotiate::negotiate (communicates with other client, returns 
pseudo-enum)
      BattleServer::fight
(calls BattleClients and returns BattleResult)
      Game::evaluateBattleResult

Note that most steps are handled sequentially in 
Server::resolveEngagement by calling other parts of the code, which 
turns this class into the main controller. The Client initiates the 
process with its first message but afterwards the Server has full 
control. In addition the code in Server::resolveEngagement will look 
very similar to the list above, it just needs some if-statements to 
evaluate the results of the calls to the other parts. The Game is only 
involved once the BattleServer has determined the result.

One aspect I didn't address is the problem that the BattleServer needs 
to ask the Server again when an angel could be called or a creature 
could be recruited. But I think this gives the general idea, details 
could be fixed later.

I highly recommend doing this refactoring ASAP. Otherwise I would expect 
the code to get harder and harder to maintain, devouring far more 
ressources than you would invest into a refactoring (which is probably 
not hard at all).

Don't get this wrong: if I would think the code is hopeless I wouldn't 
write this ;-) But I truly believe that you have a problem there, so I 
risk annoying someone or ending like Cassandra.

HTH,
    Peter

Peter Becker wrote:

>> Yes.  Dismissing all recruit chits is trivial (unfortunately 
>> finer-grained dismissal has not been coded yet) -- I will add a menu 
>> item + hotkey for this today.  We also need two options to turn the 
>> chits for past and potential recruits off completely. 
> 
> 
> I played some games today and I really miss the ability to check all 
> stack sizes in one view. It'd be nice to have this hotkey.

Done.  I'll check it in after more testing.

>> I think putting the legion display in the lower left corner of the 
>> masterboard makes sense, if there's room.

There isn't room.  It'll have to be a dialog.

> I wouldn't start with big patches anyway. Since you took my proposals 
> ;-) 

You're welcome to the improved ShowLegion dialog if you want it.  I 
thought I was being nice by offering to do it, since it had been in my 
list for months.  :->

The dialog to show all legions for a player is all yours.

> I'll try two other small things: (a) giving the option to stop the 
> game after a loss (you can't even do anything else without killing it 
> since battlefields keep popping up) and (b) not asking if you want to
> quit an already finished game. Hopefully both pretty simple, I'll just try.

a is easy, but not quite trivial because of the timer we use to control 
phase advances.  (There are several bugs related to timers continuing to 
throw events after a new game / load game, that could be caught by using 
another flag in the methods called by timers.)

b is trivial -- there's already a "game over" flag in Game.  But you'll 
have to touch four classes.
> Some other issues I noticed:
> - the caretakers stack is broken, it shows always the maximum value (as 
> does the muster dialog)

I broke this last night when caching creature counts on the client side, 
and noted it as broken in the checkin comment.  Still working on it.

> - the dialog for calling an angel shows multiple pairs of angels and 
> archangels

I hadn't noticed this one.  Possibly related to Romain's recent 
generalization of the angel code for variants?

> - sometimes the recruit chits keep staying, I guess it is related to a 
> titans death

I know they don't get cleared when a legion is wounded but not killed. 
Will fix.

-- 
David Ripton   dr...@wi...

Hello,

shall I set up something like this for the project:
   http://meganesia.int.gu.edu.au/~pbecker/xweb/sourcedoc/main.html

This is generated daily from CVS and it is highly configurable, up to 
including hyperlinked source in the documentation of the methods. 
Unfortunately my current internet access doesn't allow me using 
something like this easily (I'll use a local copy), but I could set it 
up quickly if someone is interested to use or offer it online.

Check out doxygen anyway: first time the list of options is a bit 
overwhelming, but they are well documented and powerful to use. The 
project page is linked from the logo at the bottom of the front page.

  Peter

Hello,

first patches, not for the code but for the build-file. I'd recommend 
using this to create a separate directory structure for classes:

----snip----
Index: build.xml
===================================================================
RCS file: /cvsroot/colossus/Colossus/build.xml,v
retrieving revision 1.25
diff -r1.25 build.xml
39a40
 >       <property name="CLASSDIR" value="./classes"/>
40a42
 >       <mkdir dir="${CLASSDIR}"/>
116c118
<                 includes="**/*.java"
---
 >                 includes="**/*.java" destdir="./classes"
----snap----

Then you can use this as ".cvsignore" file:

----snip----
classes
Colossus-*.cfg
version
Colossus.jar
----snap----

which removes most of the unknown files CVS complains about. I am not 
sure which would be the best way to handle the ones that are left: the 
JavaCC results. The brute-force approach would be a ".cvsignore" in the 
net/sourceforge/colossus/parsers directory enlisting all dependend 
files. Nicer would be creating the dependend files somewhere specific so 
they can be distinguished as group but I don't know if this is possible.

The reason I recommend getting rid of the question marks is that some 
people (e.g. me) tend to forget to add before commit. Typically this can 
be noticed if you do an update before the commit to check the commit 
will do what you expect (which is useful anyway), but it is far easier 
to check if there is any question mark than to check them all -- at 
least I am to lazy to do the latter ;-)

HTH,
  Peter

David Ripton wrote:

> Peter Becker wrote:
>
>> The key would be ok for me. At the moment I first check for the 
>> recruits, then I want to check for splits which needs not only the 
>> information on the size of my own legions, but also of the size of 
>> surrounding ones. This leads to a lot right clicks I wouldn't have 
>> needed before.
>
>
> Yes.  Dismissing all recruit chits is trivial (unfortunately 
> finer-grained dismissal has not been coded yet) -- I will add a menu 
> item + hotkey for this today.  We also need two options to turn the 
> chits for past and potential recruits off completely. 

I played some games today and I really miss the ability to check all 
stack sizes in one view. It'd be nice to have this hotkey.

>> Apropos right-clicks: two possible (and probably simple to implement) 
>> features I came up with while playing:
>> - the known content of legions could be shown in a corner or a 
>> floating window as a mouse-over effect
>
>
> Been in the to-do list for a while.  Requires adding a 
> MouseMotionListener to MasterBoard, seeing whenever the cursor moves 
> over a Marker (the topmost one if two overlap -- the marker list in 
> Client is already stored in z-order so this is just a matter of 
> traversing it in the right direction), and then calling a slightly 
> changed version of ShowLegion.
>
> ShowLegion should probably extend JPanel not JDialog, even if we 
> decide to put it in its own window.  That way if we change our mind 
> and dock it later, or even support both behaviors, very little code 
> changes.
>
> I think putting the legion display in the lower left corner of the 
> masterboard makes sense, if there's room.  The screen is already 
> pretty crowded, especially on low-res displays, so I don't want to 
> inflict more windows on people if I can help it.  Plus there are 
> problems with some Unix Window managers, and a Windows JDK bug, that 
> sometimes keep dialogs from showing up where you want them. 

My battlefields always appear below the masterboard (KWM). My 
assumptions judging from the flicker is that they appear on top, then 
the superflous dialog for making a deal instead of fighting appears, 
which raises the masterboard again before disappearing. The result is 
not only the wrong order, but that you need two klicks/hotkeys to fix it 
since the battlefield has the proper focus, so you need to give the 
masterboard the focus first (unless the titlebar of the battlefield is 
clickable).

The screen size is a problem, esp. since there seems to be some troubles 
with scaling/scrolling. My laptop does 1024x768 which is fine for the 
normal game plus caretaker stack and status window, but the extended 
variants are more or less a no-go. I guess I need a bigger screen ;-) 
Actually I would probably put the legion window between caretaker stack 
and status window, not on the masterboard.

> I may take a shot at adding this tonight.  Coding it isn't that much 
> harder than describing it. 

Coding is just a way of describing it a computer understands :-)

Although I appreciate your effort in answering my mails I wouldn't mind 
sparse answers if you feel distracted from your job ;-)

>> - a window with a list of your own armies would be nice
>
>
> Easy enough, but I don't see the need, since they're easily visible on 
> the board.  As long as it's optional then there's no problem adding it 
> -- I would just turn it off when I play.  If this dialog is view-only 
> then implementing it is simple. 

Having just the overview of the armies and if they can do further 
actions in this round (split/move/fight/muster) would be useful IMHO -- 
if you have the screen real estate left, that is. In some way there 
should be a connection from this dialog to the masterboard, e.g. 
highlighting of the army in the other window on mouseover and maybe 
clicking on the army in the overview should cause the appropriate action 
for the round. But the pure view would be a start.

> However, once you start adding the ability to actually control stuff 
> from this dialog, it becomes a bit of a pain.  The view and controller 
> are somewhat intertwined in MasterBoard and its inner classes.  We'd 
> have to move some of the event stuff out into another public class, 
> add parameters for stuff that's currently accessed directly, etc.  
> Splitting the view and controller classes is probably a good idea in 
> any case, but  not a high priority for me right now. 

Yes, I know this problem. Since the GUI library does half of the 
controller stuff you always miss doing your own.  How I miss Qts signals 
and slots where you typically don't need any controller at all :-(

>> What is your approach of synchronizing work? With all the updates you 
>> already do I might easily cause conflicts if I go for one of these 
>> features -- does it make sense to try anyway and then to send a patch 
>> to you / the dev list? Changes would probably be small in existing 
>> files...
>
>
> There have never been more than two people actively working on the 
> project at once, so synchronization has not been a big issue.  The big 
> thing is synching often so that we don't have huge integration problems.
>
> Testing in general is the bigger problem.  I've been thinking about it 
> a lot lately.
>
> Anyway, just send patches at first.  To the dev list if they're 
> reasonably small -- preferably dumped on a ftp/web site with a URL to 
> the list if they're big. 

I wouldn't start with big patches anyway. Since you took my proposals 
;-) I'll try two other small things: (a) giving the option to stop the 
game after a loss (you can't even do anything else without killing it 
since battlefields keep popping up) and (b) not asking if you want to 
quit an already finished game. Hopefully both pretty simple, I'll just try.

Some other issues I noticed:
- the caretakers stack is broken, it shows always the maximum value (as 
does the muster dialog)
- the dialog for calling an angel shows multiple pairs of angels and 
archangels
- sometimes the recruit chits keep staying, I guess it is related to a 
titans death

   Peter

Peter Becker wrote:

> The key would be ok for me. At the moment I first check for the 
> recruits, then I want to check for splits which needs not only the 
> information on the size of my own legions, but also of the size of 
> surrounding ones. This leads to a lot right clicks I wouldn't have 
> needed before.

Yes.  Dismissing all recruit chits is trivial (unfortunately 
finer-grained dismissal has not been coded yet) -- I will add a menu 
item + hotkey for this today.  We also need two options to turn the 
chits for past and potential recruits off completely.

> Apropos right-clicks: two possible (and probably simple to implement) 
> features I came up with while playing:
> - the known content of legions could be shown in a corner or a floating 
> window as a mouse-over effect

Been in the to-do list for a while.  Requires adding a 
MouseMotionListener to MasterBoard, seeing whenever the cursor moves 
over a Marker (the topmost one if two overlap -- the marker list in 
Client is already stored in z-order so this is just a matter of 
traversing it in the right direction), and then calling a slightly 
changed version of ShowLegion.

ShowLegion should probably extend JPanel not JDialog, even if we decide 
to put it in its own window.  That way if we change our mind and dock it 
later, or even support both behaviors, very little code changes.

I think putting the legion display in the lower left corner of the 
masterboard makes sense, if there's room.  The screen is already pretty 
crowded, especially on low-res displays, so I don't want to inflict more 
windows on people if I can help it.  Plus there are problems with some 
Unix Window managers, and a Windows JDK bug, that sometimes keep dialogs 
from showing up where you want them.

I may take a shot at adding this tonight.  Coding it isn't that much 
harder than describing it.

> - a window with a list of your own armies would be nice

Easy enough, but I don't see the need, since they're easily visible on 
the board.  As long as it's optional then there's no problem adding it 
-- I would just turn it off when I play.  If this dialog is view-only 
then implementing it is simple.

However, once you start adding the ability to actually control stuff 
from this dialog, it becomes a bit of a pain.  The view and controller 
are somewhat intertwined in MasterBoard and its inner classes.  We'd 
have to move some of the event stuff out into another public class, add 
parameters for stuff that's currently accessed directly, etc.  Splitting 
the view and controller classes is probably a good idea in any case, but 
  not a high priority for me right now.

> What is your approach of synchronizing work? With all the updates you 
> already do I might easily cause conflicts if I go for one of these 
> features -- does it make sense to try anyway and then to send a patch to 
> you / the dev list? Changes would probably be small in existing files...

There have never been more than two people actively working on the 
project at once, so synchronization has not been a big issue.  The big 
thing is synching often so that we don't have huge integration problems.

Testing in general is the bigger problem.  I've been thinking about it a 
lot lately.

Anyway, just send patches at first.  To the dev list if they're 
reasonably small -- preferably dumped on a ftp/web site with a URL to 
the list if they're big.

-- 
David Ripton   dr...@wi...

> The first bug is the simple failure to get an AcquireAngel dialog. 
> Default variant, 4-high human-controlled stack jumps on an AI-controlled
> 2xGargoyle stack, which flees.  89 + 12 = 101 points, but no 
> AcquireAngel dialog.

The code I had put in Legion.java was definitely buggy, it rounded down
both the score and the points earned ! Now, it rounds down the score,
adds the same amount to the points earned, and starts to check for
angel. Probably much better that way :-)

Hope thet fixed it,

-- 
DOLBEAU Romain               | I tell you to enjoy life,
ENS Cachan / Ker Lann        |  I wish I could
Thesard IRISA / CAPS         |        but it's too late.
dol...@cl...    |  -- Black Sabbath, 'Paranoid'

Romain Dolbeau wrote:
> I've finally comitted the use of the Acquirable/Summonable
> interface. I _hope_ I didn't break anything.
> 
> The starting 'Angel' is now the first Acquirable creature.
> I did fix SimpleAI for that (so initial Split should still
> work), but not for anything else.
> 
> Changes are surrounded by tags, 'before_angel_split' and
> 'after_angel_split'.
> 
> Any comments welcome, including in particular success/failure
> reports for all variants.

I'm seeing a couple of angel-related bugs.  I suspect that the first is 
related to your change, and the second was already there.  (Because it 
sounds a lot like a bug already in the tracker.)

The first bug is the simple failure to get an AcquireAngel dialog. 
Default variant, 4-high human-controlled stack jumps on an AI-controlled 
2xGargoyle stack, which flees.  89 + 12 = 101 points, but no 
AcquireAngel dialog.  The kickEngagements log message says acquiring = 
false.  I did see an AI player get an angel later in the game, so I 
suspect the problem is in failing to pass the messages down through 
Server and Client, rather than a points calculation error.  I'll look at 
this more tonight, and add details to the bug tracker if I fail to fix it.

The second is a human-controlled post-battle SummonAngel dialog that 
gets cancelled (either with the explicit Cancel button or the standard 
OS dialog cancel action).  This results in an NullPtrException and the 
dialog doesn't go away.  You can keep playing with that dialog up since 
it's non-modal, but if you fight another battle in the same engagement 
phase, summoning an angel is not possible.  This one should be easy to 
fix now that I have an exception trace.

-- 
David Ripton   dr...@wi...

The two Tower recruiting bugs reported under number 512860
have been fixed. You should be able to recruit the Tower creatures
anonymously, and you should not be able to recruit the Guardian with
three lords or demilords.

-- 
DOLBEAU Romain               |
ENS Cachan / Ker Lann        | l'histoire est entierement vraie, puisque
Thesard IRISA / CAPS         |     je l'ai imaginee d'un bout a l'autre
dol...@cl...    |           -- Boris Vian

I made a bunch of changes last night, but didn't check them in because 
they weren't fully debugged.  The main theme is removing client 
callbacks to the server for information.


Change BattleChit setDead(true) to call setHits(0) so we never see both 
the X and a number of hits.

Add a getCenter() method to Chit, so we can figure out which hex it's in 
using the GUI.  (Not the best way.)

Remove the calls from the server side to Client.loadOptions().  The 
client can load options by itself.

Change the logic around Client.addMarker(), setMarker(), removeMarker(), 
and MasterBoard.alignChits() a lot.  The idea is that whenever a legion 
splits, moves, undoes either, or dies, then the client gets notified, 
and handles the markers based on that.  No calls back to the server for 
redundant information.  There is a new Map, Client.legionToHex, that 
tracks which hex each legion currently sits in.  I haven't cached known 
stack contents yet -- that's a bit more complex.

Added documentation of split prediction design.  Not quite complete but 
it gets the basic idea across.

Show recruitChits for all recruits.  They get cleared during this 
player's split / move phase depending on when he takes his first action. 
This is a bit broken because there are places where we need to clean up 
the recruitChits but don't.  (e.g. when a stack recruits, but then gets 
attacked and loses some creatures)

Remove Client.setBattleChitHits(), setBattleChitDead()  This stuff is 
now handled on the client side based on tellStrikeResults()

Change some methods with Muster in the name to use Recruit instead. 
Trying to be consistent -- Muster is the name of the phase, but Recruit 
is the verb and applies to both recruiting during the muster phase and 
recruiting reinforcements during/after battle.

Get rid of MarkerComparator.  May go back in later, but it was broken 
(autoPickMarkers gave me a captured marker when some of my starting 
markers were still available) and not adding as much value as it was 
costing in complexity.

Get rid of debug mulligans.  Same problem -- AI players who weren't 
supposed to be using them were.  Some kind of options initialization 
bug, but it was easier just to remove the option for now.

Anyway, I will merge my changes with Romain's angel changes, test a bit, 
and then check this stuff in.  Then I'll test a lot more.

-- 
David Ripton   dr...@wi...

I've finally comitted the use of the Acquirable/Summonable
interface. I _hope_ I didn't break anything.

The starting 'Angel' is now the first Acquirable creature.
I did fix SimpleAI for that (so initial Split should still
work), but not for anything else.

Changes are surrounded by tags, 'before_angel_split' and
'after_angel_split'.

Any comments welcome, including in particular success/failure
reports for all variants.

-- 
DOLBEAU Romain           | I witness a time and a place that never dies,
ENS Cachan / Ker Lann    | still frozen in time, this darkness the only 
Thesard IRISA / CAPS     | place that I can hide. I witness, a dream.   
dol...@cl...|  -- Black Sabbath, 'I Witness'

Romain Dolbeau wrote:

> David Ripton wrote:

>>Teach Client to remember stack hex locations and known stack contents.
>>(No split prediction yet.)

> Will that implements per-player memory ?


Yes.  And eliminate Critter.visible


> For 'split prediction, I think an easy and useful thing to
> add would be 'any stack as at least (original number minus
> other stack size).
> 
> i.e., if a stack is known to contain 3 Cyclops, a 5-2
> split guarantee a Cyclops in the 5-high stack.


Right, that's a small case in the algorithm.  I started describing my 
stack prediction algorithm in this email, but it got too big, and the 
tree diagrams got too wide, so see docs/StackPrediction.txt


> If it's easy to code, OK. But I think it's more trouble than
> it's worth, as last recruit is visible in the stack content
> anyway. Eventually, simply add a small marker in the stack
> content to highlight it.


It's easy to code.  We already have the recruitChits logic in place.  We 
just need to use two lists (one for other people's past recruits, one 
for our potential recruits) instead of one in Client.

Several people have asked for more feedback as the game goes on. 
Showing enemy recruits on top of their stacks makes clicking on enemy 
stacks less necessary.  Showing dialogs at the end of engagements should 
also help.  But I think all such feedback needs to be optional, so that 
those who want the AI to play as quickly as possible are happy.  The 
options should be completely on the client side -- the server sends the 
information regardless, and the client chooses if and how to present it.


>>Have Game and Battle's findMoves() return the whole movement path, not
>>just the final hex, so that we can do move animation.  Does anyone have
>>ideas for what move animation should look like?
>>
> 
> Well, draw the curve that goes through all hex center amd
> slide along :-)
> 
> But this is going to be sloooowww in java...

We'll see.  If it's too slow then we can just blink the chit into the center of each hex rather than dragging it.

Teleports should be done with either a single blink (possibly with fade 
effects) or a straight drag.  I'm less concerned with the GUI part right 
now than with presenting the proper information to the client side. 
Just showing the final hex and entry side isn't enough.

-- 
David Ripton   dr...@wi...

David Ripton wrote:

> Teach Client to remember stack hex locations and known stack contents.
> (No split prediction yet.)

Will that implements per-player memory ?
For 'split prediction, I think an easy and useful thing to
add would be 'any stack as at least (original number minus
other stack size).

i.e., if a stack is known to contain 3 Cyclops, a 5-2
split guarantee a Cyclops in the 5-high stack.

> Show new recruits on top of stacks from the time they're recruited until
> the beginning of that player's next turn.  This might get a bit
> confusing, so we need to distinguish the two types of recruit chits
> visually and/or provide showPastRecruits and showPotentialRecruits
> options so that confused players can turn one of them off.

If it's easy to code, OK. But I think it's more trouble than
it's worth, as last recruit is visible in the stack content
anyway. Eventually, simply add a small marker in the stack
content to highlight it.

> Have Game and Battle's findMoves() return the whole movement path, not
> just the final hex, so that we can do move animation.  Does anyone have
> ideas for what move animation should look like?

Well, draw the curve that goes through all hex center amd
slide along :-)

But this is going to be sloooowww in java...

-- 
DOLBEAU Romain            | L'histoire est entierement vraie, puisque  
ENS Cachan / Ker Lann     | je l'ai imaginee d'un bout a l'autre.      
Thesard IRISA / CAPS      | -- Boris Vian                              
dol...@cl... |

I haven't been able to post to this list for a few days because of a 
config problem at my ISP.  (SourceForge's list software is picky.)

Anyway, in the last few days I dumped my text buglist into the SF web 
bug tracker, fixed a couple of bugs (Java Web Start resource loading, 
auto forced strikes), wrote some build docs, updated the web site a bit, 
added Jerry's Ent counter for ExtTitan, and added a test subdirectory 
with a couple of jnlp files and test scripts that use them.  (The JNLP 
files have fixed absolute paths that will probably only work for me; we 
probably need a COLOSSUS_HOME environment variable.)

I'm going to test and make a new public build tonight.

Things I want to do this weekend:

Teach Client to remember stack hex locations and known stack contents. 
(No split prediction yet.)

Show new recruits on top of stacks from the time they're recruited until 
the beginning of that player's next turn.  This might get a bit 
confusing, so we need to distinguish the two types of recruit chits 
visually and/or provide showPastRecruits and showPotentialRecruits 
options so that confused players can turn one of them off.

Add some test documentation and a few JUnit tests.  This will probably 
need java.awt.Robot, which needs JDK 1.3.  Hopefully the test code can 
be isolated so that the game code still works in 1.2.  Anyone using a 
platform that doesn't have a 1.3 JDK available?

Have Game and Battle's findMoves() return the whole movement path, not 
just the final hex, so that we can do move animation.  Does anyone have 
ideas for what move animation should look like?

-- 
David Ripton   dr...@wi...

> 1) adding the "summonable" field to the Creature, as a property in the CRE
> file. As a side effect, nothinbg would prevent a variant to include
> summonable creature that aren't points-recruited.

This is done, and I've adde a List of SummonablesCreatures, no need to
compute that every times.

> 2) having my "Angel" list become a "points-recruitable" list. So anything
> could be points-recruited.

This is done, as "Acquirable". I've also propagated the various
functions as static functions of "Game" (like for getRecruits() & and so
on), so the list should be accessible from anywhere. I've also made this
and the full Creatures Lists umodifiables.

I haven't yet changed anything else.

Any comments welcome,

-- 
Romain DOLBEAU               |  Energy derives from both
ENS Cachan / Ker Lann        |    the plus and negative
Thesard IRISA / CAPS         |       -- Metallica,
dol...@cl...    |           'Eye of the Beholder'

[I usually cut down the message I'm answering to, but David asked me to
forward his message to the list, so I've quoted the whole message.]

> I want to make sure we agree on the rules first before we talk about 
> implementation.

That's what I thought. I misunderstood one detail, so of course, It
wasn't going to work properly.

> Angels (including Archangels) are special in three main ways:
> 
> 1. They are acquired after passing various point thresholds with points
> earned in certain ways (not all points -- see 19.4 about how half-points
> awarded when titans die don't count -- I just had to look it up because
> someone reported the correct application of this rule as a bug), rather
> than mustered.
> 
> 2. They can be summoned into (or just after) battle.
> 
> 3. They are lords.

In my mind, I only though about 1) and 2), together. 3) seems mostly
irrelevant to me, as it is a well-defined property of the Creature.

> isAngel() and the various "Angel" tests only hold for Angels, which mean
> all three of these characteristics.  We should NOT overload isAngel()
> for creatures which are sort-of-like angels, but not angels. 
> (Archangels *are* angels.)  That would lead to madness.  Instead, which
> should split out the various characteristics (isSummonable(), 
> canBeAcquired() -- isLord() is already there) and test for those instead
> in the places where we currently use isAngel()

For me, isSummonable() and canBeAcquired() were the same things. I
thought that all points-recruitable being were also summonable, so I
coded it that way....

> Here are the elemental rules:
> 
> # You can take an elemental instead of an Angel, but you are
> # not required to take an elemental if you would prefer an Angel. Like
> # Warlocks, and Guardians, Elementals are Demi-Lords, so there are only
> # ever 6 of each kind, and they are returned to the creature pool when #
> # they 'die'. Fire Elementals have NO CAPACITY TO RANGESTRIKE LORDS.
> 
> My interpretation:
> 
> Elementals are clearly NOT angels, in the biological or logical or 
> object-oriented sense, because they're demi-lords and angels are lords.
> 
> Elementals cannot be summoned like angels.  (Nowhere does it say they
> can.  And that would make them even more overpowered, and remove any 
> incentive to ever take a 6-4 angel instead of an elemental.)
> 
> Elementals are acquired like angels, but with the additional rule about
> terrain type.

...and made Elementals Summonable. Thinking more on it, you are right,
and this should be two different thing.

1) adding the "summonable" field to the Creature, as a property in the
CRE file. As a side effect, nothinbg would prevent a variant to include
summonable creature that aren't points-recruited.

2) having my "Angel" list become a "points-recruitable" list. So
anything could be points-recruited.

> Balrog rules:
> 
> # Every 300 points, place a Balrog in that player's home tower.
> # The next legion, of any player, to the tower may muster the Balrog.
> # Special abilities Note that as a demi-lord, the Balrog can rangestrike
> # Lords.
> 
> My interpretation:
> 
> Balrogs are not angels either.
> 
> "Every 300 points" means "every 300 points, assuming those points could
> be used to acquire an angel."  So we check for Balrogs in the same place
> in the code where we check for acquiring angels / elementals.  The 
> alternate interpretation, *EVERY* 300 points including half-points from
> surviving creatures when a Titan dies, can be argued as what the rule
> literally says, but I don't think that's orthogonal to the rest of the
> rules.  And it would be more painful to implement.

I didn't thought about Barlogs ; they aren't really point-recruited, but
points-added-to-the-map. That would come (much) later, as it changes
deeply the Titan rules (no wandering monster...).

> "Next legion may muster" means that
> 
> 1. This counts as the legion's muster, so it can't grab both a balrog
> and a normal tower recruit.
> 2. This is a one-time thing.  If the first legion doesn't take the 
> balrog on that turn, the Balrog is gone from that tower back to the stack.
> 
> The Balrog is in addition to the angel/elemental that may be acquired
> with those points, not a substitute like the elemental.  Also, it's not
> optional -- the scoring player can't decline putting the balrog in the
> tower just because someone else is more likely to grab it.
> 
> We have two different new rangestriking demi-lords, one of which can 
> rangestrike lords, and the other of which cannot.  So clearly the 
> ability to rangestrike lords is not tied to being a demi-lord (as the
> balrog authori indicates), but is separate.  Note that it is not said
> that the Balrog has the Warlock's other special rangestrike abilities --
> the ability to ignore terrain and range modifiers.  (The range part is
> moot because the Balrog only has skill 3.)  So I think it doesn't have them.
>
> So I think the magic rangestrike test you added for the warlock needs to
> be split into two subtests, canRangestrikeLords(), and 
> ignoresRangestrikePenalties()  (The latter could be split into ignoring
> long-range penalties and ignoring terrain penalties, but I think that's
> flexibility overkill since we don't know of any cases where the two 
> parts are independent.)
> 
> Anyway, I don't like the naming of the various tests in 
> TerrainRecruitLoader.jj, because they refer to angels and elementals are
> not angels, and this might result in mingling them in other places e.g.
> making elementals summonable because they pass the isAngel() test.  I
> think using the term "acquired" instead of "angel" in these various 
> tests will make the code cleaner and more accurate.  (Though that's not
> the right term for Balrogs -- they become added to one hex's recruiting
> tree for one turn.)

I agree about these changes. But we'll need to add an isSummonable()
test.

> Of course, all of my rule interpretations (Elementals can't be summoned,
>   balrogs do take terrain penalties when rangestriking, balrogs don't
> appear based on half-points when titans are killed, balrogs go away if
> not mustered on the first turn a legion enters their hex) could be 
> contrary to the intent of the designers of these variants.  We could try
> to ask the original authors of these variants exactly what they 
> intended.  But we need to be clear on the rules before coding anything.

Given that Elemental are a lot more powerful that (regular) Angel, I
agree with your interpretation. Anyway, if we do the split and then
somebody can prove Elemental are summonable, we would only have to
change a flag in ExtTitan/ExtTitan.cre...

> One more point: archangels show up every 300 points in ExtTitan instead
> of every 500.  The logic in Legion to figure how many angels / 
> archangels can be acquired has an implicit assumption that you can never
> get enough points from a battle to get more than one archangel.  (You'd
> need 501 minimum, and that would require killing a 55-power Titan and 7
> 10-4 Colossi including one that was summoned as a reinforcement.  I've
> never seen a Titan bigger than about 30 power, though I guess it's 
> theoretically possible to get to 55 if players collude to recruit lots
> of demi-lords and feed them to each other's titans for a long time) 
> With the threshold dropping to 300, and ExtTitan having 15-4 Colossi, it
> is entirely possible to get two archangels from one battle.  So that 
> code needs to be made a bit more rigorous, using multiple levels of 
> counters instead of just a counter and an archangel flag.

-- 
DOLBEAU Romain               | I tell you to enjoy life,
ENS Cachan / Ker Lann        |  I wish I could
Thesard IRISA / CAPS         |        but it's too late.
dol...@cl...    |  -- Black Sabbath, 'Paranoid'

Romain Dolbeau wrote:

> I really like the new Elementals Chit, and I'd like
> to be able to recruit them. For that, we need to
> rework the way Angel and Archangel are used.
[massive snip]
> Any comments welcome (I haven't written any code yet,
> but the parser bit shoudn't be hard. Replacing all those
> byName("Angel") will be.)

I've rewrote the parser and data files, so that the
interface is implemented and ready to use (slightly
different from what I've proposed, see the javadoc
comments.)

I haven't changed anything else yet, so there's
still time to change the interface before I start
changing all the occurence of getCreatureByName("Angel")

Any comments welcome ,

--=20
DOLBEAU Romain               | Ce que l'on con=E7oit bien s'=E9nonce     =
  =20
ENS Cachan / Ker Lann        | clairement, et les mots pour le dire    =20
Thesard IRISA / CAPS         | arrivent aisement.                      =20
dol...@cl...    |       -- Nicolas Boileau

David Ription wrote:

> The invertedIcon is a very good idea.
[snip]
> Sure; the entry side is stored in the Legion after the move, and then
> passed through Battle into BattleMap.  The angles are fixed for each 
> entry side.
> 
> That would be neat.  Three possible problems:
> 
> 1. It might be noticably slow on slow machines.  (Of course, so might a
> 180 degree flip via AffineTransform if not special cased.  Haven't tested
> on slow machines yet.  All Java2D code in the game should honor the
> antialias option, which should help some with speed.)
> 
> 2. It might be a bit ugly.  The Java2D rotates are pretty good, but they
> might still smear the image text a bit, especially with AA off.
> 
> 3. If we cache inverted icons, then displaying at 6 different angles means
> 6 copies of each creature image to store.  It'll work, but again it might
> not be worth it on slower machines.  Ditto with the overlays, which are
> much bigger GIFs.  So I think that if we add this, it should be optional.

I was thinking of yet another option, "Purist Display", that would
display the Masterboard Overlay and the Chit properly rotated. This
would be disabled by default, being slower and more memory-hungry.

Anyway, I haven't managed to have the Masterboard Overlay display
properly when rotated ; the destination rect is still all wrong, and so
is the rotate angle. So "Purist Display" or whatever will have to wait.

I think having a more generic Angel/Archangel system is of higher
priority anyway.

BTW, to anyone who likes ExtTitan, please test to see if the newer
recruitements scheme and display still works ; it seems it's bitten by
the same bug that forced me to search the Colossus icon from the Default
directory only, i.e., the display update just stop and never come back.
But I didn't have time to check carefully (maybe the box was just slow).

-- 
DOLBEAU Romain               |
ENS Cachan / Ker Lann        | l'histoire est entierement vraie, puisque
Thesard IRISA / CAPS         |     je l'ai imaginee d'un bout a l'autre
dol...@cl...    |           -- Boris Vian

David Ripton wrote:

> I tried the same thing (on JDK 1.4 rc on Win98) and it didn't work for
> me either, so I didn't check my attempt in.  I'm sure it's doable with
> an AffineTransform -- it's just a matter of tweaking the syntax.

I managed to get it to work ; it was dumbness on my side.
The regular transform rotate around (0,0), so of course
after rotating 180 degrees, everything was out of range.
Adding an anchor point in the middle of the Chit was the
solution. I also added a local invertedIcon that's created
once and then re-used during the entire life of the Chit.

BTW, is there enough information upstream so that instead
of inverted/not inverted, we could have the actual angle
to use ? A stack entering by the right or left would
be displayed horizontally (PI/2), whereas one entering
elsewhere would have a +-[2]PI/3 inclination...

-- 
DOLBEAU Romain               | Brothers of Metal will always be there   
ENS Cachan / Ker Lann        | Standing together with hands in the air  
Thesard IRISA / CAPS         |           -- Manowar,                    
dol...@cl...    |                     'Brothers of Metal'

Hello,

I've updated the Parser and datafiles for the recruitments
tree. Tower is no longer a special case. The only (yet
unfixed) drawback/bug/feature (pick one) is that recruiting
a tower creature will ask to reveal a recruiter.

The main advantage is that non-default recruiting scheme
in Tower now works, i.e. there's Wraith in ExtTitan
(if someone start collecting Gargoyles, you know
he wants a Wraith :-)

I hope I didn't break anything else in regular Colossus.

Any comments welcome,

-- 
DOLBEAU Romain               | The Gods made Heavy Metal                
ENS Cachan / Ker Lann        |     and it's never gonna die             
Thesard IRISA / CAPS         |           -- Manowar,                    
dol...@cl...    |    'The Gods made Heavy Metal'

Hello,

I really like the new Elementals Chit, and I'd like
to be able to recruit them. For that, we need to
rework the way Angel and Archangel are used.

ATM, their names is used directly in numerous places,
including:

SplitLegion.java
SummonAngel.java
Creature.java
Game.java
Legion.java
Server.java
SimpleAI.java

My idea would be to put informations inside the TER
file, loaded by the TerraintRecruitLoader (an instance
is kept inside Game), and use the information like we
do for the StratingCreatures. We could add a few
functions:

# List getAngelList()
that would return a List of all Angel and Angel-like creatures ;
# List getRecruitableAngelList(int previous, int current)
that would return a List of Angel and Angel-like creatures
recruitable by jumping from 'previous' to 'current' points ;

(the two above should use either Creature or String, to
be confirmed).

# bool isAngel(Creature c)
# bool isAngel(String name)
that would tell if the creature is an Angel-like
(replacing Creature::isAngel())
# int getAngelRecruitmentsValue()
that would tell the numbers of point required for one
recruit (replacing the hard-coded '100')

The TER file would then hold
1) how many points needed for the 'base' Angel-like
2) how many points needed for the 'others' Angel-like
3) where the angel-like can be recruited

i.e. default would be
100 Everywhere Angel 500 Everywhere Archangel

whereas ExtTitan would use something like:

100 Everywhere Angel 100 Desert FireElemental 100 Swamp WaterElemental (...)

and so on. The AcquireAngel display could then display
one, two or three choices (or maybe more for other
variants.)

This could make the Colossus ExtTitan closer to the
'real' ExtTitan.

Any comments welcome (I haven't written any code yet,
but the parser bit shoudn't be hard. Replacing all those
byName("Angel") will be.)

-- 
DOLBEAU Romain               |                                          
ENS Cachan / Ker Lann        | l'histoire est entierement vraie, puisque
Thesard IRISA / CAPS         |     je l'ai imaginee d'un bout a l'autre 
dol...@cl...    |           -- Boris Vian

Hello,

I've added a pop-up menu for variant stored inside the JAR
file, and put the 4 variants we already have in it. The
'Load External Variant' button still works, but not if
it is the first thing to be selected. Apparently, some
select events from the pop-up get in the way.

Any comments welcome,

-- 
DOLBEAU Romain               |        Long live rock and roll           
ENS Cachan / Ker Lann        |        Long live rock 'n' roll           
Thesard IRISA / CAPS         |        Long live rock and roll           
dol...@cl...    | -- Rainbow, 'Long Live Rock 'N' Roll'

Hello,

Savefile now hold the name and location of the variant,
so we don't need to reload the variant prior to loading
the game. Unfortunately, absolute path for is stored ATM
(for external variant), so moving a savefile from one
computer to another will likely not work.

-- 
DOLBEAU Romain               |  Who made you God to say                 
ENS Cachan / Ker Lann        |    "I'll take your life from you!"       
Thesard IRISA / CAPS         |       -- Metallica,                      
dol...@cl...    |           'Ride the Lightning'

Romain Dolbeau wrote:

> draw the Image in a BufferedImage, and use an AffineTransformOp
> to rotate that 180=B0. This should work everywhere, but will
> will undoubtly be slower.

I tried it (code is in release 1.11 of Chit.java, backed-out
in 1.12), but it doesn't work. It works for a 0 radians
rotate (!), but for PI or PI/2, the createCompatibleDestImage
fails with 'transformed width =3D 0'. This under Solaris JVM 1.3.1...

On the VariantSupport subject, I moved all data (images
and Battlelands) under Default/, for coherency (and make
image loading works again :-) I tried to update build.xml,
but can't test it, so it might need a second look.

--=20
DOLBEAU Romain               |        Long live rock and roll          =20
ENS Cachan / Ker Lann        |        Long live rock 'n' roll          =20
Thesard IRISA / CAPS         |        Long live rock and roll          =20
dol...@cl...    | -- Rainbow, 'Long Live Rock 'N' Roll'