Custom battlefields

We need to agree and standardize any such extended environments, because if battleField is customized for single robot and robot for it, there is no competition on it. I wouldn't like to diversify that much that we break the competition.

Also I wonder how much more complicated AI of robots will be when there will be obstacles. Is current battleField already simple and boring ?

On the other side, it could be lot of fun to fire from behind of edge of wall :-)

This would bring a bit more of a "table-top"-like theme to the game - which might not be bad. It could be quite challenging to have (maybe even destructible) obstacles to hide behind. It would add a competely new aspect to the game.

As always with fundamental changes, some will like it, some will not. But keeping it as an option - and not something forced down on the player/developer - would make it a great addition.

How about just enabling the option of using a non-standard battlefield and then do the actual level editing in a seperate project? This would keep the Robocode source clean from "additional" stuff?

Just my €0.02 :)

To allow other people to extend the game with new ideas, we need to create extensibility API for battle rules. Because when you put obstacle on battlefield, the physics (rules) will change.
We are not prepared to do that now.

My proposal is to create first few extensions within Robocode project, so that it will help us to create and stabilize the extensibility API. After then we could mark such API as public/stable.

At this point I think we could accept prototypes in form of patches. Such patch should propose changes to battle core, the interfaces for extensions and new module which will do the extension. It should also solve problem of configuration of extensions from user perspective.
The new extensions should follow plugin module pattern which could be spotted in
/branches/repository-workspace/plugins/
Anyone interested in DOING such work drop me an email.

And yes, we are very interested to do it, but it is next big thing, not the current one ;-)

And I forgot to mention. It will also nee to extend Robot API to allow robot to see obstacles (objects) on scaner. This one is tricky, because if every plugin will bring new events or methods to the Robot PI, then the extension is not really optional but mandatory part of Robocode.

So we will need to design kind of relaxed extension Robot API which will cover broad scale of extensions to rules.

That's programming/design challenge guys ;-)

