BerryBots forums

Well, yes to interested - a few folks helped me test it last week (discussion thread), and there's been other discussion scattered around the wiki, like on the Raspberry Pi page and talk page.

But no to anyone actually building ships/stages yet. I'm not sure what will happen with Robocoders joining up, but I've tried not to spam them too much about it. For now I'm just trying to be patient and think long term and build something cool. (Though I'd of course be elated if you built a ship that crushes BasicBattler and then Skilgannon can't resist trying to one-up you... )

That might take me a while, I've got to learn Lua first! But I've got it all working on my Mac so going to give it a go over the next few days!

-wolfman

Thanks Justin!

I was going to do better results handling and a game runner API next, which are needed to enable batch battles, tournaments, "BerryRumble", etc. But I think I'll shift to the graphical debugging since it's like the first request from both you guys.

Right now, walls cannot move. This wouldn't be hard for me to provide in the game engine, but I thought it would be very hard for bot authors to deal with. (Even static walls are tough to deal with!) You can see in Snail how he creates a graph of valid paths around the stage to do real path-finding. This is very slow, and it's something you'd have to recalculate every time a wall moves. When I add CPU usage limits, the plan is to let "init" have a lot more CPU time than "run", so it's the perfect time to do this kind of one-time calculation. I'm certainly open to adding moving walls and zones, it's just something to be careful about, design-wise.

That said, there are ways a stage could implement that kind of gameplay already. The stage can change the speed / heading / location of ships, so it could simulate a moving object hitting them. It can also let ships know the location of these moving objects by sending custom stage events. So the remaining piece is just letting the stage draw the objects on screen. That's something I've considered, and giving the stage the same drawing API as ships' debugging graphics would make a lot of sense.

I started work on graphical debugging and made a new thread if you guys want to have a look and give feedback: viewtopic.php?f=1&t=36

Ok, just released v1.1.1 with graphical debugging! You can check out Snail's to see an example.

Hey and welcome!

You can split code across files with require, loadfile, and dofile. You can see require in use in the sample ships and stages. E.g., the scoring for all the battle stages is in its own module - see Battle1 using battlestage.

You mean the avatar limits on the board? I just upped it from 6kb to 50kb to start - didn't realize it was so small. I can take another look later when I have more time to play with it.

No solid plans for bots receiving keyboard/mouse input, but it's certainly doable. Adding it to "debug mode", like when you've enable graphical debugging, would seem straightforward, so I'm certainly up for that. I'd want to be more careful about designing it if you wanted to have it always on/available for all ships and stages. I've also wondered about using game pads with BerryBots - it seems like it might be an ok platform for programming simple game stages designed to be played by humans.

Ok, so "require" is always based from the root ("bots" or "stages"), and you need to use "." in place of "/". So "bots/voidious/mybot.lua" could reference "bots/frohman/somelib.lua" by doing: require "frohman.somelib", then you'd call the functions with frohman.somelib.function(). Since that's kind of verbose, I've been putting my modules in the root.

loadfile, dofile, and StageBuilder.addShip use relative paths. So the above would be: loadfile("../frohman/somelib.lua") and it's as if the code was just part of the calling file.

So I think with those paths, you need: require "frohman.libs.vector" or loadfile("libs/vector.lua"). All the relevant files should get packaged correctly, with the caveat that if you're dynamically deciding between various files to "loadfile", it's going to miss those.

About the input concerns, it's more of a "what makes sense and would be a good user experience", though I'm also slightly paranoid about privacy/security (even though bots have no file/network access). The RoboRumble client is also a good point and something I'd need to take into account.

Thanks for the kind words and great to hear you're having fun with it! Good luck and don't be afraid to post questions, or make pages for your bots on the wiki.

Well, I'm not sure yet. I think it largely depends on what bot authors are interested in.

One thing I'm planning is that CPU limits will be configurable, and calibrated based on a reference bot. So you could set the limit as "100x as much CPU as BasicBattler uses in battle vs x/y/z", and you could have multiple settings. So with that in place, we could have weight classes based on CPU time. I could also try to build a code size type tool for LuaJIT bytecode, or measure the size of the obfuscated source code.

Yep, it will be. You can try packaging BasicBattler, or most of the sample stages, which use modules and package just fine. On that note, your previous post actually prompted me to write up a wiki page about organizing source code last night, which might be useful to you.

I don't know yet since I haven't tried, but you'd probably have the same type of stuff if we took a similar approach to code size. I'm also not a huge fan of writing ugly code to appease a code size limit, so I've spent most of my Robocode life writing MegaBots. But some people love that stuff so I'm open to it.

Yeah, I think Lua's pretty cool! It feels like you can write powerful code pretty quickly and a there's a lot of flexibility, like a Perl or Python, but it's also really fast, especially with LuaJIT (which BerryBots uses). I'm still pretty new to Lua, though, and I write (mostly) Java code for a living, so it's hard to give a totally fair comparison on how much I "fight" with it.

Yeah, that's an interesting idea. Some reasons I like just telling you about all the walls up front are:

• I found walls pretty hard to deal with as a bot author, so mostly went for the simplest possible model.
• Recalculating pathfinding stuff is really slow, so it's nice if you can just do a lot of that stuff once in init instead of having to do it every tick (in case you see new walls).
• If you consider a BerryRumble with a few different battle stages, bots could just hard-code knowledge of the wall layouts for each one, so it would be kind of pointless to hide that info.

But maybe it would be cool to have as an option, especially for mazes or randomized stages. You could have a StageBuilder call that makes it so walls only get added to the set returned by World.walls() after you see them once. Seems like a pretty clean setup and would make for an interesting challenge.

Wait, you mean the default ship doesn't say "I eat tanks for breakfast"? A tank wouldn't stand a chance! Did you try ship:setGraphic("3dMonster")?

Honestly though, I am intrigued by the idea of letting you design a custom ship graphic. Even though I like the default design too. And I probably would have made the ship bigger if I'd thought of this up front - it's pretty small, so not a ton of room for crazy cool graphics. I guess I could let you design a bigger graphic even if the ship's "real" size is still small.