Facilitating language-oriented game development by the help of language workbenches

Abstract

In recent years, a strong tendency towards language-oriented engineering became visible within game development projects. This approach is typically based on data-driven game engines and scripting languages resp. editing tools alike and already provided a great deal of overall productivity improvements. However, in its current form, potential benefits are not able to fully unfold yet. This is due to a mostly manual tool development process, which provokes substantial costs and lacks flexibility -especially during prototyping phases of development. Language workbenches seem to be a viable solution to this problem as they promise the ability of (visual) language (re-)generation by introducing a meta-level of development. This paper picks up that idea and evaluates its application in the area of game development. In this particular case, we discuss first findings of an ongoing case study, covering the development of level editors for several classic games, which have been built by the help of a language workbench.

Model-driven Game Development

“…Two approaches define extremely narrow target domains: a single game or a game family consisted of a couple of very similar games. < [44] > presents MDD for Pac-Man like games, which follows a "one game at a time" principle: For a particular game or game family, a complete MDD tool-set is created, which is optimized for the development of the project and can hardly be reused without significant modifications in other projects. Creating DSLs and tools for one game may be economically unfeasible, so the language workbench is promoted as the core for the approach, which can significantly save the cost of MDGD tooling.…”

RAIL: A Domain-Specific Language for Generating NPC Behaviors in Action/Adventure Game

“…Since RAIL was designed only for modeling high-level AI of Action/Adventure games, it targets a narrower domain and lies on a higher abstraction level than Torque 2D APIs. An abstraction layer must be implemented on top of the Torque 2D APIs to promote Torque 2D to a suitable domain framework [8].…”

“…Some approaches further narrow down the scope to a game family or even a single game project, e.g. [7,8]. Our DSL presented in this paper also targets specifically the Action/Adventure game genre.…”

Ontology-Based Domain Analysis for Model Driven Pervasive Game Development

“…[42,43] ( [44,45]); B: [46] ( [47,48]); C: [49,50]; D: [17]; E: [51]; F: [13]; G: [15]; H: [52]; I: [53]; J: [54] The review revealed that no paper claimed to have used any formal DA methodology. Many of the papers proposed DSL concepts directly such as E, F, G, H, and I [13,15,[51][52][53], while some other papers identified several dimensions which contained the DSL concepts. For instance, in D [17], two dimensions (visible structure and gameplay related entities) were identified.…”