[XML] Value based continents

[degaston]

Concise description:

• Allow territories to be assigned an integer value
• Continents may then be defined based on the total value of the territories held

Specifics/Details:

• Add a subtag to <territory>: <value>#</value> - this defines the value of the territory.
• Add a subtags to <required>: <minvalue>#</minvalue> and <maxvalue>#<maxvalue> - in order for the continent to be held, the player must hold a total point value (of territories listed for the continent) between the minvalue and the maxvalue, inclusive.
• Modify the <bonus required> tag to support collections based on value.

How this will benefit the site and/or other comments:

• This would provide a great deal of flexibility to map makers for determining bonuses, conditional boundaries, winning and losing conditions, etc.

I noticed a map idea suggestion in the foundry for a map based on the US electoral college. I thought that there might be some potential for a map where the objective was to control 270 electoral votes. Unfortunately, after doing a little research, I found that "there are 51,199,463,116,367 different possible ways to accumulate 270, 271, 272 or 273 electoral votes." (http://godplaysdice.blogspot.com/2008/06/fuller-solution-to-tuesdays-electoral.html) Not something I want to try with the current XML, but if this suggestion was implemented, it would be trivial.

Who knows how else it might be used?

[koontz1973]

This can already be done in the normal way of using continents and overrides.

degaston, if you would like me to explain how to do it, then send me a PM and I will send you what the code would look like.

[degaston]

Thanks for the PM response, koontz, but what you described is not really what I was trying to do. I guess you saw the map suggestion that talked about voting districts, but that was not really what I was thinking about - just a starting point. I see you're in Hungary, so I don't know how much you know about the US system. There are 435 voting districts throughout the country, many of them with very complicated, twisting shapes, so I don't think the original idea is very workable.

My idea is not fully formed at this point, but for the purposes of discussing the xml, suppose there was a US map with 1 territory for each state. California is worth 55 electoral votes, Texas is worth 38, etc., on down to several states worth 3. There are a couple of states that can split their electoral votes, but that does not have to be considered here.

So the problem is to create an objective/continent that will be true when the player holds at least 270 electoral votes worth of states, and I don't really see how that can be done with continents and overrides. This is not about bonuses or the number of states that you hold. There might not even be any bonuses for holding states, other than for reinforcement purposes.

I believe that 51 trillion (not million) possible combinations figure is accurate. Here's a simplified example:

Suppose you had six territories with values of 1-6. The total point value for all those territories is 21, so you would need to hold 11 points to have a majority. In this case, there are 8 combinations that win: (6,5), (6,4,3), (6,4,2), (6,4,1), (6,3,2), (5,4,3), (5,4,2), & (5,3,2,1). If you have 7 territories, there are 14 winning combinations. With 8, there are 24. It appears to follow something similar to a Fibonacci sequence, and would certainly get into the billions of combinations with 50 territories. Having duplicate numbers, as in the actual problem, would just increase the possible combinations. It would be possible to hand code the combinations for a small number of territories, but it will quickly become impractical or impossible to do this for larger numbers.

I know my suggestion is not a minor change (and probably a long-shot for approval), but do you still think that what I'm talking about can be achieved with the current xml?

[BigBallinStalin]

I don't know much about coding or XML stuff, but I wish to clarify something:

how does this proposal differ from being allotted x-amount of troops per y-amount of territories?
(I know they're different, but I wanna know how so).

[koontz1973]

My idea is not fully formed at this point, but for the purposes of discussing the xml, suppose there was a US map with 1 territory for each state. California is worth 55 electoral votes, Texas is worth 38, etc., on down to several states worth 3. There are a couple of states that can split their electoral votes, but that does not have to be considered here.

So the problem is to create an objective/continent that will be true when the player holds at least 270 electoral votes worth of states, and I don't really see how that can be done with continents and overrides. This is not about bonuses or the number of states that you hold. There might not even be any bonuses for holding states, other than for reinforcement purposes.

You need to make each continent separately. Look at it like this below.

How many ways can you make ten using these ten different continents at different values?
1 is worth 10
2 is worth 9
3 is worth 8
4 is worth 7
5 is worth 6
6 is worth 5
7 is worth 4
8 is worth 3
9 is worth 2
10 is worth 1

Very quickly, I counted about 9 different ways.
(10)(9+1)(8+2)(7+3)(6+4)(5+4+1)(5+3+2)(7+1+2)(6+1+3) etc etc
You would need to make each way a different continent and give it a value of 0. Those continents go into the winning condition with a requirement that you hold any 1 of them to win.

If you have 7 territories, there are 14 winning combinations. With 8, there are 24. It appears to follow something similar to a Fibonacci sequence, and would certainly get into the billions of combinations with 50 territories. Having duplicate numbers, as in the actual problem, would just increase the possible combinations. It would be possible to hand code the combinations for a small number of territories, but it will quickly become impractical or impossible to do this for larger numbers.

Not imposable, just long.

I know my suggestion is not a minor change (and probably a long-shot for approval), but do you still think that what I'm talking about can be achieved with the current xml?

Yes. As I said, it really is a very long way to go about a winning condition or even to award a bonus, but it can be done as it is now. It all comes out when you use the value of a continent at 0.

how does this proposal differ from being allotted x-amount of troops per y-amount of territories?
(I know they're different, but I wanna know how so).

What degaston wants is to give a bonus or winning condition that has lots of different variables and not restricted to what most have on maps. Now we have maps with one or 2 winning conditions on them, imagine one with 50 different ways to win or even lose.

Another way to do this I worked out would be to use nested continents and over rides.

[degaston]

I don't know much about coding or XML stuff, but I wish to clarify something:

how does this proposal differ from being allotted x-amount of troops per y-amount of territories?
(I know they're different, but I wanna know how so).

What I'm talking about doesn't really have anything to do with bonuses, directly. This is about determining whether or not you hold a continent. A bonus may, or may not be given for holding a continent, but for the sake of discussion here, let's assume that there is no bonus given for holding 270 electoral votes, but that it will enable a conditional attack on the "White House" territory.

You can get to 270 by holding California, Texas, Florida, New York, Illinois, Pennsylvania, Ohio, Georgia, Michigan, North Carolina, and New Jersey. Or you could hold any of the other trillions of combinations that add up to 270. It doesn't work to define a certain number of territories to hold, because they all have different values. And there are too many combinations to code them individually.

[degaston]

How many ways can you make ten using these ten different continents at different values? ... Very quickly, I counted about 9 different ways.
(10)(9+1)(8+2)(7+3)(6+4)(5+4+1)(5+3+2)(7+1+2)(6+1+3) etc etc

I counted 29 ways, because if you hold something >10 (9+8), that should count also. And if you were trying to get to a majority (28), I estimate there would be about 66 ways.

it will quickly become impractical or impossible to do this for larger numbers.

Not imposable, just long.

If I coded 1 combination per second non-stop (I'm a really fast typist), it would take 1.6 million years to finish. I'd call that impossible. And isn't there a limit to the XML file size anyway? And if it was worth it to add collections to the xml in order to make it easier to code some maps, and reduce the xml file size, why not this?

I know my suggestion is not a minor change (and probably a long-shot for approval), but do you still think that what I'm talking about can be achieved with the current xml?

Yes. As I said, it really is a very long way to go about a winning condition or even to award a bonus, but it can be done as it is now. It all comes out when you use the value of a continent at 0.

Maybe we'll have to agree to disagree about what is possible.

how does this proposal differ from being allotted x-amount of troops per y-amount of territories?
(I know they're different, but I wanna know how so).

What degaston wants is to give a bonus or winning condition that has lots of different variables and not restricted to what most have on maps. Now we have maps with one or 2 winning conditions on them, imagine one with 50 different ways to win or even lose.

Another way to do this I worked out would be to use nested continents and over rides.

There's been some discussion about the Q*onqr map where a winning condition could be to hold 10 out of 19 territories. That would give 92,378 different winning conditions, but it can be done very easily because of the <required> tag. My suggestion just extends that idea to allow weighting the territories. It could function exactly like <required> if all territories are given the same value, but it would also allow some territories to become more important than others.

[Metsfanmax]

degaston is right. Besides the fact that solving this problem by defining each continent separately is just poor programming form*, it becomes basically impossible for complicated enough maps. I would really want to play the electoral college map, so +1 from me

*It's prone to error and is not automatic. For example, what happens if the number or value of territories changes in the beta stage? Imagine the headache.

[koontz1973]

If I coded 1 combination per second non-stop (I'm a really fast typist), it would take 1.6 million years to finish. I'd call that impossible. And isn't there a limit to the XML file size anyway? And if it was worth it to add collections to the xml in order to make it easier to code some maps, and reduce the xml file size, why not this?

This is correct, but you would just need to limit what you wanted. No one would ever dream of making a map with 51 billion ways to win. To get to that number, the site you linked to included all the different ways Nebraska, Maine and all other states can vote (they may not). As they have 5/4 votes each and can go 5/0, 4/1, 3/2, 2/3, 1/4, 0/5 and 4/0, 3/1, 2/2, 1/3, 0/4, these differences give you the huge number. The number is far less than the one quoted on the site.

As for the limit of xml file, we have some really huge ones now and no one has ever hit the limit yet. You would just need to limit the way you made a map.

There's been some discussion about the Q*onqr map where a winning condition could be to hold 10 out of 19 territories. That would give 92,378 different winning conditions, but it can be done very easily because of the <required> tag. My suggestion just extends that idea to allow weighting the territories. It could function exactly like <required> if all territories are given the same value, but it would also allow some territories to become more important than others.

And this IMO is not worth it. You want to make a very slight change to an already used xml feature to make one map. Why would bW make all the work for one map, and a map that in the thread most have said no to. But also, why do the work when as I above in a previous post, I showed how to do it. This might make it easier and might make it feasible to make a couple of maps, but it really is not worth the effort.

degaston is right. Besides the fact that solving this problem by defining each continent separately is just poor programming form*, it becomes basically impossible for complicated enough maps. I would really want to play the electoral college map, so +1 from me

*It's prone to error and is not automatic. For example, what happens if the number or value of territories changes in the beta stage? Imagine the headache.

Not a headache at all. If he went ahead and tried to make this map, this is how he would have to do it as this will never happen. Why would you do something to replicate something that can be already done?

This is more of a foundry type thread than a suggestion now. It might be best to move it to the foundry discussions.

[degaston]

... you would just need to limit what you wanted. No one would ever dream of making a map with 51 billion ways to win.

With the current xml, there would be 51 trillion ways to win, and they'd all have to be coded individually. If this change was made, there would be 1 way to win - hold 270 electoral votes. I don't know of too many other situations where you can achieve a 51 trillion to 1 efficiency ratio this easily.

To get to that number, the site you linked to included all the different ways Nebraska, Maine and all other states can vote (they may not). As they have 5/4 votes each and can go 5/0, 4/1, 3/2, 2/3, 1/4, 0/5 and 4/0, 3/1, 2/2, 1/3, 0/4, these differences give you the huge number. The number is far less than the one quoted on the site.

I updated the link in the first post to go to the actual analysis. No, they are not considering that some states can split their votes, so that is not a factor. And yes, 51,199,463,116,367 is the actual number of possible ways to get above 270 electoral votes, where losing any state would drop you below 270.

As for the limit of xml file, we have some really huge ones now and no one has ever hit the limit yet. You would just need to limit the way you made a map.

From http://www.conquerclub.com/forum/viewtopic.php?f=127&t=175704&hilit=collections+required+bonus+continent

The bonus collections is an update that give to us more flexibility with bonuses. It doesn't allow many new gameplay elements but it makes possible to shorten the code, and those of you who are more experienced with the developement of big maps know well how much can be a pain to code everything without having a long and big file. In addition, this update will solve an issue we had to face twice in past (Research&Conquer and War of Wizards), infact the game engine can't handle too big xml files.

People have hit the xml limit, and it was a problem. So they added the collections feature to the xml just to shorten the code and allow those two maps to be made, one of which was abandoned, and the other one is in its 5th year of development. In the mean-time, other mapmakers have found a use for collections. It looks like it came out about a month too late for Rourke's Drift - it would have saved you some time. But imagine if you had tried to make that map before the <required> tag was added. Logically, your map would still have been possible, but I suspect that the additional 17,622 continents that you would have needed to define would have exceeded the xml limit, so it would have been impossible for you to achieve the same result. (Not that anyone would even begin to work on a map knowing that they had to code that many continents.)

And this IMO is not worth it. You want to make a very slight change to an already used xml feature to make one map. Why would bW make all the work for one map, and a map that in the thread most have said no to. But also, why do the work when as I above in a previous post, I showed how to do it. This might make it easier and might make it feasible to make a couple of maps, but it really is not worth the effort.

Which is it - a very slight change, or a lot of work? I don't think it would be trivial, but I doubt that it would be any more difficult than adding the requirement tag.
Why would they do this? Probably not for one map idea that is not even a draft yet, but maybe because it would add a capability that other mapmakers could use in creative ways to make more interesting maps. See above for an example of how this was done in the past.

degaston is right. Besides the fact that solving this problem by defining each continent separately is just poor programming form*, it becomes basically impossible for complicated enough maps. I would really want to play the electoral college map, so +1 from me

*It's prone to error and is not automatic. For example, what happens if the number or value of territories changes in the beta stage? Imagine the headache.

Not a headache at all. If he went ahead and tried to make this map, this is how he would have to do it as this will never happen. Why would you do something to replicate something that can be already done?

The basic fact is that this particular scenario is IMPOSSIBLE to code with the current xml. Even if the xml file had no limit, and I automated the code generation so I didn't have to do it all by hand, no one has the time or the hard drive space to download a file that big. Other uses for this feature could be found which would otherwise be extremely inefficient and impractical to code.

Why would they do this?
1. It does not replicate something that can be done right now.
2. I don't know - why have they added new capabilities to the xml before?

[koontz1973]

1. It does not replicate something that can be done right now.

It does, maybe a bit long winded but it can be done.

2. I don't know - why have they added new capabilities to the xml before?

Because they are not limited to what can be done to them and are not themed to one type of map. When you consider that this can be done but on a smaller scale, the idea of making having this done just so one map can be made seems a waste of bigWhams time and effort.

What other maps can this be used for?

[Metsfanmax]

1. It does not replicate something that can be done right now.

It does, maybe a bit long winded but it can be done.

2. I don't know - why have they added new capabilities to the xml before?

Because they are not limited to what can be done to them and are not themed to one type of map. When you consider that this can be done but on a smaller scale, the idea of making having this done just so one map can be made seems a waste of bigWhams time and effort.

What other maps can this be used for?

With respect, we already have one or two specific map ideas that can be created with this mechanism. We usually have zero specific ideas when we submit XML suggestions. There's nothing so specific about this idea that it could only be used for the electoral college map.

Again, the electoral college map is impossible with current XML technology. It's just never going to happen this way; it even sounds like the Foundry wouldn't allow it (and with good cause). If I were the admin I would simply never allow a map that required trillions of conditional checks every time an assault is processed. It's beyond the pale.

So if we want to move this out of Suggestions, we would need a good reason from the Foundry team on why this would make things worse for the map situation.

[chapcrap]

I'd kind of agree with Mets and degaston here I think. If this is something that makes the coding a lot easier, then why not do it?

I truly don't understand all the features of the XML, so I can't be an expert here, but it sounds like this XML could get very verbose with this availability and may not even be able to completed because of character (?) limitations.

[degaston]

What other maps can this be used for?

Just off the top of my head... "The Battle of Gettysburg XVII - The Quenchening!" (I have no idea how many times it's been tried)

(Scene: Gettysburg battlefield scattered with officers and units of different types)


Code: Select all

Officers             Value
General              9
Lieutenant General   8
Major General        7
Brigadier General    6
Colonel              5
Lieutenant Colonel   4
Major                3
Captain              2
Lieutenant           1

Combat Troops   Value
Artillery       5
Cavalry         4
Infantry        3

Attacks:
Confederate assault on Cemetery Ridge requires 17 points worth of officers and 26 points worth of combat troops.
etc., etc.

Not saying that this is a perfect use of this feature, but I think there could be a lot of applications in detailed battle maps. It does not require very many items in a set before the possible combinations would exceed the limits of the current xml. Even for smaller combinations that would fit within the xml limits, coding, testing and debugging would all be complete nightmares. Who is going to go through hundreds or thousands (or more) of combinations to confirm that every one was coded correctly, and none were missed? How would you even test that? So new map ideas that could be done, will not, because it would be too inefficient.

This suggestion is in no way limited to one type of map, it gains a great deal of xml efficiency and flexibility at a relatively low cost, and I see very little difference in the justification for this vs. nested continents and collections. Both of those features were possible before they were implemented, but completely impractical for anything but extremely small sets.

I'm fine with this being moved if there is a better place for it.

[spiesr]

If one mapmaker wants this but the Foundry staff insists that it isn't something they desire at this time I don't see how we could submit this when there are other XML suggestions floating around that are demanded by more people...

[chapcrap]

If one mapmaker wants this but the Foundry staff insists that it isn't something they desire at this time I don't see how we could submit this when there are other XML suggestions floating around that are demanded by more people...

I do agree that it wouldn't be first on the XML wish list...

[Metsfanmax]

If one mapmaker wants this but the Foundry staff insists that it isn't something they desire at this time I don't see how we could submit this when there are other XML suggestions floating around that are demanded by more people...

We don't submit things based on whether there are other things that people want more, we submit them based on whether they are good for the site. Unless there is a drawback to this mechanism, and if enough people want it, we should submit it with the understanding that this is not at the top of the XML priority list.

[degaston]

I didn't expect that this would be rushed to production. I've thought of a couple of applications for it, and now that the idea is out there, maybe others will, too. I see a lot of creativity being applied to conditional borders, but none of those maps could have been started until the feature was implemented, per the official foundry rules:
2. Gameplay features must be compatible with the game engine's currently usable XML.