A Physics-Based Game Creation System
by Alec Rivers

Overview: Framework

Introduction
Overview
    Physics engine
    Object editor
    Framework
Screenshots
Downloads
Repository

Physical's third, and in many ways most important, component is its programming framework. This is a system of data structures and interfaces that put all the abstract concepts of games and objects into a simple, easy-to-work-with layout. Rather like the MFC classes for Windows programming, it consists of a number of pre-created base classes that provide core functionality and are designed to be extended. These base classes are linked together in a tight hierarchy that provide logical game structure and simple program flow.

A symbolic representation of the structure of a game built with Physical

The above diagram shows the structure of a game built with Physical. It shows the four basic classes in Physical: Game, System, Renderer, and Object.

Game:
A Game structure acts as a container for all the diverse elements of a Physical program. Physical defines a base class Game, which includes functionality common to all games: variables for holding key states, mouse position, and mouse button states; a quit() method; and a stepFunc() method that is typically called by the main program every frame and forms the basis for the game loop. A programmer would generally extend the base Game class for their own game (e.g., class SpaceGame : public Game). A Game also contains pointers to a generic System and Renderer.

System:
A System is the basis of all physics simulation. It contains lists of all the atoms and links in the world, and has an update() method that advances the physical simulation one time step. It is pretty much a black box that just "does the work". Its update() function is automatically called from Game's stepFunc(), so programmers will generally never have to deal with it explicitly.

Renderer:
A Renderer is the basis for all graphics in a game. The base class Renderer is just a stub, containing no functionality of its own: programmers must choose a preexisting extension of this or write their own for rendering. So far I have written one extension, GLRenderer, which is a fully functional OpenGL based renderer, but I may eventually add a DXRenderer or others. Again, the renderer is by and large a black box, being called automatically from the base class Game's stepFunc(). The only time a programmer will have to deal directly with it is in initializing the program window (choosing width, height, bytes per pixel, and so on).

Object:
The Object class is essential to the game dynamics of any game programmed with Physical. Understanding it thoroughly is key to developing with Physical. Simply put, an Object is something that adds functionality to a physical object in the game world. Programmers must extend the base class Object to add capabilities. The easiest way to explain this is with an example. Consider the spaceship example described in the introduction: after creating the physical object of the spaceship in POE, a programmer must then give it interactivity. This is done by creating a new Object. First, the programmer would extend the class Object to make a new class, Spaceship:

The programmer would then add some sub-objects for the engines. In this case, I presume the existence of another extension of the Object class, Engine, with the method applyForce(float). (In reality, a class very much like this does exist, called Actuator or DActuator.)

Next, the programmer would take advantage of one of Object's built in functions: stepFunc(). An Object's stepFunc() is called every game step.

Now, this is a little bit pseudo code (the Spaceship class needs a constructor and access to the keyboard, and must designate which atoms belong in the engines) but the reality is not very far off, and it demonstrates how easy it really is to create new objects and interaction schemes in Physical. Through using Object's built in functions of stepFunc() and atomFunc(Atom *) (which is called every time an atom inside an object is updated) adding functionality is a snap.

A completed game using Physical would therefore consist of a new Game class and a bunch of new Objects. One of the great thing about Objects is that they are totally portable, and if you wanted to mix a tank from one game with a spaceship from another, you would have no trouble doing so. I have already in my demo game work created a number of potentially useful Objects (a grappling hook, for example), and I can see a future in which many game developers working on independent products would slowly build up and share a huge library of Objects, to the point that entire new games could be easily created out of preexisting elements. (Can you imagine a system in which to create a war game, you just have to drop the Objects "Tank", "Plane", and "Soldier" into a common framework?) To this end I've begun work on the Repository, a place where game designers will be able to freely upload and download new game elements.