[Home]Robocode2/WildIdeas

Robo Home | Robocode2 | Changes | Preferences | AllPages
Difference (from prior major revision) (no other diffs)

Changed: 1,2c1,64
null
silted racks finely.assumed:adjudging atonement,verdure tramp Minoan task [phentermine ] illustrated
Have a crazy (or not so crazy) idea of what could be done with Robocode2? Post it here.

Custom renderers. Someone on the RobocodeRepository mentioned the possibility to use external renderers to show the games. I have been thinking along the same lines and see these benefits:
* Distributed broadcasting of games. We could actually have a wide audiance when games are played and honour decided!
* Performance
* Fun
I suppose a Swing or AWT renderer should be included in the main distribution jar working much like Robocode works today.

The open sourced CrystalSpace comes to mind. It works on many platforms and could render Robocode matches in 3D glory.
-- PEZ

I have a lot of 3D modeling + texture mapping experience (even made some counter-strike levels a few years back), so I could create the models if someone else did the programming for a 3D version. --David Alves

Robots leaving behind a "corpse" after being destroyed. Might make for some fun melee battles :-) --Dummy

Capacity to write the robot in any langage

If you mean any programming language, I don't think so. But I do think that people from other countries could translate the UI elements into different languages. Perhaps even the API? (ChineseRobot? extends Robot, provides chinese-language versions of the functions?) That might be silly though since the Java API is in English anyway. --David Alves

Not any programming language, but I know that Microsoft's experiment in creating a world in which ".NET" programmed robotic animals live (i can't recall the name) was a success. People could write their own 'animal'-DLL, and run it in that world, and see it being eaten by other animals.
I personally like the ".NET" language for Robocode II. It allows you to write in C#, VB.NET, J# and VC++ .NET, and the less known APL, AsmL?, netCOBOL for .NET, Eiffel ENViSioN?!, F#, Forth for .NET, Fortran for .NET, FTM95 for .NET, Haskell for .NET, SML.Net, Mercury on .NET, Mondrian for .NET, P#, Active Oberon for .NET, Delphi for .NET, PerlNET?, Powerbuilder, Python for .NET, Visual RPG for .NET, Ruby for .NET and S#.NET.
So I think that .NET would be a good choice, also because it will be platform independent, and it ships with a very big library with all the functions you can imagine. For example, the new GDI+ does also support Alpha transparency, which could be used for good effects.

And, I am NOT a Microsoft fan, nor an employee, but I do like this library. It saves me a lot of time! --Daniël Pelsmaeker

I am a Microsoft employee (well, intern for another week), and I also see some advantages in using the Common Language Runtime for Robocode (or a similar game). Robocode kicks the crap out of Terrarium, I just wish I could have found something like this when I was assigned to "learn C#" when I got here. Of course, on the negative side, it's less obvious how to download managed code compilers for the .NET framework, and I'm guessing there is no way to install it on *nix platforms (although it probably exists for Mac). It's also all a couple times bigger than Java :-p That aside, of course, the whole Robot API would have to be CLS-compliant, which may limit some desirable 'features' it would have if it used only one language (like I'm guessing that C# events couldn't be used because J# probably doesn't support it, but I haven't tried). -- Kawigi

I think even better than distributed viewing of Robocode matches would be distributed processing in order to take the load off of the people running tournaments. This is how I envision it: you log into the website of the tournament and load a java applet that accesses the RobocodeEngine? API. The server sends you the battles to run, and the packages you need to run them, and then you run battles for the server and send it results. This would allow much bigger leagues that ran 1v1 battles with every permutation available. --nano

That would be a ROBOCODE@Home at its very best! -- PEZ

There's a big potential for cheating there. Someone could write a client that reported incorrect scores. If you could think up a way to prevent this then it's a great idea. --David Alves

I believe cheating could be overcome with encryption. --nano

Robocode II robots are nothing more than programs. Little scripts. Altough they seem to need more space and memory lately, I don't think that a *good* Robocode II program would have any trouble with that. Robocode II doesn't need a rendered interface. If it only emits the battle data in a small format, then any client running on the Robocode II user's PC, or anywhere on the internet, can render the battle. No need for encryption, no worrying about cheating.

This would separate the actual Robocode program from the rendering program. With great increase in speed (if desired). --Daniël Pelsmaeker

This is what Roboleague does, but it still takes up a lot of time to run a decent-sized competition. I for one would love to participate in a Robocode@home project. I also believe it is already possible to do this for Robocode1. I think I'll give this idea a bit more cycles. Public/private keys could be used to verify programs and secure transfers, but it doesn't solve the problem of decompiling and modifying the client (allbeit with great difficulty).
--FnH


For ranking we might want to look att [ASE] - the All Seeing Eye. A system used by first person shooter gamers to keep track of who's king of the hill. -- PEZ


Dsitributed processing sounds great, but for what reason the Member has to calculate some battles only (just like seti I think)?

My vision for this approach is:
* There is a Server serving the simulation environment
* The Bots and the Viewers can run remote, comunication via RMI, JINI or CORBA

For this idea I see some advantages:
* bots are localy debugable
* there is not any more a problem to allow multithreading
* processing time is limited by the own system only
* you can do both, the lanparty with many systems and bot's but maybe also an single host / user game

