Tygron Serious Gaming proudly announces that we have chosen JME3

User Code & Projects
1

Tygron Serious Gaming proudly announces that we have chosen JME3



Tygron Serious Gaming, has developed serious games for a long time using the JME-engine making the switch from JME1 to JME2 back in the early days. After long consideration we decided it was time for the next level and compared a lot of different engines. Today we made the final decision and unanimously chose for the JME3 platform. Next week we start developing!



We would like to thank the JMonkey community for the hard work and look forward to a bright future for JME3!



Below some screenshot of our old JME2 games:















Thanks,

The Tygron Development Team

www.tygron.com

10 Likes
2

Thanks! That sounds good, happy that you are pleased with the engine :wink:

May I ask if you plan to use the full SDK or only the jME3 libraries for development? What jMP needs most is constructive feedback from users with actual projects and some general experience in managing them.

Cheers,

Normen

3

Best of luck!

Glad to see other devs going for jme.

1 Like
4

Heya!



I’m also in the Tygron development Team.


normen said:
May I ask if you plan to use the full SDK or only the jME3 libraries for development? What jMP needs most is constructive feedback from users with actual projects and some general experience in managing them.


We're gonna use the full SDK, and we're gonna try to incorporate jMP in the pipeline as well! What's the best place for feedback on the jMP?
2 Likes
5

Hey thanks.

maxxer said:
we decided it was time for the next level and compared a lot of different engines.

I'd be interested to know which were the other engines, and what were our pros and cons compared to them!
6
jjvd said:
We're gonna use the full SDK, and we're gonna try to incorporate jMP in the pipeline as well! What's the best place for feedback on the jMP?

The jMonkeyPlatform forum is the best place for feedback, troubleshooting and idea input. Looking forward to hear from you guys.
7
nehon said:
Hey thanks.

I'd be interested to know which were the other engines, and what were our pros and cons compared to them!


Our current games are based on a server-client network where the visualization on the client-side is done with JME2. However we are reaching the limits of the JME2 possibilities. For example our "city building" games have to zoom out and show a lot of housing models at the same time, so good LOD systems and things like hardware instancing, geometry batching etc. are very important to us. Besides the visualization our games contain a lot of game logic and networking code all developed in Java. So having Java compatibility is nice. Also having a stable/large community (or company) and a good GUI system are important aspects.

We then started to compare 6 engines (JME3, Ogre4j, Ardor, Unity, Torque, Cannibal) with JME2 based on the points above and a large feature set (+/-50 points) defined by our development team. Each engine had very different pros/cons, for example some have poor Java connection but a good support and a lots of tools. Without going into all the details we ended up with JME3, although it misses some points (e.g. hardware instancing and a good nifty-editor) at the moment (alpha 4), we think the final version will be very good! We are also pleased to see a large active community around JME3 and, starting with the post above, we want to participate ourself more actively.

As a final remark I would also like to say that, although we are a small (fast growing) company of 10 people, we think that JME3 can become a serious competitor for commercial game development and we like to help!

Cheers,
Maxim
3 Likes
8

thanks for this input.

As for hardware instancing, the base is there, we just need some more work to make it usable through the scene graph, I believe this feature, will be in before official release.

9
nehon said:
thanks for this input.
As for hardware instancing, the base is there, we just need some more work to make it usable through the scene graph, I believe this feature, will be in before official release.

Hardware instancing will most likely require shader injectors :)
10

Hi guys, welcome to the community.



Wow, you stirred up quite the shindig in here! I gotta ask, how come we haven’t heard of you before? I mean, you clearly have a lot of work well worth showing off, and these things always help to motivate the developers and community as a whole. Anyhow, looking great.



It might be a bold request, but hat 6-engine-comparison of yours is something I’d love to see. I reckon we could learn a lot from it. That aside, we’re always gonna be interested in learning more about your requirements for the engine, e.g. what you currently can’t do without, what you’re going to rely on in the future, what you’re planning to develop yourself and what you’re relying on the jME developers for.



We are certain jME3 will become a serious competitor for commercial game development, and we greatly appreciate all the help we can get!

11

Hello Erlend,



Back in the early days of JME1 we posted more on the forum, but didn’t have much to show for. But yes you are absolutely right I think we should become more involved. We made our choice for JME3 and have a large engine development project for the next 1,5 years, so we aim to increase our involvement.



