AI for MWIF - Norway

[Shannon V. OKeets]

ORIGINAL: paulderynck

ORIGINAL: Shannon V. OKeets

As an argument in your favor for treating Istanbul as a special hex, you might look at Manila (I think it is Manila). There is a problem with the hex being adjacent to two sea areas but the port only being accessible from one of them.

In WiFFE, Manila is invadeable from the South China Sea only. In MWiF, to me it is not invadeable at all, if I apply RAW (no full sea hexsides to cross from either sea zone). But I have no issue with that because of the change of scale.

It was Legaspi that I was concerned about.

[paulderynck]

Not a major issue for Africa and Asia due to the scale change IMO. The one hex in Pakistan that is invadeable only from the Persian Gulf in WiFFE is probably replaced by two hexes with the further east one invadeable from both sea zones.

[Shannon V. OKeets]

ORIGINAL: Froonp

Here are those hexes for Asia :

Patrice,

Sorry, but I can't figure out what are problems and what aren't problems from all these pictures.

---
Paul,

WIFFE players see an all sea hexside bisected by a sea area boundary and say it is 'obvious' that the hex can be invaded from both sea areas. I look at it and see that only half of an all sea hexside is present for each sea area, so neither sea area can invade the hex: because there isn't a 'full' all sea hexside bordering, say, Liverpool, for either of the 2 sea areas.

My point is that what you say is visually clear on the WIF FE maps is just something you have learned to see as an invadable hex. The maps could have been drawn as in MWIF and you would have learned a different pattern as 'invadable': there is an all-sea hexside present and the hex borders two sea areas => invadable.

I intend to use the style developed by Chris for CWIF in MWIF. It is less dependent on the pen of the artist. The WIF FE map sea area boundaries were drawn using a straight line for the most part. You can see the problems this creates in Patrice's examples at Lisbon, Malta, and La Spezia. The line's relationship to the sea area hex dot can have a razor thin separation. At 8 levels of zoom, that isn't going to work for MWIF.

Now this doesn't achieve the same result for Istanbul (comparing WIF FE to MWIF). Are there any other places?

[paulderynck]

ORIGINAL: Shannon V. OKeets

ORIGINAL: paulderynck

ORIGINAL: Shannon V. OKeets

As an argument in your favor for treating Istanbul as a special hex, you might look at Manila (I think it is Manila). There is a problem with the hex being adjacent to two sea areas but the port only being accessible from one of them.

In WiFFE, Manila is invadeable from the South China Sea only. In MWiF, to me it is not invadeable at all, if I apply RAW (no full sea hexsides to cross from either sea zone). But I have no issue with that because of the change of scale.

It was Legaspi that I was concerned about.

The Legaspi hex is clearly invadeable from either sea zone while its port no longer has direct access to the South China Sea in MWiF. I accept this as the result of the scale change. At least that is what I see if I apply RAW and the recent Q&A to the picture. I'm not clear on what the accessability of the port has to do with invading? I just assume that if you successfully invade from the South China Sea, then you crossed overland to take possession of the port versus having assaulted it on the harbour side.

[Shannon V. OKeets]

ORIGINAL: paulderynck

ORIGINAL: Shannon V. OKeets

ORIGINAL: paulderynck


In WiFFE, Manila is invadeable from the South China Sea only. In MWiF, to me it is not invadeable at all, if I apply RAW (no full sea hexsides to cross from either sea zone). But I have no issue with that because of the change of scale.

It was Legaspi that I was concerned about.

The Legaspi hex is clearly invadeable from either sea zone while its port no longer has direct access to the South China Sea in MWiF. I accept this as the result of the scale change. At least that is what I see if I apply RAW and the recent Q&A to the picture. I'm not clear on what the accessability of the port has to do with invading? I just assume that if you successfully invade from the South China Sea, then you crossed overland to take possession of the port versus having assaulted it on the harbour side.

The problem is that the fundamental data is the hex's relationship to sea areas, with the relationship of a port to sea areas being one and the same as the relationship of the hex to the sea areas. So you could move a naval unit into/out of Legaspi from either sea area. That is how the code is written for all ports on the map.

