Yaëlle Chaudy, Thomas Connolly and Thomas Hainey
A Domain‐Specific Language (DSL) to be used as an assessment configuration descriptor.
A generalised assessment engine with algorithm and DSL parser.
A communication protocol between the GBL application and the engine.
5.1 A DSL for the assessment configuration file 5.1.1 What is a DSL and why use one? A DSL is a programming language defined for a specific purpose. It has its own semantic and syntactic rules. Using a DSL for the description of the game assessment would enable developers to quickly and easily define their assessment without having to implement it with a general‐purpose programming language (GPL). In their paper, Mernik, Heering and Sloane (2005) outline the key issues for the development of a DSL and present situations where introducing a DSL is beneficial. They highlight the difficulty of DSL development as it requires knowledge in both domain and programming languages. Out of the patterns discussed where DSL is successfully used, the most relevant to our study is “task automation”. This pattern presents the introduction of a DSL as a way to automating common and repetitive tasks. In the scope of this paper, defining a generalised assessment engine that would make the assessment process quicker and more effective, development of a DSL seems to be an advantageous option. It would embed the domain (assessment in GBL) knowledge into the programming language; expertise of assessment integration would be situated in the engine itself and no longer in the game. The GBL application developer would still have to define the game’s assessment but could do so in an easier and quicker way, using our DSL to write an assessment configuration file. 5.1.2 What model for the DSL? We are at the early stages of the specification and design of the DSL, the preliminary language we propose is based on the educational concepts presented in Section 2, the model in Section 4 and the systematic literature review published in a previous paper (Hainey et al., 2013). The feature diagram presented in Figure 2 exposes the semantics of the preliminary DSL, values in bold with a grey background are terminal names of the language. Further description of the various components follows, along with an example of the language in use. The DSL itself can be seen as a guideline to the assessment process. Its intention is to encourage the GBL application developers to include, in their games, details of the assessment they might have omitted if they were implementing it themselves. However, in order to make the DSL more usable, a number of the components of the language were made optional. They are indeed omitted in numerous GBL applications as shown in the analysis in Section 3.
Figure 2: Feature model of the DSL
110