The overall goal of this book is to provide you with an extensive toolbox of hands-on development tips for jMonkeyEngine that will help you be well prepared for a wide range of projects.
The recipes are written from a practical point of view, and I strived to make sure that each recipe has an outcome that can be used directly in a game. An exception to this is Chapter 7, Networking with SpiderMonkey, where we will start from the absolute ground level and work ourselves upwards. Chapter 1, SDK Game Development Hub, also stands out as it contains a few more general tips applicable to development in general.
Due to the variation in game projects, another principle has been used to create recipes that have a wide usage potential. Some of the more advanced recipes are exceptions to this rule. They have a more narrow use but contain techniques that can be applied to other implementations. FPS, RTS, and RPG games will be explored in many of the recipes. Naturally, within these genres, games differ widely as well, but hopefully you will find that the examples can be used in your game project with a minimum amount of modification.
In general, I hope that this book will provide you with many tips on how to overcome common hurdles in game projects so that you can focus on the creative parts that make your game stand out.
Some common development concepts in jMonkeyEngine are as follows:
- Spatial: Central to all things in the scene graph is the Spatial. In jMonkeyEngine, it's an abstract class, defining translation (location), rotation, and scale of an object. Imagine it as a purely logical object without a physical body. A Spatial is extended into either a Geometry or Node.
- Geometry: This extends Spatial. This class is what gives a Spatial its physical presence in the world. It has a Mesh defining its form and shape, and a Material, telling us what the surface of the Mesh looks like.
- Node: This extends Spatial. It can have several children attached, and can in turn be attached to a parent. Since it's a Spatial, it has a translation, rotation, and scale, which it will propagate to its children. Unlike a Geometry, it can't have a Mesh. It doesn't have a visible presence in itself.
- Transforms: Translation, rotation, and scale are commonly referred to as a Spatial's transforms. A Spatial has both local and world transforms. The local transform is always in relation to its parent (if any). The world transform is the absolute transform with all possible parent transforms propagated together. As an example, imagine your own local translation being the position you have on Earth. Your world translation could be your local translation added to the Earth's local translation in its orbit around the Sun. Normally, you will only work with local transforms. World transforms are handled by the engine.
- Mesh: This is made up of triangles. In a Mesh, you will find long lists called buffers detailing the points of these triangles (vertices), how the surfaces of these triangles are made (indices), their colors, normal, and other data. Normally, you will load a model from disk, not having to care about what it looks like on this level, but some recipes will create meshes from scratch, and I recommend having a basic understanding of meshes when you do 3D game development.
- Material: This defines the surface of the Mesh. It's backed by a Material Definition (MatDef), usually containing a vertex shader and a fragment shader. The complexity stretches from simply setting a color or texture for a mesh, to ones that alter the shape of the Mesh. You will get far by using jMonkeyEngine's predefined MatDef.
These are some of the basic must-know concepts of the engine. The following concepts can be considered nice-to-know. I know from experience that these are the ones you wish you had known when your applications were in the process of being developed. They will also be used quite frequently throughout the chapters of this book:
- AppState: This is an object that affects the behavior of the whole application, and you can, for example, use them to specify logic for different parts of the application. An example could be if you have a game that is played out both on a campaign map and on the ground, both player input and game logic would probably differ quite a lot. By using the AppState class, you can manage the code more easily and avoid monstrous classes.
- Control: Like AppState, this is a good way to manage your code. The Control affects the Spatial it's attached to, and is commonly used to give Spatials special functionalities. You will see several examples of Control behavior in many of the chapters, so if you prefer learning-by-doing, you're in for a treat.