Tank Battles

This is my game project. It’s a game for programmers, inspired in robocode.

from the project site (tankbattles.sourceforge.net):

(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

Thats a really interesting project. Reminds me of my previous job, simulating survivability and lethality of military vehicles in combat.

What inspired you to do this?

Some things that’ve inspired me for starting this project:

1- I really love robocode (robocode.sourceforge.net);

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.

Cool, I'll play with it.

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.

    Hope you enjoy playing it.

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

java.lang.UnsatisfiedLinkError: ODEJAVA_VERSION_get

        at org.odejava.ode.OdeJNI.ODEJAVA_VERSION_get(Native Method)

        at org.odejava.ode.OdeConstants.<clinit>(OdeConstants.java:12)

        at org.odejava.Odejava.getLibraryVersion(Odejava.java:125)

        at org.odejava.Odejava.<clinit>(Odejava.java:95)

        at com.jmex.physics.impl.ode.OdePhysicsSpace.<init>(OdePhysicsSpace.java:308)

        at com.jmex.physics.impl.ode.OdePhysicsSpace$OdeFactory.create(OdePhysicsSpace.java:197)

        at com.jmex.physics.PhysicsSpace.create(PhysicsSpace.java:325)

        at com.jmex.physics.util.SimplePhysicsGame.initSystem(SimplePhysicsGame.java:89)

        at com.jme.app.BaseGame.start(Unknown Source)

        at net.sf.tankbattles.Main.main(Main.java:57)

Jun 19, 2007 8:21:04 PM com.jme.app.BaseSimpleGame cleanup

INFO: Cleaning up resources.

Jun 19, 2007 8:21:04 PM com.jme.app.BaseGame start

INFO: Application ending.

If you’re running Linux on an AMD 64 PC there’s a special version of libodejava.so. I forgot to put it in the release. Corrected in a bug-fix release.

You can download it from the jmephysics project on cvs.dev.java.net or here: tankbattles.sourceforge.net/libodejava.so (get the new release), and replace at the lib folder on the project.

If you’re running Windows I’ll test everything again at home and post the correction tomorrow.

Thanks for trying it.

Starts OK, after replacing the : with ; in the windows start script. I can rotate the camera around a tank, and use the SimpleGame controls.

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.

It’s on its way to the mirror system right now.

perick said:

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.

perick said:

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?

Would be cool! :D
t's name should have a 64 appended

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.

oh, well then there's probably a problem in odejava-jni, please try with the new version I have just committed.

And I removed the superfluous file from cvs.

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.

Yep, I tried changing it without any luck.  :cry:

I have had numerous problems with having a 64 bits JVM on Linux and running Physics and Fmod sound. Oh, well… I will just keep trying.


  initialize() does overwrite the value of the java.library.path system property… just checked it

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

EDIT: BTW it looks cool!  :slight_smile:

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.

I'd like to know to fix this in the next release.

joode.txt reads:

This jME Physics 2 implementation uses JOODE revision 241.
Only change is in class Body: the field 'mass' was made non-final.

Aside from that, I do not know which version I am using. I just checked out from the CVS repository as per the "getting started" wiki guide.