The MVVM (Model-View-ViewModel) software pattern is a very powerful architecture that can benefit game tool development, particularly in the area of usability. MVVM separates the UI from the underlying data through a kind of interface class, the view model. The view model handles all the manipulation in the model (the data), and serves the data to the view (the UI) in a way that the view can understand. Because of the added view model layer, the view can be more easily written with the end-user in mind, instead of in a way that best fits the data.
You would think that adding this middle layer would complicate the development process for the programmer, leading to a longer development time, but in fact, it allows the interface for the tool and the complex interactions behind the tool to be developed in parallel by the most appropriate persons. Splitting the development process in two parts, between an engineer and a designer, allows the engineer to focus on the hard programming tasks while the design expert works out the hard usability and design tasks. The two come together within the glue of the view model. This takes the time-consuming task of iterating on the UI with the feedback of the end-users off the shoulders of the programmer, and puts it onto someone in a role closer to that of the end-users, themselves.
Facilitating this relationship between tool designer and software engineer requires development tools that can bring these two worlds together. Fortunately, the most common framework for developing MVVM-based applications, WPF, has the tools to do so. WPF is a .NET UI library and a replacement for the older WinForms library. It uses a a declarative language called XAML, which is based on XML. Because of its declarative nature, XAML can be easily created with a graphical editor such as Expression Blend, which is well suited to designers, and works almost seamlessly with Visual Studio.
MVVM allows programmers and designers to come together in a way that they never have before, allowing them to shorten development time and increase tool quality by putting each task into the hands of the person best suited to it. Leveraging this power will give game developers the ability to create better interfaces for editing game data, and improve the development process overall.
Chris Granger‘s Light Table was originally a concept video for a dynamic language IDE that extends concepts by Bret Victor about how to make the coding experience more focused and integrated with the final product.
My name is Richard Rabil, and I’m a recent student member of IGDA and a participant in the Writing and Tools SIGs. I’d like to invite you to take a short, anonymous survey I’m conducting on software tools for interactive storytelling.
Ultimately, my goal is to evaluate a set of authoring tools for interactive storytelling and develop a report that can help people determine which software tool is best suited to their situation. Data from the survey will help me better understand game writers’ or designers’ preferences, and assign weightings to my evaluation criteria. This project will also count toward my graduate research.
Although the survey is geared towards game writing, I think it will be important to get a wide variety of perspectives from people who work in the industry. So even if you’re not a game writer, your input will still be valuable since you will likely have fresh insights from other aspects of the game development process.
If you have any questions, let me know! I hope you’ll consider participating and help me spread the word. The more honest input I receive, the more I believe the report will benefit the gaming industry.
XML is the de facto standard for game data, at least for intermediate data. Just about every programming language commonly in use has robust libraries for reading, writing and manipulating XML data. There are also some interesting general purpose tools for XML that not many people know very well such as XSLT (which I’ve discussed previously) and XML schema.
XML schema is most often associated with error checking (AKA validation), and that is a very powerful feature of schema. XML schema acts as a data definition language for well-formed XML data, so, once your schema is defined, you can test your XML file against it, to make sure that thew data follows the definition. This is particularly useful in situations where the data is potentially hand edited (a big no-no), corruption of data can occur, or where the definition of the data is in flux.
In the case where data definition is changing while the data is being worked on (we’ve all been there), you could use a versioning scheme that included versioned schema files to automatically fix your data, removing data that was old, and adding new data with default values defined in the schema.
And that’s not all.
The second and possibly more interesting use for schema is to add metadata to types using the annotation field using the appinfo element. The appinfo can contain any well formed XML and can be read directly by your application. This can be useful in customizing your editor to display unique controls for each data element being edited. For instance, you might have something like this:
In our code, we’d read the appinfo and initialize the various controls for each property of the Unit type as defined above, that way, instead of just showing generic property editing controls, we can truly customize it to fit the data being edited. This is just a simple example, but you can easily come up with much more interesting (and hopefully useful) uses of the concept. You can find more detailed info on the W3Schools and MSDN websites.