Robocode Online Web Application - what do You think?

Fragment of a discussion from Talk:Main Page
Jump to navigation Jump to search

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.

Chase06:31, 3 February 2014

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. :-)

Voidious (talk)14:09, 3 February 2014

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.

Straw (talk)01:07, 5 February 2014

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).

Voidious (talk)05:01, 5 February 2014

I do know that at several high schools in Seattle, Java is the language taught. Both AP and IB computer science courses use Java.

Straw (talk)03:38, 6 February 2014
 

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.

Voidious (talk)05:07, 5 February 2014

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...

Straw (talk)03:35, 6 February 2014

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. :-)

Voidious (talk)06:10, 6 February 2014

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.

Straw (talk)05:20, 7 February 2014

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. :-)

Voidious (talk)15:32, 7 February 2014

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?

Straw (talk)20:51, 7 February 2014

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.

Voidious (talk)21:18, 7 February 2014
 

Sorry, was only focused on 1v1 movement there, but my feelings are similar for Melee. It's gotten less attention than 1v1, but I think it also has a lower ceiling due to noisy data. I don't think bullet shadow detection can be improved in 1v1 (besides bug fixes), same for radar.

Voidious (talk)21:25, 7 February 2014
 
 
 

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.

AW (talk)15:18, 7 February 2014
 

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).

Voidious (talk)06:23, 6 February 2014

I used to like targeting systems, until I found the joy that was movement systems.

Chase06:45, 7 February 2014
 
 
 

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.

MN (talk)01:03, 30 June 2015