I'm working on the Gorilla game every now and then. Take a look
http://www.informatik.hu-berlin.de/~wissenba/jGS/jGS_0.5.zip
YEAHH! I was wondering what happened with this! I'm very pleased to see it back, although my aim is not very good. I tend to throw myself off the platform rather than knocking an opponent around. 
I like games which are based on physics.
In Multiplayer jGorillaSumo- could be very enjoing i think.
Some suggestions:
Limit the maximum speed/acceleration of the player. It is not very motivating if you press a movekey a millisecond to long and JUMP out of the playfield.
I would set the camera static or move it only on a circle at a constant y-level around the playfield. The moving camera makes the game harder than it would be in topdown-perspective and that should not be the core of a camerasystem, in my opinion.
The numbers which display the score should be much bigger and perhaps in the same font as your menu buttons.
Nice game
Iam looking forward to the next version.
Well, I'll think about the camera, top down seems a little boring to look at, maybe I'll make a key to switch perspective…
I think the high acceleration contributes to the gameplay, but I might try to set a max speed and see how it feels.
Then, the game actually IS multiplayer, try the WASD keys 
I like the game as well.
Stopping the camera from moving vertically doesn't make much sense – since you only move horizontally, the vertical camera movement doesn't screw up the controller/character mapping.
In LWJGL's latest iteration you can access controllers such as gamepads and joysticks, so support for that is something to consider
Well, the vertical movement plus the spinning cause a certain perspective, and I agree that this makes control more difficult, especially when the cam is very low above the floor. I implemented a switch.
Then, I will consider support for gamepads, since I heard that they are still looking for games for the PS3
Fixed cam, max speed.
Play a game against the King Kong of Artificial Intelligence:
http://www.informatik.hu-berlin.de/~wissenba/jGS/jGS_0.6.zip
Hehe, excellent stuff!
IMO:
- Make the bananas physical representation boxes instead of spheres.
- Need different skins for the gorillas as it's sometimes hard to distinguish yourself.
- I think the camera is too static. It doesn't have to rotate constantly, but what about making it do something, e.g. zoom in when the two gorrillas collide? Take inspiration from common fighting games.
Scott said:
25-Oct-2005 12:45:52 PM com.jme.system.lwjgl.LWJGLDisplaySystem initDisplay
SEVERE: Cannot create window
No idea, maybe a problem with your OpenGL?
I also see that the program doesn't exit cleanly ://
I had people reporting their computer crashed completely on program termination... and I thought java was save :)
Java is usually pretty safe…it's when you add JNI to the mix that safety is tossed out the window. :-p
darkfrog
Well, no big choice here
I read somewhere, that there are considerations to rewrite the jmephysics in pure java :-o ??
Probably only rumors…
I read somewhere, that there are considerations to rewrite the jmephysics in pure java
You are probably thinking of odejava, not jmephysics... jmephysics is already pure java. ;)
I would assume it would be only rumors that ODEJava ever be completely written in Java since the project's charter is to wrap the ODE engine which is written in C/C++.
Further, I keep getting beaten up when I suggest such a thing as a physics engine entirely in Java as it would have speed issues. Mojo, would you agree with that evaluation?
Finally, even if ODE was written completely in Java the JNI error you're seeing above is caused by LWJGL which (to my knowledge) has no possibility of ever being written in straight Java.
darkfrog
If implemented correctly, of course you can do a physics simulator in Java.
However, I don't see what's wrong with using a native lib like ODE. Writing a decent physics project takes a lot of work, and ODE seems to do the job. Also, in the future we might have hardware accelerated physics, and to take advantage of that you'll have to use a project that uses native libraries anyway. (maybe ODE will start to support such hardware)
Ok, I didn't request odephysics rewritten in java so I can write messy code
I'll fix this… I have some free time now and I intended to spend some of it with jme and my game… but…
…there is a brand new copy of CIVILIZATION 4 on my computer now… It even starts with the original sound theme from the first part… :-o
So, jme needs to wait, sorry guys…
mojomonk said:
I read somewhere, that there are considerations to rewrite the jmephysics in pure java
You are probably thinking of odejava, not jmephysics... jmephysics is already pure java. ;)
I thought jmephysics was a binding to ODE. Or am I wrong ?
Yes it is, but it mostly uses an (modified) existing binding to ODE. So jME physics itself could be considered all Java.
Meanwhile, there's two things going on now; Irrisor started working on a new jME physics from scratch, and https://joode.dev.java.net/ is a rewrite of ODE itself in java.
Anyway, as long as your using bindings to native libraries youll never get rid of strange VM crashes.
So a pure Java physics engine is really the next logical step. Plus you'd have the entire Java community
being able to contribute, instead of only the geekish C programmers
Baune said:
Anyway, as long as your using bindings to native libraries youll never get rid of strange VM crashes.
So a pure Java physics engine is really the next logical step. Plus you'd have the entire Java community
being able to contribute, instead of only the geekish C programmers :)
Well, those strange VM crashes have to do with a poorly written binding or the way the native code handles certain information being passed, not because JNI itself is bad.
darkfrog
Well, jME already uses a lot of native calls. A lot of Sun's stuff does too.
But I guess the good news for you is that Irrisors new physics lib will, like jME, give you the ability to choose whatever physics lib you want to use… so maybe you'll do a JOODE implementation one day