robocode for android

[Jeffrey Creswell]

Hi all,
Has anyone taken a stab at porting any of robocode's modules to Android?  I love robocode, Java, and Android so I'd be quite interested in this task if it isn't already in the works!  Obviously the biggest hurdle would be the lack of dedicated development tools on-device, but there are a couple ways that might be circumvented (short of trying to port the entire android dev toolchain to run on android, which would certainly be awesome, but very tricky) :
1. Pared-down dev tools within an app -- I've used multiple developer apps that supported interpretation or compilation of C/C++, Python, and Lua.  I don't think I've seen one for Java yet, but it's probably do-able. 
2. Declarative programming -- this'd be kind of like cheating, wrapping prefabricated routine modules in logic bricks or something similar that developer-users could then use to structure their bot's behavior on-device, but a semblance of robocode on smartphones is better than none!  So long as a logic brick SDK was provided so that devs could write and import custom bricks and the prefabricated bricks were open sourced, this option could really work.  This approach would also ease an iOS port...

With either of the above potential solutions prepared, I expect we'd just need to migrate the codebase away from awt and other non-android Java packages/libraries to get robocode's development and battle modes working on Android.  Thoughts?

thanks,
CCJ

[Flemming N. Larsen]

Hi Jeffrey,

I have a lot of thoughts around making Robocode available on Android - actually more devices including iPhone and iPad. I think it is a great idea to have Robocode on Android phone and tablets and well - perhaps also Raspberry PI devices. :-)

But I haven't found a good way to do this with the existing code base.

As you know, Robocode currently runs on desktop computers, and is written in Java SE and a .NET plugin is available for .NET developers.

Most existing Robocode developers might prefer developing on a desktop PC, but that should of course not stop us from making Robocode available on e.g. tables.

However, the biggest challenge I see with creating an Android version is that this will or might require two code bases to be maintained if Robocode for Android should follow the mainstream version for the desktop?

If Java is not used, all existing code should be translated into another language and/or platform, and the GUI and stuff must be moved to other frameworks. This is extremely challenging and requires huge amounts of time.

Another challenge would be to let robots run in separate threads sharing resources, and behave the same way as usual, and existing robots written in Java would not be able to run on a new version written in another language or for another platform. So this is not easy.

A third challenge would be how to write robots on a tablet? Should there be a built-in source code editor. What about the compiler etc.? This might be possible to handle though. :-)

I think the best way to make the existing version available for Android devices would be to use the existing code base as inspiration and write a new one from scratch for made specifically for Android.

The API should be similar except for deprecated methods. The GUI needs to be written from scratch anyways for tablet and would need to support touch screens and a more modern way of doing things.

I should like you to describe how you think this could be done. I think that a Android version would not necessarily have to follow the mainstream desktop version, but could have its own life.

I you want to get started on this, I welcome it. :-)

My current plans for Robocode is to finally get started with Robocode 2. I have already done lots of research for it and made small prototypes for minor parts of it like e.g. a new communication protocol (IPC).

I want to make use STDIN and STDOUT for sending commands from robots to the game (when running Robocode on the same machine/device), and the game will send game status and events to each robot.

Each robot will run in its own process, and could be written in any language. However, it will be up to the end-user to decide if a "native" C/C++, Python or robot written in any other language is allowed to run on his/her system.

Robots written in sand-boxed languages e.g. for the JVM and .NET would of course be allowed per default, but only if they don't contain dangerous code? They must follow some security restrictions of course.

The game could be written in any language, the same way as the robots. So the crucial part for Robocode 2 would be the new protocol for the communication using STDIN and STDOUT.

Robocode written for desktop PC's could be written in Java SE like the original Robocode in order to support as many platforms as possible, and could be written in Objective C for iOS, and Java using the Android SDK for Android.

