Raspberry Pi

Hi,

My name is Paul Evans, It's been 6 or 7 years since my last bot change.

Robocode is a terrible addiction and my bot SandboxDT has not been changed since 2004 but I am pleased to see it is still in the top 60.

It has recently come to my attention that a UK Charity (The Raspberry PI Foundation) is about to release a new computer on the market - this computer is the "Raspberry_Pi".

The foundation's aims are to manufacture a computer so cheap that anyone should be able to afford it (The "B" model will be $35) - their purpose is to get youngsters programming again - not just learning to use Word and Excel.

Robocode is a good fit to these aims and I would like to ask this community to help bring the joy's of programming to the next generation of youngsters.

What I would like to see:

Stage 1: An all inclusive distribution of OS and Robocode and relevent Robocode/Java documentation - The Raspberry PI will boot from an SD card into a linux OS - to get prospective coders into Robocode lets make getting Robocode up and running as easily as possible (as easy as PI).

Stage 2: As for stage one but with an ide customised for Robocode - libraries loaded/configured in an default project/robot ready to go. (BTW The compuer has at most 256MB ram (shared by the GPU) and runs a arm processor at 700Mhz).

Stage 3: Let's try and get the really young ones involved - Java is fairly heavyweight - can we have robots written in lighter languages such as Python (Jython?) or some other language or script. A distribution like this needs to be really easy to get started - most parents and teachers do not code - at primary school there may be no effective IT support.

Stage 4: Tanks, Bullets and warfare ain't to everyones taste - however Robocode has an excellent headstart in that because it has a very effective sandbox for allowing strangers code to run in - it provides an excellent environment to allow code swapping and running without risk - ideal for schools. It would be nice to see if the Robocode Physics and display could be exposed in a nice interface to allow the teaching community to develop new games - I want to encourage developers, not plagiarisers - by changing the physics of the game a teacher could force the youngsters to experiment and write their own code not just lift a bot from the internet.

It's been a long time since I've been an active part of this community - and I know I'm asking alot - I have no affiliation with the Raspberry PI or the Foundation but I have been a school governor and have been unimpressed at the level of IT skills being produced out of UK schools - I think Robocode and the Raspberry PI can help.

I you think this is a good cause please promote this page on the home page of the wiki to ensure all in the community can see it - fix up any links etc that I haven't done - feel free to take the lead. As a sweetener if the community takes this project to heart I'll give details of an innovation in SandboxDT not released to the community to date (and which I think is unique to DT)- I may even start to develop again.

Paul Evans - author of SandboxDT

Hi Paul, it has been a long time. I've also been reading about the Raspberry PI and find it a very interesting project, with a philosophy similar to Robocode, making coding accessible to everyone. It would take someone much more knowledgeable than me to make it happen, though. It would be akin to making java/Robocode run on a smartphone, with many technical limitations. A very interesting variation would be one robocode robot running on each PI, but that would take a complete redesign... Anyway I really hope someone makes it happen, even if just to finally know the secrets of SandboxDT or to see you take on the current, and apparently invincible, Robocode King. :) --ABC 12:28, 6 February 2012 (UTC)

Hi ABC - still at it I see - good to talk to an old adversary (I have a smile on my face as I type). I see some things have changed - It looks like IBM managed to release robocode which is nice - so there is a chance to make sure it works on the Raspberry PI - I think it will fit into RAM OK but I think we'll need to loose the bullets and go for a football type game if it's to have wide appeal in education - have you ever looked at the robocode source - is this even possible? -- Paul Evans p.s. no-one is invincible.

Sure thing, it has been an open source community project for a long time now, with lots of changes/fixes/improvements. But I'm not the best person to talk about it, I've been inactive for years. Flemming N. Larsen is the main developer now, and there are lots of current (or more recent) players that know much more about the current state of Robocode than I do. I know about the current King's _apparent_ invincibility though, he reminds me of another great player from a long time ago... :) --ABC 16:35, 6 February 2012 (UTC)

Hey Paul, interesting proposal! I've heard about the Raspberry PI for a while and it semed rather interesting. I don't know how much time I'll be able to find for it but I may be able to try to help. About alternative rules and getting rid of the bullets, I believe there was some recent work on the robocode engine to make it support different rulesets (i.e. capture the flag), but I think that work was incomplete and last touched over a year ago. I do wonder though, if it may be easier to make an engine mostly from scratch to support different kinds of rules though... One other thought that comes to mind, is perhaps it would make sense to make a more diverse suite of "programming games" with similar APIs, rather than just sticking to things using robocode physics. Any thoughts on those aspects? --Rednaxela 17:37, 6 February 2012 (UTC)