To rewrite the code so the relationship of a port to sea areas is independent of the realtionship of the hex it sits in to those same sea areas would be a lot of work (vast understatement). Instead, I expect to have to have special code that says: "if the port we are examining is Legaspi, then different rules apply, ...". What I want to know is are there other ports for which I have to write special code?

=======

Writing code is non-trivial. As an example, here is one of the 3 main routines for deciding about cooperation between countries. All the comments were added by me.

Code: Select all

 // ****************************************************************************
 function TMinorCountry.CooperatesWith(Cnt: TCountryID): Boolean;
 // ****************************************************************************
 // CooperatesWith returns whether Cnt cooperates with Self (a minor country).
 // This routine is for countries, but in actual use it checks for whether units
 // can cooperate.  Since cooperation is always based on country of origin and
 // the status of the country (conquered, liberated, etc.), this routine is here
 // rather than in WIFUnits.
 // ****************************************************************************
 var
   CMC: TMajorCountry;
   CountryIn: TCountryID;
 begin
   CountryIn := Cnt; // So variable is not changed.
 // ****************************************************************************
 // For CW member countries, check if CW (major power) cooperates with CountryIn.
 // ****************************************************************************
   if (ID in CommonwealthCountries) or (ID = Commonwealth.ID) then
     Result := Commonwealth.CooperatesWith(CountryIn)
 // ****************************************************************************
 // If checking whether Self cooperates with AOI, reverse the call, to check if
 // AOI, (a subcountry), cooperates with Self. 
 // ****************************************************************************
   else if CountryIn = AOI.ID then Result := AOI.CooperatesWith(Self.ID)
   else
   begin
 // ****************************************************************************
 // Commonwealth countries are treated as a one country for cooperation purposes.
 // Communist China is distinct when determining cooperation.  Some units belong
 // to subcountries and have IDs for that subcountry.  So, HomeCountry converts
 // the subcountry IDs into a minor or major country ID.
 // ****************************************************************************
     if CountryIn in CommonwealthCountries then
       CountryIn := Commonwealth.ID
     else if CountryIn <> CommunistChina.ID then
       CountryIn := Countries[CountryIn].HomeCountry.ID;
 // ****************************************************************************
 // In Barbarossa, Italian units are controlled by Germany.  The conversion to
 // CMC is added code to handle that unique condition.
 // ****************************************************************************
     if (CurrScenario = scBarbarossa) and (Self = Italy) then CMC := Italy
     else CMC := Self.ControllingMajorCountry;
 // ****************************************************************************
 // We are now ready to check for cooperation.
 // ****************************************************************************
    	Result := (ID = CountryIn) or                        // From same country
               (Parent = Countries[CountryIn].Parent) or  // With same parent
               (CMC = Countries[CountryIn]) or     // With controling major power
               ((Self = France) and                // Free France with CW & USA
                VichyFrance.Legal and
                ((CountryIn = UnitedStates.ID) or
                 (CountryIn = Commonwealth.ID)));
   end;
 end;
 

[paulderynck]

ORIGINAL: Shannon V. OKeets

Paul,

WIFFE players see an all sea hexside bisected by a sea area boundary and say it is 'obvious' that the hex can be invaded from both sea areas. I look at it and see that only half of an all sea hexside is present for each sea area, so neither sea area can invade the hex: because there isn't a 'full' all sea hexside bordering, say, Liverpool, for either of the 2 sea areas.

My point is that what you say is visually clear on the WIF FE maps is just something you have learned to see as an invadable hex. The maps could have been drawn as in MWIF and you would have learned a different pattern as 'invadable': there is an all-sea hexside present and the hex borders two sea areas => invadable.

I intend to use the style developed by Chris for CWIF in MWIF. It is less dependent on the pen of the artist. The WIF FE map sea area boundaries were drawn using a straight line for the most part. You can see the problems this creates in Patrice's examples at Lisbon, Malta, and La Spezia. The line's relationship to the sea area hex dot can have a razor thin separation. At 8 levels of zoom, that isn't going to work for MWIF.

Now this doesn't achieve the same result for Istanbul (comparing WIF FE to MWIF). Are there any other places?

