 |
Forums |
Admin  Start New Thread
By: Simon Kröger
 RE: Team battles? [ reply ]
2005-12-08 22:05
|
Just base your creations on v0.2.2, v0.3 will (only) feature a separate tournament runner and your (and maybe other) refactorings.
Next will be "RRobots v0.4 squads edition", with communication and perhaps specialized robots. (and some graphical sugar to indicate the squads)
How does that sound?
|
By: Ilmari Heikkinen
RE: Team battles? [ reply ]
2005-12-08 11:09
|
Had time, did the separation to Robot and RobotRunner. Ended up refactoring robot.rb quite a bit, now it should be a bit simpler to add new features.
Simon, what's the release plan? Should I create a patch against 0.2.1 or against the tournament runner [+ teams] or..?
I'd also like to go through rrobots.rb and clean it up so that it'll be easier to e.g. change the renderer or have the bots define their skins :)
|
By: Ilmari Heikkinen
RE: Team battles? [ reply ]
2005-12-08 08:41
|
The sandboxing _why uses in TryRuby could be a starting point. Also, it'd require separating the AI code from the Robot code, which I wholeheartedly support.
Actually, when I have some time, I'll do the separation. Then the AI would only know about the events and its state, all the internal_tick-stuff would be in the Robot. It'll make writing AIs a bit easier too, since you don't have to dodge around methods defined in Robot.
|
By: Pistos
RE: Team battles? [ reply ]
2005-12-07 00:39
|
Maybe what could be done is some sort of online submission site, where bots can be uploaded to a repository of sorts, so that competitors don't see each other's code. Then matches could be run at the push of a webpage button, running without a GUI. People could test their bots against one another (not necessarily in a formal tournament) without having to expose code.
I was thinking, this could also be done via IRC. Upload your bot via a webpage, then in IRC, issue commands to challenge other bots, and have results show in the channel. All of this without compromising code secrecy.
Once the code base settles down a bit more, I am willing to work on either of these ideas if there would be interest.
My main concern with the current state of the code is that bot code is open to review. Obfuscation, byte code, or such would be desirable, IMO. :)
|
By: Simon Kröger
RE: Team battles? [ reply ]
2005-12-06 22:52
|
Thanks, looks realy promissing.
I'm a bit focused on the tournament stuff right now, but keep it up please - this is one of the next features that will see the light of day.
|
By: Ilmari Heikkinen
RE: Team battles? [ reply ]
2005-12-05 21:57
|
I wrote a quick team battle version and am now adding the comms.
The main reason I'm for a restricted communications setup is that it requires the bot writer to optimize the communications instead of sending the events and state parameters every tick. I'll make it a 16-char string to begin with, that should teach about using pack/unpack :)
How far does that go.. if you quantize positions to 256 values horiz and vert, you can send a rough coordinate with two chars. Speeds quantized to 16 values, so that lets us send a velocity vector in a single char. Headings, distances, single char too.
Which'd give a status update package of form:
x, y, v, gun_heading, radar_heading, distance, and 10 more characters to fill up with idle chatter :)
And that's every tick. Hmm, maybe i'll make it 8 characters after all, then there'd be messages spanning several ticks...
|
By: Simon Kröger
RE: Team battles? [ reply ]
2005-12-05 21:05
|
I had thoughts like that myself, nothing is decided yet, but what about allowing 'real' communication? Like sockets, drb or whatever a robot developer might think of. This could add heavily to the educational value of this project.
I believe (proof me wrong!) that it would be hard enough to implement real teamwork regardless on how high-level the communication is. (first thing would be to determine if the robot you just scanned is a friendly one or not - not that easy at all)
|
By: Ilmari Heikkinen
RE: Team battles? [ reply ]
2005-12-05 17:38
|
Hmm, well, I wonder how easy it is to build an encryption scheme for 16 numbers. You could quite easily check if there are two numbers there which have about the same ratio as the bot's coords' ratio, and that'd throw out multiplication-based schemes. Another would be to go through all four-number sequences in the number and compare then to the bot's coords.
Or then you could just use an OTP and blammo, no way to know.
Okay, info warfare is probably too much bother. Everyone'd just use an OTP.
Some way of penalizing radio comms would be nice though, maybe the knowledge of the radio message direction, then there could be anti-radio tactics to shoot at talkers (and hopefully decapitate the enemy team.)
|
By: Evan James
RE: Team battles? [ reply ]
2005-12-04 13:46
|
I'm not sure about the idea of multiple channels and jamming/eavesdropping. The bots would only have three sensory inputs - radar, radio, and getting shot. They would have so little information available that it would be impossible to figure out what the opposing team's encryption scheme is before the battle is over. The idea behind decryption in this case would be to compare patterns in the enemy communications to patterns in the game world, but bots have so little data about the game world, and a 16-number array of floats is so arbitrary, that the task is hopeless. Imitating enemy communnications for the purpose of jamming would likewise seem extremely unlikely.
Don't get me wrong - team battles with team communications would be great, and programming bots for that would be lots of fun. I just don't think that counterintelligence and decryption would pan out very well - encryption schemes can be arbitrarily complex, while robots' data about the world is both simple and short-lived.
|
By: Ilmari Heikkinen
Team battles? [ reply ]
2005-12-04 04:47
|
How about having team battles where n-bot teams try to shoot bots not on the same side?
I think the rules could be:
- friendly fire (watch those firing sectors!)
- radio broadcast comms on one of four channels (keep switching channels to make eavesdropping harder)
- can broadcast on one channel
- can listen on one channel
- one max 16-number (array of floats) message per bot per tick (short and cryptic)
- received messages contain the rough sector (n/e/w/s) where they came from (stay on the look for leader bots)
I keep envisioning teams with each bot scanning a zone with firing control bots pinpointing targets and everyone shooting when there are no friendlies in the way. With spybots listening and trying to gleam coordinates from enemy broadcasts and jammerbots trying to send false data.
Well.. at least it'd be a good AI programming challenge :)
|
|
|
