Coming soon are UML diagrams and we can add and discuss code here…
CHAPTER 1 - LOGIC CLASSES FRAMEWORK
INTRODUCTION
In the creation of a game engine, there will be many challenges to be faced and one of those would be the incorporation of logic aspects as opposed to visual aspects of the game engine. Arguably, it is the logic side of the game engine that would be responsible for the enhancement of the appearance of that which is created by the visual classes (for example, shaders) and also the logic side would be responsible for the way certain visual elements interact with the user (for example, artificial intelligence), the world (for example, collision detection and physics) and other visual elements (like with lighting to create shadows).
In the sight of how heavily so many elements of the game engine, both visual and logic, will depend on other logic classes, it would be common that without a proper framework in place, there would arise many problems such as lack of optimisation, repetition of existing elements, unmanageable visual flaws and code which is not reusable. A framework will add structure to the game engine, apply a design pattern and also create standards to be followed for those creating logic (or non-visual classes). It will also be helpful to those creating visual classes so as to understand the non-visual side of the game engine and how the elements they create will affect and be affected by the logic classes. This framework has been designed for applying to the creation and management of the Ithaca Game Engine but will apply for a team of programmers numbering between 10 and 20 people who have divided the work into those doing visual aspects and those doing non-visual aspects.
DESIGN PATTERNS
Several design patterns may be used for the creation of these logic classes and seeing as there are people focussing on visual aspects and others on non-visual aspects, the best design pattern to apply overall would be the Model-View-Controller Design Pattern. This pattern isolates logic (the Model) from the visual aspects (View) allowing for both to be developed, maintained and tested independently of each other but both in accordance with the system controller or component class (Controller).
Following this design pattern will have the Controller (which will remain mostly unchanged during the development of the visual and logic classes) maintaining an association with both the Model and View aspects and it having the ability to detect and find the logic classes that are operational and that may be applied to the various visual elements to run and test parts of the game engine. The diagram below shows how the MVC pattern will be implemented in the game engine with the main View classes and Model class. For the controller classes, the Component class is not currently shown.
FRAMEWORK STRUCTURE
The main logic class is the GameHandler class. By the manipulation of this class, logic classes may be added to the game engine such as those which affect the visual classes. The GameHandler class, as the main logic class, holds associations with the main visual classes which are that of Camera and F3DWorld (part of the EngineClasses solution). The above diagram shows the main MVC classes for the Ithaca Game Engine version 1.0.2.5. Through the GameHandler class, logic classes may be implemented and tested without affecting the Controller classes which operate and run the game and also without touching the visual classes. The Component class (not shown in the diagram above), will check for problems that may arise from added logic classes and address them if possible or order them to be disabled.
STANDARDS FOR LOGIC CLASS DEVELOPMENT
To enable proper use and obedience to the framework above, it is important that the following standards are followed for easier integration of logic classes with the GameHandler class and so as to prevent errors but maintain clean maintainable code.
For any code classes to work with the GameHandler and be successfully able to be integrated into the game engine, they will need to have methods in them that will enable them to be
1. Initialised
2. Updated
Leaving such methods may make it tricky to incorporate classes to be used with the component class or GameHandler class. People working with logic classes such as AI and Physics will need to then have their code classes working hand in hand with certain visual classes or objects. This may be handled by editing the object classes by adding such attributes that will need to be manipulated, for instance, a float variable of mass added to a character to affect the rate at which they fall to the ground when falling under gravity and also the speed of their movement (for Physics class).
This follows that code changes made to the object classes should be
1. Well commented and their properties made known to those who may need to use the same property or to edit the object class
2. Applied immediately to the logic class in question so that the GameHandler class may immediately be able to use it and update the visual object on screen correctly
Other proper coding standards should also be applied to allow for reusability and maintainability of the code.
CONCLUSION
This framework has been developed for use in the creation of the game Ithaca by the final year students at the University of Greenwich 2010. It can however still be used to apply to other games following an agile or iterative methodology of software development and who are interested in using the MVC design pattern. The beauty of this design pattern is that it allows for the implementation of other design patterns within itself such as those for delegation. It also allows for easy reuse of different components that may then be used for the development of other game engines. Documentation is also easier to produce but what has been the main focus of this document is that of having a standard in the creation of non-visual classes so as to simplify the development process. This also helps other classes in their development as visual classes may be flexible in how they are made, provided they have a draw method and properties which may be manipulated by the logic classes.