OK I see your point. The first task is to see how many hexes are like Istanbul. The next is to decide if it is worthwhile making them exceptions (I would like to say that it is). The final task is how to convey to the players, whether old or new, the mindset of viewing the MWiF map in a way that swiftly and accurately imparts the concept of invadeability.

We are in Task 1 and I'd like to help with it. I still think we only need to do this for the part of the map corresponding to the WiFFE European map (other than assuring Task 3 works everywhere). I'll look for any other hexes but I'm inhibited from access to the WiFFE maps unitil we move at the end of next week.

[paulderynck]

ORIGINAL: Shannon V. OKeets
The problem is that the fundamental data is the hex's relationship to sea areas, with the relationship of a port to sea areas being one and the same as the relationship of the hex to the sea areas. So you could move a naval unit into/out of Legaspi from either sea area. That is how the code is written for all ports on the map.

To rewrite the code so the relationship of a port to sea areas is independent of the realtionship of the hex it sits in to those same sea areas would be a lot of work (vast understatement). Instead, I expect to have to have special code that says: "if the port we are examining is Legaspi, then different rules apply, ...". What I want to know is are there other ports for which I have to write special code?

Panama would be the first one that comes to mind as it was featured in the Q&A when it was established that "most" ports do in fact have access to all adjacent sea zones in WiFFE. Unfortunately the scale change in the Pacific may have created many more of these exceptions (as is the case for Legaspi).

I'll review the MWiF maps and start making a list (gasp)[X(] of any "Legaspi"s I find.

[Froonp]

ORIGINAL: paulderynck
The Legaspi hex is clearly invadeable from either sea zone while its port no longer has direct access to the South China Sea in MWiF.

No, the port still have access to the South China Sea.
It is the same for the Major Port of Auckland (NZ) that has access to 2 Sea Areas while being physicaly placed on only the New Zealand Coast.

Those ports had access to 2 Sea Areas in WiF FE, they had to have access to the same 2 Sea Areas in MWiF.

You just have to use some WiFZen to accept it, imagining that the ships go around the peninsula's tip to go to the other Sea Area.

[Froonp]

ORIGINAL: Shannon V. OKeets
Sorry, but I can't figure out what are problems and what aren't problems from all these pictures.

These are just comparisons of what the Sea Area Boundary connection with the land is in Wif FE and MWiF.
I can send you the full sized picture (it did not fit the forums) so you see it better.
It shows that in 99% of the cases, there are no problems.

Istanbul is the only one I found at the European Scale.

[Froonp]

ORIGINAL: paulderynck
Panama would be the first one that comes to mind as it was featured in the Q&A when it was established that "most" ports do in fact have access to all adjacent sea zones in WiFFE. Unfortunately the scale change in the Pacific may have created many more of these exceptions (as is the case for Legaspi).

I'll review the MWiF maps and start making a list (gasp)[X(] of any "Legaspi"s I find.

There are none, the CWiF map was faithfull to the WiF FE map in this regards, this is something I have checked some months (years ?) ago when I was making the mockup for the coastlines.

Legaspi is on 2 Sea Areas as I told you. Look at it ingame.

[paulderynck]

ORIGINAL: Froonp

ORIGINAL: paulderynck
Panama would be the first one that comes to mind as it was featured in the Q&A when it was established that "most" ports do in fact have access to all adjacent sea zones in WiFFE. Unfortunately the scale change in the Pacific may have created many more of these exceptions (as is the case for Legaspi).

I'll review the MWiF maps and start making a list (gasp)[X(] of any "Legaspi"s I find.

There are none, the CWiF map was faithfull to the WiF FE map in this regards, this is something I have checked some months (years ?) ago when I was making the mockup for the coastlines.

Legaspi is on 2 Sea Areas as I told you. Look at it ingame.

This is really counter-intuitive in view of the discussion about the port of Panama in the recent Q&A. How do I as a player know these are two (or more) sea zone ports?

IMO it would be better to move the port symbol 1 hex to the southeast and have the blue line bisect it or redraw the blue line as below:

[Froonp]

