Back in January, I had the pleasure to attend Jeff Ward’s talk “Data-Driven is Half the Battle” (slides) at the Game Forum Germany and— looking back now—it really was an important talk to me (thank you Jeff!). About one year before this talk, I left home to exchange my well-known domain (software-engineering research and consulting) with a job as a researcher and PhD candidate at a game-related university group. And I was more than willing to take this step! Ready to not explain other developers why cyclic dependencies suck, ready to not refactor degenerated legacy systems anymore, ready to not promote Model-Driven Software Development to managers who wouldn’t listen anyway… finally ready to do something completely new (come on, game development research, how cool’s that?). However, soon I had to learn that, at his heart, Mario will always be a plumber, no matter if he wears a Bee Suite or if he drives a kart, throwing bananas at his girlfriend. So I soon found myself mapping especially my MDSD expertise to the game development process. Although I saw enough potential for innovation in this, I was somewhat stuck in my research after this first year.
Since I suppose that not every one of you joined GFG back then, let me try to briefly outline Jeff’s talk now [I made some annotations, which are highlighted that way] (if you like, you can also watch it here… it’s a German Site and the video is somewhat hidden, in the “Mediathek”->2011->Scroll down til you find the talk). In Data-Driven Programming, the idea is to separate your data and your code, so that changing your data can change the behavior of your system (your game). That results in several benefits:
- fast iteration times (no need to recompile/link after changes)
- modularization (you can add and remove parts quickly)
- empower non-programmers
Jeff put some emphasis on this last point, and described that the underlying motivation is to allow other team members to do their work without programmer intervention, to eventually boost your productivity.
Thereby, data can be anything, but, regarding the mentioned separation of data and code so that system changes can be done on the “data-level”, data should represent the dynamic parts of your game, or, as Jeff just said: “whatever might need to be changed, either by other teams or by programmers actually”. [Here, I need to add a first annotation: In the given context of game development, “data” is somewhat too generic to me and it somewhat becomes an empty word. Maybe “content” might be a better choice, but I’m also not too happy with that one… anyway, in the end, it doesn’t really matter what we call it, as long as we know what’s behind it.]
Naturally, it is not enough to just expose your data; the degree of usefulness of Data-Driven Programming (DDP) comes with three decisions
- What data you expose
- How you expose it
- To whom you expose it
The first two questions are not that complex ([or are they?]). What about the third one? Common solutions to expose data are structured formats like XML or Json, or just Data or .INI files. But, and I want to support Jeff’s statement here very strong: human readable != human understandable != editable by anyone. In other words, although, e.g. XML, is human readable, people with less technical backgrounds than programmers have trouble understanding them, and it can be a huge pain for them to create and edit them. So, what we need to answer the third question and eventually do smart data-driven programming are the right tools.
These tools are supposed to be used by non-programmers to provide their domain-specific game data [or content]. At the same time, there must be a way that the provided data fits into the game, which means that there are two sites to consider when creating useful tools. For the front-end side, Jeff suggests that editors are (1) driven by game code, (2) easy to use and (3) don’t lose any data. For the back-end side, it is important that, whenever your system gets another property that should be driven by data via an editor, it should be very easy to adapt the editor to these new needs (‘cause programmers are lazy). Jeff’s recommendation is to strive for automation of this process and automate it using reflection. [I have to admit that the very last part here took me a while to understand, and I really hope I haven’t got this completely wrong!].
But wait… this post was not intended to just boil down and repeat Jeff’s findings?! No, I wanted to point out, why it was so helpful for me. So, what I’m going to do now is to confront DDP with Model-Driven Software Development (MDSD). I want to do this for several reasons. It’s not just that I think that there are many commonalities here, especially regarding the greater goals of both approaches, but also interesting differences which bear the potential to ultimately improve game development. And these thoughts, eventually, showed me that my research is probably not completely in vain.
MDSD is all about abstraction. Basically, you want to abstract something (a problem) from a concrete solution space so that you are able to describe it in its actual problem space (or domain). Note that abstraction is NOT EQUAL to generalization, where you summarize related concepts to a more general one. Abstraction is separation, a separation of concerns. I recognize this separation of concerns in the above description of separating data and code. The common greater goal in both cases is an empowerment of the domain experts by exposing data [or models or content ;)]. Hence, for the abstraction process in MDSD, the vocabulary and semantics of the dedicated expert group are key to find a formal description of the corresponding domain. That way, the resulting domain-specific languages are—by definition—not only readable and understandable by the domain experts, but they can also be tailored so that domain experts can use them autonomously. DSLs are also self-documenting.
Furthermore, in MDSD, just like in DDP, you need tools to do your work. Other than in DDP, the development of these tools is not driven by an underlying code base. However, when you do MDSD, you rarely end up with a system where it is useful to abstract everything away from your programming language. That means that you always have parts of your system that are modeled in your DSLs and parts that are modeled in a general purpose language (GPL). There are two ways how your DSL models can be processed. Either, they are transformed into another format (code generation, model transformation, or what not), or they are executed directly (interpretation)). I won’t deepen the topic of combining generated code and hand-written code, let me just say that many smart people had thought about this problem for some time now and they had come up with different solutions for different purposes. Hence, regarding Jeff’s tenant to make things easy whenever you want to enrich your editor: In MDSD, this basically means that you need to adapt your model (the domain expert needs to be able to address this new behavior), and you need to adapt your processing rules (genrtor, transformer, interpreter). This might let MDSD look more like a heavy-weight approach in the first place, but it isn’t. Naturally, it would be great if we could always find the perfect domain description when creating a language, but that is seldom the case. The requirements of systems are agile and so have to be the tools we use to develop the systems. Therefore, there are very powerful language workbenches and modeling frameworks that make life easy here (I’m familiar with the ones on the eclipse side, mainly EMF and Xtext, but there are others, like MPS, and Microsoft did some efforts, too, with Oslo and M, but I’m not up to date with them). For example, the language workbench Xtext provides a powerful default editor for your language definition, featuring code completion, syntax highlighting, code outline, and syntax error highlighting, out of the box. Naturally, you can add additional funcitonality as you like. Now, without getting lost in technical details, let’s finish my first post.
I do not claim that MDSD is the answer to the problems of game development, or that we should replace DDP with MDSD. But I think that at least one of the major questions in DDP (how to expose the data in a way domain experts can work with it?) could be answered by the things we know from defining DSLs for MDSD. And there is even more potential for DSLs. When this topic is of any interest, I can provide some more concrete examples how to define DSLs using Xtext/EMF in my upcoming posts. So, I’m very curious what you think about this. Especially, in case I got something totally wrong in the data-driven part!
Best,
Robert