GSoC concluded and lessons learned

Our first GSoC and jMESoC adventure has come to an end. All 3 GSoC projects were successfully completed, while jMESoC got 2/4 (the other 2 never really started). Some of the students will be moving on to other projects, while others, to our great delight, have become active members of the community.

See the forum discussion thread for links to the projects.

What we’ve learned

There’s bound to be some mistakes as an administrator or mentor of GSoC the first time around. Well aware of this, we went into our first GSoC knowing full well that all we might get out of it was some cool proofs of concept and maybe a new contributor or two, along with newfound experience. It’s safe to say that this GSoC 2014 has delivered on all accounts, and then some.

Now about that newfound experience…

Students need more structure

We’re very used to working independently, and thrive as such. Students, while definitely very capable, benefit from more structure when being catapulted into a large beast like jMonkeyEngine. Mentoring sessions and weekly status reports should have been more rigorously scheduled.

The GSoC admin should be every bit as involved as the mentors

I never intended to be a as uninvolved as I was. Had I been more in the loop – doing frequent check-ins with both the mentors as well as the students – I believe we could have avoided several hiccups caused by miscommunications and lack of structure. Also some early exposure to seagull management is good for your skin.

Make sure jME plays an integral part

Some of these projects were so loosely attached to jME that a lot of the mentoring didn’t require expertise in jME at all, only Java or programming in general. Mentoring is both more fun and efficient when the project closely ties in with jME concepts at every turn.

Standardised development environments

Too much time was spent “on the clock” simply getting set up and getting to grips with key concepts like Git and SDK development. We should have formalised a proper Getting Started guide shortly after our GSoC participation was confirmed.

Grow from within and don’t start from scratch

This time around we accepted applicants based on application merit above all else. We don’t regret this decision, as we clearly picked 3 very capable students. However, by not factoring in previous experience and interest in jMonkeyEngine we made things more difficult for our students. All of the hiccups we did run into would have been greatly mitigated in the case of an existing contributor, especially when tasked with adding to a project that’s already active.

Will we apply for GSoC again next year?

Frankly, we don’t know yet. Make no mistake, GSoC is a big time investment, and if you’re out to get “free improvements” for your project, you’re probably barking up the wrong tree. To me, the single biggest win any project can come away with from GSoC is more committed contributors, so we recommend trying to grow from within.


GSoC is an excellent opportunity to recognise existing members of your community; developers who were already kicking your tires for no incentive other than “because they felt like it”.

We already considered prior jME knowledge when selecting students this year. If we try for GSoC again and get accepted, we will probably take this one step further. Students who have already been an active part of our community prior to GSoC or who are willing to step up and contribute to the community during the application process will be prioritised.

The projects we choose will be tied more closely into jME itself and we will make sure from the start that the work students are doing is integrated into the project as a whole. Publishing progress needs to be something that happens continuously and ideally early versions should be in use by members of the community as soon as possible to provide prompt feedback and help ensure that the end result is as useful and as well integrated as possible.

A heartfelt thanks to all our hardworking (G)SoC students! May the open source spirit grow ever stronger in your caffeine-empowered hearts!


Blendswap Arcade – At long last, we have a final verdict!

4 odd months later, and the Blendswap Arcade is concluded. To give me a deserved beating for my absence, please refer to my apology. In the end, Rickard @rickard swooped in as the 2nd judge together with Nicholas @memonick, and we had ourselves a final verdict. Which is…

1st Place – Hostage


Judge 1:
An ideal contest submission – doesn’t do a lot, but it is is polished and, most importantly, enjoyable. Contains some interesting mechanics and props which really spice the game up.

Judge 2:
Simple and surprisingly addictive. Could have benefited from another fail state, too many misses, to make it more difficult. Suggestions: Drop the voice on hit miss, replace with a sound effect. Have the hostage/civilian switch places.

2nd Place – Exterminator


Judge 1:
Interesting game which could be extremely enjoyable on a smartphone or tablet. The game is rather challenging and frustrating, yet it could have used some more polishing when in the graphics.

