DSM for building adventure games
SharpLudus is a domain-specific modeling environment that generates working 2D graphical adventures. It's Andre Furtado's Master's thesis project, so his draft thesis provides some good documentation of the project. There's also a video on the download page. The bulk of it is very repetitive, defining interactions at a low level: "when character John is at x=400 and y=200, exit the room". I suggest you watch with Windows Media Player, or something else that lets you view it at 5x speed :-).
Microsoft's DSL tools were used to built part of it: a small modeling language with just two object types and one relationship type. The objects represent rooms in the adventure, and the relationships how to move between them. From what I've seen so far, the modeling part covers only a small part of the application, with most work being done in normal lists and dialogs where you can define the characters, items and interactions in the game. Why not have those elements be first class concepts in the modeling language?
This makes an interesting case in point for the ongoing discussion of what a tool for building DSM languages should offer. Microsoft think low-level integration with their VisualStudio IDE is a must, whereas we think freedom from any specific IDE is important. MetaEdit+ works on all of today's major platforms, with whatever IDE you choose. Using its API you can integrate it with that IDE, on the level of models and model elements -- but not down to the level of programming individual mouse click and move events, which Microsoft allow. The fascinating thing here is it looks like Andre hasn't used the low-level possibilities -- I'd guess they were just too much work.
The SharpLudus code seems not to be available for download yet, but so far it looks like the DSM part integrates only on the level of models and model elements. The rest of SharpLudus consists of a graphical editor for drawing the layout of rooms (non-DSM), and standard list widgets for items, characters and interactions. I presume these have just been programmed by hand, and there seems little connection to the graphical DSM models. From a model element you can open the room editor or the list widgets, but changing information in them doesn't change what the model shows. Lots of the lists are just filled with file names for the sound and graphics files (sprites and "tiles" for building rooms), which are presumably made in external editors.
Oddly, it looks like the list structures are included in the DSL Tools metamodel, which means that over 90% of the elements there are not part of the graphical models. That makes for an awful lot of hand-coded stuff that is strongly coupled to the metamodel: changing one means you have to remember to change the other by hand. I'd have either put the elements in the modeling language, or else removed them from the metamodel so they could be entirely hand-coded. Given that the metamodel takes 5 pages to display, because of Microsoft's questionable decision to force it into a tree format, making it smaller might be a good idea :-).
Of course, doing it the way Andre did does mean that the whole thing bar the room editor could be made in MetaEdit+, without any hand-coding. Maybe I should do that, and ask him how long it took to build those parts in the MS DSL Tools! He could keep the graphical editor in VisualStudio, and we could integrate that with the MetaEdit+ models using the API.
Comments
Re: SharpLudus
[Andre Furtado] June 27, 2006 08:04:01 +0300 (EEST)
Hello Steven. Thanks for your post and feedback. Please let me try to clarify some points.
> [...] the modeling part covers only a small part of the application,
> with most work being done in normal lists and dialogs where you can
> define the characters, items and interactions in the game. Why not
> have those elements be first class concepts in the modeling language?
Actually, those elements are first class concepts in the DSL. But for usability purposes, I have decided that in the chosen domain some of the concepts would be better collected from the user by dialogs, not by models, because of their nature. It would be possible to add a visual representation for the "main character" modeling concept, for example, but I can't see how such a representation would be useful to the game designer. BTW, that's one thing that I've enjoyed in Microsoft DSL Tools: you specify the concepts of your DSL and the visual representation of *some* of those concepts, and then are able to use the framework to link them together later.
> The fascinating thing here is it looks like Andre
> hasn't used the low-level possibilities
> I'd guess they were just too much work.
If I understood "low-level possibilities" correctly (programmatically interacting with the DSL Tools API and the IDE), I'm afraid those "possibilities" were used a lot. For example, they made it possible to manipulate concepts of my visual DSL after user input was received from the dialogs.
> Oddly, it looks like the list structures are included
> in the DSL Tools metamodel, which means that over 90%
> of the elements there are not part of the graphical models.
I believe that it was just the case that some elements would not fit well in a modeling environment, i.e., their graphical representation would not make much sense and would be counter-intuitive.
> I'd have either put the elements in the modeling language, [...]
Then I believe the application would not present a good usability...
> [...] or else removed them from the metamodel
> so they could be entirely hand-coded.
Then I believe I'd have a hard time making the code generator to mach the "modeling concepts" with the "hand-coded non-modeling concepts". I do not like the idea of splitting the domain into "modeling concepts" and "non-modeling concepts". What I have specified is a domain-specific language which covers a given domain, in spite of what can be visually modeled or not. Some of the concepts can be represented visually, and some cannot (or should not).
> Of course, doing it the way Andre did does mean that
> the whole thing bar the room editor could be made in MetaEdit+,
> without any hand-coding.
I'd argue it is possible indeed, but once more I call for usability. I don't think this question is related to MetaEdit+ vs. DSL Tools, but to project design decisions.
> Maybe I should do that, and ask him how long it took
> to build those parts in the MS DSL Tools! He could keep
> the graphical editor in VisualStudio, and we could
> integrate that with the MetaEdit+ models using the API.
That would be an interesting experience! Unfortunately I did not take exact measurements of the man/hour effort during my thesis development, but I believe it took half an year to assimilate the theory and specify the project, implement the solution and to write/review the thesis.
Thanks once more, Steven, for your feedback and for the opportunity to discuss the SharpLudus project!
Regards,
-- AFurtado