Don't fear the Hammer: The importance of UX in editors & tools

Do you like watching more than reading? Then you can check out this video. If not, read on below

When level designers talk about Hammer, usually the reaction they get from other developers is "But it's ancient! It's BSP/CSG! Nobody should use that to build modern games.", and that may not be the intention the level designer is going for. At GDC 2016 I gave a talk entitled 'Keeping Level Designers in the Zone Through Level Editor Design.' In it I talk about Unreal, Hammer, Unity, The Creation Kit and 3ds Max as level editor tools, and how they can improve from a UX & UI point of view.

The reactions to the talk were very good, but sometimes I received the same aversion to BSP/CSG reaction when I brought up Hammer. I think it's important to clear up a misconception here. Instead of looking at the underlying tech of the editor, let's look at the UX of the editor.

There is a rock paper scissors effect that many tools have. Hammer has as many good things to it as it does bad things, as does Unreal, as does Unity, etc. All of them allow for incredible end results, but getting to specific end results is sometimes comfortable to do in one editor, and very uncomfortable to do in another editor. It's the flow of the tool. The UX.

That does not mean the editor to engine functionality. We shouldn't change anything there anyway, as it would just take a lot of time out of many programmers' hands, and it could halt the current development of the game. Instead we need to talk about the user to editor functionality. How can the user trigger the actions in the editor so that the engine does the crazy magical things that the players love?

So it isn't 'What kind of geometry system do we need to create a framework for and render?', but 'How do developers place geometry in the editor?'. It's not about using CSG or BSP leveldesign over asset based leveldesign. It's about how geometry is placed, how fast it can be placed, how much editing capabilities the developer has when using the tool, how fast it reacts, if it allows creativity, etc, etc.

To grab the most basic of comparisons: In Hammer, to place geometry, we need to click and drag on the grid, and it shows the geometry, its measurements, and its current location all in one glance in the middle of the screen:

In Unreal, to place geometry, we need to click, we don't see the measurements, we have to go into a menu, change variables there, and then make sure we grab the pivot to put it into the right location:

The differences in actions taken is clear:

(If you want to know more details, and see many more examples from other editors as well, then the GDC vault link at the top of this post is the right place to look!)

Of course how the engine handles the geometry, how it is stored, how it is rendered, etc, are all incredibly difficult and important topics for tool & engine programmers to think about and work on. Is BSP faster? Are assets faster? 

But, that is not the issue we're looking at in this case. Whether that geometry we click and drag out in Hammer and Unreal is an asset, a brush, or terrain, is irrelevant to the end user, in this case the player of the game. So the main point for developers is: How do we place it? How can we edit it? How can we make sure it's the best for the player? If there is a BSP system in place, with which we can quickly place and edit geometry, awesome! If there is an asset system in place with which we can quickly place and edit geometry, awesome! We're just talking about the UX here, nothing else. These kinds of UX issues are everywhere in modern day editors and tools.

It's imperative we find these UX issues quickly and solve them. One person solving one of these issues in a week can save 20 tool users an hour a day. Count that up over a 3 year period and you save some serious time. Going back to the Hammer vs Unreal brush creation, we saw 1 piece of geometry, but what if we need to place 1000 over a span of days or months:



So even though both editors use brushes, you will complete the basic geometry of a level much faster in Hammer than in Unreal. We can see that these tiny UX problems have butterfly effects, depending on how much they are ran in to. And not only for individual developers, but also for entire teams. These UX problems can pop up for every single thing developers need to do in tools & editors, and not just in creating geometry. This can be as broad as:

If all these workflows each have UX issues that can be solved, imagine the time that can be saved for an entire project team!

And again: These UX problems are between the user and the editor. The editor to engine part is usually fantastic, as tool programmers have spent ages getting that right. We should not change anything there anyway, because then all manner of things could break, development could be halted, and we lose time and money. We want to gain time and money, and to do that, we have to fix the UX & UI of tools. We need specific tool designers, not just tool programmers. A single tool designer who sticks around for the entire development timeline, can be a gigantic difference for the 100 developers who are using the tools. 

And by tool designer, I mean a tool designer, not a tool programmer! A tool designer can make a gigantic difference by helping the programmers focus on what is actually important for the developers. Instead of using Jira tickets to see what is the next big thing that needs implementing, the tool designer can take a look at all the tickets, they can understand the vision and tool use throughout the project, and then help the programmers make the right cut of necessary features, or combine the design of multiple requests into one feature, so that the programmers can implement those features that make the biggest difference to the project and the team.

So in short:
When a level designer mentions Hammer being amazing, they don't necesserily mean BSP/CSG is amazing. They may just mean the UX of the toolset being amazing, because Hammer currently has the fastest way to build, iterare, and texture basic geometry. And the same goes for my talk: I'm not advocating everyone to use BSP/CSG. I am advocating everyone to critically look at their editors & tools, and see how they can improve from a UX & UI perspective.


Do you agree, or disagree? I can be contacted on twitter at @RYStorm or by e-mail on RobinYann.Storm(at)gmail if you want to let me know!

Special thanks to Timothy Johnson, Joe Wintergreen, Brenden Gibbons, and Stefan Filff for proofreading and feedback on this post.