(Welcome back, Paul!) This seems like a really interesting project. I've also been thinking about Robocode with respect to Code Year. My first impression is the same as Rednaxela: that it may be easier and better to build a lightweight, Robocode-esque game from scratch, or even something only vaguely inspired by Robocode. I've actually had some ideas for simpler, more accessible Robocode-esque programming games for a while now, though nothing that I've fleshed out.

I feel like a graphics / naming overhaul could keep the exact same rules while leaving behind tanks and bullets. But agreed that Fnl or Pavel would have the best technical input on this. I'll post this page to my Robocode circle on G+ and tweet it to @robowiki. ;) --Voidious 20:10, 6 February 2012 (UTC)

I see Robocode 2 being born... There were attempts in the past but most of them tried to make the game even more complex, and got no followers. Besides Robocode, I also like CodeRuler which is a lot simpler (discrete commands, no trigonometry). But it never had a community as big as roborumble. --MN 21:55, 6 February 2012 (UTC)

And some people don´t like LiquidThreads... :P --MN 21:55, 6 February 2012 (UTC) --Rednaxela 14:43, 7 February 2012 (UTC)

Heya Paul. Chase, probably don't know me. Good to see people interested in a new project. I have tried a few small and discrete 'robocode' like projects myself. Roboflight, etc. These never went far, despite some of them working fairly well (at the time). So I know something of the requirements to make a new one. The ARM architecture is very nice in my opinion. Due to the simplicity and cheapness of reformatting and ghosting a SD card, not even sure a sandboxed language would be required (like java). But just my 2 cents, always exciting to start a new project. — Chase-san 04:00, 7 February 2012 (UTC)

As a comment, having discrete moves in a game doesn´t make it any less challenging. CGOS is a good example of the opposite. Although it is definitely not for beginners. --MN 14:34, 7 February 2012 (UTC)

I am on rewriting from scratch with other language. I don't really know about this, but I heard that Android's Dalwik (or whatever it spells) is one of the performance limiting factor on the system. If that is true, and since Robocode is very performance intensive, I don't think we should use VM language.

I just started playing with CodeRally (part of CodeRuler) I think it is nicer for beginner than Robocode (though I find it limiting in some way, especially when an angle is an integer. Much like how JuniorRobot is right now). I think CodeRally idea of throwing spare tire is very good replacement for Bullet and War, though. --Nat Pavasant 12:36, 7 February 2012 (UTC)

I also thought in CodeRally as being good for beginners. The theme is appealing. Although not as good for competitive programming. --MN 14:34, 7 February 2012 (UTC)

About using a non-VM language Nat, I don't think performance would be a good reason to do so. If robots are written in the non-VM language, then then it would be very difficult for users to trust running third-party robots. What's a solution to that? Have the bots written in an interpreted language while the engine is still in a non-VM language perhaps. But then you don't really get speed benefits anyway. So, I don't think performance could possibly be a good reason to use a non-VM language in this case. Btw, Android's VM is probably not relevant to this, because so far as I understand the Raspberry Pi will more typically run a more usual Linux installation (an android port to R-Pi is probably possible, but likely to happen later rather than sooner), so something like OpenJDK Zero (a version of OpenJDK that can, for one, run on ARM), is a more likely VM if Java were used. --Rednaxela 14:43, 7 February 2012 (UTC)

I don't really know about performance, so I compare it to Android since both are ARM. About the trust, I just follow what Chase said above -- run and re-format the system. I don't know much into these things anyway. --Nat Pavasant 14:49, 7 February 2012 (UTC)

Well let me clarify. While its true that's what I ment, I am up for anything. However some may not want to do that, I mentioned it out of hand because it actually seemed like a viable solution to the problem, but was just my silly 2 cents. Not to say it is something that you would actually want to do. What if a robot flashes the binary blob or SD's boot sector with something. Not everyone has the technical expertise to repair either of those. But the project sounds fun, regardless of what environment is chosen. — Chase-san 17:02, 7 February 2012 (UTC)

