BerryBots pre-release testing help

So far it's working on my Windows XP box. But the first match I tried seems potentially buggy. I put Drifter and MyFirstShip into lasergallery. Is lasergallery just meant for 1 ship? The two ships seems to start on top of each other. Is robot positioning random? Or controlled by the level perhaps? Sometimes Drifter drifts away and it runs okay, but most of the time Drifter holds still while MyFirstShip totally spazzes out, always appearing to touch Drifter but bouncing from side to side like mad. [1]

A couple other things. I realize this is still an early release, but is there a way to set descriptions for stages? One of the first things I noticed was that I had no idea what the stages were meant for, outside of guessing based on the file name. It would be nice if their was a way for stage designers to set descriptions for their stages that could be read by users when picking a stage to run.

Also, when the New Match window is open, the BerryBots window where the battle plays out doesn't repaint. A minor thing, and it's interesting the patterns I can make by running other windows over top of it, but I doubt that's an intended feature. :-)

I think I've fixed the repainting issue, but I don't have any machine where I can reproduce it. If you could try this on XP sometime (no rush) I'd love to know if it's fixed: [1] (I'm actually kinda of surprised/excited BerryBots even works on XP...)

Also took a pass at the stage description / wrong number of ships stuff.

Another bug or perhaps just me not understanding the level, on the drift stage I put WallHugger and Drifter in it. WallHugger wanders around the walls while Drifter tries to go up the middle. Drifter always wins, but WallHugger always makes it to and around the zone at the top before Drifter gets there. If the goal is to get to the zone first, WallHugger should be winning. Or maybe I misunderstand the goal?

Looks like what's happening on this stage is that it was meant for only 1 robot. It appears as though whichever robot comes first in the alphabet gets to play, while the other robot just wanders around pointlessly wondering why the other kids won't play with him.

Would you rather me be spamming all this feedback in your BerryBots forum? Or do you want to keep it here among Robocoders for the moment. I have been assuming the latter.

Either is fine. Here probably makes more sense for now. Huge thanks for all the testing/feedback!

• Not knowing which bots/stages work together is definitely the biggest source of confusion I see at the moment. Indeed lasergallery and drift are only designed for one ship. I'm not sure the best way to address this, but I think I'll raise the priority on this and get it fixed before release.
  • I could just read any comments at the top of the stage file as the description (they do all have such comments) and put it in the UI somewhere, like stage preview.
  • In addition, each of the 1p stages could just destroy any player ships beyond 1 and print a message to the screen. (The mazes do print a message actually, but not the others.)
  • It's no substitute for fixing this in-game, but if you do want to read about the stages, they all have write-ups (though some with out-of-date source code) at the wiki: [1]
• Specific start positions can be defined by the stage, any beyond that they're random.
• Did you mean literally "on top of each other", like they were overlapping and stuck? If so, that's a bug I'd love to reproduce. It's fairly low level in the game engine that this should never be possible.
• The New Match dialog is styled to be a modal thing. The main window doesn't accept input or update until/unless you close New Match. I'd never seen any visual artifacts like that though (just tested here Mac and Win 8). I'll see if I can reproduce somewhere and try to figure out a fix. This happens even with New Match retaining focus the whole time, just covering/uncovering part of the main window?

Ok, I see what's happening now on lasergallery. The first ship nabs the built-in starting position, but the second ship is what the stage saves as the "player ship", and the stage tries to set its position to that spot each tick.

I have a bunch of thoughts on the ship/stage compatibility issue. I'm trying not to over-engineer it, but it is lacking right now for sure.

• The stage description would go a long way, I think that's a must-have.
• In general, I think for ships/stages you download yourself, you have a good idea what you're doing, and engineering solutions to ensure compatibility are probably overkill. In Robocode, I don't see a lot of confusion trying to run 1v1 bots in Melee battles, or Movement Challenge bots in regular battles, etc. So I partly see this as an issue specific to sample ships/stages, or at least magnified there.
• An API to let the stage set min/max ships is an idea I'm considering. This would let me fail fast and not even start a misconfigured match. My issue with this is it's still not sufficient (Snail would be pretty dumb on lasegallery).
• On my to-do list is to let a stage set a tag for the rule set it's using. Just a string, like "battle" or "maze". Then ships could check this value in case they wanted to behave differently based on the rule set. E.g., a team might support "battle" and "ctf". I could expand on this by letting ships define what rule sets they support, though I'm on the fence about that.

I think for now I'll just do:

• Show stage descriptions in New Match dialog somewhere.
• Update sample stages to gracefully handle too many ships.

Oh, and:

• Include in the stage descriptions which sample bots work.