31 Mar 2015
March 2015 - Yì for Unreal

Okay, yes, I've now ported this game twice for different 1GAM projects, but it hasn't been a minor undertaking either time. The first time around, it was my first mobile game, and this time, in honor of this month's 1GAM theme of "Transform," it's my first serious attempt to really get on my feet in the overwhelmingly powerful and complex and awesome and infuriating and somewhat unstable and definitely free (for my purposes) Unreal Engine.

If you're interested in the game, I'd advise trying out the older but significantly more polished and enjoyable Unity version of Yì, but if you're interested in a moderately experienced Unity hobbyist's experiences in Unreal Engine, particularly in an attempt to create a blueprints-only conversion of an existing Unity game, then read on, brave visitor, about Yì for Unreal.

Drowning in Freedom

So, suddenly as of this past month, Unreal Engine is free (until you make significant revenue), and Unity has a new version and is free (unless you want team features and whatnot or make significant revenue). Getting a new version of Unity after doing most of my projects in Unity for over two years is good stuff, especially with all of the old professional-only features available to dirty casuals like me alongside all the new toys, but who can resist the temptation of full, free access to Unreal?

Time to settle in for a bit of reading, a long list of tutorial videos, and a whole lot of not knowing what I'm doing.


The basic gameplay of Yì remains the same as before - a simple game of moving tiles, with a short list of rules:

  1. Wooden tiles can be moved to any open space, so long as it is not adjacent to another tile of the same element, indicated by its colored stone.
  2. Elemental stone tiles cannot be moved.
  3. Grey lock tiles can be moved to any open space.
  4. A lock is satisfied if the elements on the lock match the elements of the tiles on those sides of the lock, and if a number is displayed on the lock, it must be adjacent to that number of tiles.
  5. If all locks on the board are satisfied, the puzzle is solved.

Nothing here as changed, and that's as designed - the goal was to try to duplicate what I already had, so I would just be focused on learning the engine and implementing rules I'd already designed and tested.

All The Blueprints

Once I decided on the project I would work on, I started two versions of it - one a C++ project, and one using Unreal's blueprints. Not surprisingly, getting up to speed with the Blueprints was the faster option, and recreating my game strictly using blueprints seemed like an interesting undertaking, so that's the way I went.

Sometimes, the blueprint version of a portion of the code was quite pleasingly elegant and straightforward, as in this function to check the element of the tile in a cell, if present:

Sometimes it was more complicated, but even then, I could get some relatively complex things done in just a blueprint, like this function that takes a string representation of a puzzle and creates the cells and tiles and initializes the puzzle state:

But, as expected, there were also times when I felt like I spent way more time fiddling around with repeated nodes and connectors than I would have spent just writing the code directly:

Perks of Moving Yì from Unity to Unreal

I'd dabbled in Unreal 3 a few years back, and the one thing I'd sorely missed was the material editor (although Shader Forge went a long way towards filling that need), so it was nice to be able to use that again. Setting up the various materials for everything was a breeze.

The big plus for me coming from Unity was the Viewport in the blueprint editor, shown at right, where I could assemble the various components (like the elemental stones and overlays on the locks) in a dedicated window. I'm looking forward to being able to implement things in code where it makes more sense to do it that way, then tie it all together in a blueprint using the viewport. Very nice.

Drawbacks of Moving Yì from Unity to Unreal

Every other little issue and complication I ran into pales in comparison to the fact that if you're expecting Unreal to be super-stable high-quality big-league software, you're in for a rough time. I know Unreal 4 is a major change from previous engines and a huge codebase, but it's now well into its release (this project was built against the latest stable release version at the time, 4.7.3) and the number of crashes I encountered regularly was honestly pretty surprising. Seemingly innocuous actions would sometimes lead to a hard crash out of nowhere, including (and most terrifyingly) just saving the project. I had a blueprint file get corrupted in one crash, and there's no coming back from that - it's a binary file, and if Unreal itself won't load it, I'm not aware of anywhere else to go from there, so it's rollback time.

I will say that of all the differences between Unity and Unreal, the one that surprised me the most is the apparent inability to disable an object in the editor without deleting it. This is a given in Unity, a checkbox in the UI for every object, and a major part of my workflow. Finding out that I wasn't just overlooking this, but that it was actually unavailable, was a shock, and seeing people ask about it on forums and have Unreal veterans react as if it's a weird request was doubly shocking. I'm still a little unsure how to proceed there for any future projects. Maybe it's a result of using Unity for years, but being able to selectively enable and disable objects seems like a basic engine feature to me. Totally baffling.

The Verdict

I went from close to zero knowledge of Unreal Engine 4 at the start of the month to producing a playable if unpolished version of one of my more complete and cohesive original games by the end of the month, so that's a victory for me. I didn't have time to add any of the normal niceties of a proper game, much less the various small details I included in the original version, so what I've ended up with is basically just a technical demo of something that allows you to play through the puzzles, but that means all of the meaningful logic in the game was implemented. If this were a full project, the only things remaining would be the kind of things that wouldn't rely on knowledge and proficiency with the engine itself, so I'm fine with that not fitting into the schedule. It's working, it's playable, and it's certainly pretty, so that sounds like a win to me.