To swap or not to swap game engines …
Posted by Rampant Coyote on August 18, 2014
I love Unity. I’m very, very happy about it. My art guys… well, maybe not so much, but I think it’s more of a matter of what they are used to.
But although this article isn’t favorable towards Unity (it’s not really unfavorable, either), it’s an outstanding discussion of the analysis and challenge of switching game engines – and a little bit of why they chose the Unreal 4 engine in the middle of development.
If I were in their shoes, I might make the same decision. And yeah, that’s me, Unity fanboy. The weird thing is, in two years, the analysis might come out completely differently. A year or two ago, it clearly *did* come out differently.
We live in a strange, new world. Engines have become a commodity within the reach of any indie. Grab ’em off the shelf at indie prices. They compete in price, features, platforms, intended audience, and style. This is a great thing for game developers at all levels. Okay, maybe for us programmers, who historically were on the front-line of awesome creating the technology (and also making us the bottlenecks), it drops our importance down a few pegs. You know what? I’m okay with that. I’ve been okay with games not being tech-driven for many years.
I made the painful and expensive decision to switch to Unity rather than the upgrade of the Torque engine for the sequel to Frayed Knights. This meant having to rewrite a ton of code, and learn a whole new way of doing things. That took time. But I don’t regret that decision, at all. And I’ve had to let a ton of sunk costs go (including about a year of work).
I’m still sticking with Unity for the foreseeable future. Unity 5 is promising some new new features to compete on several fronts, and I’m sure the leading competitors will offer some outstanding improvements to match. It’s a win / win for me.
Filed Under: Production - Comments: 4 Comments to Read
McTeddy said,
As a fellow unity-fanboy… don’t get your hopes up on any new promised features. Unity has a tendency to push back features like the freaking GUI time and time again. Even when they put something in… its not uncommon for it to be broken or unwieldy for a few releases.
Complaints aside though, I know a number of pure artists who are now making their own games with Unity. It’s amazing to have a tool that’s powerful enough for a programmer, yet simple enough for an artist.
It’s not perfect, but I am a fan.
Xian said,
If you are comfortable with what you are using I would say stick with it, unless their is a must-have feature in a new engine. You would also have to weigh that against rewriting things to support the new engine, and additional delays while you are learning it.
Wasn’t it a couple engine changes with Duke Nukem Whenever that delayed it to the point of being one of the longest running jokes in the Industry?
Anon said,
Switching engines can indeed be very problematic – another “bad” example is “Daikatana” which suffers more or less from the very same problems as Duke Nukem Forever does (too long in development -> expectations rise too much, graphics not good enough anymore, game design is antiquated…). Developers actually fled from the company when John Romero decided to switch…
On the other hand “Deus Ex” switched engines, too: From Quake2 to Unreal.
This also prolonged development but the end result was much better as Unreal better fit to the design goals – and the switch didn’t happen late in development but rather early.
Now Daikatana is largely forgotten and Deus Ex is one of the classic PC games of all times, spawned sequels, still very popular among fans and definitely the best game IonStorm ever produced.
(There’s an interesting tidbit about them using the Unreal Engine here:
http://en.wikipedia.org/wiki/Deus_Ex#Technology)
The main difference between Daikatana and Deus Ex was this, though: Megalomanical producer (with too much resources) vs. rational producer (who more or less exactly knows what he wants from the beginning)
Amir said,
Dunno how you code in Unity but I make most of the stuff fairly engine agnostic. I treat Unity as a level design tool for the artists and a decent multiplatform deployment solution. From a game-code perspective I think the only Unity code I have are calls for GetComponents() and StartCoroutine() (both of which are hidden behind an interface and can be replaced). The real Unity code tangle comes from writing the design GUIs.