GFW Project

Version 0.1.2

Introduction

GFW stands for "Game Framework" (how inventive). It provides a framework for game development that uses an object-oriented architecture to respond to some fundamental difficulties that game programmers face during the development cycle. Specifically, the framework provides the following:

• A high-level, platform-independent multimedia API. The framework provides an abstraction layer for input access, precise tracking of time, and video access. This layer is "pluggable" and implementation drivers can be written that communicate with a variety of low-level multimedia APIs such as Microsoft's DirectX, Apple's GameSprockets, or the Simple DirectMedia Layer (www.libsdl.org). Currently, an implementation that uses SDL is provided.

• A GUI framework. Building on the hardware abstraction layer is a basic model-view-controller architecture that provides a low-level foundation for a graphical user interface.

The downside of all this, of course, is that too much abstraction can lead to performance problems, which is a very real issue in game development. I'm not entirely sure where this project stands in that regard.

Installation

You may download the source tarball here.

See the Installation Instructions for detailed information. But for the most part, if you're in a Unix environment, just get the SDL library if you don't already have it, do the standard ./configure; make; make install, go into the release directory, and run the gfw executable.

Running the Test Program

The test program that comes with the application is pretty simple. Some boxes displaying a text label and the framerate bounce around the screen, and the framerate is also displayed in the upper-left hand corner. All the labels displaying the framerate are actually view/controller objects (Testing::CFPSGraphicalObserver) being dynamically updated by a model (CFPSTimer). The bouncing boxes are Testing::CPhysicsObserver view/controllers being dynamically updated by Testing::CPhysicsModel objects.

You can press CTRL-F to toggle between fullscreen mode and windowed mode, and press the F key to turn the frames-per-second display on and off. Press a number key to reverse the direction of a bouncing box.

Exploring the Framework

I suggest you take a look at the Patterns Used page to see what architectural and design patterns are used, and follow the links provided to explore the class interfaces and source code using your web browser; the documentation system I used, Doxygen, does a very good job of displaying class heirarchies, collaborations between classes, and it also provides great source browsing capabilities.

Credits

I (Atul Varma) wrote 100% of the code. Some of the architecture, code, and documentation has been imported from my Pman project, a pac-man clone in C, of which this framework is an object-oriented descendant.

Certain parts of the library were inspired by ideas taken from other sources. For instance, the reference-counting based garbage collection routines used in the CSurface / CSurfaceImpl classes was outlined in detail by Bruce Eckel in chapter 12 of Thinking In C++ (an excellent read without which this project certainly wouldn't have been completed; I'm still not finished reading it, actually, and it looks like some of the problems I ran into during development are covered in the sections I haven't gotten to yet).

The seminal "Gang of Four" text Design Patterns was also very helpful for the architecture, especially when designing the MVC-related components and interfaces such as IObserver and CModel. To this end, the chapter on design patterns in Game Architecture and Design by Rollings and Morris was also helpful.

Thanks also go to Mark Shacklette for teaching our CSPP 51091 class about what patterns are, their history and philosophy, as well as how, why, and when to use them; also for introducing us to refactoring and other "extreme programming" concepts, which I like a lot and am currently trying to put into practice, but which also seem somewhat incompatible with C++, which makes me feel a little more justified in despising the language. I suppose if I just designed a class really carefully and never had to change it after I implemented it, C++ would be a fun language to program in, but knowing me (and accepting the arguments motivating the refactoring philsophy in general), that's never gonna happen.

Thanks also to Sooyoung "I never tell anyone my last name" the asian dude for telling me about the Doxygen package, which is the coolest C/C++ tool I've ever seen, and causing me in my utter excitement over the whole thing to start writing pages and pages of documentation making this assignment look like some kind of premiere open source framework when in reality it's a rushed hack job that I'll probably never touch again.

(And if the pretty-looking Doxygen-generated manual you're reading now makes you think it's not a rushed hack job, just take a look at the Todo List and Long-term Todo List. Granted, a number of these problems surfaced because I didn't really know C++ very well when I started the project; fortunately, constant coding and Eckel's Thinking in C++ are quickly changing this.)

---

Project Statistics:

• Length of development: 1 week (August 20-27, 2003)
  
• Development software used: Microsoft Visual C++ .NET Academic, GNU Emacs, GNU Make/Automake/Autoconf, GNU C/C++ Compiler (gcc), Doxygen
  
• Total size of project code: 84,416 bytes

---