Would jMonkey be good for this kind of project?

Does anyone here have any opinions on LWJGL or the jMonkeyEngine? Particularly, I personally am wanting to create what might be loosely (and maybe misleadingly) described as a “City Simulator” – though it will be bit different than “traditional” Simcity-clones and I prefer to call it a “community simulator.” I do want players to be able to look at there towns in disembodied 3D swiveling camera mode (normal for play) but also enter a first person mode to walk through them like a resident.

I have started the simulation engine (does nothing yet, but starting to flesh out some classes), but have no clue on the rendering engine (I’m a total noob with graphics and game programming). I don’t want use any external libraries (other than standard Java libraries) for simulation engine, and want to be strongly encapsulated the simulation from the rendering engine. I was planning on teaching my self graphics and rendering and LWJGL, but am tempted to pick up jMonkey as a way to make life easier – but I don’t want jMonkey oriented design to take over my project and many thing (e.g., physics) are not needed (or would simply help with eye-candy). Anyone have any advice on this?

Any thoughts on this?

I think you should use jME instead of plain LWJGL. jME will give you tons of stuff you probably would have to build yourself eventually. It is a sound idea to keep the simulatin logic separate from the rendering, however I do think you should do a little digging into the engine in order to understand how it works. Otherwise you might end up with a simulation design that is cumbersome to integrate with jME. Good luck with your project!

Just recently got reminded about a Ludum Dare contest I took part in. It has conceptually the same type of code design. Like kwando says, keep the logic separate from the rendering is nice.
And yes, jME is very suited to do the graphics for your project :slight_smile:

http://hub.jmonkeyengine.org/forum/topic/scene-graph-approach-to-game/#post-240478

1 Like

Take a look at http://www.tygron.nl/

They use jME3 in a professional environment to do some similar things to what you are talking about.

1 Like

Thanks everyone. I think I’ll keep working on the logic in NetBeans, and at the same time study and experiment on the 3D with throwaway toy projects. Hopefully once I have the simulation ready for testing I’ll be able to start on the rendering (possibly fork it, move code into JM3-JDK perhaps, and leave the orginal in NetBeans incase I want to make a server from it). Proof of concept (probably with a throw-away 2D display) will be a few months off, so that gives me some time before making the real UI is an imediate concern. Thanks again everyone.

<cite>@JaredBGreat said:</cite> Thanks everyone. I think I'll keep working on the logic in NetBeans, and at the same time study and experiment on the 3D with throwaway toy projects. Hopefully once I have the simulation ready for testing I'll be able to start on the rendering (possibly fork it, move code into JM3-JDK perhaps, and leave the orginal in NetBeans incase I want to make a server from it). Proof of concept (probably with a throw-away 2D display) will be a few months off, so that gives me some time before making the real UI is an imediate concern. Thanks again everyone.

Though, I do agree game logic should be separate from the render portion of JME, consider that physics can play a fairly large part of any simulator. I’d suggest jumping in right away and use a “headless” application to bypass rendering. This will give you access to bullet physics and many other useful feature of JME that may play a heavy role in how you decide to structure you code.

Physics could run inside a GUI application just as well.
Headless is for games where you separate GUI and actual game logic into separate Java process and connect the two via sockets (via internet or on the same machine). Worth it if you plan to do a client-server game, going to soak up effort if it’s all running locally. (Consider that locally-run games may evolve into client-server later.)

@JaredBGreat Your use case does not affect the LWJGL vs. JME decision it seems.
The JME <i>engine</i> (run-time library) gives you a great deal of scenegraph and OpenGL state management. Also, the engine tends to use whatever background engine works best - currently that would be LWJGL vs. JOGL (and the transition won’t affect application code, which is great).
The JME <i>SDK</i> is a Netbeans-based IDE. It offers plugins for various tasks, mostly stuff associated with importing and editing assets (3D models and such). The usual trade-offs when switching to a different IDE apply; the SDK is definitely worth checking out, but if you find it not worth the trouble, return to your traditional IDE. (I returned to Eclipse - the vast majority of what I do is Java coding.)

Currently, JME is internally using LWJGL but about to transition to JOGL.

Headless sounds like it could be very useful. I want to write the engine, test it in a 2D swing interface with 1979 graphics, then attach it too a real 3D for single player and ultimately make a multiplayer sever version. Its a social engineering sandbox game (because Tilted Mill had a great idea but failed in delivery, Simcity’s classic logistics/econmics game has apparently reached a dead end, and the mainstream game industry seems at a lose about what to do about it.) Limitted physics in the UI might be useful as eye-candy (look, the demolished building fell down in a believable way!) but probably not in the main engine (which is based mostly on psychology, as interesting as physics is to me as science on it own).

I have a rough road map:

  1. Do the central, rudamentry parts of the simulation engine to the point of being potentially runnable.
  2. Test in in 2D (PROOF OF CONCEPT; comparable to Notch’s cave game, and probably months away)
  3. Build the simulation engine into a 3D game (ALPHA; JME comes in here)
  4. Improve simulation and interface, start working on networking and multiplayer server
    5, Either implement or give up on the sever (BETA)
  5. Squash bugs and tweak game (simulation, UI, files, and network)
  6. When bugs are minimal and I’m satified with play, FULL RELEASE.
  7. ??? Continue with update? Call it done except for occational bug fixes? I’ll see when and if I get there…?

In the mean time I may play around with JME, do some tutorials, etc., so I don’t have to learn it all when the time come to really use it.

Thanks again for all the comments and advice. I’ll be back when and if I have something; as a total JME noob I’m not ready to comment much on other people’s stuff.

Expect lots of rewriting for Swing->3D and for 3D->client/server.
Other than that, it’s not the worst plan I have seen considered.