An up-and-coming game development suite is Havok’s Vision Engine. I had the opportunity to use it recently and offered them some suggestions on how to improve workflow. Building upon my previous redesigns, I was able to quickly mock-up a new layout and set of features that could benefit Vision users.
Current Design
Redesign
Right off the bat, I realized Vision could only have one Scene loaded at one time. In addition to that, the editor could only render one viewport. Past editors gave me the ability to see a level from different views at the same. On Prey 2, we constantly had more than one level open to let us work on smaller prefabs with a larger city chunk or easily swap collections of objects from one level to another.
I had to build in a Quad Viewport example as well as multiple Scenes open at the same time (represented as Scene Tabs).
New Quad Views
The Havok team had some really good, well-thought out features. The weighting and surface depth for some of these features was another area I offered improvements. For example, the current editor allows you to quickly change how your middle mouse affects navigation in the viewport. Past experience has told me people usually pick one method they like and stick with it for 90% of their work. In my mind, that pushes it off into a preference sub-menu instead of complicating the main UI surface.
Current Preference Example
I scooped up several other editor choices and placed them in a dedicated Editor menu. This included the suggestion of adding toolbar choices and placement. Vision currently only has two toolbars and they’re placement is fixed. If you can break down large toolbar sets to themed groups, you can let users remove groups they don’t need. You can also easily introduce new toolbars as new features come in without disrupting a user’s layout choice.
Redesigned Editor Options
Several really common and desirable features were missing or not easily accessible. I strongly believe any feature should be listed as a dropdown menu bar option. An example of this was creating a Tools menu to include all transform features like Move, Rotate, Scale, Grid snapping, as well as my always present Marker Mode. You can read more about Marker Mode in previous Editor posts.
Redesigned Tool Options
One of the hidden time sinks developing games can happen when users wants to change the class-template for an object already placed in the world. Most editors require you to redescribe, place, and link this object from scratch. An easier method would be to maintain the shared properties within the current selection and exchange the underlying class-template. You’ll no longer break any assigned game logic, world placement, or unique settings.
Vision features a wide variety of handling different groups of objects: a Scene, a Prefab, Layers, Zones, 3D Groups, and Static Mesh Groups. I proposed rolling these all into a unified Prefab structure similar to what Ross and I developed on for Prey 2’s editor (Ross did all the work).
Folding these into one structure will allow users to quickly change how the game interpret this object without having to redescribe it from scratch. For example, if I want to turn an existing neighborhood prefab (sub-level) into a zone (streaming chunk), I only have to flip a property switch, or class-template depending on how it was developed.
The current editor touched on different States for object with Freeze, Visibility, and Export features. There wasn’t a consistency location for these options, however. They might appear in some form on the actual object while others might only show up as a Layer option. My proposal was similar to Prefabs… let’s unify and expand this concept. What’s worked great in past editors can apply to Havok’s as Hide, Freeze, Lock, and Exclude. You can read more on these States in previous Editor posts.
All of these previous ideas were exposed by improving the current Shapes List. The Shapes List involved two panels; one for all the different game layers people could exclusively work on, and the other for listing the individual objects found in the currently selected Layer. As with previous redesigns, I introduced the Outliner feature. This combined Layers and individual objects nested beneath them into one list. You can read more about this Outliner concept in previous Editor posts.
Shapes List Changes
A common theme within Vision was providing a wide variety of powerful tools, but finding them spread around in unique locations sometimes. Once I realized a lot of them shared similar themes, it was easy to collect them into larger categories and present them in clearly defined areas of the editor.
An example of this involves the context menu, or rather two different context menus. Vision features one menu for the currently selected object and one menu for the larger game world. By combining these back into a more common, single menu there would naturally be options that weren’t contextually relevant to the current situation. However by removing the second menu, the user can more easily remember where a feature exists.
Current Context Menus
Redesigned Context Menu
Another example was pooling all the ways objects can be displayed in the world. Filters are nothing more than on/off switches for objects in view. If you don’t want to see navigation nodes, uncheck them. Different objects can be viewed in different ways if they’re filtered on. Render Styles handle these cases. One of the more commonly known styles is displaying a model wireframed or textured. In addition to organizing the various methods Vision offered under dedicated dropdowns (Filters or Render Styles), I also suggested creating Filter Groups. These are sets of Filter and Render Style options so users don’t have to turn on or off a dozen different choices each time they want to switch major views. A common Filter Group would be only showing objects that appear in the final game.
Redesigned Filters
I was surprised to find a lack of hotkeys. Every power-user relishes a wide variety of keyboard shortcuts. Vision had a handful, but nearly the amount needed to cover all major features. I asked Ross to summarize the approach he took for Prey 2’s editor and shared it with the Havok team. Ross took all editor functions and automatically associated them to an action which could then be assigned immediately to a key combination using a text file. This allowed any person on the team modify their workflow any way they wanted. For Prey 2, we also featured several themes for quick collective swaps: 3dsMax, Maya, and Unreal.
One of the larger surprises was the lack of an Asset Browser. Each time you wanted to add an object to the gameworld you have to add a blank class item then associate it to an asset. If you’re populating various city blocks across several different zones, this method will quickly consume most of your time. At the time of this writing, they’re already in the process of adding an Asset Browser, so I won’t spend more time discussing the merits of pre-packaged assets, browsing the library, and filtering with tags.
I hope the Havok team finds these suggestions worthwhile and takes the time to implement them.
That is bad ass.