Custom level editor for Polars in UE4
Hi again, we’re back with out next update! Our level editor has just reached a state, which I can share with you without bad feelings. This post will be solely about it, we’ll detail our gameplay progression in the next diary entry.
Polars is a work-in-progress magnet-based puzzle game using Unreal Engine. This series is meant to keep you updated on our development process. We’ll try our best to keep this interesting for both those who are merely interested in our overall progress, as well as those who are curious about the technical challenges we face along the way.
Building methodology
To have a clearer understanding about our editor, it’s important to know how our levels are constructed. To make it as reusable and easy-to-build as possible, we build up everything from modular elements and objects. We have a surface (wall, floor, ceiling) building mechanism and a number of configurable objects to be placed. For example, a force field has a polarity and a scale property, while a conveyor belt has a single 3D gizmo to mark its end location.
Reasons for a custom editor
But why work on an editor in the first place if Unreal Engine already has a built-in one, which will always be smarter than anything we’ll be able to develop on our own? Well, it has multiple reasons.
First, I wanted level builders to be able to focus on what’s important. There’s only a handful amount of objects a level is built of, and there’s a limited number of relevant properties to set up. For scaling, should I set the scale, the box extent, or use location marker gizmos? Similar questions come together with the engine’s super bloated property panel, which has billions of editable attributes, without any indication which is relevant, and which is only a 5-level inherited property only set up by internal code.
Secondly, I wasn’t sure if I’ll have enough game developers to build interesting levels, why couldn’t someone talented in a totally different profession build a few levels for us? Of course in this case we can’t expect them to download tens of gigabytes for UE4 and learn its functionality, out of which, once again, most of the features are not relevant.
And lastly, I wanted regular players to be able to create and share their own creations, either in Steam Workshop, or any other system that we’ll use. It might not only help the economy of the game by keeping it alive after release, but also to increase the value of the game for newcomers.
Usage example
So how does it actually work currently? Probably it’ll make much more sense to show you instead of trying to explain:
Implementation
Technically, there are no huge innovations here. However, we’ll detail some not-necessarily-trivial solutions for the ones who are interested in some technical details.
Placables
At the core of both the game and the editor there are some classes, which contain most of the reusable functionality. Our most generic base class is Placable, which is the basis for everything that can be placed on the levels, including walls, buttons, magnets, everything. It specifies a number of virtual functions to be overridden by the actual objects, so that the objects can decide how can they be serialized or cloned, instead of a monolithic editor class with hundreds of cases.
For saving levels made in the editor, we had to employ a different path than the original SaveGame objects. Naturally, we wanted the game’s core levels to be packaged with the game, however, UE’s built-in solution does not support saving to and loading from custom locations out of the box. Even though we could have gone around it, it didn’t seem like a proper solution, so at the end we have used simple byte array streams to (un)serialize our objects, which were loaded and saved with FFileHelper.
Since saving the basic attributes of Placable actors is handled globally (class and actor transform), saving a specific object is as easy as it looks on the example above! We have created the stream classes simply by exposing the memory reader and memory writer C++ classes to Blueprints, and we have even submitted it as a small plugin to Unreal Marketplace in case anyone is looking for a similar functionality.
Gizmo
Maybe the most challenging step was making the object moving gizmo work smoothly as you’d expect in other editors. Naturally, it’s much simpler than the ones in game engines or modelling tools, but it does the minimum you’d expect it to. The logic is something like this:
- The user clicks on a gizmo arrow.
- We virtually draw a perpendicular plane on the axis of the arrow. It can be done 2 ways in a 3 dimensional coordinate system, for example for the X axis, we can either make the plane face the Y or the Z axes. We’ll choose the one, which has a smaller angle with the location of the player’s camera.
- We store the location where the cursor intersects this plane.
- In each frame, we check where does the current mouse location intersect the plane.
- We calculate the difference with the previously stored location.
- We translate the object the gizmo is linked to with this difference.
- We store the new location.
Future plans
Of course there are endless things to improve, but the scope for the editor will remain limited. For the next quality-of-life features I’d like to:
- Mark somehow the axes, so that scaling and rotating will be able to indicate which axis the object will be transformed on, instead of the current trial-and-error method
- Show the name of the current level being edited
- Break down the object picker to categories
- Validate the level name
- Make default levels unsavable (as it’ll fail anyways)
If you have any questions, suggestions or feedback about our project or its implementation, feel free to share these in the comments below, we’ll get back to you soon with our gameplay progression!