In the next week (from Tuesday to Saturday) I will be on a trip to Ireland for the GamesPro including Robocode Ireland 2013 (http://www.gamesfleadh.ie/compete/robocode/) together with Mathew Nelson, the original author of Robocode.

Here I will discuss the ideas for a new version of Robocode 2 written from scratch. I expect to get started on this from April. I certainly don't expect Robocode 2 to by written finished within a couple of weeks or months. It will require much more time to do.

But I expect it to be fun while doing it too.

Perhaps we could cooperate, so that you could focus on Robocode (2) for Android, and I could focus on the desktop version. That is, developing these in the same time? This would require that the design and rules are settled first as first priority for the core game.

Next the core (serving the game) must be made to handle the game and communication to and from robots using the new communication protocol. Then a basic GUI (view) could be provided for viewing and controlling the game. Sounds easy? It is not. ;-)

I expect lots of prototypes and adjustments made to the game while it is being developed to balance weapon powers, behaviors etc.

Perhaps it is easier to finish a simple prototype for desktop PC's first written in Java, adjust it, and then port this to Android and continue improving both version?

Just my thought, which you asked for. ;-)

Best regards,

- Flemming N. Larsen

2013/3/7 Jeffrey Creswell <cres...@gmail.com>

--
 
---
You received this message because you are subscribed to the Google Groups "robocode-developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to robocode-develo...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jeffrey Creswell]

Hi Flemming,
<thinkingaloud>
So in sum you're interested in making the robocode 2.0 environment an abstraction layer which manages bots implemented in arbitrary languages via messages from STDIN and to STDOUT, which would mean that only the environment would necessarily need to be ported between supported platforms and the bots themselves would run as disparate processes as long as they were implemented in a language supported by a given target platform... that could work, but might be tricky, and the communication via STDIN/STDOUT messaging would definitely be comparatively slow.  Also, making each bot its own process might be a problem on iOS, given the Apple approval process for apps. 

I think a single environment, implemented in C/C++ using cross-platform UI frameworks such as Qt, with software sockets open for plugins, each of which would run on its own thread, might be better.  Every bot would be a plugin with metadata informing the environment what other plugins (such as a python interpreter, for instance) are necessary to run it.  That should reduce the environment to a single unified codebase, with plugins accepted from and supported by the community, much like the Boost libs.  Bots themselves could be implemented in almost any programming language, so long as a suitable plugin for interpreting/just-in-time compiling the bot's source/intermediate code was available for a given platform.  There are already plenty of Lua, Ruby, Groovy, Javascript, Python, etc. interpreters available in C/C++ which could be wrapped as plugins for the robocode 2.0 environment.  Java and .NET  intermediate code interpretation or JIT would be the real challenge; on Android it would be easy enough to create a plugin that performed this functionality (see https://play.google.com/store/apps/details?id=com.aide.ui&hl=en) for Java bytecode and monotouch for .NET could probably be leveraged similarly.  This architecture should be fine for Win32, *n?x, and OSX desktop platforms as well.  iOS would possibly be a problem though, as they are still resisting Java related apps as far as I can see.  Interpreted languages for bots would work on iOS as Apple has eased their restrictions on interpreted code somewhat.  By far the easiest approach from an architecture standpoint and the most desirable for performance would be to provide a source code translator which would take in Java, Python, Lua etc. source and export the functionally equivalent C/C++.  Bot developers could then hand-optimize the C/C++ and submit the resulting native code as a plugin for the environment on any platform, and everything would run smoothly and with great performance.  Unfortunately, I have yet to find an existing source translator from arbitrary languages to C/C++... C/C++ are rather exact and unforgiving with their syntax.
</thinkingaloud>

<actualproposal>
A fair compromise for the time being might be to implement the single cross platform C/C++ environment described above and require developers to program plugins (including bots) using a standard robocode C/C++ API.  Each plugin would have its own thread, but since everything would be in native code we could use machine-level IPC rather than relying on service calls to STDIN/STDOUT.  C/C++ plugins that support interpretation etc. of other source languages for bots could be added later, with their own mechanisms for communicating the IPC messages they receive from the environment to their bots and vice versa.   This would yield a nicely segmented architecture with everything guaranteed to run on any supported platform, and with appropriate division of maintenance support for plugins between robocode developers and the developer-user community.
</actualproposal>

