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.
The interface is defined as the following:
class ISerializable {
public:
ISerializable() {};
virtual ~ISerializable() {};
virtual void serialize( ISerializedOutput* const out ) = 0;
virtual void deserialize( ISerializedInput* const in ) = 0;
};
The two methods serialize() and deserialize() are used for writing out and reading in data for objects. The interfaces for ISerializedOutput and ISerializedInput have methods for writing and reading strings, primitives, and other ISerializable objects, respectfully. These interfaces also have generic ways of marking blocks of data, so a collection of common variables can be grouped together. Since these interfaces are generic, how the data is written or read doesn’t matter. A binary, flat-file, XML, networked, etc. format can be used with no serialization code changes. Another side effect of serialization is that if we wanted to have, say, and in-engine editor, transitioning from “edit mode” to “game mode” would be as simple as “serialize” and then “deserialize”.
For audio in our engine, we are using FMOD. FMOD was used in the previous version of the engine and is a simple and powerful API. Different sound formats can be loaded and played in a straightforward manner. The old engine for 2D didn’t take advantage of FMOD’s positional sounds and was basically playing sounds in mono. This version of the engine has positional sound enabled. The two main components to make this function are the AudioEmitterComponent and the AudioListenerComponent. These components can be attached to an object and use the object’s position as the sounds position for the emitter or the listeners position for the listener. So, for example, an object that moves from left to right, across the listener, the sound will play out of the left speaker, fade to the center, and then to the right.
Audio is actually a really simple system with the use of FMOD. Those two components are all you need. The emitter component has support for both positional and non-positional sounds and can play any sound that is passed. The listener needs to be attached with the camera so the audio matches the visuals, but that’s about it. The hardest part of audio is actually the audio assets themselves. Having a sound that does not match what the user sees detracts from the experience of the game and can break immersion really quickly. Serialization is an on-going process. New objects that need to be serialized have to have the serialization code implemented and registered as a serializable object in the system. For now, we are using XML as our main serialization medium. It provides a logical, human readable format we can play with. A binary format would be preferable as the final release format as it provides the best loading speeds.