As Pavel points out, there would have to be a new event to allow robots to detect obstacles or objects. I don't think this event should return the entire obstacle, but only the part that the radar covers. This seems more realistic to me.
Robots that run into an obstacle would get a HitWallEvent.
Another issue would be dealing with old robots, robots that don't detect obstacles. Since obstacles would be a major change to the battlefield, these old robots would be at a huge disadvantage. I think the best solution is to detect whether the robots can "see" the obstacles. If any robot can't, then the steps would be taken. The battle might finish immediately as a tie, the "blind" robot might be dropped from the fight (if it's a melee), etc. At the very least, an error message could be sent (i.e. "Warning: FooRobot cannot see obstacles").

Here are some comments and questions:

The new extensibilty framework should allow for some cool modifications to the base game. To ensure backwards compatability, these should, of course, be optional. My suggestion is to include some kind of selection ability under the "Rules" tab of the "New Battle" dialog within Robocode. Perhaps a list, like we have for robot selection, for the different extension modules would be appropriate?

One of the big issues with the extensibility framework handling old robots. It is unlikely that old robots would be to compete with any new module. I think old robots should be allowed in the battle, but they fire off a warning message. This could open up interesting possibilities. For example, if someone makes a racing module, old robots could be "hunters" that the racers have to avoid during the race. The old robots would hardly be expected able to win, but they could certainly shoot at passerbys.

Obstacles have some specific issues that must be addressed. The first of these is how much the robot knows at the beginning of the battle. The robot could be given a list of all the objects, or the robot may have to scan each object to discover it. The latter would be more realistic.

It might be better to have two types of modules for obstacles. One would contain all the basic information, such as events and other rules. The other type would deal with the placement of obstacles and could have a static map or generate placement randomly.

Scanning objects would be a large issue. The onScannedObject event could contain a closest distance, a list of polygonal edges within the scan arc, or even the entire object. The largest scanning challenge would be considering occlusion - what to do when a robot or object is within a scan arc but behind an obstacle. One solution might be to do some ray-tracing to the robot / object to check for obstacles in the way.

Collisions would be handled in the same way as a HitWallEvent.

After the extensibility API is worked out, I'll probably work on "trench" obstacles first (robots can see and shoot over, but not cross). I'll be able to get much of the framework in place and won't have to deal with some of the harder challenges, such as occlusion.
If we go with a robot that doesn't know every obstacle's position from the beginning, I'll also come up with a "mapping" API robots can use to track obstacles.

The extensibility framework still needs to be created. I'll do a similar post about it once I have a better idea about what is needed.

Comments or concerns?

Actually, I myself vote for this change, only for Robocode 2, not this 1.x.x version. That way we can completely forget the backward compatibility. We still need to maintain the stable version for RoboRumble (we don't want a version like 1.6.2/1.7 happen again)

For the plug-in system, I think we must wait until Pavel finish his net4java before he start to work more seriously on the plug-in system.

Regarding to your example on race way with old robot being hunter, that really may not work as expected. Most of robot now is one-on-one, which won't work with any battles that contain more than 2 robots. And if it is the real raceway, the old yet decent melee robots will hunt them down pretty fast as the racer move in the same pattern.

Nat:

• re Robocode 2: I think that API should stay backward compatible anyway.
  I'm as well for evolution rather than revolution, so let's develop it on top of current code, and once we will have it done, we could call it 2.0 engine. But in one of settings it will be still able to run old rules with old robots.

Joshua:

• re plugin system: there is no collision with .NET plugins, fee free to start working. Only concern I have is that the current Battle and RobotPeer classes are not extensible yet and I would like to provide strong feedback into process of making the extensible.

Let's call it battlefield processing framework and plugins.

This will mean that there should be framework which will run each round. It will contain extension points (listeners or something like that) which will distribute the call about battle field processing to plugins.

Plugins will be the modules, created same way as most of the in current robocode. The extension points will lookup for all implementations of listeners in picocontainer. (And maybe cached locally on start of battle.)

The extension points should allow for processing events like robot moves, bullet moves, collisions, objects and walls scanning, robot scanning behind wall and so on.

Best way how to do that is the you will dig out current rules and implement them as one of the plugins to the framework you will create.

Most difficult would be to allow different rules to apply together. I mean if there will be

• robot scanning
• object scanning plugin
• object collision plugin
• original rules plugin
• race rules plugin
• bomb drop plugin
• aid pack drop plugin
• capture the flag plugin
  You could imagine that some of them could work together and some not. The framework should allow for this combinations.

We need to come with turn processing lifecycle, something like this, i'm not sure about the order.

• first move all
• match collisions
• update energy
• update score
• evaluate special win rules

Each shuch type of lifecycle event should have it's own interface, which will allow to read the data from battle field, but send back only changes specific to that step. This restriction will allow us to keep thing immutable after the step is finished.

As you can see there is challenge to design information exchange between different types of plugins. Probably we will need to have common store with items in game, and the items should implement some common interface and maybe other more specific.
I can imagine that each item/object have position. but bullets are different from walls and from weapon drops. I think that this kind of information exchange is called white-board pattern.

It will be quite challenging to do it. I will create working branch in robocode svn and grant you write access to it. So that we could watch how you are progressing. Don't worry if you couldn't do that on first try. I dropped several working branches already and started again.

And the last thing for all. The actual new rules are not that important for implementation of the framework, so keep them coming, but just for the purpose of the design, there is no room for chatting about particular rules vs different rules YET ;-)

First of all, I agree with all of Pavel's comment. :-)
We should build on top of the current Robocode so that old robots can also run under "Robocode 2".
However, if the "New Battle" is set to use obstacles or "Robocode 2" rules, old 1.x.x robots should not be allowed to participate in the battle. This is easy to check, as every robot is packed with this information when packaging the robot using the Robocode packager.

I also propose that we add new extensions to Robocode as "one pack" (= Robocode 2 rules), meaning that the robots should not need to check if e.g. aid packs, bombs, obstacles are on or off. It would be too complicated, I think. All rules should be "on", even if the battlefield does not contain obstacles, aid packs, bombs etc. It is better that the robots expect these to be "on" so they are prepared for it.

Obstacles:
I prefer a simple approach, where obstacles are squares (bounding boxes) placed on a grid. Not pixel based, as this will require heavy computation.
I propose to use boxes of 40x40 pixels. Why? -> Because these are not too big and not too small. And they fit nicely into most standard battlefields:

Battlefield size: 800x600, Obstacle grid 800/40 x 600/40 = 20 x 15 boxes, 300 in total
Battlefield size: 1200x1200, Obstacle grid 1200/40 x 1200/40 = 30 x 30 boxed, 900 in total

Note: Even though an 800x600 battlefield would allow up to 300 obstacles, we should have a threshold for how many obstacles that can be on a battlefield. Otherwise there will be no room for robots. In addition, we should make sure we don't box in robots, so they cannot shot at each other. All robots must be placed on the battlefield so they are able to hit each other.

Using a grid would make it easy for robot to create their own internal "bit map" over the obstacles the robot discovers. It just needs to set a bit, when it sees a new obstacle. In addition, it would be simple to add a battlefield editor, where the obstacles can be placed on a grid.
It should also be "easy" to use classic binary search trees (divide & conquer) known from classic 3D games for fast detecting of obstacles, and preventing the scanner to see robots hiding behind obstacles etc. It needs to be fast to allow the game to function in real time, even with big battlefields.

Also notice, that I should like the ability to represent the obstacles in a string representation like e.g. "Ba53bcD7GE", which represent one unique map of obstacles (including the grid size). So, if a map is randomly generated, it would still be represented as a string. This way, people can play a good map again and again just by entering this string. I think this would be great for competitions, but also when trying to reproduce and issue seen with a specific map of obstacles. This will also be very useful for storing Replays, which Robocode currently supports, as it just need to store a string representing the obstacles.

I am against (re)using the HitWallEvent for obstacles. The HitWallEvent should only be used when the robot hits the borders of the "world". I prefer a HitObstacleEvent that includes specific information about the obstacle(s) it have hit, and it will be easier for the robots to differ between hitting the edge of the world and an obstacle without being forced to code stuff that test in order to differ between having hit a wall or obstacle.

We could introduce the following events:

HitObstacleEvent when colliding with an obstacle
BulletHitObstacle when a bullet hits and obstacle
ScannedObstacleEvent when the radar has obstacles within its view angle (max. 1200 pixel scan)
ScannedAidPack when the radar has an aid pack within its view angle (max. 1200 pixel range)

The robots should not be able to see a mine/bomb drop. Not even its own, which it needs to track/remember by itself. ;-)

