Game Object Oriented Framework         The Game Object Oriented Framework (GOOF) is a game engine (GOOF Engine) and a world editor (GOOF Editor) for Ogre3D

The Game Object Oriented Framework Introduction

Note: GOOF was canceled sometime around 2006. An archive is available in the Ogre Add-ons project.]

The Game Object Oriented Framework (GOOF) is a game engine (GOOF Engine) and a world editor (GOOF Editor) for Ogre3D.

The GOOF Engine is built on top of existing scene managers and can work with any Ogre scene manager. Its purpose is to provide various game systems such as object partitioning, serialization, level of detail on any type of object, input management, sound management, user interface and game state management, and various types of built in game objects for speeding up game development. All of these systems are implemented using a plugin framework so that new systems and game objects can be plugged in easily.

The GOOF Editor is an editor framework that can be used as a container for content creation tools for your production pipeline. Simply put, it's a framework for tools you build for your game using a nice plugin framework, and includes two plugins : a terrain editor plugin for the Paging Scene Manager, and a world editor plugin that builds scenes that can be used in the GOOF Engine. In fact, the GOOF Engine runs right inside the GOOF Editor, so it's really WYSIWYG - and includes all of the features of the Engine right inside the Editor.

GOOF started out as a generic object handling framework that provided a system for managing game objects. Clay Larabie (Falagard) is the primary contributor and maintainer of this project.

See this forum thread for ongoing discussion of the GOOF Engine and GOOF Editor:


GOOF is currently available in ogreaddons as an early pre-alpha version and is being updated daily. Click below to follow instructions on how to install GOOF.

Game Object Oriented Framework Installation

Game Object Oriented Framework Design

Todo - describe the major systems in detail here


Above you can see some of primary classes in GOOF for dealing with GameObjects.


Above you can see the editor framework, which includes plugin systems for tools.


Input Controllers are used for controlling the camera and possibly other objects such as Players.


Manipulators are used to manipulate anything in the scene. This may include GameObjects, but is not specifically tied to GameObjects since the actual translation, rotation, etc. of the currently selected object is handled through callbacks. For example, other editor plugins could use manipulators to move their own types of objects.


Here is a list of some of the game objects currently included in GOOF, as well as partitions.


Game systems currently implemented in GOOF. SoundGameSystem is currently in the process of being added.

Out of Date Information

Some of the following information below is out of date but is being left in until it can be updated.

Core Functionality

The core functionality provided by GOOF includes:

  • Saving and loading serialization system. Includes the ability for custom objects to serialize their own properties. A generic "metadata" system to share data across objects of the same type, which speeds up loading time, lowers disk space requirements, lowers memory requirements, and allows you to alter all objects saved in your world by just modifying one .meta file.
  • Update management system so that objects can receive update events
  • Editor Framework with plugin system for tools. Editor can be compiled standalone or embedded directly into a game, sharing code between the editor and the game.
  • Custom level of detail system that can be used by any type of object (such Particle Systems which stop emitting particles after a specific distance, Sound objects which only play sounds when within a distance, etc.) Automatic level of detail selection based on object size. Distances can be configured within a configuration file or updated dynamically.
  • Space partitioning and paged loading of objects so that only objects that are within a partitioned distance are loaded. Example: Terrain pages, or other custom space partitioning schemes (imagine loading objects by room or sector in an indoor manager).
  • Implementation of category browsing and object enumeration using a simple file system browser. By creating folders and placing .meta files in those folders which describe objects, the CoreGameObjectManager will return categories for the folders, and objects within the categories by searching the file system.
  • Dynamic properties - the ability to assign properties within .meta files which are then automatically added to the property enumeration and are saved/loaded with the serialization system. This allows you to take an existing object type and add custom properties to it without creating a new object type, if desired. (An example would be to take the MarkerGameObject and use it for a custom purpose in your game, such as a player start point).
  • Simulation start and end events which are passed down to all objects. This allows objects to know the difference between when they are being edited, versus when they are actually supposed to behave as real objects in-game. No one wants their explosive objects to explode in the editor and kill all the nearby NPCs, while you're still editing the world!
  • StaticGeometry merging of entities.

Editor Functionality

Editor specific functionality is provided by exposing a set of functions in the GameObjectManager that may be used by an editor application. An example is a function which rotates a set of selected objects, called rotateObjects( vector<GameObject*>& objects, Radian rad, const Vector3& axis ). This function would be called by the editor, and internally the GameObjectManager determines the center of the objects and rotates them about their combined center by the rad amount, along the axis provided.

  • Select multiple objects
  • Move/rotate/delete multiple objects
  • Link parent, unlink parent to create hierachies in the scene
  • Ability to query an object manager for a list of available categories, and objects in each category, and an object factory system for creating objects based on the ID returned from one of the queries. Abstracted to allow an object manager to implement any type of mechanism for storing these objects, such as xml, file system, or database driven object storage. This is good for editor applications. Example, you can have a Meshes category, with Trees, Rocks, Folliage, Characters, etc. sub categories. The default implementation is to just use folders under the app directory, they are enumerated at runtime and displayed as categories. Objects are defined by creating .meta files in the folders (meta data description files) that describe your objects, including the object type, name, and default property values of your object. This functionality can be easily extended to have a data driven system from a database.
  • Property enumeration functionality to query an object for properties and assign values to the properties. This is good for an editor application (such as the PLM2 MapEditor) which can modify properties on objects without needing to know anything about the object. An editor can enumerate available properties and display them in a dynamically created form, allowing you to define any properties you want and edit them in the editor. Supported types are currently: String, Float, Int, Vector, Boolean.
  • Start Simulation/End Simulation allows objects to perform custom operations. Example, the particle system object doesn't actually emit particles until the Start Simulation button is clicked.
  • Undo/Redo

Built-in Objects

  • MeshGameObject - an object that handles the loading of entities, including background thread loading of entities. Only loads the required entity based on the current level of detail. If a MeshGameObject is loaded and is far away from the camera, depending on its size it may either not load an entity at all, or load its lowest detail entity.
  • ParticleSystemGameObject - a particle system which supports level of detail to only emit particle when the camera is close. Emits particles while in simulation mode.
  • LightGameObject - supports any of the Ogre light types.
  • SoundGameObject - supports playing a sound, and level of detail to only play sounds within a certain distance. Plays while in simulation mode.
  • MarkerGameObject - a simple object that can be used in conjunction with dynamic properties for various game specific purposes.
  • TreeGameObject - a special tree rendering object.
  • Compound objects. Create a hierarchy of objects using the link functionality mentioned above, then save them out as a "Compound" object which can then be inserted as many times as you want with hierarchy intact. An example is a water fountain mesh with a particle system attached to it. Save it out as a Compound, then it becomes available as an insertable object.


A partitioning system allows arbitrary space partitioning. A GridPartitionManager is built into GOOF which performs grid based partitioning, and it is planned to create a interior partitions for dealing with room to room connections as well.

Player Movement, Collision Detection and Camera System

An ActorGameObject has been created which represents a character in the game and includes a movement and collision system. A mesh/mesh collision and player movement system has been implemented using OpCode, and a 3rd person camera has been created. This includes the ability to walk on the terrain, slide along walls, jump up on objects. This class will be improved upon, adding animation synching with actions.