BerryBots forums

BerryBots vs Robocode game rules / physics
Page 1 of 2

Author:  Voidious [ Wed Jan 16, 2013 2:12 am ]
Post subject:  BerryBots vs Robocode game rules / physics

I’ve been writing Robocode bots for 7 years, so it’s hard for me not to draw comparisons between the Robocode and BerryBots game rules. And since Robocode is among the best and most popular programming games ever, it seems like a useful reference to have around.

What BerryBots lacks:
  • No radar management. You see in all directions, only blocked by walls.
  • No gun turning. You can fire in any direction.
  • No variable bullet power. All lasers/torpedos move at the same speed and do the same damage.
  • No energy management. No energy cost for bullets, no energy gained if they hit.
  • No complex scoring formula. A stage can handle scoring however it wants. The sample battle scoring library uses survival rounds for 1v1, or kills + damage for free-for-all battles.
  • No wall damage.
  • No ram damage.
  • No max speed.
  • No bullet-bullet collisions.
  • No filesystem access.

What BerryBots adds:
  • Walls. You navigate around them or hide behind them. They obstruct your vision and lasers (and everyone else’s).
  • Torpedos. Secondary weapon, more powerful but harder to aim, do splash damage and knockback, and move through ships and walls. A nice complement to the classic projectile weapon and to the presence of walls.
  • Programmable stages. You can create interesting configurations of walls and zones and write all types of custom gameplay or scoring. So bot programming doesn’t have to just mean battling other bots - it can mean navigating mazes, racing, jousting, arcade style challenges, targeting challenges, battle mode variants, or anything else you come up with.
  • Easier to program teams. A team is a single program that controls multiple ships. No need for laggy inter-bot communication and the entire team automatically shares all vision of the battle.

While the “missing” elements each add some gameplay depth to Robocode, they also add complexity to the game rules and to writing bots. I’ve heavily scrutinized every bit of complexity added to BerryBots. I want the ship API to be as simple as possible and any sacrifice to that really needs to prove its worth.

Here’s an example: If you start writing a 1v1 Robocode bot, you will spend some time figuring out how to spin your radar and lock it on the enemy so you scan him every tick. Maybe it takes you twenty minutes or an hour before you have a radar lock. In all the rest of your Robocoding days, you will not improve upon this radar, and it will be functionally identical to every other 1v1 bot in history. You will copy/paste it into your next bot and watch newcomers struggle with this silly exercise.

For a 1v1 Robocode bot, writing radar code is like a tax you need to pay before getting the chance to program any real intelligence or strategy. It doesn’t add anything cool to the gameplay, but you have to do it. These are the types of elements I've tried to avoid in BerryBots.

Note that some of Robocode’s missing features could be added as part of a stage. And I’m open to modifying the game rules of BerryBots if something proves to be really unbalanced or there’s enough demand for it.

Author:  Wolfman [ Tue Mar 12, 2013 9:37 am ]
Post subject:  Re: BerryBots vs Robocode game rules / physics

Heya chap. I was about to re-start robocode after a long absence but saw this project of yours. Convince me to try my hand at Berrybots rather than go back to robocode! :)

Are there any Berrybot competitions or community challenges around? (Is there much community yet?)

Is it worth learning yet another scripting language to play the game? :)


Author:  Wolfman [ Tue Mar 12, 2013 10:46 am ]
Post subject:  Re: BerryBots vs Robocode game rules / physics

Also is it deliberate that the API allows access to the exact location and heading of the bullet so you can exactly predict where it is at all times? In Robocode you don't have access to this and half the game is trying to predict where the opponent is firing so you can avoid it. In Berrybots with the current system the game will turn into avoiding the lasers with the highest accuracy. Which in itself is an interesting challenge.

Are lasers a point but drawn at as a line? I couldn't see anything in the Constants table that suggested a length, or how they check for collisions etc.


Author:  Voidious [ Tue Mar 12, 2013 12:53 pm ]
Post subject:  Re: BerryBots vs Robocode game rules / physics

Hey there! :-) Man, you were before my time in Robocode, though I've read about some of your stuff. You might be curious to hear that genetic algorithms are something a few of us use to tune our guns these days.

No, there's not much community yet. I only just released the GUI version of BerryBots last night, which I think is a prereq to really gaining any momentum. One of the next things I'll be building is a battle runner API, which is needed for any batch battles and competitions, and to hold onto anyone that wants to get serious about BerryBots.

So I'm not sure I can convince you :-) Getting into BerryBots vs Robocode would be pretty different experiences at this point, and Robocode/RoboWiki is still going strong. I'd be much more prepared to argue why BerryBots > Robocode in a classroom setting - the programmable stage gives a lot of flexibility in how it's used and what it teaches, and lessens the ability to plagiarize bots off the web. Another cool looking game, which is pretty sleek and more similar to Robocode is

Not sure what misled you, but you can't see bullets directly - they are invisible in the air just like Robocode. You do have two additional pieces of information though:

* Instead of having to monitor energy, you simply see an event when any visible ship fires a laser or torpedo.
* You see when lasers hit any ship that you can see, not just when your own lasers hit enemies.

Between these and the ability to see in all directions, you could actually build kickass melee surfing on an open field. Walls make this a lot hairier though.

Lasers are a line segment, with length the same as speed, which is also how Robocode works (though not how it's drawn/presented). Each tick, everyone moves, then lasers move, then it checks for collisions. If you want to get your hands dirty, here's the actual physics code: ... e.cpp#L359

Hope to see you around!

Author:  Wolfman [ Tue Mar 12, 2013 2:49 pm ]
Post subject:  Re: BerryBots vs Robocode game rules / physics

I think I may try Berrybots as it will be a learning experience (no Lua knowledge) and its not so much of a solved space - lots of opportunity to be more creative than robocode currently which seems to be incremental changes of surfing and GF targeting (although melee battles are probably a different problem). The introduction of walls and pathfinding adds a lot of strategy for the movement.

Regarding seeing bullets, the API here: ... LaserEvent

mentions "LaserHeading: The angle at which the laser was fired."


Author:  Voidious [ Tue Mar 12, 2013 2:59 pm ]
Post subject:  Re: BerryBots vs Robocode game rules / physics

Aha, I see - that's the stage's version of events, which does have full knowledge of everything.

Author:  Wolfman [ Tue Mar 12, 2013 3:01 pm ]
Post subject:  Re: BerryBots vs Robocode game rules / physics

Oh yeah sorry, missed that! My bad! :)


Author:  Wolfman [ Tue Mar 12, 2013 3:02 pm ]
Post subject:  Re: BerryBots vs Robocode game rules / physics

Also it would be nice to have graphical debugging, thats one of the most useful things when coding! :)


Author:  Voidious [ Tue Mar 12, 2013 4:00 pm ]
Post subject:  Re: BerryBots vs Robocode game rules / physics

It's most definitely on my short list! I also use them a lot as a bot author. Maybe I should move them up the list since you're my only active forum member. :-P

(Trivia: the "ship destroyed" graphics in BerryBots are actually inspired by some "victory graphics" I added to Diamond, my Robocode bot.)

Author:  Wolfman [ Tue Mar 12, 2013 5:50 pm ]
Post subject:  Re: BerryBots vs Robocode game rules / physics

Anyone else from the robocode community interested in this project at all?


Page 1 of 2 All times are UTC
Powered by phpBB® Forum Software © phpBB Group