(updated 2007-06-11)
This project is an effort to build a 3D simulator for teaching robot
artificial inteligence. Tank Battles is
heavily influenced by IBM's Alphaworks Robocode, but differs from the
former in that it adds the complexity of a fully 3D scene with
realistic physics. Instead of relying on predictable, almost
deterministic, movement code, as found in robocode, one has to
implement tank behavior by using methods that depends on the physics
engine simulation to complete. This aproach makes Tank Battles
chalenges closer to real world robots coding.
The current status is pre-alpha. The project is under heavy development and we
2 - I’m insterested in investigating multithreaded game development for my soon to begin PhD program;
3 - I’m a teacher in a college. Teaching Java, OO, and researching game development.
If you’re interested, take a look at the project next week. I’ll probably post downloadable binaries for MacOSX, Win and Linux. The sources are already there on CVS, but changing very fast.
I’m proud to announce that I just made the first public release of Tank Battles.
tankbattles.sourceforge.net - go to the download page… Just made the upload so maybe one should wait a little while sourceforge distributes the release over the mirrors.
This a VERY EARLY release, pre-alpha stage, so there’s just the basic functionality.
What does work:
Scene graph created from the mission.xml configuration file where one can chose heigthmap for the terrain and set the tanks for the battle
Each tank has its own implementation, as in robocode, so one can extend net.sf.tankbattles.AbstractTankController and make its own tank.
The radar already works and it's possible to override the onRadarDetection(event) method and react properly.
For those who have played with robocode it's not that difficult to understand the basics. Remember, Tank Battles is a programmers game, so don't expect to control the tank by hand. The only control you have during simulation is changing which tank the camera will follow, with the TAB key.
While trying to run it, I get the error of no ODE implementation found… This is when trying to run it right "out of the box". I assume there is a version mismatch for AMD 64 (which is what I am using).
I’ve put a bugfix release (pre-alpha-R02) on tankbattles.sourceforge.net where I corrected the windows start.bat script and put the alternative libodejava.so for AMD 64 linux machines. There’re new instruction on the README.txt file for replacing this native library.
There're new instruction on the README.txt file for replacing this native library.
You shouldn't need any specific instructions for linux 64bit support. Odejava should use it automatically. Just put it in the native path without renaming it.
These are exactely the instructions on the file… I've put them there so people who are not seeing this forum thread can use it…
It has the same name as the other one, libodejava.so, so I've put it in another folder, just like jmephysics distribution, and instructed to replace the file which is on the library path, the lib folder.
Thanks a lot for the inputs, I think everything is OK with the pre-alpha release now. I'm refactoring some code to make it more understandable, especificaly at the Tank's Physics and Scene graph nodes. I'm planning a release with guns and everything for the next two weeks.
Anyway, jMEPhysics rocks Irrisor, I'm thinking if it's possible to implement a GPGPU binding to it. What do you say? After some time I'll post a thread on the jMEPhysics part of the forum.
It has the same name as the other one, libodejava.so, so I've put it in another folder, just like jmephysics distribution, and instructed to replace the file which is on the library path, the lib folder.
That's not what I meant. It should already reside in the same folder and it's name should have a 64 appended (before the extension, of course). So odejava can load it on demand without having the user to change anything (works only with odejava-jni / jME Physics 2).
I'm thinking if it's possible to implement a GPGPU binding to it. What do you say?
Humm, but that's already a libodejava64.so in the folder, is it the AMD 64 version? If it is what's the purpose of the different one I found on the jMEPHysics2 CVS?
If they are the same file (I checked and they seem to be) I don't know what was the problem with duenez machine.
hevee ran it in a windows box, I'm running it in my macbook. Don't have a Linux box at hand right now, but I'll try to test it later.
Maybe I am just too naive, but I looked at the Main class, and it sets the java library path to "native/linux" (on Linux), and that path does not even exist… Is this setting overwriting the -Djava.library.path command line option?
That code in the Main class is just a test. When you use the -Djava.library.path in the command line it overrides that one, at least it's working here. But you can change the value of those constants to "lib" for testing and see what happens. On the next release we'll be using that code properly.
Well… I managed to run it… I still don't know why it would not run out-of-the-box. All I know is that when I set the library path to my own copy of the ode implementation, (the one I use to run the jmephysics examples) it works, when I do that with the libraries provided in the release, it does not.
Duenez, what are the versions of the ode natives you're using? I'm deploying with the latest I got from Irrisor's CVS. The issue is that I don't have a Linux box at hand to test it right now. The other natives I tested.