Capture the flag would be great when using Teams and Droids. :-) If we use these, we also need this event:

ScannedCaptureFlagEvent when the radar detects a Capture Flag.
WinEvent will need additional information that it won due to capture of flag etc.

My 2 cents. :-)

I'm with Flemming here.

I actually think about no backward compatible because, as Pavel mentioned somewhere, the current Robot API is hard to add new feature. If we redesign Robot API with Robocode 2, we can create more things easier. I think if we still use old backward-compatible API, then if we are creating some new thing that as big as this one, we might needed to create Robocode 3. But if old robots only allowed to run under legacy environment, it is fine with me.

One issue I want you all to think about, the "speed". If the engine is too complicated, the robocode might gone too slow. One thing I like in Robocode 1.7.1 is the speed. I can run it as twice as fast as older version (1.6.1.4)

Another issue: There is a lot of brain storm about Robocode 2, which is now migrated at http://testwiki.roborumble.org/w/index.php?title=Robocode_2_Brainstorm I don't actually read it all, but I think there should be some ideas about the thing there. Some ancient Robocode2 project is still hosted at SF.net

I'm not sure what I mentioned somewhere ;-) but I'm sure that
it's difficult to make Robot API backward compatible but same time extended and extensible. What I mean exactly is, that the old robots should be able to run in new environment with extensions, but they will loose because there will be items and events which they don't watch. Compatible API will bring the benefit of smooth transition of people. And possibility to stay on old rules, but with latest Robocode engine, which is very important to me. I'm sure it's worth of the effort.