ORIGINAL: paulderynck
This is really counter-intuitive in view of the discussion about the port of Panama in the recent Q&A. How do I as a player know these are two (or more) sea zone ports?

You see it in multiple ways, first by looking at the information bar that tells you which Sea Area an hex is adjacent to.

IMO it would be better to move the port symbol 1 hex to the southeast and have the blue line bisect it or redraw the blue line as below:

I don't want to move it, because it is at the right place (see attached map).
And I can't draw the blue line as you drew it. I don't draw blue lines. I tell the game that Legaspi is on 2 Sea Areas, I tell it which Sea Areas, and I tell it the same for the hex SE of Legaspi. Then the game draws the line it wants to draw.

[Froonp]

With the blow up effect in the scale of the map on the Pacific, this kind of thing is neither surprising nor bothering me. There is no great continent-like mass of land barring the way to ships from Legaspi (or Auckland, NZ) to go into the South China Sea (or Tasman Sea). The way is just 50 miles away.

There are a score of other abstractions in the Sea Areas on the WiF FE map, this is only one more.
For example, was the the Skaggerat the real bottleneck to enter the Baltic, as the WiF FE map shows ? No, it was the straits around Copenhagen. So why is the Sea Area boundary at the wrong place ? Other example, was the Plymouth-Brest the real Bottleneck to pass the British Channel ? No, it rather was the Dover-Calais area, so why is the Sea ARea boundary at the wrong place.

[paulderynck]

ORIGINAL: Shannon V. OKeets

I intend to use the style developed by Chris for CWIF in MWIF. It is less dependent on the pen of the artist. The WIF FE map sea area boundaries were drawn using a straight line for the most part. You can see the problems this creates in Patrice's examples at Lisbon, Malta, and La Spezia. The line's relationship to the sea area hex dot can have a razor thin separation. At 8 levels of zoom, that isn't going to work for MWIF.

Now this doesn't achieve the same result for Istanbul (comparing WIF FE to MWIF). Are there any other places?

I've been thinking about this some more since last night, and since there are exceptions to the blue line following the hex border, why can't the blue line be redrawn to fix the impression of non-invadeability for the veteran WiFFErs? After all they will be the corps of the initial buyers and the Newbies have to learn the system regardless.

Is there something about the blue line that affects the program's decision on invadeability? If not then, the lines can be corrected for Tripoli, Liverpool, Kristiansand, and Plymouth. It can be redrawn to make MWiF match WiFFE for Narvik and it is already correct for Istanbul.

ORIGINAL: Shannon V. OKeets
The problem is that the fundamental data is the hex's relationship to sea areas, with the relationship of a port to sea areas being one and the same as the relationship of the hex to the sea areas. So you could move a naval unit into/out of Legaspi from either sea area. That is how the code is written for all ports on the map.

I hope you aren't saying that the presence of a port is used to determine invadeability somehow? There are many ports that cannot be invaded - Trieste for example.

[Shannon V. OKeets]

ORIGINAL: paulderynck

ORIGINAL: Shannon V. OKeets

I intend to use the style developed by Chris for CWIF in MWIF. It is less dependent on the pen of the artist. The WIF FE map sea area boundaries were drawn using a straight line for the most part. You can see the problems this creates in Patrice's examples at Lisbon, Malta, and La Spezia. The line's relationship to the sea area hex dot can have a razor thin separation. At 8 levels of zoom, that isn't going to work for MWIF.

Now this doesn't achieve the same result for Istanbul (comparing WIF FE to MWIF). Are there any other places?

I've been thinking about this some more since last night, and since there are exceptions to the blue line following the hex border, why can't the blue line be redrawn to fix the impression of non-invadeability for the veteran WiFFErs? After all they will be the corps of the initial buyers and the Newbies have to learn the system regardless.

Is there something about the blue line that affects the program's decision on invadeability? If not then, the lines can be corrected for Tripoli, Liverpool, Kristiansand, and Plymouth. It can be redrawn to make MWiF match WiFFE for Narvik and it is already correct for Istanbul.

