This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
In the world of game industry, the term "game engine" is something that makes everyone interested wonder what all is about. One must think and compare this "game engine" to a car engine or anything of that sort. The game engine, much like a car's engine is what makes the game go.
Generally speaking, the concept of a game engine is fairly simple; it exists to abstract the details of doing common game-related tasks such as physics, rendering and input so that developers can focus on the details that make their games unique.
Almost all engines offer reusable component that can be used to bring a game to life. The loading, displaying, and animating models, collision detection between objects, physics, input, graphical user interfaces, and sometimes parts of a game artificial intelligence can all be major parts that make up the engine.
The content of the game, precise models and textures, the significance behind object collision and input and the way these objects interact with the world, are the parts that make the real game.
For quite a while, many game companies made their own game engines and kept the technology behind the engine in house. With the advancement of computers, more advanced versions were needed (1)(http://www.gamecareerguide.com/features/529/what_is_a_game_.php?page=2 ). For instance Engines like SCUMM (A program that allows a player to run certain classic graphical point-and-click adventure games, provided you have already have their data files) by LucasArts (Figure 1.1 - 1.3) and SCI by Sierra (Figure 1.4), powered most of the adventure games that the said companies released in the late 1980s and into the mid 1990s.
Over the past several years, the cost of making an in-house engine has grown up drastically paving way for these companies to specialise in making either full game engines or game engine parts to sell to other companies rather than make games. These companies are classified as middleware providers. Middleware providers can offer these products at very competitive prices and for some can be downloaded in the form of an open source project.
Game engines types:
Jeff Ward, in his article on Game Engines, in April 2008, mentioned that there are many types of engines but all are under three main categories.
These engines come in many forms and levels of programming expertise. But in general, there are three main types of game engines: roll-your-own version, the mostly-ready version and the point-and-click engines (Ward, 2008).
Roll-your-own game engines (lowest level): Many mainstream game companies as well as game makers attempt to roll their own engines regardless of the cost. It means that, they will use publicly available applications interfaces such as APIs like DirectX and OpenGL, to develop their engines. It gives developers the greatest amount of flexibility; letting them select the components they want and put them together the way they want. The cons being the amount of time it takes to build such systems (Ward, 2008).
Mostly-ready game engines (mid level): These engines are ready for primetime right out of the box with rendering, input, graphical user interface and physics. Most of these engines have mature tool chains so you don't have to roll your own. Example of engines in this category include OGRE (Figure 1.5 - 1.6) and Genesis3D (Figure 1.7 - 1.8); which can be downloaded as open source, Torque (Figure 1.9 - 1.10); which is a low-priced engine, and Unreal, idTech and Gamebryo (Figure 1.11); which are high-priced engine (Ward, 2008).
All the mentioned engines require a bit of programming skills to get them up and running into a complete game. Most of these ready game engines are limiting than roll-your-own engines and are commonly for the general case.
Point-and-click Engines (Highest level): Recently, these engines are becoming more common. They include a full tool chain that allows you to point and click your way to creating a game. They are built as friendly as possible and are made to require as little coding as possible. GameMaker, Torque Game Builder and Unity3D are examples of these engines. These engines can be tremendously limiting but the best thing about these engines is the ability to let you work quickly and play your games quickly without too much work (Ward, 2008).
1.2: Project Aims and Objectives
This paper will be basing its work on Java-based game engine. In this paper, I have considered three main reasons for choosing a java-based game engine:
Java popularity: Java is being used everywhere by students and other programmers alike, and it is the main programming language that I have covered during my studies here in Bangor University.
Platform independence: The ability of any java-based application to be written once and to run anywhere on any platform/environment such as mobile devices and the internet.
And as the best programming language for Automatic Garbage collection (in Memory management)
Therefore, the aim and objectives of this paper is to investigate java Monkey Engine with the following main overall aims:
Investigate the capabilities of Java Monkey Engine
To develop the materials for the teaching of Java Monkey Engine to second/third year students
Extend the demos to be used by the students as a possible assignment
Sample screenshots of adventure games from the late 1980s to mid 1990s:
Examples of Mostly - ready game engines (Mid-level):
Chapter 2: Java Monkey Engine-Overview
This section will concentrate on giving the brief introduction of Java Monkey Engine, its history, legal issues, architecture features and advantages of using jME over other game engines
2.1: Introduction - What is Java Monkey Engine?
Java Monkey Engine (jME) is a high performance, open source Java-based 3D game engine that is used to create interactive 2D and 3D graphics systems. JME provides scene-graph based graphics API. jME is a community-driven and completely open sourced project that supports both Lightweight Java Game Library (LWJGL) and Java OpenGL (JOGL) rendering systems.
2.2: History of jME
jME was founded in June 2003 by Mark Powell and was rewritten in September 2003 using scene graph architecture to support real time rendering systems based on OpenGL, since the first JME didn't allow this. In October 2003, JME became part of dev.java.net middleware. Java.net was chosen over other SCM (Source Code Management) tools such as CVS (Concurrent Versions System) etc, because java.net was far better than the rest at that time.
jME is 100% written in Java and it runs on a Java Native Interface platform. Linux, OSX (Mac Operating System X - which is a Unix-based operating system) and Win32, are examples of LWJGL supported JNI platforms.
Inspiration behind JME creation:
jME was created out of interest in game engines by the founder, Mark Powell. He was curious about 3D graphics in Java. At that time, 2003, there wasn't any major game engine written in Java.
2.3: Legal Issues behind jME
Since jME is a community-driven project, with BSD licensing, the more experienced and less experienced developers can help and learn from each other. This helps in improving team-working skills in a programming environment for developers. It is as well something that helps to build a good CV - personal development/career building.
Why BSD licensing?
BSD licenses ( a family of permissive free software licences) was chosen by the creators of jME simply because BSD recognises the Author's contribution on the source / appreciates the source of the software. BSD lets anyone with the knowledge of developing software projects to contribute and doesn't have a lot of constraints.
2.4: jME Architecture features
Figure 2.1: JMonkey Engine Architecture (Source: Patton G, 2003)
2.4.1: jME Scenegraphy
Scenegraph means that game data is grouped in hierarchical structure that includes parent nodes containing child nodes. Child nodes do have only one parent node and the root node has no parent. The leaf nodes in this context contain geometrical data that is to be rendered to the display while internal nodes are meant to manage grouping. This grouping resembles a tree structure.
Benefits - Using scenegraph in game engine:
Below are the benefits of using scenegraph in game engine:
Management of global attributes is simplified
Example is to set a light to shed light on a single sub-tree in the graph
It facilitates the grouping of objects in the same spatial place
Places of the scene that are not visible and do not need to be rendered are quickly removed
It makes it possible for the direction of hierarchical models like humanoid characters
Example, the head determine the direction of the body
It assists in keeping on the state of the game meaning that all nodes can save themselves recursively.
Purpose of a tree-based representation:
It provides nodes to maintain spatial and semantic information that allows rapid discarding of whole branches for processing
For providing transformations
Positions, adjust and size objects
For culling and collision/intersection checking
Setting up the renderer to draw objects
Provides the representation of time changing node data
2.4.2: jME Geometry
This describes a leaf node of the scenegraph and it comprises of geometric data for rendering objects. It manages the state of the renderer and data for a model.
2.4.3: jME GUI
It provides abstractions to communicate to the graphics card. It consists of Layout managers that are modelled after java.awt.LayoutManager - this is a java Abstract Window Toolkit that contains predefined objects that controls the size and the layout of components inside a container object (Pawlan M. 1998). The Layout Managers consists of two java interfaces which are:
All Widgets implements the Widget interface and the communication is managed by implementing the java.util Observable interfaces. For example, mouse activity or change in value.
The default Widget implementation is WidgetAbstractImpl that extends Spatial so widgets can be included in scenegraph.
WidgetAbstractContainer extends Node and implements the widget interface so that it can merge Node with a Widget
WidgetAbstractFrame provides a high level framework for managing Widget and it extends WidgetAbstractContainer.
The purpose of this is to handle directing input events to the child Widgets in its sub tree structure
2.4.3: jME Sound
Platform dependable - sound systems are pluggable and rendered in 3D space. jME sound is specified by two interfaces:
ISoundSystem that manages playing of the sound
ISoundRenderer that manages the connection of the sound to the scenegraph for handling 3D sound effects.
2.4.4: jME Graphics
jME Graphics has the following capabilities:
(Mipmapping, environmental mapping, multi-texturing and shader texturing)
Model loading support
(3DS, Obj, MD2, MD3, Milkshape, X3D, skin, bones and weighted skeletal animation)
Render to texture (Figure 2.2 demonstrates)
Turn any scene into a texture object (in V2.0 requires Frame Buffer Object (FBO) support).
Built-in shape primitives such as Sphere, Cylinders, capsule, Torus, Arrow, Disk, Hexagon, Tri-mesh, Box, Pyramid
Tracks and manages the status of the OpenGL machine. Some of the managed states include: Lights, textures, culling, fog, wireframe, ZBuffer, materials, and shading.
2.4.5: jME Effects
In the current version (version 2.0), the available effects are:
Particle System (Figure 2.3 demonstrates)
Tinting (Figure 2.4 demonstrates)
Texture-based dot3 bump-mapping
Water with configurable reflection, refraction and wave generation
2.4.6: jME Input
Input is through a Mouse and a Keyboard
2.4.7: jME Camera
The purpose of the camera is to be used to project objects to the computer monitor. The systems maintains camera as a separate node in the scene.
2.4.8: jME Controller and Animation
The Controllers adjust nodes and render states over time. They are used for animation of the scenegraph.
Figure 2.2: Render to Texture demonstration / Camera (Source: Gregg Patton, 2003)
Figure 2.3: Particle System demonstration (Source: Gregg Patton, 2003)
Figure 2.4: Tinting in jME (Source: Gregg Patton, 2003)
Chapter 3: Design and Implementation
This chapter will look at how some jME capabilities and will extend some demos for students to use as part of laboratory exercises.
3.1: Software design and setting up
The main software used to develop java Monkey Engine games are:
Java Development Kit
NetBeans IDE 6.8
Command Prompt Interface
Since Java is platform independent, it has been assumed that all platforms (Mac, Windows, Linux and UNIX) will be able to run the java files without any complications. Originally, this has been written using Windows-based Operating System.
It is also assumed that since java is one of the most popular programming languages and widely taught in our University, students will be familiar with the use of code editors such as Java Development Environment, NetBeans, Eclipse and JCreator as they are all following almost the same pattern.
This demonstration is expected to be able to do the following:
List all the java source files that have been used in this paper
Show how to compile the files using the basic java code compiler
Show the expected results from the code that has been run
3.2: Design Implementation
Java Monkey Engine
3.3: Coding issues
Some coding problems occurred while trying to implement the codes. Some of these issues were very unexpected as it was expected and assumed that java Monkey Engine will be easy to set up and creation of the source files would be simple.
3.3.1: Incorrect File address
The engine requires all library files to be installed / added in the library / source package for it to run them. Without the files, expected results won't be achieved. Figure 3.1 demonstrates a sample error that occurred during the implementation of the sample terrain system. The source code file must point to the required source packages; that is the correct address must be put otherwise the compiler will return a null value hence terminating the game. When creating terrains, the developer must make sure that the files are being saved with the correct file extension. Sample files here have been saved as .png or .jpeg.
The compiler will still compile the source code file and throws an Exception.
3.3.2: Incorrect Dimensions from the source code file
Java source code files require the developer to specify / define the dimensions of the terrain. If the dimensions are incorrect / do no match (main class and the constructor file), the compiler will return a null value, that is, the file will be compiled successfully but nothing will be displayed. Java Monkey Engine seems to tolerate some of these errors but when they are correctly defined. Figure 3.2 illustrates the above statement.
3.3.3: Source Packages Error
There are 2 main source packages that all source code files point to. These files must be imported before the main classes are defined. These are:
com - It contains constructor files for java Monkey Engine. Some of these constructor files are (to name few): all files responsible to build animation objects, curving, math, rendering, scenes, bounding, input and images. It also contains files responsible for building applications / games with audio, managing 3D and 2D fonts, editors, terrain and models.
jmetest - This source package contains all the test files required to run a game. All test files must be kept in this package. Failure to do this will result into the game not to return the expected result / a null value.