Building a UI with the help of WinForms

Twinspire, as you may already be aware, is being developed with the User Interface framework first. With this approach, we can build a framework that is built around a UI. Generally, when you make a video game, you are building within a canvas (2D or 3D). This canvas is typically custom drawn and requires you to program in event handling manually. By building a video game within an interface, event handling can be done automatically, which serves two benefits:

• You do not have to manage two separate event interfacing systems, which often complicates event handling or makes it harder to determine if the UI or the games' canvas is in focus.
• The UI does all the event handling, passing any events not interfacing with the UI to the game's canvas. This maintains the notion of two separate systems while keeping event handling streamlined.

Most game engine's built properly do this, as it is the most sane way to manage events. Unfortunately, not all game engines do, and often they leave it to the programmer to build the event handling yourself. And while handling these events are trivial and don't exactly require much effort to complete, the triviality of the task makes the extra effort mundane and an unnecessary waste of time.

Why do I say all of this? Because in Twinspire, while building the main UI toolkit, we have stumbled across a very mundane task. Similar to the triviality of event handling, user interfaces are also generally very trivial and don't require much effort. But it is time consuming, and putting together a user interface "framework", if you like, is typically met with frustration and the desire to put it off.

Twinspire is likely to offer a low-level user interface API, meaning that we offer the tools to build user interfaces with event handling managed automatically. Instead of offering components that are pre-defined to a series of parameters that may or may not help your use case, we build the toolset to allow you to build these components exactly how you need to.

We will still offer trivial components, like Buttons, Drop-downs, Check boxes, Radios, Progress Bars, and other basic components. But beyond this, we will not be offering complete out-of-the-box components as that's not the goal of this exercise. However, we will be providing the tools to help build user interfaces and components, such as our in-progress tool Twinspire Creator.

The idea behind this tool is actually to generate code, not be incorporated into the Twinspire UI framework in the way you would expect. So, whether you choose to use Twinspire in C#, ODIN or Haxe, all three options will be covered from this tool.

Twinspire UI, with it being low-level, is split up into several concepts.

• Layouts - The lowest level concept is Layouts, which is effectively the mandatory component for building user interfaces and/or areas for custom drawing. Layouts are easy to manage in code, but things start getting complicated fast when you start managing the other two concepts.
• Widgets - This is a high level concept which is designed to retain the state for a given layout. They are technically optional, but when you want to add things like text, you create a Widget in which to store that text.
• Styles - This is another high level concept. It allows you to create styles from which your layouts use to draw things (primarily rectangles at present).

All three are linear arrays, with the centre being Layouts. From Layout building, you create Styles that those layouts use and Widgets to store data used within that layout. Despite how generic these concepts are, they are simple to understand if not for the additional work required to build something useful. But it shouldn't have to be complicated.

However, understandably, the work involved programming everything together, only to build, debug and preview your results, inevitably leads you going back to your code to fix up any issues, often going through several iterations before something useful is built. We make mistakes all the time, but UI should be something fairly trivial to build. Most developers who develop user interfaces are not building for the purposes of the end-user, they are simply putting in the functionality.

And finally, we are ultimately at the purpose of Twinspire Creator. It generates all of the functionality for you. All you need to do is think about design, which is what user interfaces are for, not wasting trivial hours on mundane event handling.

When we look at some of the options shown in the above illustration, we notice an "Immediate Mode" option.  The idea behind this is to allow the generated code to represent a procedure returning a value determining the last event performed on the wrapping layout. It would also generate more of the code in line and work on indices directly, versus what would typically happen in a retained mode procedure.

Here are some differences:

While building the WinForms application does add time to the project, the aim is to reduce this significantly in the long-term. Twinspire Creator, alongside the ODIN version of Twinspire and updated for Haxe and C# will be released simultaneously, with the primary aim of helping people wishing to build desktop applications that are cross-platform, fully customisable and provide much more enjoyment than typical UI API's.