Post Mortem: Star Search – a student-made space game
April 19, 2011 in Spotlight
The Concept
Click image for a video.
VSSEC provides space educational services to primary and high school students in Australia. La Trobe University offers game development courses. Each year VSSEC offers a project to complete a space-themed educational game project to La Trobe students. This year we were the lucky recipients.
We were given the task of taking one of VSSEC’s old desktop game/simulations aimed at year 11 students (around the age of ~17) and converting it to a web-based game aimed at year 5-6 students.
In a nutshell the game was to allow the player to navigate around a 100ly sphere of real stars in our galaxy collecting information about different stars, managing fuel and encountering hazards every so often. Our development team consisted of 5 programmers + 1 project lead and 10 weeks of development time.
The Development Process
The development process consisted of 4-5 weeks of pre-productions which included designing the UI, coming up with bits of gameplay and selecting a technology. Selecting a technology was a challenge because we were new to web-based 3d games and had a limited budget for tools ($0). We looked at a number of options for technology: Unity, Shiva and the likes (too expensive 5 programmers * $1000 = ouch). Silverlight was also an option; we would use pre-rendered videos for detailed shots of the stars and software rendering for the dynamic components.
A ship HUD.
We were going to go down this route until we saw some 3D Java applet games and we were blown away at how good they looked and how easy it was to run from a browser. This eventually led us to jME3. Some of the things that sold jME3 were shader support + post-screen effects (which sadly we had to remove to lower the minimum specs). We prototyped key challenges, rendering a sun up close, spaceships, and a star field, in jME3 and in Silverlight (Balder 3d engine which we thought was representative of a lot of the software rendering engines available) and found that jME3 looked better, had more features and could put more meshes on the screen.
As far as jME3 being in development, we looked at the main parts of the engine we were going to use: 3d graphics and NiftyGUI and came to the decision that the engine was stable enough for our needs. Worst case scenario – we could have a look at the source code and play around.
Journey Planning Screen.
After pre-production we presented our findings to the client who signed off on our ideas and we began full scale development. In retrospect we could have shortened pre-production because we generated a lot of ideas that never made it in to the final version. We used Mercurial for version control. The jMonkey Platform/Netbeans integration worked on and off so sometimes we had to resort to command prompt.
One of the great things about jMonkey which we can appreciate in retrospect was that we didn’t need any extra libraries or have to write any large amounts of game engine code. All the boring code 
was a given; the math libraries, asset manager (which saved headaches when we deployed to an applet ), importing models and multiple image formats, and baseline application code, saved a lot of time allowing us to start coding after a week of design in pre-prod. That being said, it would have been nice to have some best practices to organising a game on top of the jME3 as I am sure we made some design decisions that would make the dev team shudder. Early on we decided we wanted to have some 2D minigames to represent some of the challenges a space voyage may encounter. So it was nice to have 2D overlays built in.
2D minigames
There was a bit of a learning curve for Nifty which mainly involved forum crawling and trial and error. We would have loved to have more documentation and maybe a gui editor (or are we asking too much 
).
As far as learning jME3 there was a lot of tutorials, and resources on the website and plenty of forum posts. Most of the elusive bugs came from not being familiar with java game development, like accidently modifying the unit_x static member variable or odd things like the applet asset manager being case sensitive and the desktop version not. I guess one of the biggest “Oh dear” moments was that we didn’t realise that when an applet crashes it just switches back to the lwjgl loader. So we had to make sure if our game were to fail it would be nice and print out all the results the students collected.
Conclusion
Towards the end of the development VSSEC organised a group of students to play the game which was great to see the students enjoy the game, and test the stability of the game. It would have been great to have done at least one more of these sessions earlier on. At the final presentation deploying the applet was very easy and it was nice to be able to tell the client that they we could deploy the game to a desktop version as well.
Ship travelling at faster than light speed.
If we had to sum up jME3:
Pros
+Loved shaders
+Loved the tools (math lib, asset manager, app code, importing facilities)
+Loved 3d in a browser with easy deployment
Cons
+The lib was a bit big 5megs.
+Nifty was a challenge to get working right
+As much docs as you have, we would have loved sample architecture or best practices
The Star Search team, John, Jason, Tim, Yvan, Leon, and Ken, would like to say a special thanks to the jMonkey team and community. Keep up the good work
This was post was a “post mortem” project analysis
If you would like to make a similar guest-posting for your completed project, please send your inquiry to . We prefer projects based on jMonkeyEngine 3.
nehon said on April 20, 2011
“we made some design decisions that would make the dev team shudder.”
lol, that never happen!
Very nice work, and thank you for this feed back!
Is there a way we could test some demo?
rickard said on April 20, 2011
Nice job.
A couple of things i’m curious about:
Is the game meant to be educational in the sense that limitations and hazards are realistic (aside from having them abstracted into 2d)?
What was the reason for choosing 2d over 3d for the mini games?
Is it free form, or does the player have a set of goals/missions to fulfill?
Jason said on April 20, 2011
G’Day Mate, We have linked a video to the first image. But, for a demo we would have to have a chat with the Lead and VSSEC to see when the game goes live.
zathras said on April 20, 2011
teimthepirate said: “As much docs as you have, we would have loved sample architecture or best practices”
The dev team published an open-source demo game showcasing best practices in February, but I guess you were already working on your project at this point:
http://jmonkeyengine.org/2011/02/13/monkeyzone-a-jme3-game-from-the-core/
I started summing up the main points on the wiki, but I’m not very far yet.
http://jmonkeyengine.org/wiki/doku.php/jme3:advanced:monkey_zone
On the other hand I have to say, you did well, considering the number of docs you had, and the fact that jme3 is still in alpha!
And yeah, I agree that more Nifty docs are necessary, but I’m still figuring it out myself…
teimthepirate said on April 21, 2011
@nehron. As Jason mentioned we not really sure when the game will go live. Will try to update when we know.
@rickard. The minigames are just to break up the normal gameplay and add some uncertainty and excitement to the game. They are roughly based on things which could happen during space travel but aren’t realistic or educational. We chose 2D over 3D for the minigames because they each of the games are fairly simple, lasting only a minute at most. Also, our development schedule was quite tight and it’s much easier to create 2D art assets.
The education value of the game comes from gathering data about the stars and using that data in a classroom environment (specifically to plot the Hertzsprung-Russell diagram). From my understanding, the teacher will specify which stars each student is to travel to, otherwise the students can roam freely. We didn’t want the player to feel constrained, the teacher can be the bad guy.
@zathras. Awesome! We nearing the end of development in February so unfortunately it came too late for us, but it looks like a great reference to use in the future.