What do you think of this proposal?  If cross-platform support is a major goal, I really think a focus on C/C++ implementation would be prudent.

thanks,
CCJ

[Patrick Cupka]

In general, I'm not too hot on the idea of having Robocode or similar
programming games on mobile devices. It just seems like a bad fit. As
a bot author, it would be neat to have _something_ there on my
phone... I love Robocode and I love my phones/tablets. But coding on a
mobile device is cumbersome at best, the battery life is not there for
long-running processes using max CPU, and it just seems like a bad
experience overall. At most, some interface to view battle replays
from a repository (eg, from the RoboRumble, or others submitted by
users) is something I think would be cool. If the allure is tinkering
on a cool/small device, I say target the Raspberry Pi instead - it
would be a great boon if there were good / modern programming games on
the Rpi.

As for STDIN/STDOUT, it's true it will be a lot slower than one
process or other IPC models, but in practice it may not matter much.
Sophisticated Robocode bots are already taking a few milliseconds per
turn, which STDIN/STDOUT may be able to keep up with (I actually am
not sure how quite slow it is). A different game design might have
even longer turns. Simpler bots that run much faster might be greatly
slowed down by it, but the people writing such bots probably won't
care/notice this as much - they are probably watching battles, not
running batch battles at max speed, so run-time speed is limited by
frame rate for them anyway.

Sorta off-topic / shameless plug, but what I'm doing with BerryBots
(http://berrybots.com) is not too different from what you describe.
The app is C/C++, it's cross-platform (Mac/Linux/Windows) with the
help of wxWidgets and SFML, and bots/stages are coded in Lua, each
running in a separate Lua state. Version 1.1 with the cross-platform
GUI is coming in the next couple days. On Raspberry Pi, which was the
initial target platform, it runs individual battles from command line
and draws full screen.

(It's not abstracted to have plug-ins supporting different languages,
but I'm personally not convinced I want language independence in a
programming game anyway - there are lots of trade-offs, so I think it
depends on the game design.)

> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "robocode-developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to robocode-develo...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
Patrick Cupka, pcu...@gmail.com
--

[Jeffrey Creswell]

Hmm, interesting points.  BerryBots looks awesome by the way, congratulations!  A similar implementation for robocode cross-platform might be best, though I'd ideally like to see a C/C++ environment with a minor plugin architecture, and bots coded in either C/C++ acting as their own plugin objects or bots programmed in a scripting language (probably python, though Lua would work fine too) wrapped by a C/C++ plugin that supports interpreting their code. 

Your point about a programming environment on mobile devices being awkward is definitely worth keeping in mind, but personally I don't mind having to tap in code if it means I can bring my development projects with me anywhere!  For those who do mind this, my declarative programming suggestion might be a happy compromise in the form of a visual programming language (blocks and icons, much easier to manipulate on a touchscreen), and the interpretation of this VPL could also live as a plugin similar to that which might interpret python/lua scripted bots :)

--
Patrick Cupka
--

[Patrick Cupka]

I haven't checked this one out yet, but this iOS game Hakitzu looks like an interesting take on a programming game designed for mobile.

http://www.kuatostudios.com/games/hakitzu/

-- Patrick

Sent from my iPhone

[Xeo Show]

Hi,

I am new to robocode, and also would like to get it work on mobile platforms. Why not consider using libgdx (http://libgdx.badlogicgames.com/), a java framework which can make cross-platform mobile games?

By this way, you only need to replace the render part with what libgdx provided.

在 2013年3月7日星期四UTC+8下午3时43分39秒，Jeffrey Creswell写道：