Choosing a framework for tool development
One of the first decisions to make when thinking about building a toolset is what framework you are going to use. Since there are quite a few options out there it can be a pretty hard decision as to what framework you’d want to go for. Every framework comes with its pros and cons. When I was deciding which framework to use I selected the following candidates:
- ATF: On paper, this framework looks perfect for our needs. It’s build upon WinForms C# and is built specifically for developing game development tools. Besides this, it’s documentation seems to very extensive.
- QT: QT is a C library for creating UI applications. A lot of good apps have been created using QT which proves it capabilities. Another big plus is of course that it’s written in C , a language I’m familiar with and gives a lot of low level control and speed.
- WPF: WPF (Windows Presentation Foundation) is the successor of WinForms and, like WinForms, it’s build upon the .NET framework and written in C#. It also uses xaml as a mark-up language and was built to have better performance than WinForms.
My goal was to get an external renderer working in all frameworks and see which one was the easiest to implement.
One thing I soon discovered when working with ATF is that it’s no longer as well maintained as it used to be. In the first place, it’s no longer being developed by Sony WWS. Secondly, the open forums are deserted with the most recent post originating from 2015. This wouldn’t be a problem if the framework itself wasn’t hard to learn. But as it turns out, it has a very steep learning curve. These things combined made it hard to get anything working properly. And besides this, there are a few other quirks that make this framework worse than when I initially heard about it. Here are a few of the other things that hindered my development:
- It’s based on WinForms, but how the use WinForms is unclear.
- It has a lot of third party dependencies (13 in total if you choose to use all available modules).
- The samples are unclear as to what they do and how systems talk to each other.
|Mature codebase||It has a very steep learning curve|
|It’s very flexible (MEF based)||It’s no longer under active development|
|It comes with a lot of basic features||It’s no longer supported by sony|
|ports both WPF and (WinForms although it’s main focus is WinForms)||It can be hard to debug if you are new to the system because of all the abstraction layers|
|A lot of third party dependencies|
|Written in C# thus interoperation code will be required|
QT is a very large library with lots of functionality. It also took me considerably less effort to get my test working (approximately 4 hours). The interface looks well developed and understandable and the result is pretty good. The main downside however lies with one of its strengths. Because it’s such a vast library it can be quite hard to find the right class/system for the job. It might also be too large for what I need.
|Written in C||Not tailored to game development specifically|
|Under active development/well maintained||Because it’s such a big library it can be hard to find the right information|
|Lots and lots of functionality|
WPF is as bare bones as it gets. It only has a minimal amount of controls to start off with but the most important things are there. It’s also relatively easy to create your own controls/systems to suit your needs. It took me approximately 3 hours to get my sample working using WPF which was a pleasant surprise. WPF is written in C#, giving you a bit more control over directory operations which is nice when creating an editor.
|Its newer than WinForms||Almost everything has to be built from scratch|
|Clear distinction between mark-up and behaviour||Written in C# thus interoperation code will be required|
|Easy to create new controls||Not yet many third party controls available|
|Lots of controllability|
|Build around data binding|
Looking back at the pros and cons of all three frameworks it becomes clear that there are 2 main contenders, namely QT and WPF. On one hand QT is built in C which is fast. QT also has lots of out of the box functionality. WPF on the other hand offers lots of control and an easy to understand interface. In the end, I decided to go with WPF since I have the time to develop the tools and the controllability is really tempting. Choosing for WPF will also keep my dependencies to a minimum (at the cost of some overhead that comes with C# and the .NET framework). One downside is the requirement of writing an interoperation layer. But since we decided that the editor will be a separate process from the engine this would also be required with a C application (albeit slightly less work).