What’s in an Engine?
A little bit of background: when we charted our course for UQM2 and Pistol Shrimp, one of our guiding principles was “own what we make.” That had a lot of meanings, but it directly pointed to building our own technology, and leveraging other open-source technologies. Fred was passionate about making Simple, our tool for creating gameplay and netplay. Working together, Ken started creating tools to apply audiovisual layers on top.
We are well aware of a lot of game development technologies, having worked with them professionally or as tinkerers. Unity and Unreal are two of the most familiar proprietary packages, while GameMaker is another, accessible starting point. Simple actually ran within Unity at one time in the past, too!
We could have used any of those technologies, but we didn’t. A major reason was that it would take our ownership of what we made away. The other one is a general peril of any monolithic software package: you often spend more time working around its 100 unneeded features just to use the 10 needed ones. It might have saved us time – we truly don’t know – but it would have put our project at risk in other ways.
The recent events surrounding Unity are painful to hear about and must feel like shocks of cold water for other developers and players.
On Ownership
For better or worse, we’ve been through losing ownership many times before.
Having worked for larger companies in the past, we never really get to keep the work we’ve done. If we have a cool solution to a problem on one project, we may not be able to use it on the next. While the idea can live on in our head, the intellectual property and sweat output belongs to the company. Even technologies we license on a project may not be up to us, and the parent company (or owner of the technology) could decide we can no longer use it. We didn’t want to lose our ideas and technologies – no matter how good, bad, or otherwise – anymore.
The Ur-Quan masters is open source, and that also means no one can take it away. As long as someone is willing to port it, it can be made to run on anything. We like that. As long as Pistol Shrimp owns what we do, we can decide our own product’s destiny. We can make different platforms support it. We can release it freely. We can make sure it embodies what we want for it, even if that changes, just as UQM became open source many years after its original release.
UQM2’s needs were fairly modest, so we calculated it would be easier to build what we needed ourselves rather than buy into one of the behemoth engines. When Ken journeyed into retirement, Fred and I took stock of the remaining work. Our question was simple: without Ken, is it going to be faster to just finish in the direction we’re going, or is there another way to do this that will simplify and expedite our work? One way or another, we would have to pick up the remaining work somehow. We took a week to seriously research options, and we arrived at an answer. It was time to pivot.
Enter Godot
I (Dan) have watched and toyed with the open-source Godot engine with some interest for its relatively short lifespan. Frankly speaking, I like it, and I’ve even enjoyed a couple games that were made with it. At the end of July, I suggested to Fred that we give it a look as a potential candidate for how we would be handling our audiovisual needs.
After a week of building some proof-of-concepts, both Fred and I weren’t turned off. We might have too much experience to ever be really sold on anything, but we hadn’t found anything to terrify us, and we liked what we were able to do.
Within another week, our proof-of-concept quickly stopped being a proof-of-concept and became the answer. We had almost all of UQM2 running within Godot! Within less than a month, we had all of UQM2 functioning, as well as features we had planned but had not been able to do.
So why do we like it?
By working in a world that was more fleshed-out, we empower ourselves to not only do more work on our own, but also more readily bring in additional contributors. A few of our community members who had been working on our ProceduralPlanet toy, for example, have turned to work on a Godot implementation. That was made much simpler by having a more standardized framework for everyone to work and learn in instead of our bespoke solutions.
Godot leaves a lot to our imagination as far as how to answer tech questions. Unlike larger tools which try to provide a lot of easy answers (which are only easy if you promise to color inside the lines), it leaves a lot of implementation left to the end-user and the project. It’s “just enough engine”.
Permit me to wax philosophical for a moment. Video games – still a new idea, relatively speaking – are a marriage of technology and artwork, and the tools we use often inform the kind of art we can make. If the only tool the world had for 2d art was a pencil, we would have a lot of pencil drawings. What about paint, crayons, and inks? Massive, proprietary tools often optimize for their own solutions to problems like how a camera should work. Applying different solutions or trying to deviate becomes difficult. A ‘best practice’ becomes a solved problem, and then developers don’t have the opportunity to offer new, different ways to do it. Most importantly, tools represent the visions of creators, and we want them to be as individual and as varied as the people who use them. We celebrate the diversity of art through technology which gives people the ability to decide, for themselves, what tools, mediums, and ideas let them feel and be creative. Godot fits this spirit!
Not even last and certainly not least, Godot is available under the permissive MIT license. In the original spirit of UQM, we – and others – can build our own versions of Godot and guarantee it will be supported as long as we want. Any improvements we make to Godot or anything we build just for Godot is something we can also share outwardly as well. Simple running on Godot means there is a long future for not just UQM2, but games that haven’t even been imagined. The ProceduralPlanet toy that’s part of UQM2 is something we want to release for everyone and we hope will help someone else make their own game. Whatever we do, Pistol Shrimp and the world at large will never lose access to it or have the privileges of ownership revoked. We deeply feel that it touches the heart of our goal: “owning what we make”.
Last, for this blog post, anyway, is simply: shifting to Godot will help us finish UQM2. There’s almost no better reason than that, but, as outlined above, we hope you can appreciate our multifaceted thoughts as well.
What Did it Cost?
The short answer is: about a month. The longer answer is more nuanced. With a shift into some new technology, we had to pause, learn, and re-create some things. However, we had very few things we needed to actually re-create from scratch. Ken’s work on the game viewer already told us how we would be doing things, and it was just a matter of porting over some of those ideas. As people who work in technology may know, ideas are cheap, but proving that an idea works from front to back is the hard part. We already had done a lot of that, and going from our handmade game viewer to using Godot as a different game viewer was fairly straightforward.
There are lots of little details that are far too technical to write about here, but the other big aspect of our work is in the content. Not just code, but the actual game part a player will experience. Because so much gameplay had been built in Simple, we got to keep all of that. We had a few rendering tricks that were used in our own game viewer, but the actual content that makes a ship look like a ship had been made and just came along for the ride. Beyond that, because some of our solutions to certain things like UI were still just coming online with our current technology, we were able to build all new kinds of content we had been waiting to build until later.
While we spent about a month on the pivot, we also shot past where we were previously on other fronts during that time. We had to slow down certain aspects, but others became much faster. We started having entirely new questions about how we would do certain things because Godot enabled us to reach those milestones faster. It had given us a tool to solve so many old problems that we started uncovering new ones. That is a strong and exciting indicator of progress. We like that!
Lastly, as we touched on in the previous section, we are happy about what it didn’t cost. We’ll never have to worry about an onerous license or surprise fee that affects our future. We’ll never encounter an intractable problem because our technology is locked behind closed doors. And we’ll never have to worry about the game relying on anything that could disappear tomorrow and make it unplayable.
And We’re Off!
This would be an awfully silly blog post if we didn’t have any Godot to show you, but we’d actually like to take this opportunity to walk through everything on one of our development streams. We can show you things, you can ask questions, and we can learn what’s really exciting about these changes together. Games are built on a lot of imagination and “what could be”, and it will be much more fun to show and tell together. We’re much more interested in what you have to say than what we have to say!
Join us on Wednesday, September 27th at 11am PT at https://twitch.tv/pebby. In the meantime, feel free to join the discussion on Patreon, Discord, Twitter, or Reddit.
And thank you to everyone supporting us on Patreon for helping us continue to own what we make.