ORIGINAL: Shannon V. OKeets
The problem is that the fundamental data is the hex's relationship to sea areas, with the relationship of a port to sea areas being one and the same as the relationship of the hex to the sea areas. So you could move a naval unit into/out of Legaspi from either sea area. That is how the code is written for all ports on the map.

I hope you aren't saying that the presence of a port is used to determine invadeability somehow? There are many ports that cannot be invaded - Trieste for example.

As Patrice, described, the program draws the sea area boundaries (calling them blue lines can be misleading) based on the data. It was a real nightmare to get that code correct: 60-80 hours. I had tried to straighten it out in 2005 but I didn't understand enough about the CWIF code to figure out what was/should be coded. It was only earlier this year (2008) that I revisited that code and was able to make it do what I wanted it to do. Legaspi, the northern Japanese port, and the islands around Rabual were the hardest to get right.

At no time does the program know what the land mass outlines/graphics look like. It only knows that an island is an island if the data says there are all sea hexes/all sea hexsides on all 6 sides of a hex. Add data entries that Moscow is surrounded by all sea hexsides, and the program will consider Moscow an island, regardless of what the graphics look like.

Ports are data that provide added functionality to a hex. A hex's relationship to sea areas is data driven. If the data says a port is in a hex, then the hex recieves the 'benefits' of being a port. The same is true of cities, factories, resources, etc.

Ports have zero interaction with invasions - there are no rules one way or another (aside from notional unit stuff). It is the hex that is invaded and it is the hex's relationship to sea areas that determines whether the hex can be invaded from sea areas or not.

===
If you and Patrice can work this out, with hopefully the involvement of others (Norman42, Brian Brian, and others: you know who you are), I will defer to your group consensus. Right now I am deep into the code for destroying units - the 27 different places in the sequence of play where that occurs. That requires/consumes most of my time and concentration.

[brian brian]

There is a hex in paper WiF:FE that takes some getting used to in this regard, that being Batavia. The port symbol is only one one zone, but you can use the port to enter two zones. How about this for a solution - make Legaspi the example in the tutorial. It could be the new Batavia. Think carefully about trying to explain it to a new player without it looking very contradictory to several other one-zone ports, like Cebu only a few hexes away.

As for drawing the zone boundaries, like I said about Liverpool last year, if it ain't broke, don't fix it. The current paper system works perfectly fine. Why confuse the experienced players to no purpose? I _could_ right-click the map to identify the invadable hexes and then scratch my head about why Liverpool is invadable from the Faeroes Gap. Or I could just look at the boundary drawn to the center of the hex. For new players, however you solve this has to be taught in a tutorial anyway.

Look how this question re-appeared ... over a strategy question after looking at a screen shot. I think something that could be conveyed by a mere visual is far more elegant than making it into something that has to be conveyed by another mouse-click. There are going to be thousands of mouse-clicks in this game already.

[Froonp]

Steve, in a similar way to what we do for the lake and river graphics, that we draw in hex where the data show no lake or river, wouldn't it be possible to have a CSV map data file for drawing exceptional Sea Area boundaries connections to some exceptional land hexes ?

The CSV file would show the coordinates of the hex, and then a 1-12 number that would "connect" the Sea Area border to a place on the hexagon placed at the 1-12 O'Clock positions on its cirumference (12 being the top position and 6 the bottom one) (similar to how cities, ports, symbols are shown inside the hex, but here it would be on the cirumference).

That way we could have the Sea Area boundary connect to pretty much the place we would prefer.

For example, for Plymouth, I would connect it to position 7 (middle of the SW hexside).

[Shannon V. OKeets]

ORIGINAL: brian brian

There is a hex in paper WiF:FE that takes some getting used to in this regard, that being Batavia. The port symbol is only one one zone, but you can use the port to enter two zones. How about this for a solution - make Legaspi the example in the tutorial. It could be the new Batavia. Think carefully about trying to explain it to a new player without it looking very contradictory to several other one-zone ports, like Cebu only a few hexes away.

As for drawing the zone boundaries, like I said about Liverpool last year, if it ain't broke, don't fix it. The current paper system works perfectly fine. Why confuse the experienced players to no purpose? I _could_ right-click the map to identify the invadable hexes and then scratch my head about why Liverpool is invadable from the Faeroes Gap. Or I could just look at the boundary drawn to the center of the hex. For new players, however you solve this has to be taught in a tutorial anyway.

