A collection of recommendations and expert tips. Feel free to add your own!
If you are a beginner, you should first read some articles about game development. We cannot cover all general tips here.
As a quick overview, answer yourself the following questions:
How you actually name or number these milestones is up to you. People use the words "milestone", Greek letters, version numbers, or combinations thereof.
Every milestone is made up of a development phase and a test phase. Here are some best practices:
You have a list of features that you want in game, but which one do you implement first? You will keep adding features to a project that grows more and more complex, how can you minimize the amount of rewriting required?
Acknowledge whether you want a feature because it is necessary for gameplay, or simply because "everyone else has it". Successful high-performance games are the ones where someone made smart decisions what to keep and what to drop.
Typically, developers extend a custom class off of jME3's com.jme3.app.SimpleApplication (or even com.jme3.app.Application). For a racing game you would create a different base game class than for a space game or a shooter.
my.company.MyBaseGame.java
.my.company.zombieshooter.MyGame.java
.As your jME3-based application grows more advanced, you may find yourself putting more and more tests in the simpleUpdate() loop, and passing around lots of object references. Don't implement game behaviour by copying and pasting boilerplate code! It is a best practice to move game behaviour into classes of their own. In jME3 these classes are Controls and AppStates.
Both classes automatically hook into the main update loop. Instead of remote controlling game entities via simpleUpdate(), you define the desired behaviour in the update methods of custom Controls and AppStates. You then add Controls to Spatials, and AppStates to the application, and jME3 will automatically trigger the update methods. This cleans up your simpleUpdate() loop code considerably.
Learn more about Custom Controls and Application States.
Put your assets into subfolders of your project's assets
directory. This is the default path where the assetManager looks for files.
jMonkeyProjects/Pong/assets/ # Store assets here jMonkeyProjects/Pong/build/ # jMP generates built classes here * jMonkeyProjects/Pong/build.xml # Customize Ant build script here jMonkeyProjects/Pong/nbproject/ # jMP stores default build.xml and meta data * jMonkeyProjects/Pong/dist/ # jMP generates executables here * jMonkeyProjects/Pong/src/ # Store Java sources here jMonkeyProjects/Pong/test/ # Store test classes here (optional) (*) managed by jMonkeyPlatform, don't edit
assets
in any way that suits the project – but stick with one system.Textures/vehicles/car/
, Materials/vehicles/car/
, Models/vehicles/car/
Here is an example of a commonly used directory structure:
jMonkeyProjects/Pong/assets/Interface/ # .font, .jpg, .png, .xml jMonkeyProjects/Pong/assets/MatDefs/ # .j3md jMonkeyProjects/Pong/assets/Materials/ # .j3m jMonkeyProjects/Pong/assets/Models/ # .j3o jMonkeyProjects/Pong/assets/Scenes/ # .j3o jMonkeyProjects/Pong/assets/Shaders/ # .vert, .frag jMonkeyProjects/Pong/assets/Sounds/ # .ogg, .wav jMonkeyProjects/Pong/assets/Textures/ # .mesh.xml+.material, .mtl+.obj, .jpg, .png
See also: Asset Packs
Here are some tips especially for users who already know jME2. Automatic handling of the Geometric State has improved in jME3, and it is now a best practice to not mess with it.
It's unlikely you will be willing to fully document every class you write. You should at minimum javadoc all crucial methods/parameters in a meaningful way.
Whether you work in a team or alone, keeping a version controlled repository of your code will help you roll-back buggy changes or recover that code that you or someone deleted and now is needed.
From the beta on, convert all Ogre mesh models and scenes to the binary .j3o format. Use the jMonkeyPlatform for the conversion, and save the .j3o files into the Models directory.
Unit Tests (Java Assertions) have a different status in 3D graphics development than in other types of software. You cannot write any assertions that automatically test whether the rendered image looks correct, or whether interactions are intuitive. Still you should create simple test cases for separate game features such as loaders, content generators, effects. Run them now and then to see whether they still work as intended – or whether they are affected by side effects. Keep the test classes in a test directory in the project, but don't include them in the distribution.
Quality Assurance (QA) means maintaining a clear list of steps that must always work, and checking them. There can be bugs in software, but tasks such as installing and de-installing, saving and loading, starting/pausing/quitting the game, must work, no excuse. After every milestone, you go through the list again, on every supported operating system, and systematically look for regressions or bugs.
Alpha and Beta Testing means that you ask someone to try to install and run your game. It should be a real user situation, where they are left to figure it out by themselves (you only can include the usual read-me and help docs). Provide the testers with an easy method to report back descriptions of their problems, e.g. why they gave up. Evaluate whether these problems are exceptions or must be fixed for the game to be playable.
A Java Debugger is included in the jMonkeyPlatform. It allows you to set a break point in your code near the point where an exception happens. Then you step through the execution line by line and watch object and variable states to detect where the bug starts.
Use the Logger to print status messages during the development and debugging phase, instead of System.out.println().
A Java Profiler can be added to the jMonkeyPlatform via Tools → Plugins → Available. The profiler presents statistics on the lifecycle of methods and objects. Performance problems may be caused by just a few methods that take long, or are called too often. If object creation and garbage collection counts keep increasing, you are looking at a memory leak.
Pre-Release To-Do List
Distributable Executable
The SDK can help you with deployment. Do you release your game as WebStart, Desktop JAR, or Applet? Each has its pros and cons.
Distribution | Pros | Cons |
---|---|---|
Desktop Launcher (.EXE, .app, .jar+.sh) | This is the standard way of distributing desktop applications. The jMonkeyPlatform can be configured to automatically create zipped launchers for each operating system. | You need to offer three separate, platform-dependent downloads. |
Desktop Application (.JAR) | Platform independent desktop application. | User must have Java configured to run JARs when they are opened; or user must know how to run JARs from command line; or you must provide a custom JAR wrapper. |
Web Start (.JNLP) | The user accesses a URL, saves the game as one executable file. Easy process, no installer required. You can allow the game to be played offline. | Users need network connection to install the game. Downloading bigger games takes a while as opposed to running them from a CD. |
Browser Applet (.HTML+.JAR) | Easy to access and play game via most web browsers. Userfriendly solution for quick small games. | Game only runs in the browser. Game or settings cannot be saved to disk. Some restrictions in default camera navigation (jME cannot capture mouse.) |
Which ever method you choose, a Java-Application works on the three main operating systems: Windows, Mac OS, Linux.