But there is also an disadvantages:
* (lanparty) all members has to be online for the battle.
* (single host / user batle) with an realtime OS there is the posibility to build up well balanced Robocode 1 like Single host battles (many VM's in OS tasks an on higher prior. task for the simulation). Maybe there is also a way to do this in pure Java - but I did'nt know no easy one. -- mje

I think that RoboCode2 should support any programming languagens, not just Java. Instead of directly running the components it should run as a server which listens for clients to connect and send commands. That way, you could implement your robot in any programming language you wish. -- Acid06

That would mean no security then. I don't want to download a robot (manually or automatically through RoboRumble@Home or similar) that screws up my entire computer, deleting files, installting spywware, inserts a virus or two, a trojan etc. Anyway, the robocode2 discussion here is a bit obsolete now that robocode is open source. -- Pulsar
Have a crazy (or not so crazy) idea of what could be done with Robocode2? Post it here.
Custom renderers. Someone on the RobocodeRepository mentioned the possibility to use external renderers to show the games. I have been thinking along the same lines and see these benefits: I suppose a Swing or AWT renderer should be included in the main distribution jar working much like Robocode works today.

The open sourced CrystalSpace comes to mind. It works on many platforms and could render Robocode matches in 3D glory. -- PEZ

I have a lot of 3D modeling + texture mapping experience (even made some counter-strike levels a few years back), so I could create the models if someone else did the programming for a 3D version. --David Alves

Robots leaving behind a "corpse" after being destroyed. Might make for some fun melee battles :-) --Dummy
Capacity to write the robot in any langage
If you mean any programming language, I don't think so. But I do think that people from other countries could translate the UI elements into different languages. Perhaps even the API? (ChineseRobot? extends Robot, provides chinese-language versions of the functions?) That might be silly though since the Java API is in English anyway. --David Alves
Not any programming language, but I know that Microsoft's experiment in creating a world in which ".NET" programmed robotic animals live (i can't recall the name) was a success. People could write their own 'animal'-DLL, and run it in that world, and see it being eaten by other animals. I personally like the ".NET" language for Robocode II. It allows you to write in C#, VB.NET, J# and VC++ .NET, and the less known APL, AsmL?, netCOBOL for .NET, Eiffel ENViSioN?!, F#, Forth for .NET, Fortran for .NET, FTM95 for .NET, Haskell for .NET, SML.Net, Mercury on .NET, Mondrian for .NET, P#, Active Oberon for .NET, Delphi for .NET, PerlNET?, Powerbuilder, Python for .NET, Visual RPG for .NET, Ruby for .NET and S#.NET. So I think that .NET would be a good choice, also because it will be platform independent, and it ships with a very big library with all the functions you can imagine. For example, the new GDI+ does also support Alpha transparency, which could be used for good effects.

And, I am NOT a Microsoft fan, nor an employee, but I do like this library. It saves me a lot of time! --Daniël Pelsmaeker

I am a Microsoft employee (well, intern for another week), and I also see some advantages in using the Common Language Runtime for Robocode (or a similar game). Robocode kicks the crap out of Terrarium, I just wish I could have found something like this when I was assigned to "learn C#" when I got here. Of course, on the negative side, it's less obvious how to download managed code compilers for the .NET framework, and I'm guessing there is no way to install it on *nix platforms (although it probably exists for Mac). It's also all a couple times bigger than Java :-p That aside, of course, the whole Robot API would have to be CLS-compliant, which may limit some desirable 'features' it would have if it used only one language (like I'm guessing that C# events couldn't be used because J# probably doesn't support it, but I haven't tried). -- Kawigi

I think even better than distributed viewing of Robocode matches would be distributed processing in order to take the load off of the people running tournaments. This is how I envision it: you log into the website of the tournament and load a java applet that accesses the RobocodeEngine? API. The server sends you the battles to run, and the packages you need to run them, and then you run battles for the server and send it results. This would allow much bigger leagues that ran 1v1 battles with every permutation available. --nano

That would be a ROBOCODE@Home at its very best! -- PEZ

There's a big potential for cheating there. Someone could write a client that reported incorrect scores. If you could think up a way to prevent this then it's a great idea. --David Alves

I believe cheating could be overcome with encryption. --nano

Robocode II robots are nothing more than programs. Little scripts. Altough they seem to need more space and memory lately, I don't think that a *good* Robocode II program would have any trouble with that. Robocode II doesn't need a rendered interface. If it only emits the battle data in a small format, then any client running on the Robocode II user's PC, or anywhere on the internet, can render the battle. No need for encryption, no worrying about cheating.
This would separate the actual Robocode program from the rendering program. With great increase in speed (if desired). --Daniël Pelsmaeker

This is what Roboleague does, but it still takes up a lot of time to run a decent-sized competition. I for one would love to participate in a Robocode@home project. I also believe it is already possible to do this for Robocode1. I think I'll give this idea a bit more cycles. Public/private keys could be used to verify programs and secure transfers, but it doesn't solve the problem of decompiling and modifying the client (allbeit with great difficulty). --FnH

For ranking we might want to look att [ASE] - the All Seeing Eye. A system used by first person shooter gamers to keep track of who's king of the hill. -- PEZ

Dsitributed processing sounds great, but for what reason the Member has to calculate some battles only (just like seti I think)?

My vision for this approach is:

For this idea I see some advantages:

But there is also an disadvantages:

I think that RoboCode2 should support any programming languagens, not just Java. Instead of directly running the components it should run as a server which listens for clients to connect and send commands. That way, you could implement your robot in any programming language you wish. -- Acid06

That would mean no security then. I don't want to download a robot (manually or automatically through RoboRumble@Home or similar) that screws up my entire computer, deleting files, installting spywware, inserts a virus or two, a trojan etc. Anyway, the robocode2 discussion here is a bit obsolete now that robocode is open source. -- Pulsar

Robo Home | Robocode2 | Changes | Preferences | AllPages
Edit text of this page | View other revisions
Last edited May 18, 2006 23:42 EST by Florent (diff)
Search: