Game rules
200 views
Skip to first unread message
Andreas Flierl
May 12, 2012, 6:59:51 AM5/12/12
to scal...@googlegroups.com
Hi there,
after extensively hacking on scalatron bots with my collegues, we'd like to propose 2 changes to the game rules because we think they would make the game even more interesting in the long term:
1) The problem: bot score increases linearly with spawning more children bots. This is because the moment one bot eats a fluppet/zugar, a new one appears. We think this makes the game boring very quickly because instead of (few) smart bots you can simply throw a huge number of rather dumb bots on the field and increase your score into the millions.
We propose two possible solutions:
a) Make the price for new spawns increase exponentially. My idea would be something like 99 + 2^n, so the first spawn costs 100, the 2nd 101, the 3rd 103, the 4th 107… the 10th 1123, the 20th 1024675. Maybe the curve could be a little less steep but you get the idea. This would effectively limit the number of children bots.
b) Alternatively, spawn X fluppets / zugars initially, then every N rounds, spawn new fluppets / zugars up to a limit of Y fluppets / zugars. This would limit the maximum score you can get. I think this is far more boring than a)
2) The problem: snorgs are not scary enough. They hit for less than what you can get from eating a fluppet. This leads to a very easy strategy where you can more or less just ignore the snorgs. Therefore, I think it would be preferable and more interesting to have snorgs hit harder (like 200 or 250).
after extensively hacking on scalatron bots with my collegues, we'd like to propose 2 changes to the game rules because we think they would make the game even more interesting in the long term:
1) The problem: bot score increases linearly with spawning more children bots. This is because the moment one bot eats a fluppet/zugar, a new one appears. We think this makes the game boring very quickly because instead of (few) smart bots you can simply throw a huge number of rather dumb bots on the field and increase your score into the millions.
We propose two possible solutions:
a) Make the price for new spawns increase exponentially. My idea would be something like 99 + 2^n, so the first spawn costs 100, the 2nd 101, the 3rd 103, the 4th 107… the 10th 1123, the 20th 1024675. Maybe the curve could be a little less steep but you get the idea. This would effectively limit the number of children bots.
b) Alternatively, spawn X fluppets / zugars initially, then every N rounds, spawn new fluppets / zugars up to a limit of Y fluppets / zugars. This would limit the maximum score you can get. I think this is far more boring than a)
2) The problem: snorgs are not scary enough. They hit for less than what you can get from eating a fluppet. This leads to a very easy strategy where you can more or less just ignore the snorgs. Therefore, I think it would be preferable and more interesting to have snorgs hit harder (like 200 or 250).
Kind regards
Andreas
Andreas Flierl
May 12, 2012, 7:10:15 AM5/12/12
to scalatron
Oh, forgot to mention for 1a) that n is the number of total spawns of
your own bot _on the field_. That means that n would go down again if
a spawn died.
your own bot _on the field_. That means that n would go down again if
a spawn died.
Scalatron
May 14, 2012, 4:19:07 AM5/14/12
to scal...@googlegroups.com
Hi Andreas,
thanks for your input. Based on your benchmark scores you are clearly the authority as far as writing Scalatron bots is concerned. :-)
I actually whole-heartedly agree with your observations. I never thought Scalatron would get such an enthusiastic response, and that folks would go to such lengths optimizing their bots.
But I am glad that they do, and so I think we should amend the rules based on such feedback to restore some balance to the game. I also got similar feedback from @mj604, who was the record-holder before you and observed similar problems.
Regarding the details, I think (a) would be my preference over (b), too.
However, we should review a potentially simpler option: imposing a hard limit on the number of entities that a player can control at any one time.
I added this feature to 1.0.0.2, I think: there is now an option "-maxslaves", which defaults to Int.MaxValue in normal play and to 20 in the (experimental) secure mode (try "-secure yes").
The original intention was to keep players from mounting "denial of service" attacks on the server by releasing an avalanche of bots.
One reason this change may be preferable is that a fixed cost per slave would make it (a little) easier to document the commands and to reason about strategies.
What are your thoughts on this?
If we do make the change, we should also update the "official" benchmark, obviously. I've been thinking about renaming the current one the "freestyle" benchmark and adding a new "head-to-head" benchmark that pits two bots against each other, everything else staying the same.
Regarding the rule changes: once we nail this down, would you be interested in making the changes and sending a pull request? Potentially also for the github pages repo defining the benchmark?
Let me know.
Thanks in any case!
- Greg
Andreas Flierl
May 14, 2012, 9:38:36 AM5/14/12
to scal...@googlegroups.com
Hi,
On 14.05.2012, at 10:19, Scalatron wrote:
> Hi Andreas,
>
> thanks for your input. Based on your benchmark scores you are clearly the authority as far as writing Scalatron bots is concerned. :-)
>
> I actually whole-heartedly agree with your observations. I never thought Scalatron would get such an enthusiastic response, and that folks would go to such lengths optimizing their bots.
> But I am glad that they do, and so I think we should amend the rules based on such feedback to restore some balance to the game. I also got similar feedback from @mj604, who was the record-holder before you and observed similar problems.
>
> Regarding the details, I think (a) would be my preference over (b), too.
> However, we should review a potentially simpler option: imposing a hard limit on the number of entities that a player can control at any one time.
> I added this feature to 1.0.0.2, I think: there is now an option "-maxslaves", which defaults to Int.MaxValue in normal play and to 20 in the (experimental) secure mode (try "-secure yes").
> The original intention was to keep players from mounting "denial of service" attacks on the server by releasing an avalanche of bots.
> One reason this change may be preferable is that a fixed cost per slave would make it (a little) easier to document the commands and to reason about strategies.
> What are your thoughts on this?
I agree that a hard limit is definitely simpler. But a nice exponential growth (such as 99 + 1.5^n) would make for some interesting decision finding about whether spawning another bot would be energy efficient - and the more interesting decision possibilities, the better, in my humble opinion.
> If we do make the change, we should also update the "official" benchmark, obviously. I've been thinking about renaming the current one the "freestyle" benchmark and adding a new "head-to-head" benchmark that pits two bots against each other, everything else staying the same.
I know people who would like that. I am personally the non-competitive type and liked Scalatron exactly because I could "benchmark" my bot alone. But everybody likes a different game. :) So yes, why not.
> Regarding the rule changes: once we nail this down, would you be interested in making the changes and sending a pull request? Potentially also for the github pages repo defining the benchmark?
I can take care of that yes. I also have a pull request planned to decouple the rendering from the game calculation, i.e. have the game render its frames on a timer. This allows the calculation to go at full speed always (if the player doesn't choose to delay it).
Kind regards
Andreas
On 14.05.2012, at 10:19, Scalatron wrote:
> Hi Andreas,
>
> thanks for your input. Based on your benchmark scores you are clearly the authority as far as writing Scalatron bots is concerned. :-)
>
> I actually whole-heartedly agree with your observations. I never thought Scalatron would get such an enthusiastic response, and that folks would go to such lengths optimizing their bots.
> But I am glad that they do, and so I think we should amend the rules based on such feedback to restore some balance to the game. I also got similar feedback from @mj604, who was the record-holder before you and observed similar problems.
>
> Regarding the details, I think (a) would be my preference over (b), too.
> However, we should review a potentially simpler option: imposing a hard limit on the number of entities that a player can control at any one time.
> I added this feature to 1.0.0.2, I think: there is now an option "-maxslaves", which defaults to Int.MaxValue in normal play and to 20 in the (experimental) secure mode (try "-secure yes").
> The original intention was to keep players from mounting "denial of service" attacks on the server by releasing an avalanche of bots.
> One reason this change may be preferable is that a fixed cost per slave would make it (a little) easier to document the commands and to reason about strategies.
> What are your thoughts on this?
> If we do make the change, we should also update the "official" benchmark, obviously. I've been thinking about renaming the current one the "freestyle" benchmark and adding a new "head-to-head" benchmark that pits two bots against each other, everything else staying the same.
> Regarding the rule changes: once we nail this down, would you be interested in making the changes and sending a pull request? Potentially also for the github pages repo defining the benchmark?
Kind regards
Andreas
Scalatron
May 14, 2012, 11:50:28 AM5/14/12
to scal...@googlegroups.com
Regarding the rule changes: your arguments for exponential growth are valid - getting people to think more deeply about the problem is actually better.
So OK, let's do the exponential option. If you can send me a pull request, that'd be great.
I won't be able to integrate anything until the weekend, though. :-)
Scalatron
May 14, 2012, 11:50:59 AM5/14/12
to scal...@googlegroups.com
Regarding the rendering: have you already done anything in that direction, or are you still thinking about it?
The reason I'm asking is because I'm thinking about a few pretty significant refactorings that would probably be good to complete before making that kind of change.
The primary thing I'm after is to make the games themselves (such as BotWar) pluggable, so that other people can write their own games, using Scalatron merely as a multi-user/plug-in/IDE platform.
I've started along this path in the v2 branch on github, but have since made so many changes on the v1 branch that I'm thinking about starting over again... :-)
One thing that may be nice would be to decouple the renderer completely into another process, making the server permanently headless (already an option: "-headless yes") and allowing game display on a (or even several) different machines.
One way to do this would be to implement the Tournament resource of the RESTful API, pull the current/most recent tournament game state as JSON and render it in the remote process.
This could even be done in a browser; it is probably actually be my preferred option. Very easy, too, with HTML5.
Note that one of the drawbacks of a completely temporally decoupled renderer is that you can no longer single-step through the game for debugging purposes.
Maybe one way to make this optional is to turn the current option of slowing down the renderer (keys 1...9) into a two-way option:
- 1..4 accelerates the simulator (20,10,5,2 sim steps per frame)
- 5 is 1:1 sim/render stepping
- 6...9 slows everything down (min. time per cycle 10, 250, 750, 2000 milliseconds).
I must admit that I'm a little weary decoupling the in-process rendering completely from the simulation, for said reason.
Maybe the best thing would be a combo of the two options:
- Step 1: Tournament state via REST, with browser-based rendering - temporally completely decoupled, obviously
- Step 2: in-process rendering with options for gearing/slowdown
This would significantly remove the number of moving parts, eliminate many of the conflicts with my planned refactoring and add A LOT of value (remote display - very nice!).
What do you think?
- Greg
Andreas Flierl
May 15, 2012, 2:29:42 AM5/15/12
to scal...@googlegroups.com
Hi,
On 14.05.2012, at 17:50, Scalatron wrote:
> Regarding the rendering: have you already done anything in that direction, or are you still thinking about it?
nah, I just looked at the code a bit and thought that it would be a rather easy change to make. So I was just thinking about it.
> The reason I'm asking is because I'm thinking about a few pretty significant refactorings that would probably be good to complete before making that kind of change.
> The primary thing I'm after is to make the games themselves (such as BotWar) pluggable, so that other people can write their own games, using Scalatron merely as a multi-user/plug-in/IDE platform.
> I've started along this path in the v2 branch on github, but have since made so many changes on the v1 branch that I'm thinking about starting over again... :-)
Sure, go ahead, I don't have too much time on my hands right now anyways.
> One thing that may be nice would be to decouple the renderer completely into another process, making the server permanently headless (already an option: "-headless yes") and allowing game display on a (or even several) different machines.
> One way to do this would be to implement the Tournament resource of the RESTful API, pull the current/most recent tournament game state as JSON and render it in the remote process.
> This could even be done in a browser; it is probably actually be my preferred option. Very easy, too, with HTML5.
I am not so sure about that the benefit justifies the cost (of implementation and runtime). Process switches waste precious resources :) I like the model as it is now. Also keeps things simple for the admin + users.
> Note that one of the drawbacks of a completely temporally decoupled renderer is that you can no longer single-step through the game for debugging purposes.
The keys could just slow the game calculation down. That way you could still watch the game step-by-step.
For what it's worth, I didn't have to do any (step-by-step) debugging at all when I programmed my bot. Because the control function can be pure, the whole bot is very easily testable, which is what I (and my colleagues) did. Worked great and spared us the debugging.
> Maybe one way to make this optional is to turn the current option of slowing down the renderer (keys 1...9) into a two-way option:
> - 1..4 accelerates the simulator (20,10,5,2 sim steps per frame)
> - 5 is 1:1 sim/render stepping
> - 6...9 slows everything down (min. time per cycle 10, 250, 750, 2000 milliseconds).
> I must admit that I'm a little weary decoupling the in-process rendering completely from the simulation, for said reason.
>
> Maybe the best thing would be a combo of the two options:
> - Step 1: Tournament state via REST, with browser-based rendering - temporally completely decoupled, obviously
> - Step 2: in-process rendering with options for gearing/slowdown
> This would significantly remove the number of moving parts, eliminate many of the conflicts with my planned refactoring and add A LOT of value (remote display - very nice!).
> What do you think?
As stated above, I am not so fond of the process separation. But that's just me.
We did remote display via VNC which worked great. :)
The foremost goal should probably be to keep things as simple as possible. As soon as there is networking involved, there _will_ be people who will have problems.
Just my 2c.
Andreas
On 14.05.2012, at 17:50, Scalatron wrote:
> Regarding the rendering: have you already done anything in that direction, or are you still thinking about it?
> The reason I'm asking is because I'm thinking about a few pretty significant refactorings that would probably be good to complete before making that kind of change.
> The primary thing I'm after is to make the games themselves (such as BotWar) pluggable, so that other people can write their own games, using Scalatron merely as a multi-user/plug-in/IDE platform.
> I've started along this path in the v2 branch on github, but have since made so many changes on the v1 branch that I'm thinking about starting over again... :-)
> One thing that may be nice would be to decouple the renderer completely into another process, making the server permanently headless (already an option: "-headless yes") and allowing game display on a (or even several) different machines.
> One way to do this would be to implement the Tournament resource of the RESTful API, pull the current/most recent tournament game state as JSON and render it in the remote process.
> This could even be done in a browser; it is probably actually be my preferred option. Very easy, too, with HTML5.
> Note that one of the drawbacks of a completely temporally decoupled renderer is that you can no longer single-step through the game for debugging purposes.
For what it's worth, I didn't have to do any (step-by-step) debugging at all when I programmed my bot. Because the control function can be pure, the whole bot is very easily testable, which is what I (and my colleagues) did. Worked great and spared us the debugging.
> Maybe one way to make this optional is to turn the current option of slowing down the renderer (keys 1...9) into a two-way option:
> - 1..4 accelerates the simulator (20,10,5,2 sim steps per frame)
> - 5 is 1:1 sim/render stepping
> - 6...9 slows everything down (min. time per cycle 10, 250, 750, 2000 milliseconds).
> I must admit that I'm a little weary decoupling the in-process rendering completely from the simulation, for said reason.
>
> Maybe the best thing would be a combo of the two options:
> - Step 1: Tournament state via REST, with browser-based rendering - temporally completely decoupled, obviously
> - Step 2: in-process rendering with options for gearing/slowdown
> This would significantly remove the number of moving parts, eliminate many of the conflicts with my planned refactoring and add A LOT of value (remote display - very nice!).
> What do you think?
We did remote display via VNC which worked great. :)
The foremost goal should probably be to keep things as simple as possible. As soon as there is networking involved, there _will_ be people who will have problems.
Just my 2c.
Andreas
georg
May 16, 2012, 10:17:19 AM5/16/12
to scal...@googlegroups.com
Hi Andreas, Greg,
the proposed game rule with spawn cost growing exponentially will lead to the following strategy:
the proposed game rule with spawn cost growing exponentially will lead to the following strategy:
- I assume that the spawn cost is NOT lost to the bot (same as in the current implementation)
- Then it is still essential to spawn as often as possible, since more bots can eat faster, and spawning does not lose any points (of course, in the last few rounds the bots must return to the master and not spawn any longer).
- To be able to spawn as often as possible, the slave bots have to run around a while and harvest energy, then return to the main bot to deliver the energy. The main bot then can take the combined energy of, say, 3 slaves to create 4 new slaves.
- So the game would become a run-around-then-return-to-main-bot thing.
I'm not sure I like that prospect (although I could live with it). So here is an alternative proposal:
Proposal: Make the upkeep of slave bots a function of the number of slave bots, e.g., upkeep cost per slave bot per round = number of slave bots / 2. With this formula, spawning 100 or more slaves would not be worth it, because just for the upkeep, the slaves would have to hunt down a fluppet every 4th cycle.
With this rule change (as opposed to Andreas' proposal), slave bots could still roam freely until they have to return at the end of the round.
Georg
"Freedom for my slave bots!"
Andreas Flierl
May 16, 2012, 1:29:26 PM5/16/12
to scal...@googlegroups.com
Hi,
On 16.05.2012, at 16:17, georg wrote:
> Hi Andreas, Greg,
>
> the proposed game rule with spawn cost growing exponentially will lead to the following strategy:
>
> • I assume that the spawn cost is NOT lost to the bot (same as in the current implementation)
I'm not sure what you mean by that.
> • Then it is still essential to spawn as often as possible, since more bots can eat faster, and spawning does not lose any points (of course, in the last few rounds the bots must return to the master and not spawn any longer).
short answer:
no
longer answer:
there's not nearly enough energy on the board to do that. try it and/or do the math. if the 30th bot costs 1M+ to spawn (with the 99 + 1.6^n formula), it's in no way worth it. with current rules, i have to have 100+ bots on the field to get ~5M score in the end. if less bots are on the field, there is less possible energy on the field. no way you'll gather enough energy with 29 bots to make the 30th for 1M worth it. If you can show me a bot that can do that (and I'd be very interested in how that would be possible… but I'm looking forward to stand corrected), then clearly Greg's solution with a hard limit is better.
> • To be able to spawn as often as possible, the slave bots have to run around a while and harvest energy, then return to the main bot to deliver the energy. The main bot then can take the combined energy of, say, 3 slaves to create 4 new slaves.
Kind regards
Andreas
On 16.05.2012, at 16:17, georg wrote:
> Hi Andreas, Greg,
>
> the proposed game rule with spawn cost growing exponentially will lead to the following strategy:
>
> • I assume that the spawn cost is NOT lost to the bot (same as in the current implementation)
> • Then it is still essential to spawn as often as possible, since more bots can eat faster, and spawning does not lose any points (of course, in the last few rounds the bots must return to the master and not spawn any longer).
short answer:
no
longer answer:
there's not nearly enough energy on the board to do that. try it and/or do the math. if the 30th bot costs 1M+ to spawn (with the 99 + 1.6^n formula), it's in no way worth it. with current rules, i have to have 100+ bots on the field to get ~5M score in the end. if less bots are on the field, there is less possible energy on the field. no way you'll gather enough energy with 29 bots to make the 30th for 1M worth it. If you can show me a bot that can do that (and I'd be very interested in how that would be possible… but I'm looking forward to stand corrected), then clearly Greg's solution with a hard limit is better.
> • To be able to spawn as often as possible, the slave bots have to run around a while and harvest energy, then return to the main bot to deliver the energy. The main bot then can take the combined energy of, say, 3 slaves to create 4 new slaves.
> • So the game would become a run-around-then-return-to-main-bot thing.
> I'm not sure I like that prospect (although I could live with it). So here is an alternative proposal:
>
> Proposal: Make the upkeep of slave bots a function of the number of slave bots, e.g., upkeep cost per slave bot per round = number of slave bots / 2. With this formula, spawning 100 or more slaves would not be worth it, because just for the upkeep, the slaves would have to hunt down a fluppet every 4th cycle.
>
> With this rule change (as opposed to Andreas' proposal), slave bots could still roam freely until they have to return at the end of the round.
I wouldn't want anywhere near 100 bots. 20-30 is already too much, if you ask me. Something like 5-15 would probably nice. But then maybe that's just me.
> I'm not sure I like that prospect (although I could live with it). So here is an alternative proposal:
>
> Proposal: Make the upkeep of slave bots a function of the number of slave bots, e.g., upkeep cost per slave bot per round = number of slave bots / 2. With this formula, spawning 100 or more slaves would not be worth it, because just for the upkeep, the slaves would have to hunt down a fluppet every 4th cycle.
>
> With this rule change (as opposed to Andreas' proposal), slave bots could still roam freely until they have to return at the end of the round.
Kind regards
Andreas
georg
May 17, 2012, 5:27:40 AM5/17/12
to scal...@googlegroups.com
Hi,
> I assume that the spawn cost is NOT lost to the bot (same as in the current implementation)
This means, that with the 99+1.6^n formula e.g. spawing the 20. slave would cost the bot dowing the spawn 12188, and the new slave bot would have 12188 energy - so there is no energy loss, only energy redistribution when spawning bots.
> do the math
Here is my math:
1) Assume you currently have N slave bots and still 1000 cycles to go. In average, each of the N slave bots can collect a fluppet or zugar every 10th cycle (could be). This would mean, in 1000 cycles, N slave bots can collect N * (1000 cycles / 10 cycles/prey * 150 average eu/prey) = N * 15000 eu.
2) Obviously, if I can somehow manage to have N+1 bots with 1000 cycles to go, I would have the opportunity to collect 15000 eu more.
3) To be able to spawn the 21. slave, I have to gather at least 19442 eu somewhere in a single bot. I could try to gather that much in the 20. slave bot (which had the starting energy 12188), but it would take about 500 cycles to gather (at ~10 cycles / prey). Instead, I proceed as follows:
4) I let my bots hunt for 50 cycles, then return ten slaves to the main bot. The summed energy of these ten will be enough to spawn 11 new bots (not necessarily all spawned from the main bot)!
In the same way, I proceed until it's time for all slaves to return home. I don't know with how many bots I will end the game, but I think it will be about 30 bots on the reference board based on the assumption that each slave can hunt for 15 eu / cycle.
Now that I have thought about it some more, it sounds more interesting than in the beginning. :)
------
Nevertheless, let's compare it with my proposal "upkeep cost per slave bot per cycle = number of slave bots / 2"
If each slave can hunt for 15 eu / cycle, the energy gain per cycle will be E = N * 15 - N * N/2, which has the maximum of E = 112.5 at N = 15.
With my proposal, a bot programmer would mainly have to take care its bots can hunt as efficiently as possible, feed the energy gain per cycle in the formula and find the optimum number of slave bots to keep. No need to return early.
------
Summed up:
spawn cost = 99 + 1.6^n => more complex fun, probably up to 25-30 slave bots (adjust the 1.6 carefully if you want higher or lower numbers)
upkeep cost = n/2 => also fun, propably less complex math, probably up to 15 slave bots (adjust the /2 carefully if you want higher or lower numbers)
Georg
> I assume that the spawn cost is NOT lost to the bot (same as in the current implementation)
> do the math
Here is my math:
1) Assume you currently have N slave bots and still 1000 cycles to go. In average, each of the N slave bots can collect a fluppet or zugar every 10th cycle (could be). This would mean, in 1000 cycles, N slave bots can collect N * (1000 cycles / 10 cycles/prey * 150 average eu/prey) = N * 15000 eu.
2) Obviously, if I can somehow manage to have N+1 bots with 1000 cycles to go, I would have the opportunity to collect 15000 eu more.
3) To be able to spawn the 21. slave, I have to gather at least 19442 eu somewhere in a single bot. I could try to gather that much in the 20. slave bot (which had the starting energy 12188), but it would take about 500 cycles to gather (at ~10 cycles / prey). Instead, I proceed as follows:
4) I let my bots hunt for 50 cycles, then return ten slaves to the main bot. The summed energy of these ten will be enough to spawn 11 new bots (not necessarily all spawned from the main bot)!
In the same way, I proceed until it's time for all slaves to return home. I don't know with how many bots I will end the game, but I think it will be about 30 bots on the reference board based on the assumption that each slave can hunt for 15 eu / cycle.
Now that I have thought about it some more, it sounds more interesting than in the beginning. :)
------
Nevertheless, let's compare it with my proposal "upkeep cost per slave bot per cycle = number of slave bots / 2"
If each slave can hunt for 15 eu / cycle, the energy gain per cycle will be E = N * 15 - N * N/2, which has the maximum of E = 112.5 at N = 15.
With my proposal, a bot programmer would mainly have to take care its bots can hunt as efficiently as possible, feed the energy gain per cycle in the formula and find the optimum number of slave bots to keep. No need to return early.
------
Summed up:
spawn cost = 99 + 1.6^n => more complex fun, probably up to 25-30 slave bots (adjust the 1.6 carefully if you want higher or lower numbers)
upkeep cost = n/2 => also fun, propably less complex math, probably up to 15 slave bots (adjust the /2 carefully if you want higher or lower numbers)
Georg
Greg Scalatron
May 20, 2012, 3:25:12 AM5/20/12
to scal...@googlegroups.com
Just to confirm, the spawn cost is not lost - the spawned bot receives it as its starting energy and will retain it until the game ends or it re-merges with its master, minus the energy that is consumed every n-th cycle. But then you already knew that.
Regarding the question what the best rules are I think we should probably distinguish two scenarios and objectives:
(a) multi-player: the setting is generally a tournament that includes a mix of more and less experienced programmers and where the time constraint of the workshop imposes a natural limit as far as the complexity of the bot code is concerned (at least assuming people don't just cut and paste existing bots' code). The primary objective here is to ensure that everyone has fun, and can work against a challenge that is appropriate for their respective skill level. This is obviously a complex topic, but the most critical short term concern is the fact that experienced users can use excessive bot spawning to (1) simply crush less experienced users with overwhelming force and (2) cause unacceptable slowdown of the server. Players perceive this as not "fair". The simplest solution to this problem is (A) limiting the number of permissible concurrently existing slaves and (B) limit the permissible CPU time consumption per bot.
(b) single-player: the setting is generally an enthusiastic, experienced programmer going head-to-head with the game rules. My take here is that it doesn't really matter what the game rules are. Whatever they are, you accept the challenge and try to beat the system. I did not anticipate the 3M EU bots when I wrote the initial rule set, but I did anticipate that people would find some way to exploit whatever "loopholes" were available in the rules. But that's precisely the point of the game, isn't it? You try to find the weak spots (or let's call the them the sweet spots) and exploit them. A variety of players quickly figured out that slaves' superior speed was key to winning and went for spawning-heavy strategies. PandaCub then began to converge on the mathematically optimal strategies for moving around and harvesting energy. Awesome - exactly what should be happening.
There is only dissonance if we plug bots built for (b) into tournaments run like (a). It's like a technologically advanced alien force invading a stone-age village. A context problem.
Ultimately this is not fixable as long as the rule set allows for emergent complexity (which is something that I think should be preserved) and people can focus on the same challenge both inside and outside a workshop.
I really think that the solution is not so much in refining the rules of the BotWar game (although both of your suggestions are clearly improvements), but that we simply need more different games. That is the only way to keep tournaments fair (because it makes it very costly to prepare solutions in advance) and to generate new and fresh challenges for enthusiastic and ambitious users (like you).
So rather than fiddling much with the existing rules I propose the following steps forward:
- we simply place a hard limit on the number of slaves in BotWar and the time a control function may take - and leave it at that.
- you start thinking about new and different games that could be played on the same basic "engine" as BotWar but have different rules and strategies - make them as "deep" and clever as you can.
- I work on pushing Scalatron towards being more of a multi-user framework for such games, with a plug-in API through which games like BotWar are exposed.
Let me know what you think.
If you come up with game ideas, better to make them new topics, rather than responses to this thread.
- Greg
Andreas Flierl
May 20, 2012, 6:46:22 AM5/20/12
to scal...@googlegroups.com
On 20.05.2012, at 09:25, Greg Scalatron wrote:
> Just to confirm, the spawn cost is not lost - the spawned bot receives it as its starting energy and will retain it until the game ends or it re-merges with its master, minus the energy that is consumed every n-th cycle. But then you already knew that.
>
> Regarding the question what the best rules are I think we should probably distinguish two scenarios and objectives:
>
> (a) multi-player: the setting is generally a tournament that includes a mix of more and less experienced programmers and where the time constraint of the workshop imposes a natural limit as far as the complexity of the bot code is concerned (at least assuming people don't just cut and paste existing bots' code). The primary objective here is to ensure that everyone has fun, and can work against a challenge that is appropriate for their respective skill level. This is obviously a complex topic, but the most critical short term concern is the fact that experienced users can use excessive bot spawning to (1) simply crush less experienced users with overwhelming force and (2) cause unacceptable slowdown of the server. Players perceive this as not "fair". The simplest solution to this problem is (A) limiting the number of permissible concurrently existing slaves and (B) limit the permissible CPU time consumption per bot.
>
> (b) single-player: the setting is generally an enthusiastic, experienced programmer going head-to-head with the game rules. My take here is that it doesn't really matter what the game rules are. Whatever they are, you accept the challenge and try to beat the system. I did not anticipate the 3M EU bots when I wrote the initial rule set, but I did anticipate that people would find some way to exploit whatever "loopholes" were available in the rules. But that's precisely the point of the game, isn't it? You try to find the weak spots (or let's call the them the sweet spots) and exploit them. A variety of players quickly figured out that slaves' superior speed was key to winning and went for spawning-heavy strategies. PandaCub then began to converge on the mathematically optimal strategies for moving around and harvesting energy. Awesome - exactly what should be happening.
> There is only dissonance if we plug bots built for (b) into tournaments run like (a). It's like a technologically advanced alien force invading a stone-age village. A context problem.
> Ultimately this is not fixable as long as the rule set allows for emergent complexity (which is something that I think should be preserved) and people can focus on the same challenge both inside and outside a workshop.
>
> I really think that the solution is not so much in refining the rules of the BotWar game (although both of your suggestions are clearly improvements), but that we simply need more different games. That is the only way to keep tournaments fair (because it makes it very costly to prepare solutions in advance) and to generate new and fresh challenges for enthusiastic and ambitious users (like you).
>
> So rather than fiddling much with the existing rules I propose the following steps forward:
> - we simply place a hard limit on the number of slaves in BotWar and the time a control function may take - and leave it at that.
Reply all
Reply to author
Forward
0 new messages