Damn…i thought that nobody would notice this little flaw… ;D I’ve discovered this myself yesterday. Thanks for making it clear that others will notice it too… 
What are actually the Java requirements for this game? Is Java 1.4/5/6 enough or does it also require the extra Java3D packages that can be downloaded? I had a look at Java3D myself - think it is a disadvantage that people have to download separate libraries. So if you have gotten around it that is great! 
Java5 is enough…plus an OpenGL compatible graphics card and an architecture/OS that LWJGL supports (i.e. Windows, Mac, Linux and (in the near future) Solaris).
Ok, i did three things to narrow down the DisplayMode-problems that some have:
- I’ve updated the LWJGL2.0 version to rc2+ with two fixed DLLs for the Windows-version
- I’ve uploaded an additional version based on LWJGL 1.1.4 here: http://jpct.de/robombs114/robombs114.jnlp
- I’ve added an additional fallback DisplayMode that has no requirements at all
One note about the 1.1.4 version: For me, this version creates distorted sound output under OpenAL when using Linux. If this version works DisplayMode-wise on the systems that have failed before, i can easily fix this by reverting to JavaSound instead.
Could you please try the updated version and/or the version based on LWJGL 1.1.4 to see if that helps? I’m just displaying the modes that LWJGL returns to me… ???
BTW: I would love to see it running at that resolution… ;D
It works fine now with 1.1.4. ;D
Great! Thanks for testing. I assume that the updated 2.0rc2-version still doesn’t work?
The both versions work fine here under Mandriva Linux 2007. I have emptied my cache to be sure of it. It was a pleasure to help you for your test as you did for me Your game is fine. I like the blood on the screen ;D
Anybody with a Solaris x86 out there to test it? I’m not sure if i got the webstart section for it correct.
My girl friend did that blood texture for me with Photoshop. I simply don’t understand Photoshop… I guess it’s the only part of the game that isn’t “kids compatible”…i was thinking about changing its colour to green or blue or something…but if people like it, i may leave it like it is.
Well bomberman didn’t have giant rooms either - everything was a corridor. It’s just relatively impossible to blow someone up in a big room unless you have bomb kicking.
Also I discovered a bug - I had like 20 bots in and two of them somehow got stuck in the wall.
Worked great for me, windows vista with java 6 update 10. The game’s very good - I’ve never played bomberman but I quickly picked up how to play without reading anything. I see that it’s all about trapping the poor martian in a corner with a bomb :’(
The view and graphics are very good. I reckon you could do more tricky things with the camera though, like zooming in to the player’s current position from really high up when the level starts, so the player gets a feel for where everyone/thing is. By the way, what did you do the menus with?
20 bots is quite a lot of them. If all regular spawn points in a level are occupied, the bots spawn at random positions. Due to some latency, it may happen that they spawn very close to each other. Then inaccuracies in the collision detection may add up and finally, someone ends up in a wall. I think i’ll simply live with that…
By blitting a backdrop and rendering text into that. It’s done with a very small GUI-“framework” that i’ve written in two hours or so. Nothing special at all.
Ah bomberman, one of my favorites!
Unfortunatly I couldn’t join a server, so I played singleplayer. I love the waterpistol idea! The game feels very solid and plays very fluid except for some minor hickups that occur once every while (could it be the GC? I tried both lwjgl versions)… One thing I noticed myself bumping into walls often because of the perspective and 360 degrees of freedom… maybe you could have the player slide along the wall as long as he presses forward?
Test systemspecs:
OS: XP
JRE: 1.6.0_10-beta
CPU: 2.2Ghz dualcore
GPU: Geforce 8600GT
Try to make a projection against the obstacles with the explosion in the center of the current cell. This way you still have the bomberman style gameplay and nice projected explosion volumes. You could then fill the volume with particles. This might look very effectful then:)
Wow, this is very nicely implemented. Worked without a problem ;D
The server browser doesn’t access the internet, it’s LAN only. If you want to connect to someone’s server on the internet, you have to enter the IP by hand. But i’ve never tested this. The netcode contains some optimizations for internet play, but i’ve never really tried how good or bad that will work. It wasn’t my main focus, i’ve written it all with LAN play in mind.
Could be the shadow mapping as well. I’ve noticed that kind of hick-ups on some lower end NVidia based cards when setting the shadows to high. A 8600 defaults to 4xAA and shadows high (maybe that’s bit too much for it…). Maybe lowering the shadows in the options-dialog in the startup-window by one notch helps…on a 7600, it did.
I notice very brief slowdowns whereas I use ATI cards with no shadow map. I don’t think it comes from the garbage collector except if your engine produces lots of garbage. I don’t notice this kind of slowdown on the demos of JPCT.
The engine is pretty clean, but the game itself creates some garbage or course. Even when running in single player mode, it’s a client/server-based architecture, i.e. data is constantly wrapped into transport containers, sent over the net and unwrapped again. That creates some garbage, but it shouldn’t be that much. There are some critical paths left that i can optimize a little to reduce the amount of short lived objects easily. I’ll do that for the next release. Anyway, it’s more likely that the small hickups come from the network synchronization than from the gc.