First thing is to see if we can get an SD card distribution with all the software and documentation to get a newbie started - anyone know of a Java Primer that can be included to get them started? This should not be too difficult to achieve (no coding required I think) - but it has to be an easy one stop shop to capture the market (and not rely on an internet connection from the Raspberry. Where would be distribution be kept?

BTW - off message but where do you get the latest bots from - I want to see DrussGT demolish DT! - as far as I can see the repository and this site does not have the version that is in the rumble. Paul Evans

We could likely use Fedora based distro for it, since all the hardware is the same, don't even need the installer. Get the distro, add the packages, copy the disk image.

Also, you can find all the rumble robots here: http://robowiki.net/wiki/RoboRumble/Participants

— Chase-san 18:26, 7 February 2012 (UTC)

Just a thought, if we use a pure Robocode solution it would be nice to have a static version of the wiki onboard that students can use for offline reference. Maybe some sort of 'sync' mechanism that can be used for updating the pages when internet is connected as well. I've also been looking at the Pi for some time, although more as a replacement for a microcontroller in embedded applications where it would be nice to be able to write components in Python and have USB interface with plenty of easy datalogging available. --Skilgannon 09:43, 8 February 2012 (UTC)

Yeah, actually I was looking around and was thinking BlueJ looks like it might be something to consider as well. I especially like the look of that graphical class structure. I have not tried it yet, but looks like it might be better to just package it instead of our own editor. — Chase-san 12:30, 8 February 2012 (UTC)

Okay, update I tried BlueJ. It is a very simple coding tool, and I think that it is perhaps a bit different from what we are used to. First it can do these fancy graphs, but only if all classes are in the same package. So the tool still needs a little work, but it is probably simple for beginners.

I decided to do a little test and imported Nene into it, which is by no means a small robot. It seems to build the graph OK, but there were a few classes I had to open and resave to get them to register.

http://file.csdgn.org/image/nene_graph.jpg

Next I could not determine a way to move classes between packages, not the end of the world, but I don't see myself using it. Importing the robocode library was fairly easy and straight forward, the actual programming UI had what looked like colored blocks. Making it easier to see what is part of what block, which is kinda awesome. But otherwise it is a very simple IDE like our built-in editor, except with a nicer interface. It has some kind of testing system, which might even be able to fire up robocode and test the robot with the correct test class.

— Chase-san 19:48, 8 February 2012 (UTC)

What a great idea to have Robocode on Rasperry PI! :-) I have been looking for a perfect excuse for buying one! :-) Well, first of all, Pavel did a great job with the modularization of Robocode. But I do expect that we need to adjust Robocode even more with cleaner interfaces in order to e.g. replace the UI.

For quite some time, I have been considering building a completely new version of Robocode from scratch, where bots run in individual processes (instead of thread inside the same JVM), and the communication between the game process and bot processes would be plain IPC based with a simple (Robocode specific) protocol using only STDIN and STDOUT. The process would still need to run in a virtual machine (sandbox... using e.g. the JVM, .NET, Mono) in order to keep the system from harm from evil robots, but if the end-user accepts, the bots could be written in any language (but not necessarily run on any system, if e.g. C/C++ or machine code is used).

We could even wrap the IPC into socket communication as well, meaning that bots could battle across different machines and be run on the net. The game/server, the bots, the UI etc. should be totally independent modules and only communicate through a simple, but fast protocol. This way they could be written in any language and also be replaced. For example, I could do an standard 2D view, and somebody else could create an alternative view using 3D graphics etc. It would be great if Robocode could run "anywhere", on the net, and across multiple machines. I should also love to extend the game with new features, like obstacles, different game types, real tournaments etc. However, all this would mean that the new version (Robocode 2 - The Ultimate AI Challenge) would not be compatible with the current Robocode at all. However, we could get rid of old stuff and limitation present with the current version of Robocode. Personally, I think we/I will need to go into this direction if Robocode should survive in the long run and be even more attractive. :-) However, this will require some time to do, and this would "steal" time from working on the current version of Robocode (1). --Fnl 19:33, 27 March 2012 (UTC)

I would be happy to help out. Been trying to design/create/get people interested in a Robocode 2 for awhile now. :-D — Chase-san 01:56, 28 March 2012 (UTC)

New project from scratch? It's rare event now days:) I'm in too:) --Jdev 17:05, 28 March 2012 (UTC)

I'd love to compete in a Robocode 2. First, I'll say that I don't think compatibility with Robocode 1 is on anyone's wish list. My dream for a Robocode 2 would mainly involve:

• Learn from the things we don't like about Robocode 1, like the arbitrary scoring algorithm, some of the poor API design (JuniorRobot, RateControlRobot were good steps in this direction).
• Add a couple carefully designed features, like random obstacles and a secondary gun that could shoot over obstacles.

Just 2 or 3 small game play changes could open up worlds of new strategies and programming problems. I like a lot of the ideas Fnl puts forth above, architecture-wise, and there's no reason not to re-design all the code with a clean structure. But for me, my main focus would be on well designed game rules that allow for interesting bot programming. Support for any programming language, ability to run matches between remote computers, making it extensible so as to allow any rule set, that all sounds neat, but also sounds like a ton of work that isn't necessarily going to give me more of what I want as a competitor. --Voidious 20:53, 28 March 2012 (UTC)

That architecture overhaul would solve a lot of the issues we are currently facing, like unconstrained heap usage and incompatibility with other languages. Would also combine other ideas that appear from time to time, like Virtual Combat.

But there are some things I would advise to keep. Imperfect information (bullets invisible to radar), continuous move set (doubles), skipped turns (real-time), melee/team and sandboxed execution. These are what make Robocode unique as an AI game.

The drawback would be leaving all those thousands of Robocode 1 robots behind. A very serious drawback. --MN 22:52, 28 March 2012 (UTC)