The development of Vista 2 - aimed to be a standalone, cross engines, cross platforms terrain generator - has been going for a while. Up until today, we have a pretty neat user interface with dockable panels, bare bones graph editor and a serializer to transfer data between the runtime and the GUI client.
In this post, we will share an insight on how we managed to do that.
Creating the terrain generator UI from scratch?
No! Absolutely no. There are many libraries out there to choose from, why bother?
Picking a sweet GUI library
After searching, we choose Dear ImGUI library to build the user interface.
Dear ImGUI is a cross platforms UI library that is fast and flexible, packed with lots of controls and widgets. The single pass immediate GUI approach is somewhat similar to Unity's IMGUI. It's quite easy to get familiar with.
Our most favorite features is docking, that allows you to reposition a panel as you like, similar to how Visual Studio works.
Instead of calling to its API directly, we wrap it inside our own function, like this:
This way will bring more consistency in the code base, easier to create custom control and easier to switch to another GUI library, just in case.
Want to see how we make a float2/Vector2 field? Take a look
Making the graph editor
Once we have the dockable panels system established, it's time to deal with the graph editor so we can manipulate terrain graphs.
Yet again, we don't waste our time to write it from the ground up, but integrate the ImGui Node Editor extension to the project.
Currently it can handle basic graph editing action such as search/create node from blank space, or from an IO port, as well as deleting and positioning them.
Deal with serialization
Once a node was selected in the graph window, its properties should be displayed for modification in the Property window. We need a way to serialize node data, not as complex as Unity serializer, but simple enough to handle our graph. There're several way to serialize data, in binary, text or JSON format. For simplicity, we prefer JSON.
But unfortunately, C++ doesn't have a dedicated standard library for JSON, that's where the JSON for Modern C++ comes to the rescue. It is easy to use, support most primitive types and custom types. A downside is that its JSON items are sorted so the order in Property window was not what described in code.
One of our most important principles when developing Vista runtime is that only primitive types can pass beyond the DLL boundaries, custom types must be kept internally, otherwise it may crash on certain platforms (Unreal, Godot? Not sure, but maybe!). But this case, for serialization and properties modification, we have to make an exception that let JSON object to cross the line. It's safe for the JSON to go back and forth between Vista editor & runtime because they're built in the same Visual Studio solution, thus the same compiler.
Making a type serializable is easy with a single macro VISTA_MAKE_SERIALIZABLE
To inspect any serializable object, we provide some sort of "default editor" that scan the JSON items, check for their type and display the corresponding widgets. You can clearly see that the properties order are sorted alphabetically, which was not the order we declared in code. That's why an editor for specific type is needed.
Final words
Developing software is not always about making everything from zero. By using libraries from other dev fellows, you're saving lots of time and ton of effort, to focus on the main purpose of your app (remember to check the lib's copyright!)
Follow our blog posts to get latest news from the development process and useful tips to apply to your own projects.
Want to try Vista now? Take a look at the current version on the Asset Store: