Game Development Reference
In-Depth Information
Figure 19.8.
Model translation: Once the game model is created, it can be translated
into source code for different underlying platforms.
19.2 Reducing Effort
Up to this point, we have presented the concepts we abstracted during the devel-
opment of Eberos GML2D, which we found common in the 2D game domain. By
doing this, we have taken would-be repetitive work and encapsulated it into simple
language constructs. In implementation terms, we have taken what would have
been repetitive code and reduced it to a simple operation. Also, by developing
a language, we are now constrained by the language semantics and have reduced
the number of errors that can be made during the development of these repetitive
tasks. However, before we can profit from our language, we must first develop the
means to translate it into implementation artifacts, such as source code or any
otherartifactspecifictothedesiredtechnology(see
Figure19.8
)
.
The final step before we can enjoy our saving of effort is to develop a translator
for the language. This last step, however, does require some platform knowledge
by the translators. That is, the translator must know what is the equivalent of the
language on the target platform or engine. In our specific case, we have implemented
translators for Microsoft's XNA and SDL, so our language constructs translate to
either a set of classes or a set of function calls specific to the libraries.
In the case of our implementation, this abstraction meant reduction in the
amount of code that was needed for items like state machine, animations, and
game logic (see
Figure 19.9
)
, and an overall reduction of as much as 86.4% in the
entire game code. Before Eberos GML2D, programming a state machine meant
we would copy and paste most of the architecture code for each state class and