Look how this question re-appeared ... over a strategy question after looking at a screen shot. I think something that could be conveyed by a mere visual is far more elegant than making it into something that has to be conveyed by another mouse-click. There are going to be thousands of mouse-clicks in this game already.

Ah, but it is broke from my point of view. That is because the drawing of the sea boundaries in WIF FE is done by the hand of an artist - it is not data driven. I have no interest in writing code (or creating a lookup table) so each of the sea area boundaries are drawn "just so".

For instance, I already have 300+ lines of code that detemine which exact pixel within a hex's rectangle is the vertex of the hexagon, for each of the 6 vertices, for each of the 8 zoom levels. That enables the program to draw the hexes so they look like a hexagon lattice. It is really ugly code, but essential to render a hex map. And it has the benefit of working for every hex (there is some exception code for handling the top and bottom of the map).

Drawing each sea area boundary "by hand" for all 8 zoom levels, ain't gonna happen.

Let me reiterate my point with another example, the rivers that are drawn on the map have no effect on game play. They are just pretty pictures. What determines the ability of units to receive the benefits of a river defense is the data file that defines which hexsides have rivers separating two hexes. It took a lot of work by Patrice and myself to make sure that the river pictures and the data file matched (7000+ entries).

[Shannon V. OKeets]

ORIGINAL: Froonp

Steve, in a similar way to what we do for the lake and river graphics, that we draw in hex where the data show no lake or river, wouldn't it be possible to have a CSV map data file for drawing exceptional Sea Area boundaries connections to some exceptional land hexes ?

The CSV file would show the coordinates of the hex, and then a 1-12 number that would "connect" the Sea Area border to a place on the hexagon placed at the 1-12 O'Clock positions on its cirumference (12 being the top position and 6 the bottom one) (similar to how cities, ports, symbols are shown inside the hex, but here it would be on the cirumference).

That way we could have the Sea Area boundary connect to pretty much the place we would prefer.

For example, for Plymouth, I would connect it to position 7 (middle of the SW hexside).

If you look at the WIF FE map you will see that the sea area boundaries do more than just 'arrive' at the coastal hex. They also traverse all the open sea hexes and go around islands (e.g., the Pacific map). What you are proposing is a look up table, that would be of monstrous size.

Furthermore, I have no interest in rewriting code that is both complete and accurate just to duplicate the visual of hand drawn graphics.

[Froonp]

ORIGINAL: Shannon V. OKeets

ORIGINAL: Froonp

Steve, in a similar way to what we do for the lake and river graphics, that we draw in hex where the data show no lake or river, wouldn't it be possible to have a CSV map data file for drawing exceptional Sea Area boundaries connections to some exceptional land hexes ?

The CSV file would show the coordinates of the hex, and then a 1-12 number that would "connect" the Sea Area border to a place on the hexagon placed at the 1-12 O'Clock positions on its cirumference (12 being the top position and 6 the bottom one) (similar to how cities, ports, symbols are shown inside the hex, but here it would be on the cirumference).

That way we could have the Sea Area boundary connect to pretty much the place we would prefer.

For example, for Plymouth, I would connect it to position 7 (middle of the SW hexside).

If you look at the WIF FE map you will see that the sea area boundaries do more than just 'arrive' at the coastal hex. They also traverse all the open sea hexes and go around islands (e.g., the Pacific map). What you are proposing is a look up table, that would be of monstrous size.

Furthermore, I have no interest in rewriting code that is both complete and accurate just to duplicate the visual of hand drawn graphics.

I am not proposing that the whole Sea Area boundary be defined in a CSV file, only a dozen or so of Sea Area Boundaries connections to selected hexes.

The game would see that Plymouth ought to have a Sea Ara Boundary traced so that it joins its initial at sea starting position to the position 7 on the hexagon of Plymouth. The rest of the Sea Area boundary would not change. It is similar to how railways flow. They are automatic, but in some selected hexes we made it connect to a specific place in the hex.