Aside from bugfixes and small additions for Alpine Lakes, there is a new primary focus. As promised in the last few blog posts, the time has come to start talking about what comes next.
So… Fun fact:
Over the past year, a branch of World Machine has been quietly in progress. That progress is accelerating rapidly now that Alpine Lakes is out.
To modernize World Machine and migrate from its original GUI platform.
I would forgive any new user of WM for thinking that that the sometimes difficult current UI is because I simply don’t care. This is far from the truth! But we’ve been struggling with a legacy framework that made the easy, hard… and the hard, impractical.
Before we talk about where things are going, let’s look at why they are the way they are.
In the Beginning…
Unless you’ve been around for a while, you may not know how World Machine began – as a side project many moons ago to explore my interests in CG, geology, and proceduralism. The very first version was shared with the world (…or at least a few Terragen mailing list users…) in 2002! World Machine grew steadily and surpassed my dreams to become a fantastic tool, a mission, and a business.
Here’s what it looked like at the start:
The GUI for that very first version was built on a platform called MFC. It was one of the very few choices available for a C++ project at the time. And every version since has grown on that same framework. Even at the start, MFC was already somewhat antiquated technology that was cumbersome and frustrating to work with. Fast forward to 2019, and it represents a critical limitation on what we can do.
The part where Stephen rants about MFC
It would frankly be quite difficult to overstate the ways that the old framework has blocked or slowed progress. MFC is a very thin wrapper around Window’s oldest C-based API. Common affordances that developers are used to having these days simply don’t exist. Combined with a long development history, the result is an uneven user interface. Things work one way in one place and then differently in another. Fundamental actions are more cumbersome than they need to be. There was a recent prescient post by mattnava on the forums about this subject. They offer a number of suggestions, and I had to be very circumspect at the time in my answer.
Let’s actually dig into an example here of how the framework shaped things. Take the Advanced Perlin dialog from the current version of World Machine:
Setting aside all else, I’m going to pick on just one obvious flaw in this dialog. Why can’t you directly input numeric values into the text boxes? This is certainly a valuable thing for the user.
The answer is that this dialog is completely bespoke, laboriously crafted out of raw elements. There are several thousand lines of boilerplate code just populating, converting, and updating values in the various bits of the dialog. This is more code by a fair margin than the actual device’s functionality! And it’s not nice clean code either. Due to the legacy framework, most of it is baroque and obscure:
Allowing input from the text boxes (with the resulting need for validation of each parameter, etc) would double the amount of code like the above required for the device. In the cost-benefit analysis, having them read-only was good-enough… the time and effort better spent elsewhere. And so, you can’t directly enter values.
If your response to the above was “That’s crazy.. you should be able to just have World Machine handle the device parameters rather than custom crafting a dialog for every device”… you’d be very right! That exact thing happened about halfway through WM’s history, and all of the more recent devices use the generic parameter system. However… for a host of similar reasons the generic system is not very expressive, and produces homely dialogs that can be described simply as “functional”.
A deal with the devil
Here’s the worst part: All that trouble above combines with new UI-requiring features to create a devil’s bargain: You get to pay now AND pay later. Create the feature with unusual labor in the current framework, all the while knowing that the work will be thrown out when the inevitable migration does occur. This has had a profoundly chilling effect on UI improvements.
And so it’s been clear for years that the platform migration, sooner or later, must happen.
On the other hand…
Rewrites and migrations can be slow, dangerous affairs. Changing GUI platform is a lot of work, and in of itself doesn’t deliver value. Respected developer Joel Spolsky famously blogged about the perils of rewriting your product. Yet we have very compelling reason to believe (and have already experienced!) that there are a lot of low lying fruit to pick that were prohibited by the old framework.
And so we’re best served by keeping things simple initially. The sky will eventually be the limit! But fancy new workflows are for later.
The goals for the next release of World Machine are:
- Keep the overall way you work with World Machine essentially similar.
- Bring in as many easy UI/UX wins as possible.
- Deliver as soon as reasonable, given 1 & 2.
The branch under construction we’ve been internally calling ‘LTE’ for Long Term Evolution (yes, I borrowed the acronym from your mobile phone). Our new framework is a conscious choice that provides immediate value and also paves the way for a long and exciting future. Including, eventually, more platforms than just Windows.
In Part 2 of this article, I’ll talk about where we’re going. We’ll cover the decisions made for the new framework, what long-awaited features have already been unlocked by the switch, and I believe I can provide a first sneak peek of the new version in action.
Progress has been exceeding my expectations, and with the cat is out of the bag, I’m looking forward to sharing dev milestones and features as they happen and get your feedback.
See you next time 🙂
“It is not the end. It is not even the beginning of the end.-Winston Churchill
But it is, perhaps, the end of the beginning.”