|
|
|
|
Overview |
|
|
Physics Engines and Game Creation Physics engines are generally seen as luxury items in game design - nice ways to add special effects to a game, but generally just a graphics tool and not something central to a game. Game worlds are usually simulated using hard-coded motions and behaviors, and a physics engine is added on top to deal with special cases like falling boxes. I feel that this should change. I believe that physics engines' rightful place is at the very core of a game system, determining the physical laws that govern all interactions in a game world. Previously, this was simply not possible, given the processing constraints of gamers' systems - physical simulation is a processor-intensive task, and the more objects you simulate, the more processor speed you require. Now, however, at least in 2D, this approach is possible. When a game has a physics engine as its very foundation, the entire way of thinking about game design changes. Everything in your game is part of the physical world: the target, the main character, vehicles, bullets. When you add a spaceship to a game, you are not just changing some logical construct, you are actually creating a physical object. When you design a level, you are not coding a program, you are crafting a world. This approach is not just conceptually interesting, it actually brings great advantages for the developer. Consider the case of designing a spaceship in a computer game. In a traditional computer game, this would involve creating a class Spaceship, giving it properties like rotation, speed, acceleration, health, etc., etc.. The programmer would then have to create many specialized functions for controlling the spaceship: what to do when the player accelerates, how to handle inertia, collision detection, and a million other factors. Rendering would add another layer of complexity. Using Physical to Create Games In Physical, it's an entirely different matter. To create a spaceship in Physical, one only has to consider what it really is: an object that moves. A programmer just has to create a physical object (first drawing the spaceship in a paint program, then loading the image into Physical's included object editor to make it into an actual physical object that can be simulated) and then give it a few properties. Using the object editor, the programmer can designate where he wants the engines to be, and then using Physical's simple programming framework he can create actuators at those points that apply forces in response to user input. Voila: a spaceship that accelerates, turns, collides, and even breaks apart all with just a few lines of actual code. And what's more, the rendering is handled automatically.
A spaceship, first being edited in the object editor, then in action in a game Unlike most programming libraries, Physical incorporates its own programming framework that systemizes and facilitates the design of game elements. This programming framework makes it a cinch to handle interactions with or behaviors of physical objects. Adding weapons, controls, and even AI can be accomplished in a matter of minutes. Physical also has over a dozen built in game elements, including engines, a basic gun, particle effects, and automatically expiring bullets. All of these objects are designed to be extended easily, so you can customize their functionality as you see fit. Using these tools, a simple game can be written with just one or two hundred lines of code. With a good grasp of Physical's framework, you'll be able to write arcade, action or puzzle games in days instead of months. To get you up to speed, I've written an overview of Physical's physics engine, object editor, and framework. This should give you enough familiarity with Physical to understand what it is and how it works. For more information, download Physical's help file. |
|
