|
Project Information
Links
|
Game Object Framework is a framework for making games. GOF describes different types of entities and how they should interact. The open source code is in ActionScript 3.0 and is mainly composed of interfaces; however, the concepts are not specific to any platform. Game Object Framework was designed with the following in mind: minimize complexity and maximize re-usability. Benefits of GOF: If you use GOF instead of not using a framework, your code will be easier to read and maintain. Moreover, it will be easier to generate estimates and the code you produce will prove to be more reusable. As regards to the impact of GOF on teams, your team will work together more effectively as GOF provides a common language for team members to talk about the game with. Additionally, GOF provides out of the box code separations that are useful in assigning tasks to developers. More specifically, GOF code is easier to read because of the clear metaphors and classifications. It's easier to maintain because GOF guidelines force specific logic in to specific places in the code. Because GOF breaks a game up into standard smaller parts, you can estimate development time by estimating in terms of these parts. GOF is as reusable as possible because logic has been encapsulated based on commonality and variability. For example you can develop an engine you can reuse in all your games, a state manager you can use for all of your physics games and maybe even 3 renderers one for all of your 2D games, another for all of your 2.5 D games and a third for all of your 3D games. Once these pieces are written they are reusable since they use a standard interface. GOF Layers: GOF is composed of the game stream layer, and the game engine layer. The game stream layer is a nice and friendly layer where you think about the game objects you're going to add. Programming in this layer most resembles the games design. Logic in this layer only applies to that specific game. This layer behaves a lot like spring does, you simply instantiate the game objects with their properties and let the lower layers handle the rest. The game engine layer is all the code that has to exist to support the game stream layer. Here is where the math is done, where the game loop delegates tasks like collecting moves, calculating the next state, and rendering. GOF Entities: Game Stream: All of the different parts of GOF in one way or another support the game stream. The game stream is the part of the game that contains all of the action. The game stream is made up completely of living, breathing game objects. GOF does not concern itself with the part of the game experience which navigates to, or navigates out of, or complements the game stream; it simply creates game streams. To do this, the greater game code must: 1.Instantiate a game stream 2.Register the core parts of the game stream. 3.Add the game objects to the game stream. The game stream is controlled through various exposed public functions like “start” and “togglePausePlay”, and the stream also dispatches events that the greater game code user can listen to. Game Objects: Game Objects, or GOs, are the thing a user notices when playing a game. If something is drawn, or has a state, or makes a move, it is a game object. The classes that represent the game objects should store all of the data necessary for the game object to be processed by the game engine. In other words, if the game object must be rendered, it should include display data. And if the game engine must make a move, it should include a reference to the class that returns the move. Our top layer simply consists of creating a game stream. This top layer is made possible by the next layer down, the game engine layer. Game Engine: The game engine layer begins with the game engine. The game stream works directly with and is supported by the game engine. We have divided all of the functionality needed to run a stream into parts. The game engine supports the game stream by conducting these various parts. What all game stream's have in common is that they have a state, have to be able to generate the next state(based on its current state and inputs) and must be able to render this state to the screen. This definition tells us that the functional parts of our game must be to manage state, get inputs, and draw. Since these classes can be implemented a number of ways, we create a common interface for each class, and the engine will use that interface without worrying about implementation details. The game engine layer executes a game loop on interfaces for the main framework parts. The main framework parts for a game include: Translator: Translates state positions into display object positions. Renderer: Logic that draws the scene. State Manager: Logic in charge of going from one state to the next based on user input. Turn Manager: Logic in charge of managing who's turn it is. Additionally, the game stream should also aggregate a “controller,” which helps bubble events from the state manager up through the game stream. you can browse the UML here: http://www.scuge.com/gof/uml/ |