Robocode Online Web Application - what do You think?
I need to work on it, but I was considering switching it over to C/C++ Lua like Berry Bots. I realize that Java is a lot of overhead, but due to Robocode I am most comfortable in the language.
I think Lua is awesome and totally perfect for programming games, but its relative unpopularity is probably worth considering too. I think Python or JavaScript are probably the ideal languages for attracting people to a programming game right now. But I like Lua and it's a choice I'm still happy with. And if Lua suddenly takes off, I'll be in pretty good shape. :-)
It doesn't seem language is the largest barrier of entry into robocode. In order to make a semi-decent robot, many basic systems need to be in place which can be difficult or time consuming to program, especially for newcomers such as myself: wave tracking ( especially enemy's), precise prediction, radar control (especially in melee), movement control (wall avoidance, getting where you want to go),and bullet shadows. Getting these systems into place is necessary to make good bots, however, none of them seem particularly interesting or fun to program, and they can be quite difficult to do well. Perhaps a helper class extending AdvancedRobot could be made to perform some of these functions, so newcomers could spend more time thinking about and programming their strategies. I have seen a school robocode competition video online, and all the robots in it were very basic by roborumble standards, probably because the students had to spend most of their time figuring out basic things as opposed to strategy / AI.
Well, I'd agree that the algorithms etc needed to succeed in Robocode are more complex than just a language syntax. But I think a beginner or novice programmer has a pretty strong inclination towards certain languages, like the ones they already know (obviously) or that seem popular or easy to learn. In my mind, once you are starting to assess game rules and trying to design a good robot, you have already passed the "barrier to entry". :-) And I think that demographic is also more likely to play programming games than experienced software developers (though our numbers at the RoboWiki are surely skewed).
Oh, and there are some frameworks that I think are like what you're suggesting. Module is the big one I know of. But my experience with Robocode is most people (myself included) use it as an outlet for urges to build stuff, almost like Minecraft or Lego. So people are more likely to build a robot framework that nobody will ever use than they are to use someone else's framework so they can focus on building a strong bot. :-) But people do use Module and they also take parts from other bots. Maybe we could organize that / make it easier to find somehow.
That doesn't do exactly what I am talking about. While it provides some functionality, in the form of modules which perform an action for a specific part (such as anti gravity movement system), it doesn't provide the tools for making your own systems. Say you had a framework which automatically: controlled radar, tracked enemy waves, tracked your own waves (with virtual wave functionality), tracked bullet shadows on enemy waves, and provided a goto point sequence function which would automatically take the robot to the specified points, avoiding walls, in order, in an efficient manner, allowing modification of course. This would take most of the basic "gritty" aspects out of the game, allowing newer programmers to start thinking about where to move, not how to get there at all. I think the strategy is the much more interesting and intuitive part of robocode. Maybe I should start making such a framework...
I don't know, I could be wrong… But I think you greatly underestimate how much your appreciation for that strategy was nurtured by the process of building those systems. :-)
I haven't even finished building all those systems! Still haven't bothered with precise prediction, not even a real movement system either. To me, the machine learning part is one of the most interesting parts, but it meshes with other things that make it a bit more than pure classification. For example, how bots surf multiple waves is more of a path finding than classification problem, and can be approached in multiple ways. Bullet shadows also make targeting movement interaction more complex: should I shoot to an area which I think has high danger which I cannot easily avoid in order to reduce the danger, if I I think the enemy has a lesser probability of moving there? Melee seems to add many more layers of complexity above raw classification.
Haha, ok, I stand corrected. :-P
Btw, don't take any of this as me disagreeing with you on a fundamental level or anything. But my Little Man kinda hears it as building a Robocode framework to plug all the holes in Robocode's game design so you can focus on the tiny slice of the game that you actually like. It just feels unproductive, like you could build something so much better completely outside of Robocode. But that's what happens when you stop building Robocode bots and start building your own games. :-)
Do you think movement at a base level has been "solved"? That is, do you think that the movement algorithms (actually going places, not classification) can be improved? What about precise prediction, bullet shadows (where they are, not what to do about them), and radar?
I'm not sure, I haven't thought about it in a while. I don't feel like it's solved, but it does feel like a point of diminishing returns. (Well, for me and Skilgannon. The rest of you have work to do. :-P) Then again, that feeling also precedes most breakthroughs.
I do think any general improvements to movement would still fall under the banner of "Wave Surfing". But I certainly think there are improvements. Heck, maybe a lot of them - for all the bots in the rumble and all the activity on the wiki, there's actually very few people in the world that have reached the upper echelons of Robocode and kept trying to improve on the state of the art. I'm sure if 5,000 PhD students spent a few years building Robocode bots, they'd do pretty well. :-)
But I think there's a lot more fertile ground hidden by our metrics, too. We focus pretty strongly on APS. Only a few top bots (eg Shadow, DrussGT, Diamond/Dookious) have any kind of evolved strategy for fighting other strong bots. I'd say we've mostly side-stepped the arms race between adaptive movements and anti-adaptive targeting, which could be pretty interesting.
I think (and my weighting experiment with Gilgalad seems to back this up) that the attributes used in the classification algorithms are far more important than the weights (although there is still the cluster size, the shape of the function, and the data decay). Since most of the recent top bots use kNN and most of them, I assume, have similar attributes, I suspect that the difference in strength between these bots is actually the "frameworks" not the classification systems. Also, I agree with voidious that most people who play robocode like to make everything. I could have used rednaxela's kd-tree, but making my own is fun. It's not like we are on a deadline and need to get things done quickly. If you enjoy playing with classification schemes, I think you would enjoy making your own framework.
Although I do think there are a bunch of parts of Robocode itself that are mostly friction, stuff that takes time and energy but doesn't add much to gameplay depth. I noticed and thought about this stuff a lot while developing BerryBots and wrote up some thoughts if you're interested: [1]. I know what you're saying - for instance, a lot of us are content to spend most of our lives writing classification (targeting) algorithms, so why not just make that the game and get rid of all the cruft? In BerryBots you can sorta get halfway there by writing a stage (eg LaserGallery).
Processing input and output data is a huge part of Robocode development. Which is an important part of AI too.
A simpler game which focus more on strategy is Code Ruler (also created by AlphaWorks, like Robocode). Most of the operational stuff is embedded in the main framework. Units move in 8 directions, you produce 2 types of units and everything in the battlefield is given to you in a big array. But the game is not very popular.
In most other popular strategical games with strong AI community, like computer Chess and computer Go, you end up spending most of your time polishing "operational" sub-systems too, like move generation, caching, threading, networking...
And these are virtual robots, with no physical/mechanical parts. In "real" robots, mechanics take most of the effort in building a robot.
