Under Development: VARbot
First off ... Hey Bro
Second, I think it would be better to store a matrix of game probabilities to reduce Monte-Carlo time.
Third, I think the bot should do a fairly good calc to check for the turn goal, but then should chew the problem up one territory at a time, reevaluating after each capture. This will take some time and is why I advocate the direct calc method rather than the Monte-Carlo approach. I believe this is somewhat closer to how we play, making a quick check of where we want to go and then reevaluate as we go.
Got to go, but I'll check back later.
Oh, and BTW, I haven't played a game here yet, so I don't know what the heck I'm talking about anyway.
Second, I think it would be better to store a matrix of game probabilities to reduce Monte-Carlo time.
Third, I think the bot should do a fairly good calc to check for the turn goal, but then should chew the problem up one territory at a time, reevaluating after each capture. This will take some time and is why I advocate the direct calc method rather than the Monte-Carlo approach. I believe this is somewhat closer to how we play, making a quick check of where we want to go and then reevaluate as we go.
Got to go, but I'll check back later.
Oh, and BTW, I haven't played a game here yet, so I don't know what the heck I'm talking about anyway.
- varoadstter
- Luxer
- Posts: 67
- Joined: Wed Jan 23, 2008 9:22 am
- Location: Raleigh, NC
Hey Dino,
Yeah, we talked about that on the phone the other night and I'm still holding to my guns for the time being. There's really 3 different ways this could be approached:
I have seen marathon games with battles with far in excess of 1000 armies a side. Imagine generating matrices that large and still not have covered every circumstance.
Now, on your second point regarding performing move by move evaluations and how you believe that more closely resembles how humans play. I actually disagree with you completely here. I think humans preplan entire turns in their head prior to placing and attacking even if they aren't completely aware that they are doing it. They are able to quickly adapt if there's a reason to do so (bad dice, miscounting, etc). For my bot to be able to compete on an equal footing I will have to do the same.
Yeah, we talked about that on the phone the other night and I'm still holding to my guns for the time being. There's really 3 different ways this could be approached:
- Use a "rule of thumb" estimate to determine if you have sufficient strength to win a given battle.
Store a matrix as you suggest which solves the one major weakness in the rule of thumb - precision.
Simulate attacks repeatedly to arrive at an answer. Done properly, the matrices should have the same data the simulation would generate.
I have seen marathon games with battles with far in excess of 1000 armies a side. Imagine generating matrices that large and still not have covered every circumstance.
Now, on your second point regarding performing move by move evaluations and how you believe that more closely resembles how humans play. I actually disagree with you completely here. I think humans preplan entire turns in their head prior to placing and attacking even if they aren't completely aware that they are doing it. They are able to quickly adapt if there's a reason to do so (bad dice, miscounting, etc). For my bot to be able to compete on an equal footing I will have to do the same.
I have made some preliminary calculations in this area. At present, I have a table of outcomes for anything from 2-21 armies attacking a single defender, 2-21 armies attacking two defenders and 2-21 armies attacking three defenders. From this, I can establish the median outcome, or I could skew it to a -5% or -10% prediction (e.g. using the 45% attacker effectiveness or 40% effectiveness) or any other user defined value. Of course, I'd have to extend this data out to some very large number of armies, but at some point, the calculation approaches a limit that is very stable and has a similar stable standard deviation. This is what I would offer in place of Monte Carlo calcs in order to speed things up.
There are three steps in performing this calc, as I see it. First, you have to develop the possible combinations to be studied. This by itself will produce a fantastic number of run loops that need to be crunched. The second step is to determine the probability of getting to the end of a specific combination. The third step is to "score" the final position. In this way, the Bot runs much like a modern chess program.
Consider having all of SA and it is your (the Bots) turn.
You can attack Central Am or N. Africa.
round 1 you get two branches and the scores are easy to compute.
From each of these two R1 events, you have new options. My memory may be poor but I believe there are two above C America and four from N. Africa.
round 2 we have to score CW (C America + W. US), CE, NWe (North Africa + W. Europe), NEg, NEa (North Africa + E. Africa) & NC. With the solutions from R1 you can reduce time and combine the probabilities by piggybacking on R2 assuming you don't run out of storage. In round three, the problem begins to blow up. It is because the permutations can become large that I advocate storing the precomputed probabilities.
As for a rule of thumb guide, I think this will have a place in a future version, but is not required during this initial development. I think it degrades the merit of what you want right now. But I do believe over time we will discover it can be used. The rule of thumb might be to accept the 45% result as a guide for determining losses during some initial tree pruning, but doing the exact calcs on the highest scoring branches.
On the other hand, computers may be so fast now, that this is all moot. As an engineer, I still run apps which do not include graphics that require me to wait several minutes to get answers. Therefore, I tend to avoid looping when I am able to prepare such a matrix. Also, I am no code writer. I am a longhand calc kinda guy. This is also why I rely on tables of information to look up preliminary answers to advance to a final solution.
I look forward to meeting you and your bot OTB. I may even have a little matrix at my side when we do.
There are three steps in performing this calc, as I see it. First, you have to develop the possible combinations to be studied. This by itself will produce a fantastic number of run loops that need to be crunched. The second step is to determine the probability of getting to the end of a specific combination. The third step is to "score" the final position. In this way, the Bot runs much like a modern chess program.
Consider having all of SA and it is your (the Bots) turn.
You can attack Central Am or N. Africa.
round 1 you get two branches and the scores are easy to compute.
From each of these two R1 events, you have new options. My memory may be poor but I believe there are two above C America and four from N. Africa.
round 2 we have to score CW (C America + W. US), CE, NWe (North Africa + W. Europe), NEg, NEa (North Africa + E. Africa) & NC. With the solutions from R1 you can reduce time and combine the probabilities by piggybacking on R2 assuming you don't run out of storage. In round three, the problem begins to blow up. It is because the permutations can become large that I advocate storing the precomputed probabilities.
As for a rule of thumb guide, I think this will have a place in a future version, but is not required during this initial development. I think it degrades the merit of what you want right now. But I do believe over time we will discover it can be used. The rule of thumb might be to accept the 45% result as a guide for determining losses during some initial tree pruning, but doing the exact calcs on the highest scoring branches.
On the other hand, computers may be so fast now, that this is all moot. As an engineer, I still run apps which do not include graphics that require me to wait several minutes to get answers. Therefore, I tend to avoid looping when I am able to prepare such a matrix. Also, I am no code writer. I am a longhand calc kinda guy. This is also why I rely on tables of information to look up preliminary answers to advance to a final solution.
I look forward to meeting you and your bot OTB. I may even have a little matrix at my side when we do.
The quick and dirty calculation is not to tell you if you should but to answer the automatic no situations. (The automatic yes is still dependent on pathing.) If the opponent has 10x the armies don't bother simulating the attack it won't succeed. This calculation doesn't have to be extremely precise if its conservative enough and it could prevent you from looking at some the players letting you spend your time better.
- varoadstter
- Luxer
- Posts: 67
- Joined: Wed Jan 23, 2008 9:22 am
- Location: Raleigh, NC
VARBot is heading quickly to the alpha milestone. I had said I was aiming for March 1st but it will probably be closer to the 3rd as I want to get some more hours on it over the weekend. I am having a lot of fun writing the strategy portion of the bot right now and it's coming together pretty well. Something that human players may not like is I have got an absolutely elegant Turtling strategy fully implemented. When VARBot thinks it's in trouble and needs to become an uninteresting target, it does an awesome job of it.
Basically:
When it holds less than two cards, there are more than 2 players left ( including VARBot), it's the weakest player remaining and it's weaker than half the average strength of the players remaining it's time to shut down. It will place any reenforments it gets on it's largest standing army, stops all attacks, and fortifies all armies in the direction of the largest army currently found in the cluster.
If game conditions change and the above no longer applies (e.g. there are now only 2 players left in the game), it starts attacking again.
It was surprizingly easy to code this up using the infrastructure I had. Mostly, all I added was a routine to the Shape class to create fortify commands to cause armies to fortify towards the largest army in the current cluster.
Oh, and I'm still thinking about whether or not to make my code public. I'm still leaning towards yes but I need to check into a couple things first.
Basically:
When it holds less than two cards, there are more than 2 players left ( including VARBot), it's the weakest player remaining and it's weaker than half the average strength of the players remaining it's time to shut down. It will place any reenforments it gets on it's largest standing army, stops all attacks, and fortifies all armies in the direction of the largest army currently found in the cluster.
If game conditions change and the above no longer applies (e.g. there are now only 2 players left in the game), it starts attacking again.
It was surprizingly easy to code this up using the infrastructure I had. Mostly, all I added was a routine to the Shape class to create fortify commands to cause armies to fortify towards the largest army in the current cluster.
Oh, and I'm still thinking about whether or not to make my code public. I'm still leaning towards yes but I need to check into a couple things first.
- The Wontrob
- Ninja Doughboy
- Posts: 2792
- Joined: Wed Oct 03, 2007 9:56 pm
- Location: The Pan-Holy Church, frollicking
- varoadstter
- Luxer
- Posts: 67
- Joined: Wed Jan 23, 2008 9:22 am
- Location: Raleigh, NC
Hey 3DA,
I've had some other things crop up. I do intend to get finished up with my alpha version soon. I was showing my code to another software engineer friend of mine and he was pretty excited about it, too. I think my biggest problem is I want to write everything right away instead of just putting it into a good state to get some playtesting done.
Anyway, thanks for checking in. I know this has run past my target date but I am planning on getting something out soon.
I've had some other things crop up. I do intend to get finished up with my alpha version soon. I was showing my code to another software engineer friend of mine and he was pretty excited about it, too. I think my biggest problem is I want to write everything right away instead of just putting it into a good state to get some playtesting done.
Anyway, thanks for checking in. I know this has run past my target date but I am planning on getting something out soon.
- n00less cluebie
- Lux Cantor
- Posts: 8377
- Joined: Sun Jan 06, 2008 8:55 am
- Location: At the Official Clown Reference Librarian Desk--'All the answers you weren't looking for.'
- Contact:
It seems to me the way to "participate in the early game dance" is to do what 3DA does. That is, identify who is "controlling" a continent.
Something like
If NumberofArmiesInContinent (PlayerX) >= MinimumPercentage * NumberofArmiesInContinent (All Players)
then farm that continent. I.e. Do not add armies to this continent, and use any armies to attack any empty countries in order to gain a card.
Basically, if the bot finds that a continent is more than x% controlled by a single player, the bot places elsewhere.
What the MinimumPercentage is, can be debated, whether it's 50% of the total number of armies or less/more. The bot can use the same logic to determine whether or not to TRY for that continent, perhaps placing his own armies in there, and if the number of armies in the continent is not enough to take it over, to "farm" one of the occupied continents.
Often there will be multiple continents to farm, and the bot can choose which one to farm first based on which continent has the higher percentage of ownership by one player. If there are no empty countries for the bot to farm, well, it's up to the owner of the continent to make a path for the bot, or coordinate one with the other players.
Something like
If NumberofArmiesInContinent (PlayerX) >= MinimumPercentage * NumberofArmiesInContinent (All Players)
then farm that continent. I.e. Do not add armies to this continent, and use any armies to attack any empty countries in order to gain a card.
Basically, if the bot finds that a continent is more than x% controlled by a single player, the bot places elsewhere.
What the MinimumPercentage is, can be debated, whether it's 50% of the total number of armies or less/more. The bot can use the same logic to determine whether or not to TRY for that continent, perhaps placing his own armies in there, and if the number of armies in the continent is not enough to take it over, to "farm" one of the occupied continents.
Often there will be multiple continents to farm, and the bot can choose which one to farm first based on which continent has the higher percentage of ownership by one player. If there are no empty countries for the bot to farm, well, it's up to the owner of the continent to make a path for the bot, or coordinate one with the other players.
- kitty on catnip
- Lux Elder
- Posts: 2209
- Joined: Tue Jun 06, 2006 12:34 pm
- Location: BACK IN THE FORUMS...
- Contact:
- kitty on catnip
- Lux Elder
- Posts: 2209
- Joined: Tue Jun 06, 2006 12:34 pm
- Location: BACK IN THE FORUMS...
- Contact:
just to extend, I'd say...I will post an example, and many different scenarios for classic 0% 4 6 8 , starting from round 1, to round 10
each round will have it's own division, for you need to look at things, as they progress. each round changes, therefore, the bot should also change.
there are thousands of different scenarios that could occur. A well tuned bot only needs to know afew of the most important, more occuring scenarios. Even most humans do not understand them. program a bot to understand a few op ening scenarios, and how they progress, and you have a bot that can beat humans. consistently.
first off, a bot that speaks to humans. 'Please farm oz' 'Leave africa', etc, would be a totally brilliant addition. obviously humans use chat, to let other humans understand their intentions. Bots , IMO should do the same.
A bot that does not asshat. in classic, 0%, a bot should never attack remotes, unless they feel it is in their best interest.
A bot should never hit income, unless it is their best interest, and not making another player weak.
These 3 things, asshatting, hitting income/ remotes randomly, and using chat to reflect intentions are the most important, IMO, to compare a bot to a human.
A more elaborate reply will be posted shortly in the next few days. I will need time to collect informatino, and form judgements based off multiple starting scenarios. and for it to be coherent, and simple.
A simple bot, is a perfect bot. make it too complicated, and I feel it would have a difficult time reacting to multiple scenarios, because it starts to 'think' too much.
do we agree on these points?
each round will have it's own division, for you need to look at things, as they progress. each round changes, therefore, the bot should also change.
there are thousands of different scenarios that could occur. A well tuned bot only needs to know afew of the most important, more occuring scenarios. Even most humans do not understand them. program a bot to understand a few op ening scenarios, and how they progress, and you have a bot that can beat humans. consistently.
first off, a bot that speaks to humans. 'Please farm oz' 'Leave africa', etc, would be a totally brilliant addition. obviously humans use chat, to let other humans understand their intentions. Bots , IMO should do the same.
A bot that does not asshat. in classic, 0%, a bot should never attack remotes, unless they feel it is in their best interest.
A bot should never hit income, unless it is their best interest, and not making another player weak.
These 3 things, asshatting, hitting income/ remotes randomly, and using chat to reflect intentions are the most important, IMO, to compare a bot to a human.
A more elaborate reply will be posted shortly in the next few days. I will need time to collect informatino, and form judgements based off multiple starting scenarios. and for it to be coherent, and simple.
A simple bot, is a perfect bot. make it too complicated, and I feel it would have a difficult time reacting to multiple scenarios, because it starts to 'think' too much.
do we agree on these points?
- varoadstter
- Luxer
- Posts: 67
- Joined: Wed Jan 23, 2008 9:22 am
- Location: Raleigh, NC
I like your thinking and I welcome all input. Keep the ideas and thoughts coming!
I have been on hiatus from the project since things at work got heavy (I am the lead developer for the Blackberry team where I work). Our project is in Java so when I get home at the end of the day the last thing I want to do is to slog through even more Java code. We are due to ship our latest work at the end of June and there is typically a lul after a release. I will definitely be looking to occupy my mind with *something* once July rolls around and at this point VARbot is the top thing on my list of fun stuff to do. That and play tons of correspondence chess games over at Chess@Work, lol.
Just wanted everyone to know this is not dead.
I have been on hiatus from the project since things at work got heavy (I am the lead developer for the Blackberry team where I work). Our project is in Java so when I get home at the end of the day the last thing I want to do is to slog through even more Java code. We are due to ship our latest work at the end of June and there is typically a lul after a release. I will definitely be looking to occupy my mind with *something* once July rolls around and at this point VARbot is the top thing on my list of fun stuff to do. That and play tons of correspondence chess games over at Chess@Work, lol.
Just wanted everyone to know this is not dead.
- varoadstter
- Luxer
- Posts: 67
- Joined: Wed Jan 23, 2008 9:22 am
- Location: Raleigh, NC
Some complication is inevitable for what I intend to build. Because my bot will gather game information as things unfold it works optimally (according to it's perception of optimal) for any given situation on any given map. Of course, the bot isn't out there yet so it's idea of optimal is likely to have to undergo some work once I see it performing in the wild.kitty on catnip wrote:A simple bot, is a perfect bot. make it too complicated, and I feel it would have a difficult time reacting to multiple scenarios, because it starts to 'think' too much.
do we agree on these points?
Regardless of the complexities of Lux, the actual turn to turn tactics are fairly finite (I purposefully did not say this regarding metagame considerations). If my bot determintes, for example, it's time to kill an opponent based on it's ability to evaluate it's chances of success and it's evaluation of the game state after eliminating an opponent (usually positive), then that's all there is to it. If it's weak, it may decide it doesn't want to become a target and decide to turtle (which it does marvelously already, BTW).
Where it get's sticky is in the interaction between itself and humans. It's quite difficult to programatically understand if a given action would be considered "asshattery" but there are some general guidelines that can be used as a starting point. Trouble is, one person's asshat move is another's brilliant strategy. It's non-trivial to say the least but I think it will be fascinating to try. What will suck, though, is having a bot that actually can play in a way that humans do and still have it subject to Bots-first. In effect, that would be the same as having a boxer with one arm tied behind it's back as it would be the express goal of the humans to asshat the bot. My only way to fight back against this would be to change tactics if the bot feels like it is being asshatted itself! You can already see that this will cause some problems - I certainly do at least!
- kitty on catnip
- Lux Elder
- Posts: 2209
- Joined: Tue Jun 06, 2006 12:34 pm
- Location: BACK IN THE FORUMS...
- Contact:
varo, I must disagree with this statment:
An asshat to one, is brilliant to another.
there is definitely in classic risk, 0% 4 6 8, a definitive line that seperates a constructive play from one that asshats.
as before, someone mentioned you should start the bot off with classic, the setting that is most preferred.
when I said simple, I do not mean to undermine the integrity or complexity of your programming. what I am trying to say, (since I don't know a lick of programming languages) , is that there are a few 'simple' rules to follow, when playing classic.
Kind of like...a mantra. Some things so important, yet simple, that someone should repeat over and over and over...for it to be the highest law.
"I will not weaken another player needlessly"
"I will not weaken myself needlessly"
"I will take one country at a time, until I can secure a bonus"
"I will always attack open countries, rather than countries with armies in them"
"I will not attack another players continent bonus"
"I will always cash on 3, or 4 , after the first round of cashing"
these 6 'laws' encompass the essence of classic. If a bot can follow these laws appropriately, it will be respected by other humans. If a bot plays like a human, it will be treated as one. Reaper came close, but he asshats a damn lot. No offense to bertrand.
I think humans would be more willing to take 'asshat' first, then 'bot' first.
As a side note, before I forget, I am re-writing your country weight whatever it's called, lol. You have the right 'idea' about it, but your importance is off. You are thinking like this: 'Too create a quilt, you must knit. Therefore the edges are what you start with."
It's not entirely true...you sort of create the quilt, and then the edges come last.
Same is true in classic. The borders always come last. And here is why. Other players, if they so choose, must EXIT through those borders...why would you wish to start with them, or conquer them, if you must then move them in the the future...? it's illogical.
Countries WITHIN a continent are actually more important. To take NA, the worst starting position would be greenland, Alaska, and central america. Other players won't have room to farm, nor will they be able to exit. make sense?
If you would trust me to label each country a number, represented by weight, I would be honored. I've always wanted to see a bot that plays better than most humans. I think you are on the right track, but need help by another who understands the complexities of the game.
An asshat to one, is brilliant to another.
there is definitely in classic risk, 0% 4 6 8, a definitive line that seperates a constructive play from one that asshats.
as before, someone mentioned you should start the bot off with classic, the setting that is most preferred.
when I said simple, I do not mean to undermine the integrity or complexity of your programming. what I am trying to say, (since I don't know a lick of programming languages) , is that there are a few 'simple' rules to follow, when playing classic.
Kind of like...a mantra. Some things so important, yet simple, that someone should repeat over and over and over...for it to be the highest law.
"I will not weaken another player needlessly"
"I will not weaken myself needlessly"
"I will take one country at a time, until I can secure a bonus"
"I will always attack open countries, rather than countries with armies in them"
"I will not attack another players continent bonus"
"I will always cash on 3, or 4 , after the first round of cashing"
these 6 'laws' encompass the essence of classic. If a bot can follow these laws appropriately, it will be respected by other humans. If a bot plays like a human, it will be treated as one. Reaper came close, but he asshats a damn lot. No offense to bertrand.
I think humans would be more willing to take 'asshat' first, then 'bot' first.
As a side note, before I forget, I am re-writing your country weight whatever it's called, lol. You have the right 'idea' about it, but your importance is off. You are thinking like this: 'Too create a quilt, you must knit. Therefore the edges are what you start with."
It's not entirely true...you sort of create the quilt, and then the edges come last.
Same is true in classic. The borders always come last. And here is why. Other players, if they so choose, must EXIT through those borders...why would you wish to start with them, or conquer them, if you must then move them in the the future...? it's illogical.
Countries WITHIN a continent are actually more important. To take NA, the worst starting position would be greenland, Alaska, and central america. Other players won't have room to farm, nor will they be able to exit. make sense?
If you would trust me to label each country a number, represented by weight, I would be honored. I've always wanted to see a bot that plays better than most humans. I think you are on the right track, but need help by another who understands the complexities of the game.
- kitty on catnip
- Lux Elder
- Posts: 2209
- Joined: Tue Jun 06, 2006 12:34 pm
- Location: BACK IN THE FORUMS...
- Contact:
I just hypothesized on the different sublevels of luxers, and bots. It's sort of like a food chain, and also sort of like a psychological inquiry into how humans treat other human/bot components in the game.
so, here is the list. You were a bit anxious about how your bot will be treated in the realm of human games.
This might qualm some of your fears.
Human classes:
1.) Brilliant classic players.
2.) Amatuer classic players
3.) Noob classic players
4.) Complete ^*(%^*% idiot mother ^*(%(*^'ers (also known as asshats)
Bot classes:
1.) Superiour bot (Reaper)
2.) Mediocre bot (boscoe, bot 'o matic
3.) Basic bot (trotsky,
4.) Complete ^*(%^*% idiot mother ^*(%(*^'ers ( also known as killbot , or angry)
If you wish to combine these 2 classes together...then...You'd get something like this.
1.) Superiour classic human
2.) Ultra Superiour bot (varbot)
3.) Amateur classic human
4.) Superiour bot (reaper)
5.) Noob human
6.) Asshat human
.) All others
In my prediction, your bot will only be used by those more superiour to the game to begin with. Why would noobs or amateurs use a bot that will kick their ass every game? unless it's offline, for practice.
But, the only problem with bots being treated as inferior is due to raw. Bot games give less raw. Bots in generaly have less raw.
I feel if your bot creation can prove itself, Dustin should implement a standard raw equation to that bot, the same as any human. I think that should be fair, considering it would equal to humans. Let's hope he does this.
so, here is the list. You were a bit anxious about how your bot will be treated in the realm of human games.
This might qualm some of your fears.
Human classes:
1.) Brilliant classic players.
2.) Amatuer classic players
3.) Noob classic players
4.) Complete ^*(%^*% idiot mother ^*(%(*^'ers (also known as asshats)
Bot classes:
1.) Superiour bot (Reaper)
2.) Mediocre bot (boscoe, bot 'o matic
3.) Basic bot (trotsky,
4.) Complete ^*(%^*% idiot mother ^*(%(*^'ers ( also known as killbot , or angry)
If you wish to combine these 2 classes together...then...You'd get something like this.
1.) Superiour classic human
2.) Ultra Superiour bot (varbot)
3.) Amateur classic human
4.) Superiour bot (reaper)
5.) Noob human
6.) Asshat human
.) All others
In my prediction, your bot will only be used by those more superiour to the game to begin with. Why would noobs or amateurs use a bot that will kick their ass every game? unless it's offline, for practice.
But, the only problem with bots being treated as inferior is due to raw. Bot games give less raw. Bots in generaly have less raw.
I feel if your bot creation can prove itself, Dustin should implement a standard raw equation to that bot, the same as any human. I think that should be fair, considering it would equal to humans. Let's hope he does this.
- kitty on catnip
- Lux Elder
- Posts: 2209
- Joined: Tue Jun 06, 2006 12:34 pm
- Location: BACK IN THE FORUMS...
- Contact:
I had just a terribly brilliant idea...
I don't know if this is possible...but...
in lux, diplomacy is a big issue. Also, LONG TERM diplomacy!
is it possible, to store in your bots memory, a list of players it recognizes?
example:
VarBot: Player A, please farm oz.
Player A farms oz.
Then, the bot stores in it's memory that PlayerA farmed oz.
thus, when 3 players,
Player A: Please farm oz, VarBot
Player B: Please farm NA, VarBot
Player C: Please farm EU, VarBot
It weighs it's decision to farm, based off the number it has stored. Which player has farmed for it the most? That is it's answer on who to farm for first, if it so chooses.
IT WOULD BE AWESOME!!!!!!
I don't know if this is possible...but...
in lux, diplomacy is a big issue. Also, LONG TERM diplomacy!
is it possible, to store in your bots memory, a list of players it recognizes?
example:
VarBot: Player A, please farm oz.
Player A farms oz.
Then, the bot stores in it's memory that PlayerA farmed oz.
thus, when 3 players,
Player A: Please farm oz, VarBot
Player B: Please farm NA, VarBot
Player C: Please farm EU, VarBot
It weighs it's decision to farm, based off the number it has stored. Which player has farmed for it the most? That is it's answer on who to farm for first, if it so chooses.
IT WOULD BE AWESOME!!!!!!
- n00less cluebie
- Lux Cantor
- Posts: 8377
- Joined: Sun Jan 06, 2008 8:55 am
- Location: At the Official Clown Reference Librarian Desk--'All the answers you weren't looking for.'
- Contact:
Kitty brings up a very interesting idea, but the implementation would require server access to some sort of Varbot Knowledgebase. At this point we're really getting into the Learning Systems of AI, which would REALLY make for an interesting opponent; but considering the current state of the art of lux bots is to be completely self-contained, so that each game the bots essentially forgets what it learned from previous games.
The closest that's been developed so far, is Reapers "Bots first" list, where it reads the chatlog, and makes a list of players it won't team with by whoever says "bots first" more than once. This only remains on the server Reaper is running on, and only for as long as that server runs.
If you don't want to involve internet access for Varbot to access the database each time the server boots up with Varbot playing and read into memory the current knowledge base about players habits, and then record such knowledge after each game, the best locale to test this on (IMHO) is the MOTW server.
That's a server where the range of players is relatively small, and remains fairly constant, so that the bot can learn about the other players quicker, PLUS it would make it more difficult to win the MOTW, because whoever is in 1st place would probably be playing the most games, teaching Varbot more and more....
So then the question is: What can Varbot learn, how is that learning interpretted, how can this knowledge be stored (locally, and/or globally), accessed (locally and/or globally) and applied (what does Varbot do with the info). I think each of these topics can be addressed in a separate reply.
The closest that's been developed so far, is Reapers "Bots first" list, where it reads the chatlog, and makes a list of players it won't team with by whoever says "bots first" more than once. This only remains on the server Reaper is running on, and only for as long as that server runs.
If you don't want to involve internet access for Varbot to access the database each time the server boots up with Varbot playing and read into memory the current knowledge base about players habits, and then record such knowledge after each game, the best locale to test this on (IMHO) is the MOTW server.
That's a server where the range of players is relatively small, and remains fairly constant, so that the bot can learn about the other players quicker, PLUS it would make it more difficult to win the MOTW, because whoever is in 1st place would probably be playing the most games, teaching Varbot more and more....
So then the question is: What can Varbot learn, how is that learning interpretted, how can this knowledge be stored (locally, and/or globally), accessed (locally and/or globally) and applied (what does Varbot do with the info). I think each of these topics can be addressed in a separate reply.
- kitty on catnip
- Lux Elder
- Posts: 2209
- Joined: Tue Jun 06, 2006 12:34 pm
- Location: BACK IN THE FORUMS...
- Contact:
OK! I know I have been putting a lot of input into this, but I've been so excited to be back in the forums, and I've wanted to post here for soooooooo long!!!
Here is my country weight. I have done it 2 ways.
1.) Individually. Every country has a weight of 1-42
2.) Subdivided based on continent. Each country within the continent has a weight of 1-x (x being how many countries are within the cont)
So, here it is.
1.) Japan 16.) Great Britain 31.) Ukraine
2.) Yakutsk 17.) Venezuela 32.) Northern Af
3.) Afgan 18.) Brazil 33.) Indonesia
4.) India 19.) Southern Europe 34.) Ontario
5.) Mongolia 20.) South Africa 35.) Western Australia
6.) Irkutsk 21.) Madagascar 36.) Eastern Australia
7.) Ural 22.) Congo 37.) Quebec
8.) Siberia 23.) Easter Australia 38.) Western Canada
9.) Siam 24.) Western Australia 39.) Northwest Territory
10.) China 25.) New Guinea 40.) Greenland
11.) Middle East 26.) Scandinavia 41.) Central America
12.) Kamchatka 27.) Iceland 42.) Alaska
13.) Peru 28.) Egypt
14.) Argentina 29.) East Africa
15.) Norhtern Eu. 30.) Western Eu.
OK, so those are the list of most importance to least importance.
The reason I weighed asian countries the most, is simply because remotes are CRUCIAL to survival in classic. You need to balance defense and offense together...I prefer a stronger defense intially through rounds 1-5...I become very agressive , sort of like 'ATTACK MODE', after that. The list will make more sense after you digest my next list.
Start in DEFENSE MODE. Enter ATTACK MODE.
My next list. Subdivided by continent importance, then subdivided again into country importance within those continents. Then I will put 2 extra subdivisions, the first: Every country bordering any country within a continent bonus. FORTIFY RANGE. 2: Any country with 1 country in between. 'ATTACK + FORTIFY RANGE'.
Here it is:
1.) South America
1.) Peru
2.) Argentina
3.) Brazil
4.) Venezuela
FORTIFY RANGE: All countries within FORTIFY RANGE are same weight.
Central America, North Africa
ATTACK + FORTIFY RANGE: All countries in this range are equal weight.
Western US, Eastern US, Western EU, Eastern EU, Egypt, East Af. , Congo
2.) Europe:
1.) Northern Eu
2.) Great Britain
3.) Southern Eu
4.) Scandinavia
5.) Iceland
6.) Western Eu
7.) Ukraine
FORTIFY RANGE: Greenland, Ural, Afgan, ME, Egypt, North Af
A + F RANGE: Northwest Terr, Ontario, Quebec, Brazil, Congo, East Af, India, China, Siberia
3.) Africa:
1.) Southern Af
2.) Madagascar
3.) Congo
4.) Egypt
5.) East Af
6.) North Af
FORTIFY RANGE: Brazil, Western Eu, Southern Eu, ME
A + F RANGE: Argentina, Peru, Ven, Britain, Northern Eu, Ukraine, India, Afgan
4.) Australia:
1.) Eastern Oz
2.) Western Oz
3.) New Guinea
4.) Indonesia
FORTIFY RANGE: Siam
A + F RANGE: India, China
5.) North America
1.) Ontario
2.) Western US
3.) Eastern US
4.) Quebec
5.) Western Can
6.) NW Territory
7.) Greenland
8.) Central America
9.) Alaska
FORTIFY RANGE: Kam, Iceland, Ven
A + F RANGE: Peru, Brazil, Britain, Scand, (Yak, Irk, Mongolia, Japan)
***The countries in () ARE BAD countries***
they are never good to have when you wish to take NA...everyone is leaving through alaska, and you will never get a chance to move them in.
It is important to note, that.
A.) The bot must make sure he keeps his remotes. 2 remotes in the beginning DEFENSE MODE is a good number. Any more, and it will lock up asia. Have the bot farm to the best rated asian countries listed above, 1-7. Those are the best 'remote', or 'defense' countries.
B.) Make sure the bot fortifies all armies together in a single 'cluster'. This will give humans a chance to farm, and open room to exit, if they so choose. Make sure the Bot moves ALL of it's armies, if possible to the highest rated country listed within the continent.
Trust me, This is the best way to weight countries and continents. By fortifying all armies into the highest rated number it occupies, That is the most efficient way to secure a continent.
***One more tip. Once the bot secures a continent, A good rule of thumb is to set the bot to put no more armies on a border than what the border is equal too itself. Except SA or OZ. The borders should be double, 4-6 on each. NA/EU/AF, 5 at the most.
Noone will hit the bot, becuase they themselves would lose more armies than the bot will lose itself. make sense?
You need higher borders in sa, and oz, because they are highly desired as 'safe points'. They are more important for Defense, than their bonus itself.
I know it's a lot to take in, but To program a bot as a classic player, will be quite astonishing. I am so looking forward to meeting him on the board. (Might as well put a 'him' in place of 'it', because it will be more human than most humans that play the game.)
Here is my country weight. I have done it 2 ways.
1.) Individually. Every country has a weight of 1-42
2.) Subdivided based on continent. Each country within the continent has a weight of 1-x (x being how many countries are within the cont)
So, here it is.
1.) Japan 16.) Great Britain 31.) Ukraine
2.) Yakutsk 17.) Venezuela 32.) Northern Af
3.) Afgan 18.) Brazil 33.) Indonesia
4.) India 19.) Southern Europe 34.) Ontario
5.) Mongolia 20.) South Africa 35.) Western Australia
6.) Irkutsk 21.) Madagascar 36.) Eastern Australia
7.) Ural 22.) Congo 37.) Quebec
8.) Siberia 23.) Easter Australia 38.) Western Canada
9.) Siam 24.) Western Australia 39.) Northwest Territory
10.) China 25.) New Guinea 40.) Greenland
11.) Middle East 26.) Scandinavia 41.) Central America
12.) Kamchatka 27.) Iceland 42.) Alaska
13.) Peru 28.) Egypt
14.) Argentina 29.) East Africa
15.) Norhtern Eu. 30.) Western Eu.
OK, so those are the list of most importance to least importance.
The reason I weighed asian countries the most, is simply because remotes are CRUCIAL to survival in classic. You need to balance defense and offense together...I prefer a stronger defense intially through rounds 1-5...I become very agressive , sort of like 'ATTACK MODE', after that. The list will make more sense after you digest my next list.
Start in DEFENSE MODE. Enter ATTACK MODE.
My next list. Subdivided by continent importance, then subdivided again into country importance within those continents. Then I will put 2 extra subdivisions, the first: Every country bordering any country within a continent bonus. FORTIFY RANGE. 2: Any country with 1 country in between. 'ATTACK + FORTIFY RANGE'.
Here it is:
1.) South America
1.) Peru
2.) Argentina
3.) Brazil
4.) Venezuela
FORTIFY RANGE: All countries within FORTIFY RANGE are same weight.
Central America, North Africa
ATTACK + FORTIFY RANGE: All countries in this range are equal weight.
Western US, Eastern US, Western EU, Eastern EU, Egypt, East Af. , Congo
2.) Europe:
1.) Northern Eu
2.) Great Britain
3.) Southern Eu
4.) Scandinavia
5.) Iceland
6.) Western Eu
7.) Ukraine
FORTIFY RANGE: Greenland, Ural, Afgan, ME, Egypt, North Af
A + F RANGE: Northwest Terr, Ontario, Quebec, Brazil, Congo, East Af, India, China, Siberia
3.) Africa:
1.) Southern Af
2.) Madagascar
3.) Congo
4.) Egypt
5.) East Af
6.) North Af
FORTIFY RANGE: Brazil, Western Eu, Southern Eu, ME
A + F RANGE: Argentina, Peru, Ven, Britain, Northern Eu, Ukraine, India, Afgan
4.) Australia:
1.) Eastern Oz
2.) Western Oz
3.) New Guinea
4.) Indonesia
FORTIFY RANGE: Siam
A + F RANGE: India, China
5.) North America
1.) Ontario
2.) Western US
3.) Eastern US
4.) Quebec
5.) Western Can
6.) NW Territory
7.) Greenland
8.) Central America
9.) Alaska
FORTIFY RANGE: Kam, Iceland, Ven
A + F RANGE: Peru, Brazil, Britain, Scand, (Yak, Irk, Mongolia, Japan)
***The countries in () ARE BAD countries***
they are never good to have when you wish to take NA...everyone is leaving through alaska, and you will never get a chance to move them in.
It is important to note, that.
A.) The bot must make sure he keeps his remotes. 2 remotes in the beginning DEFENSE MODE is a good number. Any more, and it will lock up asia. Have the bot farm to the best rated asian countries listed above, 1-7. Those are the best 'remote', or 'defense' countries.
B.) Make sure the bot fortifies all armies together in a single 'cluster'. This will give humans a chance to farm, and open room to exit, if they so choose. Make sure the Bot moves ALL of it's armies, if possible to the highest rated country listed within the continent.
Trust me, This is the best way to weight countries and continents. By fortifying all armies into the highest rated number it occupies, That is the most efficient way to secure a continent.
***One more tip. Once the bot secures a continent, A good rule of thumb is to set the bot to put no more armies on a border than what the border is equal too itself. Except SA or OZ. The borders should be double, 4-6 on each. NA/EU/AF, 5 at the most.
Noone will hit the bot, becuase they themselves would lose more armies than the bot will lose itself. make sense?
You need higher borders in sa, and oz, because they are highly desired as 'safe points'. They are more important for Defense, than their bonus itself.
I know it's a lot to take in, but To program a bot as a classic player, will be quite astonishing. I am so looking forward to meeting him on the board. (Might as well put a 'him' in place of 'it', because it will be more human than most humans that play the game.)
- varoadstter
- Luxer
- Posts: 67
- Joined: Wed Jan 23, 2008 9:22 am
- Location: Raleigh, NC
Who is online
Users browsing this forum: No registered users and 48 guests