I'm also sure that if you start from scratch most of the problems of good API design will stay anyway, but you will need to retrain whole community to new API, rewrite all articles and documentation and transfer all knowledge and robot libraries. I'm not going to work on this, because it's not worth of the effort.

I think that Flemming didn't mentioned anything about starting from scratch. Flemming already learned about scratch approach harder way some time ago I believe. Flemming please confirm explicitly.

I'm not sure if string representations of maps would be feasible. Even if 64x64 boxes were used (the size of the tiles on the battlefield) and only half of them could have obstacles, there would still be roughly 2 ^ 6000 unique battlefields. That's just for a 5000 x 5000 board. A similar 800 x 600 board would need 2 ^ 128 unique string representations.

I really like the idea of users being able to share maps, but a simple string would be too long - unless it was passed along in a .txt file.

Perhaps the sharing could be made possible by giving an option to use a given seed to randomly generate a map. Of course, there needs to be a different way so that people can make their own maps.

Pavel and Nat:

I want to keep the Robot API as it is will all old methods, and then extend the Robot API with new methods to support Robocode 2. I don't want to start from scratch as I think the current "engine" of Robocode is now in a very good shape. So why start from scratch? And like Pavel mentioned, I don't want to rewrite or create separate rules between Robocode 1 and Robocode 2. The old rules should still be valid, but new ones should emerge (extensions). I am not sure if this is possible, but currently I think it is. :-)

Old robots should be able to run in Robocode 2, but only if the rules/environment are set to "classic Robocode" (meaning Robocode 1). Otherwise, Robocode 2 should disallow the robots to participate, as it is unfair in competitions when the old robots does not know about the additional rules and new battlefield with obstacles etc.

Josh:

I get your point, and the seed is a very good suggestion. But this way it will not be possible to "design" the battlefield, as it is very likely that it cannot be represented in any way with the random seed. Hence, we should just let the user enter a seed, as show the resulting battlefield. This is of course much easier to implement. ;-)

I am still into the 40x40 pixels boxes. I think the 64x64 or bigger are too big. You could try it out by taking some screenshots of the battlefield with robots, and paint some boxes. But on the other hand... with your random seed idea, we could let the user specify the box size from e.g. 20 to 100 pixels (square boxes with same width and height) + the seed. I think this would be the best from all world, and somewhat flexible.

Hey guys,

After reading the comments here, I'm wondering if the focus might be a bit much on the obstacles and things. If we allow extensions, we will naturally fragment the environment, some robot's will simply not be able to participate in some extensions. I think there will be a handful extensions that developers will find interesting and fun, and the rest will just fall away...

However, if there is perhaps a way to write a robot to find out what extension is in effect, it can adapt to each extension individually.. I doubt this will ever really be done, but I suppose someone might want to build an uber-bot that can adapt to any known game.. and it brings in the possibility of playing a triathlon of sorts, see which bot is best rounded :P

Can we not just ignore obstacles altogether and simply build a way to plug-in a new battle behaviour set that can paint and implement its things seperately? that means an extension off RobotPeer (as, say ObstacleRobotPeer) would be able to leverage the obstacles from the customized battle behaviour. That way, every part of the game can be customized, without affecting the base game at all.

Another scenario then, if I want to implement weapon switching (guided missiles, rocket launchers, lasers) and ammo depletion (for instance), I can just override the bullet handling with my own customized logic in the Battle and provide my own subclass of RobotPeer that provides access to the detail I'd need. Of course, I'd prefer if any additional logic could just be tacked on without using a subclass of RobotPeer, so that I'll be able to build another extension that pulls a couple of extensions together and adds some more logic..

On maps, I found that Armagetron has a pretty good way of building custom maps through xml, and there's a bunch of tools for converting svg's into the basic xml files needed..

Anyhow - my 2c. hope i'm not just talking out my ear and that it's actually useful for something :P