» Engine zero0.org

Tag Archives: Engine

Content Management and Model Instancing

I posted the following on the Card Kingdom development blog.

Content management is a large part of any game. In terms of our engine, “content” is any external resource that needs to be loaded into the system. Shaders, textures, models, and sound files are all content that the system needs to load. Another aspect of content is that it only needs to be loaded once. Loading the same file multiple times is a waste of resources and load time. Creating instances of the content is more efficient in both memory and time. Multiple instances of the same content resource can be created and destroyed with no consequence in the original resource.

Serialization and Audio

I posted the following on the Card Kingdom development blog.

Object serialization and audio have both been in the new iteration of engine from the beginning, but had little to no work done on them since other systems needed more focus during the initial stages of development. Now that these systems are in a state of equilibrium, serialization and audio can be worked on.

Our serialization model is inspired by Java’s (without the automatic reflection of object variables). Objects that want to be serialized extend the ISerializable interface.

Who Needs Scaleform…

I posted the following on the Card Kingdom development blog.

Another new feature for the engine this go-around is an enhanced UI. Our previous UI was built using objects and custom components for each type of widget. Buttons, text labels, sliders, and other such controls could be placed in the game interface with a few custom animations, such as sliding in and out of the frame and rollover/highlight states. These controls functioned well and were pretty simple to use and extend, but it took a lot of initial work developing the widgets that could have been used in other areas of the engine.

Physics Integration

I posted the following on the Card Kingdom development blog.

This week I will be working on integrating Havok Physics into our engine. Our previous engine used Newton Dynamics, of which I have previous experience with on other projects. I hadn’t used it in a while before the previous engine so I had to get reacquainted with the API. It hadn’t changed much on the outside, but how physical interactions and materials worked was completely new. In the end, I managed to wrap Newton in a logical and useful way.

Havok and Newton share many of the same concepts, but their implementations could not be more different. Newton is a C API, with discrete functions for handling all aspects of the system, while Havok is a C++/object oriented approach. The more I learn about Havok, the more I appreciate Newton for its relative simplicity. I’ve only scratched the surface of the iceberg that is Havok physics.

Integrating the Squirrel Scripting Language

I posted the following on the Card Kingdom development blog.

One of the new features that I wanted for the engine this go-around was the ability to script the entire engine. Previously, any change to the game, be it game play, adding a new component, or what have you, required a full recompile of the code base. This takes time and we are constantly discovering that time is the one thing in short supply. Scripting the entire game would mean that any changes, updates, fixes, etc. would only require a restart of the application. Testing time would be drastically reduced. Problems could be resolved quickly and efficiently with minimal time wasted. Smaller applications, such as a model viewer or an in-engine editor, can be quickly created and aid in the development of the actual game.