February 27, 2005
Other applications for CDL
My main justification for CDL to this point has been as a tool to automatically generate a schema from an annotated C++ class definition, together with additional automatically generated C++ code to support the binding of objects to binary data cooked with the schema. As I see things, the only viable alternative (using C++ at least) is to automatically generate C++ code from a hand-written schema. See my previous post for more info.
Now I want to consider some of the other applications of CDL, which I don't think could be achieved, or could only be achieved with increased redundancy, through the code from schema approach. As I said before, I think serialization, specifically serialization of level data, is the most important application for a language like CDL. But there are other forms of serialization that are useful in game code and for tool / game interoperation.
Here are two examples. The first is allowing realtime editing of game data as the game is running, for example with a level editing tool connected to the game engine over a network. The second is supporting automatic synchronization of objects in network games. These are both related. They require that it be possible to access and change individual properties of an object after it has been instantiated.
With the CDL approach, realtime level data updates could be supported without extending the CDL language. It is a case of automatically generating the code needed to access and modify individual accessor functions and member variables in response to network messages. For synchronizing objects in a network game, it would be necessary to annotate the class definition with attributes indicating which properties should be synchronized and which should not.
With the C++ from schema code generation approach, I can't see a way of supporting this easily. The problem is the game objects are not directly described by the metadata in the schema. So there is no way to automatically generate code to access or modify individual properties of game objects after they have been instantiated.
Now I want to consider some of the other applications of CDL, which I don't think could be achieved, or could only be achieved with increased redundancy, through the code from schema approach. As I said before, I think serialization, specifically serialization of level data, is the most important application for a language like CDL. But there are other forms of serialization that are useful in game code and for tool / game interoperation.
Here are two examples. The first is allowing realtime editing of game data as the game is running, for example with a level editing tool connected to the game engine over a network. The second is supporting automatic synchronization of objects in network games. These are both related. They require that it be possible to access and change individual properties of an object after it has been instantiated.
With the CDL approach, realtime level data updates could be supported without extending the CDL language. It is a case of automatically generating the code needed to access and modify individual accessor functions and member variables in response to network messages. For synchronizing objects in a network game, it would be necessary to annotate the class definition with attributes indicating which properties should be synchronized and which should not.
With the C++ from schema code generation approach, I can't see a way of supporting this easily. The problem is the game objects are not directly described by the metadata in the schema. So there is no way to automatically generate code to access or modify individual properties of game objects after they have been instantiated.
# posted by Alastair Patrick : 6:52 PM
