An Unreal Transition

An Unreal Transition

Thanks to everybody reading this for being patient, as I've been pretty preoccupied for the last month. Work's been done on design and story during all this time, as we've felt that it was essential to pin down the formula for a good StarCaster adventure in order to proceed much with building gameplay, but we've been wanting to hold off on sharing updates about that until we feel there's something really concrete to show for the effort. In the meantime most of my programming horsepower has gone into Terrain of Magical Expertise, which is much more so my full-time project.

Funnily, my experiences on that project has led me to the newest development for this one. Namely, we're going with Unreal over Unity for StarCaster.

This is a decision I've weighed in a lot of different respects repeatedly over the last year as I've prepared to build our gameplay prototype. Eventually I landed on Unity out of an admission that I probably wouldn't use the full power of Unreal and for the fact that tools development would be easier, but as TOME has grown into a bigger and bigger project over a year of development a few things have stood out about Unity's scalability. Namely, it plays so poorly with version control software and loses information so often in the process of grabbing and pushing updates that managing a big project becomes like Sisyphus pushing a boulder up a hill. All it takes is for a few minor mistakes with meta files, which are bound to happen with less technically-inclined personnel. This isn't to say Unreal never experiences version control issues, but its in-editor integration is comparably more mature and it especially plays better with Git than Unity does.

Meanwhile a lot of tools and frameworks I've counted on have wound up having distinct holes in execution in ways that, while I've been able to work around them or fill them in myself for TOME, I don't deem them acceptable for StarCaster at all. Some of these are related to the above version control woes, with more ambitious frameworks often generating caches of files in the assets folder every time the game runs. Some of these are implementation choices that, while not especially problematic taken in the context of standalone Unity assets, don't make for an especially clean whole of a product when combined together. I feel like half of my time is managing race conditions in scene management or cutscene execution rather than building gameplay, while in Unreal these are concepts that're relatively on lockdown. In fact, the overall concepts of characters, player starts, scene initialization, and cutscenes are all significantly more developed, behave more consistently, and are less prone to race conditions.

I've also never been happy with Unity as an editor so much as Unity as a programming framework. Editing prefabs inside the level hierarchy is intuitive in a beginner-friendly kind of way, but it's also back-asswards and opens a lot of holes in the workflow. Having to edit UI inside the level hierarchy is especially back-asswards. C# is wonderful, but in the long run everything about GameObjects makes design needlessly clunky and prone to dumb mistakes as a result of a mis-click. Unreal's entity-component system leaves a lot to be desired, but at the same time the Blueprint editor makes the composition and construction of an object something a lot more stable and concrete. Meanwhile Unity has no solid equivalent of "level script" which makes implementation of scripted events -- an essential component for building this game -- somewhat awkward.

This is all to say little of the gigantic gulf between Unity and Unreal in terms of the technical art pipeline. Animation blueprints are significantly more flexible and easier to tune to the needs of this project than Mechanim graphs, which I've known for a long time. In the past I've almost gone with Unreal over just that specific issue. I told myself to man up and just figure out Mechanim, but even after that I've found some odd rendering issues with low-poly 3D models, whereby parts of the character just flat-out disappear.

All in all this has been a big question of "what am I willing to put up with/fix/build myself, and how much benefit is that actually giving me?" After about a year of building a different, "simpler" RPG in Unity and observing these kinds of issues compared with my past Unreal experiences, at the very least I feel like I'd benefit from giving myself a little bit of a break. There is something to be said, though, for the appeal of a more holistic toolset that's a little more specifically aimed at the kind of experience I'm wishing to build.

Fortunately I hadn't gotten that much done in the Unity prototype to begin with, and the same controls and animations I spent a solid several weeks rigging up have been easy to rebuild in Unreal in about ... a day. If there's a time to make this change and commit to it, it's right now, when I'm not really sacrificing anything doing it. I've got an uphill battle ahead with dialogue sequences, but I'm confident in my ability to adapt, even to Slate's goofy and obtuse syntax, and I've found that the cinematic sequencer tool handles a surprisingly huge proportion of what I'd need to build myself. Otherwise gameplay programming's gameplay programming, an Update event is an Update event, and nothing about my job changes that much.

Stay tuned in the coming weeks, and hopefully we'll start to see this pay off rather quickly. For the next update expect some information about design direction.

About Michael S Prinke

Mike Prinke is a video game technical designer with six years of experience, his past credits including 'Til Morning's Light, Adventure Time Puzzle Quest, Cryamore, and Terrain of Magical Expertise.

Comments