Judge 2:
Simple concept, well executed. Well defined game states and boundaries. As frustrating as ‘whack-a-mole’ (in a good way).

3rd Place – Marbleway


Judge 1:
Fun, challenging and tedious, Marbleway makes perfect use of the theme and is solid all around. The only areas it lacked in are the camera movement and the physics, which sees undesired consequences, such as the marble getting caught beneath seats.

Judge 2:
Classic gameplay. Camera somewhat annoying. The game would benefit more from open levels (no walls in the way for camera).

All of the games made for the contest are freely available here:


The Blendswap Arcade contest definitely had its share of flaws in both planning and execution, which I take full responsibility for. But in concept, I think it works exceedingly well (yeah I know that’s also what they say about communism, but this is different, read on).

The games speak for themselves. There were some concerns that 10 games using the same asset could easily result in 10 near identical game experiences, but in retrospect this concern was unwarranted. Game design muscles were amply flexed that week. Indies, I applaud you.

If someone else from the community ever wants to do another contest, re-using this concept or doing something new, please get in touch; I’m not gonna be in the driver’s seat, but I can help.

If I’m not mistaken, Rickard is eager to do a contest of his own to celebrate the release of his kick-ass “jMonkeyEngine 3.0 Cookbook”. Keep an eye out!

Comment on this thread


jME3 Game Contest – “Blendswap Arcade”


Starting next week on the 19th of May (same day as the coding kick-off for the SoC students!), we will be hosting a one-week game development contest for the jMonkeyEngine community. It’s been too long since our last game contest, which produced some wonderful games. But we are going to be doing things a bit differently this time.


19. May – 25. May, i.e. 1 week

Why one week?

– Two reasons:

1) Practice your downscoping muscle! Do you often find yourself spending 2 weeks on something that was supposed to be done over the weekend? Well then you probably didn’t do enough 1-week game contests.

2) It is our hope that since we’re just asking for 1 week of commitment, more developers can justify taking 1 week off from their main project to test their skills in a fresh new undertaking.


Make a game for a given scene.

There will be no theme. Instead, before the contest starts we will have scoured through the Blendswap database of low-poly and realtime models and picked out a scene or modelpack that will be the basis for your game.

If for example we picked this racetrack scene, all gameplay would have to happen within the confines of this scene. You would however by no means be required to make a racing game; the type of gameplay is entirely up to you.

Why a single scene?

– Constraint is creativity’s best friend. Seriously.

But all the games will look the same!

– They might, but they will in all likelihood not play the same, and that is the key exercise here. You need to make your game stand out through gameplay alone.


  • You may use or even make other assets, but;
    • You may NOT extend the confines of the game level.
  • You may use any existing open source code, including your own.
  • The scene does not in any way dictate the gameplay.
  • The game must be completely open source and made freely available through a code repository like GitHub upon completion.
  • Game submission must be an executable, preferably fully functional on all PC platforms.

Judging Criteria

Game entries will be judged on:

  • Utilisation – Appropriate & innovative use of the scene.
  • Completion – Completeness of the game: Keep it simple!

Am I experienced enough for this contest?

If you’ve gone through the Beginner’s tutorial and are able to make anything that’s passable as a game using jME3, you should participate. It doesn’t matter if your code isn’t worthy of the Nobel prize; if your submission is fun to play, you might just end up as a finalist.


We’ve asked around for sponsors and we’ve put together quite a nice collection. While the 3rd and 2nd place will have to settle for bragging rights (might do this differently next time), the 1st prize winner will get:

  • 1 month Associate Membership on Blendswap (unlimited downloads).
  • 1 month Citizen Membership on CG Cookie – Full access to all premium tutorials.
  • $200 in credits on – Awesome professional models (we recommend static .OBJ models, as jME3 does not yet support FBX animations)
  • 6 months free Personal hosting on – An affordable and developer-friendly hosting service.

Interested? Dang diddely straight you are! Ask any questions you’d like in this thread.