Big update today!
What you’re seeing in this image is a very simple level being pulled from XML markup, parsed into Nape physics entities, and painted over with a preloaded texture that resides in a BitmapData object pool. You can’t tell, but a sound track is being played in the background and fades in from silence.
A LOT goes in to actually making this happen, and it’s so nice to finally be at this point in development!
The following engine features have been implemented over the past few weeks:
GameObject: This class is a super class for any object that is used in game. It uses a component-based structure to handle aspects like graphics, physics, AI, etc.
DisplayManager: This class manages containers that hold various GameObjects, like background, game stage, foreground, and UI elements. It handles the ability to move into and out of full screen mode. It also initializes the ImageLibrary on start up.
ImageLibrary: This class is an object pool for bitmap and meta data for any image seen in the game. Once an image is loaded, its bitmapData and meta XML stored and cataloged in an associative array for quick lookup.
Animations, Frames, and FrameScripts: These classes are a means for a GameObject to display graphics on screen. When called by name (e.g. “walk”, “run”, “reactToHit”), an animation will dig its corresponding spritesheet image out of the ImageLibrary, then use a sequence of Frame objects to designate what section of the spritesheet to display on screen, and for how long. FrameScripts can run on each frame, allowing me and my designers to create more dynamic looping effects, spawn particles, pause animation, etc. It’s MUCH easier to do this through a crude script markup than by tracking it in code, though it might make debugging a bit more difficult. We’ll see.
Graphics Component: This component class is used in tandem with Animations to display images on screen. Since I’ve decided to forego Startling until I’m more comfortable with designing around its API, it will use the standard Sprite.graphics object to draw items on screen.
Physics Component: This component class is used in tandem with the Nape physics framework. It handles managing the shape, friction, material, and other attributes associated with GameObject in the game’s physics model.
AudioManager: This class manages anything audio related, whether it’s playing sound effects or music.
AudioLibrary: Similar to the ImageLibrary, this class acts as an object pool for all Sound Objects.
LevelManager, LevelStage: These classes represent how the game loads levelStage data from XML markup, parses and initializes all necessary GameObject assets, and begins the game loop. A lot of the heavy lifting happens here, because this is essentially the game!
…
What a haul. But, now I have the basic backbone in place for the custom game engine. Level stages can be loaded from XML files now, which means that I can finally start in on actual game design, as well as start building a level editor for my designers. It’s been a long wait, but now the fun can finally start. Hooray!
