Following last week’s post about how we’re handling trendy-looking 2D in Unity3D, I had a few requests for a bit more info on what we’re doing Editor-side.
Here’s Tim again, explaining what on Earth he’s been up to:
We use Unity Editor extensions for lots of things, The Transform2D Inspector is an example of one we use to customise the editor to work better in a 2D game. It overrides Unity’s default Transform Inspector for object that have a Toolkit2D Sprite component attached. It simply cuts away all the information we don’t need for a 2D game; for example, we never have to rotate something on the x or y axis… it just doesn’t make sense in 2D, so we hide that data away and only show the z rotation, which the inspector surfaces as ‘Rotation’. We use Unity layers to separate objects in to different render layers, but there are also loads of other unity layers for special case physics filtering, so we have a Layer drop down on the 2D transform inspector that is filtered to just show the render layers.
The Enable Snapping Checkbox turns on our snapping tool. This is implemented as a delegate that hooks in to EditorApplication.update. Unity has an inbuilt snapping mode, if you hold down control whilst moving an object with the transform gizmo the position is updated in 1 unit steps. If there is a fractional position, the object keeps that. Our snapping tool is different; it always caps the X and Y position to an integer. This is important so we don’t get any gaps forming between world tiles. Unlike Unity’s snapping, it also works on scale. There is also some smart stuff in there to copy an object’s scale out of transform and in to the Toolkit2D sprite, which helps with performance.
We also use Editor extentions for data entry. A neat example of that would be the Day/Night system. For any time in the 24 hour cycle we can set a custom atmospheric colour. When we draw a frame, we interpolate between the two colours that are closes to the current in-game time. It’s a simple but effective system, but it relies on that colour-time list being easy to edit. As the data in this component is a list of classes, Unity’s default way of drawing its inspector proves… awkward.
Unity defaults to showing the whole list in a tree view, which is confusing to say the least. The custom inspector lays the information out in a table like structure. At the top we have some helper buttons to either clear the entire dataset, or to replace it with sample data. Each entry in the table has helper buttons to delete the entry, or to clone it up or down. The table sorts itself as the times are changed:
A lot of our tools are designed to visualise dynamic systems at design time. The Time of Day Slider here is an example of that, as you move the slider the day/night system updates in real time in the Editor, so we can see how changes to the data effect the game. For example, if the game was looking too bright at 3am, we can quickly set the slider to 3, and the table shows up what colours are being mixed at this time, along with the previous and next time marks. We can clone one of these entries, tweak the colour to something darker and fiddle with the time until we are totally happy with the look.
Some other examples of extensions that help visualize dynamic systems are our Level Tinting Tool (which helps us change the colouring of the entire level on the fly) and the Dynamic Rope Tool (which helps set the start/end points and tessellation values of a physically-simulated rope or cable)
Finally, we have really complex data creation tools, like the Waypoint Network Generator. We use A* pathfinding to allow the guards to navigate around the world. In the XNA version you had to lay out waypoints and link them together by hand, it was a cumbersome process to say the least. For the Unity version we have an editor extension that can automatically generate the waypoints themselves, as well as drawing the waypoint network in the Editor. We do this by spawning probes at a starting point. They follow along the platforms, periodically laying down waypoints. If the probes hit interesting objects like a locked door they lay down waypoints that have extra information to describe the obstacle. If a probe finds something like a staircase of a survivable fall, it spawns more probes on the other end to link the two paces together. In a matter of seconds these probes can explore an entire level and leave an accurate waypoint graph for the AI to use.
When generating the waypoint network we could do an entire level in one go, but as it is a long task we don’t want the editor to become unresponsive while doing. Instead, the generator is step-able When we are updating the waypoint network, the generator hooks in to EditorApplication.update and steps the probes once per frame. This lets us watch the probes travel around the world. Its a fantastic way to spot problems with the map or waypoint generator (it also looks totally cool and futuristic -D)
Different types of waypoint are drawn in different colours, while the lines between the waypoints show us how they connect together. For example, the falls from the platform over the door are one-way only. The dark green marker in a line shows the direction of travel allowed by the connection.
Hello. Dan again. So there you have it! Clever, eh? As ever, if you want to know more about The Swindle, the best thing to do is keep an eye on my Twitter feed.