I think we can help in several ways; defining requirements (hardware instancing would be our #1 at the moment ;)), user feedback, maybe some showcases and if you ever need a donation for a new website or server hardware let us know.



As for the 6-engine-comparison I am happy to email the details, but I am a little reluctant to put them on a public forum.



Cheers,

Maxim



P.S. Below two more pictures of one our latest (JME2) serious games. It was developed for a dutch trade mission in Vietnam and was played by several high officials (including our Dutch Prince of Orange). Also noteworthy is that it was developed as a “touch screen” game on a 50 inch screen.







1 Like
12

Thanks a lot for that @maximusgrey . Please send the comparison to e.soghe at gmail.com. I will only share it with the other core members.

13

I’d like to chime in and thank the jME community for the help it has given us over the course of the last few years. We’re all itching to get to work with jME3 and excited to lift our games to new levels.

1 Like
14

cant wait to see what you guys make, awesome!, good luck

15

We are not finished yet, but we did want to give you an update of our progress with JME3!



The team has been working very hard these last two months and as a result we can almost play our original games again. Mostly textual updates and performance profiling remain.



Below some screenshots, but first some (interesting) design choices we have made:

  • Nifty: We have been woking close with Lessvoid on how to translate all GUI panels in our games (+/- 50). Having a lot of panels makes the game slower, so we decided to remove the update from NiftyJmeDisplay and run the update in a separate thread. Also the input manager is running separate. This resulted in a significant FPS boost and only some minor concurrency issues. Overall JME3 seems to be better prepared for multithreading (e.a. the SafeArrayList) then JME2, which is great!
  • Selection and overlays was always tricky in the old game, thus we created a new overlay system using shaders. This makes it possible to overlay the entire scene with a texture. For example and overlay showing quality of the neighborhood. (see picture 2). Or using a generated texture to do a selection.
  • Our city games contain about 15.000 seperate geometries of houses, buildings, trees, etc. Using a viewport as a reference we attach and detach geometries as the camera moves around the map always maximizing the amount of geometries to a fixed number. So in area with less houses the fog starts later then compared to busy areas. The added models are also batched together in small amounts to allow proper culling. Although this works great on new machines (74 FPS) on older machines the FPS is still very low, probably due older video cards.



    And of course we have been using all cool new JME3 shaders; SSAO, PostWater, PSSMShadows, FXAA, light scatter! :wink:



    Thanks,

    The Tygron Team



    http://www.tygron.nl/download/tygron_jme3_1.png



    http://www.tygron.nl/download/tygron_jme3_2.png



    http://www.tygron.nl/download/tygron_jme3_3.png



    http://www.tygron.nl/download/tygron_jme3_4.png
1 Like
16

God helpe ons allemaal, de Nederlanders zijn er.



[translation: welcome, Dutch]

17

That’s beautiful!

Nice to see what’s possible with JME3 :slight_smile:

18
maximusgrey said:
Overall JME3 seems to be better prepared for multithreading (e.a. the SafeArrayList) then JME2, which is great!


This one scares me just a little so I thought I would drill in more.

To be clear, SafeArrayList is not thread safe on its own. It was added to allow the list to be modified while it is also being iterated over which happens very often (for example: iterating over children and calling detach on some of them or having a control that itself modifies the scene graph in some way).

Are you doing some other synchronization/thread coordination on top of that or have you just been getting luck? :)
19

Hey its looking great! Glad you are posting more screens :slight_smile:

20
pspeed said:
Are you doing some other synchronization/thread coordination on top of that or have you just been getting luck? :)

Haha, no worries! Although we are new to JME3 we are not new to Java multithreading ;). Our games are heavily multithreaded to sync all server-client connections and heavy simulation models running in the background. On average 20 threads are running of which some as execute services that run (update) events. The events (for example "add a new building") fire to an extension of JME's AbstractControl called SynchronizedControl which makes sure that the new "building" node is attached at the correct moment in the render thread. So yes you are right that SafeArrayList is not thread safe but it makes life easier since I do not have to put the list in a new list when iterating and changing things.
I don't now exactly the Nifty/Jme connection works but updating and lay-outing nifty in a separate thread does not seem to create problems with the main update loop doing the rendering. So here JME3/Nifty seems to do a good job.(please correct me when I'm wrong).

@xenofobiq Jaja, we zijn er al 6 jaar ;)