It has been one month since my previous post, since then some major design changes have been made, but I won’t go into details about what changed, but about what has been added.
First of all, like I stated on my previous post I’m using WPF to build my editor’s UI and using MVVM pattern to bind data between the UI and data models, it’s amazing how both WPF and the MVVM pattern fuse together really well to create a UI without much complexity.
During my WPF studies a lot of people, from both Stack Overflow and Code Project, kept saying exactly what I think at the moment about these working methodologies “the learning curve is big, but once you get along with it you will love it”, and it’s true indeed , XAML at first sight is very intimidating, not many people enjoy looking at XML, and understanding all the magic that goes behind data binding and how we can use it for complex requirements is not easy, but once we understand how to surpass these difficulties we can create a good looking and functional UI really fast, and with a very short and readable code, where all the responsibilities are well divided.
Need to add an additional field to your List Box? No problem, just add another line in XAML and the field will be there.
Need to synchronize this field with some text from a model? Simple, just have a model’s property bound to this field and allow it to perform notification when it’s changed.
And so on. This idea is so good that I even added something like this to my own work… but one thing at a time.
In my previous post I didn’t show any illustrative images from my work, that was one of the first critics from my friends, so before publishing this post I committed myself to tidy the UI so people can at least take a look at my, unfinished, work.
This image represents the editor once it’s open, I added some numbers in the image so I can describe them, at the moment these are the most important components of the editor.
1) The toolbar contains useful icons that perform different actions in my application, like saving its current state, revert the changes made, open other windows to work with other available tools, etc.
2) The content tree contains the different entities that take role in my game engine and help fill the world. In the above image only two groups are represented (sorry for the names, but sometimes when I’m creating stuff for testing I just randomly press my keyboard to give something a name): Scenes and Actors.
The idea behind it is that Scene’s are the levels of the game that can be populated with different assets, while Actors are part of the assets that populate the world, and are loaded from assemblies that contains a game project data, this way it’s possible to create an assembly containing as many actors as needed, and as long as they derive from BaseActor and are located in the right folder the development kit will be able to load it for design purposes.
3) The scene viewer represents the scene loaded from the content tree, it’s possible to interact with the scene viewer in order to modify our level the way we desire to build our own game levels.
4) The property editor (at the moment it’s not complete, so it just contains demo properties in the image) is used to change properties of a selected asset in the scene, just like it would be possible to do in, for example, Visual Studio’s WPF UI editor, this is helpful to reuse assets, since the idea is not to create a new one everyone we want to have a similar asset in our game, but to simply change one of its properties in design time, avoiding creating additional code on the game assemblies.
The following image is an example of how to add scenes to the editor allowing the designer to create as many levels as he wants:
To add assets to our scene the designer simply needs to select the desired scene to work on and drag and drop the asset from the content tree, by selecting one of the scenes and dropping the asset name “Actor” the result should look like this:
As you can see the tool bar changed according to how it was done, after adding the Actor the back arrow icon became enabled allowing us to perform the inverse action, which in this case would be remove the actor from the scene, and the transformation widgets icons become enabled too.
After selecting the actor with my mouse the result is that the translation widget becomes selected (this is the behaviour by default) and the widget showed in the scene, after dragging the blue arrow down, selecting the rotation widget icon and dragging over the rotation widget that showed up on the scene the result should be like in the following image:
The transformation widgets are part of the recently added in game UI layer, in my current architecture each Scene contains a GUI Manager object that will react to user generated events, like a mouse click or a button press and will be in charge to propagate the event to a UI widget.
This UI layer is not part of WPF, it’s a library that I’m writing according to my needs, both in terms of the editor and of the game built from it. My motivations to build an in game UI for the scene editor were to understand how UI systems work at a low level and to be able to build a library for two purposes in parallel, editor purposes and game purposes.
Like I said in the beginning of the post I’ve added data binding to my engine, the idea of having UI elements attached to model objects is pretty good, and really came in handy when making changes in the scene using the scene widgets, here’s an example of code on how to, currently, bind a UI widget to an in game object:
The first step as to create a model (TransformActorViewModel) sensible to property changes and then create a Binding Engine, passing the rotate widget reference (_rotateWidg) and the model as constructor parameters, and then using the bind method expressions are passed as parameters binding the properties.