Game Development Reference
In-Depth Information
Table 13-1.
Principles of Language Engineering
Principle
Description
Simplicity
An easy-to-learn language is easy to use.
Consistency
Choose a suitable design and hold [on] to it.
Flexibility
Give the user flexibility in how to formulate a DSP.
Homogeneity
Show related concepts in the same way and keep them together;
show unrelated concepts differently and separately.
Color
Use color sparsely.
Testing
Test the language design on language users.
For this example, you'll look at a fictional language creation process at Fictional Game Studio (FGS), following
the toolsmith and language engineer Tobey, working with a game designer called David to create a DSL for defining
weapons and their behavior. Tobey is new to the team and does not yet know how the internal processes at FGS work.
In a first iteration, David describes the requirements for the language as follows.
David: In our upcoming game, the player will use different kinds of weapons, each with its own abilities and
behavior. The goal is to have a simple language that allows us designers to describe the weapons and how to use them.
Based on these descriptions, we want to generate different things like a media list for the art department, statistics
about the weapons, and the necessary code files so that our game engine can work with the weapons.
Tobey: By “kinds of weapons,” do you mean that there will be different weapon classes you want to describe with
the language, like Sword and Axe, or do you mean to describe specific weapons like a sword called Slicer, for example?
David: Both! There will be what we call weapon types, like Sword, Dagger, or Axe, which determine distinct
abilities for a weapon, like range or how the weapon is handled. Then there will be concrete swords, like a Slicer or an
axe called Splitter, which are the actual weapons used by the player.
Tobey: So there is already a fixed set of weapon types?
David: We know that we want to include swords, daggers, and axes, but the language should allow us to define
new weapon types during development.
Tobey: This means we need a weapon type description language as well as a weapon description language. How
is a weapon type defined?
David: Every weapon type determines if it is a one-handed or a two-handed weapon. What's more, a weapon type
is either of short, medium, or long range, and either of slow, medium, or fast velocity.
Tobey: And what abilities do weapons have?
David: Every weapon has a unique name and a unique look. Naturally, a weapon has an attack attribute that
determines how much damage the weapon can do. There is also a durability attribute, which determines the
weapon's status.
Tobey: What does that mean exactly?
David: Over time, weapons get worse, and durability decreases. When durability becomes zero, the weapon
breaks and becomes worthless when used.
Tobey: So weapons get worse over time regardless of whether they are being used?
David: That's actually a good question! The durability was meant to decrease by stroke and a certain probability.
However, our game tells a story throughout several decades, so let me discuss this with my team before making a
decision.
While the domain expert, David, describes the intention for the language, Tobey needs to ask the right questions
to find and define the requirements of the domain at hand. As you can see with the durability property for weapons,
the process of defining the language requirements might be used as a tool to reconsider game design itself, although
this is not its primary focus, of course. Tobey and David are going to refine this first requirement talk after taking a look
at the second layer of the language engineering workflow, namely the reference artifacts.
