I am new to jME (used to use Java3D and JBullet or OpenGL in C).
My main question is whether to bother using MTGame (https://wonderland.dev.java.net/mtgame/MTGameProgGuide.pdf).
I intend to use JGN (and likely jME physics engine as JGN can synchronize with it).
I intend also to build a FPS game.
I guess when it comes down to it, is the MTGame multi-threading necessary for a game where you want the threads to synchronize to rendering? Though I am distressed by jME having a single thread and I agree with darkfrog’s tutorial on threading.
Anyone have any experience with MTGame (as a wrapper to jME etc…)? Or any thoughts?
Cool - glad to hear you got it going.
MT Game does allow for complete synchronization with the rendering thread. Any ProcessorComponent has the ability to run (or even not run) at different processing levels. It can be run off of the render thread - and therefore not in the direct path of frame rates. This is good for far away objects, which need to be updated - but not in full synchronization. Objects closer to the camera will be processed on the render thread for full fidelity. The key is that you can build ProcessorComponents that match the functionality of the entity - rather than focusing on the slice of time that you have in the render thread. Even the lowest end laptops have multiple processing cores, so careful threading is the way to go now.
I recently posted a blog at project Wonderland which gives a short description of MT Game's features.
We are committed to building all our tech and applications on MTGame.
We post quite a bit on the Wonderland forums as well as on our blog about the development.
When you say "I intend also to build a FPS game." would this be from some existing IP or a first time hobbyist effort?
In any case, take a look at our dev journal (link below), and we will be posting some web start-able demos in the next week.
Shawn Kendall CTO
Immediate Mode Interactive
www.imilabs.com
http://cosmic-game-engine.blogspot.com/
Yensid
Its funny, after reading the paper there was something not "clicking" about the processor/component model since I actually might enjoy the idea of subclassing (though I can understand the disdain when one has a miriad of objects), but the idea that you mentioned now makes a little more sense in regard to focusing on functions.
I am now to assume that closer objects implies this idea of closer is handled by mtgame?
I do agree that MTGame seems to have much better multi-threading (though my laptop sadly has only one core), and that intrigued me.
The main reason why I guess I was hesitant is that I am wondering if MTGame as a basis for Wonderland caused it to lose some features a game developer might desire, but it seems not. Yensid as someone who contributes to MTGame, I really do appreciate the input.
I still will likely use JGN and so I guess I will start looking at code for MTGame, JGN, jME.
ShawnKendall,
When I was looking into the blog Yensid mentioned, I did come across the Cosmic Game engine. I understand it is responsible for the avatar system wonderland has a lot of focus on including user interaction.
I would say this is a "hobbyist" effort in one way or another. I am designing the FPS for fun, but I intend to use it as a platform for some other code: human interaction, and A.I. I enjoy both, and hope to integrate head/body tracking as well as a "gun" like interface. For the hardware (ie: gun) I do have a lot of code surrounding a 6 degree of freedom device (ie: accelerometers, gyroscopes etc… that was developed as an input for a 3D pool game (Java3D & JBullet), but the code and device could be used for a UAV for instance), but I might just "drop" the code in favour for the Wii remote as more people can afford that ($50 vs $500). I also enjoy/know AI (ie: Pattern recognition: Neural Networks, Bayesian etc…), and though I have never built an AI for a FPS it might be fun to attempt. Long story short it is hobbyist, but its more primarily as a base for other code then an end in itself.
I hope that wasn't too long or boring. I will definitely try to keep an eye on cosmic game engine as well, and will need to start looking at some code soon. Thank you for bringing it to my attention.
msj121 said:
The main reason why I guess I was hesitant is that I am wondering if MTGame as a basis for Wonderland caused it to lose some features a game developer might desire, but it seems not. Yensid as someone who contributes to MTGame, I really do appreciate the input.
I still will likely use JGN and so I guess I will start looking at code for MTGame, JGN, jME.
While MT Game is the engine for WL, it was designed as a full performance game engine. There are things in there that WL may never use - but I wanted to make something that could be used without WL. It's still growing by leaps and bounds. Be sure to check out some of Shawn's demos when he shares them. They are closer to the game quality simulations that you want.
Doug.
Doug,
That is great to hear. I was hoping that was the case, and I was guessing it was, as it was called "mtgame" which implies it is for games, but I was not sure. Thank you for the clarification, I do appreciate it.
I have the code compiling and can't wait to start using it, though it might need to wait until Monday until I have free time.
I must say getting it to compile in eclipse was making me go crazy… I switched to Netbeans and compiled the wonderland version of JME and MTGame. But I have the jars running in a new project with the native files etc…, and I tested a few things and I am quite happy and impressed. But its 3:30 am here and I am happy I got it working "today" :).
I have a question has the org.jdesktop.mtgame.processor.FPSCameraProcessor been finished? I have been playing with it (very cool that its implemented out of the box), but the path following does not seem to work… I am using a Terrain from one of the Terrain examples and the FPS processor to no avail (I did set RenderCapture to null, but does that make a difference? I assume thats for screenshots?).
I did notice the test case (OrientationWorld) that seems to use the FPSCameraProcessor does not have a "terrain" added to it (just a sky box).
I am not quite sure if I am using the Terrain properly (ie: if its making its way to be able to be picked, but it should be).
Btw, where is the best forum for MTGame questions, here or java.net in the wonderland area?
Thanks. I will provide code, just curious if the processor is incomplete etc…
I finally figured it out… (for anyone curious) I needed to add the Terrain to the JMECollisionSystem to be able to Pick, I figured that if it was a rendered component this was enough to be able to pick in the collision system etc…
I started to look into the code more and realized that it used the collision system which needed the terrain to be a collision component…
I also created my own camera processor based off of FPS and Portal (quite similar in the way I used them), MTGame is certainly an interesting library, I can't wait to use it more!.