The user experience of Level Editors

I'll definitely go through this one. Is not like I used every tool, but between experience and videos presenting editors… I keep thinking nobody has made the ideal editor.

I've been saying this for years! Really solid talk about a really important topic that is too neglected in this industry. It's all too frustrating to see developers glance over the pipeline when there is real work to be done.

Thanks for sharing.

I agree with a lot of what you said; nice to see someone bring up a lot of these talking points and to know there's someone who shares some of these frustrations. I do hope some UX/UI developers take heed.

Thanks for posting.

Good talk! I think you're 100% right and concentration is extremely important as we work... even the slightest extra step, delay can make us lose our flow, and precious ideas... I sometimes consider myself a maniac when it comes to these things... I rebind functions I use the most to my left hand so I don't need to look down at the keyboard as often, create macros using external softwares that runs several function really fast, I make macros just for clicking where specific buttons are in the editors I use the most, so I don't need to look and "aim" for it, which takes a precious second, several times a day... stuff like that.

So yeah this is important to me!

I dream of a day when we can make editors react to everything we want to do without any delay... like we control it with our thoughts or something Thanks for sharing Tyker!

MikeGon: Examples of those macros?

As a hobbyist in VFX one thing I really love is the flexibility of some of the UI's there. This would really suit level design imo. In Nuke I can write a few lines of Python (having no previous experience with it) and suddenly I have some knobs that can control all similar settings all around the file. Imagine something like this for controlling light on all similar types of lighting in your level as an example.

here is the youtube link:

I knew this was coming from a mapcorean I posted it in the "interesting conferences" topic when it popped up on my stream

havent had the time to watch it yet tho

Very interesting video. There was a point early comparing Hammer to Unreal for number of clicks per brush that I wanted to insert because I've got some tools for Source in Max that just don't make it fair for clicks-per-brush... in fact he mentions at # 24:35 a tool that architects use that designs with splines called formz.... I've actually built a tool for Source in Max that does just that called CorVex (which I'm proud to say Autodesk featured on their app store for a couple years). I built CorVex because I personally think that the Hammer design philosophy for brushes is inefficient.

I'm curious why he left Max out of the Terrain discussion... as that is one topic specifically that Max has no limits. Likewise, placing assets -- as Max has giant set of options on this (think of the Forest Plugin). Instancing, also...

And for the texturing/UVs the information on Max was not exactly correct. He was correct in terms of Vanilla Max, but there are solutions for the issues.

I did enjoy the video, but as both an expert and advocate of Max level design, I was keen on those aspects that were erroneous or skipped.

But overall I agree with the speaker. While developing Wall Worm, I've had to update several functions and UI elements because my initial decision for action x/y/z was not good or immediately obvious for users. And this is an important aspect of design UI (which is not my personal forte). On the flip-side, one of the issues I've always had to deal with in terms of Wall Worm/Max is that most of the new users have always been having to accommodate have backgrounds in Hammer--which comes with it's own set of design-philosophy baggage. I know of many design strategies that are far faster in Max than you could ever do in Hammer... but so many people in the Source world have actually conformed themselves to Hammer that it makes it hard for them to think about level design differently. I suspect that UE4 will probably start changing that over the next few years, though.

In terms of my baby Max, Playtesting is really the only area that it fails to hold it's ground. But in terms of the Source Engine, playtesting a level made in Max is no different than playtesting a level made in Hammer. In both cases, it's hit the compile button, go make some coffee and find something else to do for the next 5-60 minutes.

Good speech. I was feeling a slight urge today going back to Hammer and create a map for CS, but I could only think of all the time consuming problem it has so now I'm not sure anymore. It's good that this subject is talked about. Let's just hope that the tools will be updated soon.

This is interesting, but I feel a little too simplistic due to the time constraints of the presentation and assumptions on developers workflow, nevertheless it's a good rundown of a few of the many tasks performed in a level editors. For example, I don't know any designer who crates (pun intended) a new brush (bsp) for everything that they add, instead, you modify existing ones or duplicate them, and work from there, just that one change in workflow produces drastically different results for UX (for example in unreal you hold alt + drag mouse to duplicate anything) Additionally, where as first time UX of where buttons are is important, once you've learned how to do something, you'll know for the future, UX often focuses on actions that needs to be performed for the first time, and to make sure that they are not frustrating, which obviously makes a lot of sense for a game, but something as complicated as a level editor is never going to be easy to pickup, especially since new editors have to do so much more than older ones (yes hammer looking at you, still love you though) a complex action that must be performed many times often gets a special macro or tool written internally for it, and simple ones often get hotkeys, although personally I don't really master hotkeys in tools because when swapping around them it becomes a nightmare.

This is not to say that the UX experience of the tools doesn't matter, this is a great talk and a wish more people cared, it's just to say that every developer has their own preferences for workflow, some of the tricks I picked up at Epic make the hammer BSP method seem slow by comparison, it just requires that knowledge to be shared. The fact is that different developers use DRASTICALLY different workflows for creating levels, none of which are necessarily better or worse than each other, and this point alone makes comparisons complicated and messy, so by that point the best tool is the one that gives the most flexibility not necessarily the best single optimised workflow.

It all boils down to, the overall package, and just like everything in life each has their pros and cons, I've been saying this for years, but the tools matter a lot less than the experience of the developers themselves (I've heard some comments in this industry that believe tools are everything and that they can replace experience!!) I've managed to master every editor I've come across pretty fast, because as mentioned they all do similar things, the knowledge of HOW to do something soon becomes trivial, and then the tricky question is WHAT to do, which unfortunately is not so easy to answer

Flow is also important, but the realities of being a level designer in a studio pretty quickly ruins any chance of that, since you'll be interrupted or asking questions constantly, on the rare occasion it happens though, it's a wonderful thing

Anyway, keep it up, thanks for being brave, tackling the subject and fighting for the user experience!

Quote from 2d-chris

2 hours ago, 2d-chris said: The fact is that different developers use DRASTICALLY different workflows for creating levels, none of which are necessarily better or worse than each other

While I agree with most of what you said, I cannot agree on this part. Unity/Unreals method of click dragging meshes into the editor is unquestionably better than hammers and the creation kits. The same goes for many of the aspects spoken about such as preview images, search tagging or custom libraries, testing the game in editor and many more. There are so many things with some of these engines that is just a step above completely unusable or broken, mostly so with Hammer and the Creation Engine.

And something @Tyker didn't specifically mention, but maybe implied. Is bad UX not only causes worse work to be performed, but in some cases no work performed at all. I can't count how many times in hammer I have abandoned ideas simply because I cant be bothered to go through the model importing nightmare or mess with the VMT's to bother with a texture. I know something is bad, but don't care to improve it at all. And since I love Skyrim and Fallout so much I would have loved to work on a mod for them, but one look at their toolset instantly puts you off. Games using Hammer and the Creation engine are the most modded games out there, but their toolsets are absolutely terrible and I have to wonder how much UGC is lost because of how bad they are.

Also a shame you wasn't able to speak about flowgraph as well as in editor animation systems, such a huge time saver that is so powerful short and long term.

Yeah level editors are much more than primitive editing tools these days, that's where Unreal obviously excels, being the complete package. Here is the thing though, obviously creation kit is designed for a complex RPG and it's also not designed to be flexible, it;s a tool designed for one thing, it's not fair to compare it to a tool traditionally designed for FPS games, but I suppose, what is the fun in that It's the things you don't think of that are really tricky, dialog systems, tutorials etc, how they integrate into tools is just as important as world building.

Building a complex RPG in any editor not designed for it is a nightmare, you'll end up writing most of the tools again, much can be said for racing games etc, expecting any single tool to master all of the genre's and workflows is just not viable. So as the saying goes, you must use the right tool for the job! Aint no multi tool that will do everything even if people have tried

Quote from Skybex

1 hour ago, Skybex said: I can't count how many times in hammer I have abandoned ideas simply because I cant be bothered to go through the model importing nightmare or mess with the VMT's to bother with a texture.

Alt-tabbing in and out of CS and inputing mat_reloadallmaterials after every single VMT parameter/and or mask change is killing me right now.

I have been summoned! Awesome to see more people talkin' about this stuff.

I made some videos called Level Editing In UE4 Kinda Needs To Catch Up To Quake 1 and Hypothesising Negative Effects of Ubiquitous Modular Mesh Based Level Design, latter of which was discussed at length on the UE4 forums (I'd be interested in whether you saw that, @2d-chris). These days I'm working with UE4 but making my maps in Hammer, because modular mesh based level design is only a sensible idea for large studios with lots of artists, and Unreal doesn't have good level design tools for anything outside that situation. I do love Unreal though.

Quote

Quote For example, I don't know any designer who crates (pun intended) a new brush (bsp) for everything that they add, instead, you modify existing ones or duplicate them, and work from there, just that one change in workflow produces drastically different results for UX (for example in unreal you hold alt + drag mouse to duplicate anything)

This is totally a thing, but compare the UX of alt+dragging a brush to clone it in Unreal to shift-dragging a brush to clone it in Hammer. Same thing, except with Unreal, you have to click-drag on the pivot, (why does it have a pivot?!?!), which is a tiny target for your mouse, which is probably not in the center of the brush, or might be nowhere near the brush if you've resized that brush a lot, and then it drags really laggily across to where it belongs, and then either you've got to manually hit "rebuild geometry" to see the result, or you have automatic rebuilds on, and now you have to deal with a potentially-very-long hitch while Unreal rebuilds the entire map's geometry because you moved one brush...

Quote

Quote some of the tricks I picked up at Epic make the hammer BSP method seem slow by comparison, it just requires that knowledge to be shared

Epic's BSP implementation is so slow I don't know if I could come up with a method that didn't make it feel slow by comparison But that's because it's a bad BSP implementation.

I'd be super interested to hear some of your tricks, and see if they're applicable to a smaller-scale operation than you have at Epic.

Quote

Quote Flow is also important, but the realities of being a level designer in a studio pretty quickly ruins any chance of that, since you'll be interrupted or asking questions constantly, on the rare occasion it happens though, it's a wonderful thing

This is interesting. To me, if you're in a studio that ruins any chance of you getting a flow going, that... sounds like a pretty bad work environment? Shouldn't that be a priority?

I think the difference is I don't let things get to me, I've learned the quirks of something like 5 engines, and the blockout phase is actually a small part of my job, so I'm not going to lose sleep about it. I have thoughts on improvements for all the tools within the various engines, but I've never hit a point where I can't create what is in my mind, you can do just about everything with all modern engines, of course, if you go out of the box from what the rest of the team is doing, you'd better know how to do it because that is asking for trouble In crysis 3 I pushed the boundaries by building a level where the two major location you play in both get completely destroyed, that was a nightmare and a real challenge but worth it in the end, it was possible because I understood all the tools (cinematic tools, scripting etc) and was able to prototype it myself.

This is going a little bit off topic, but @Lacabra if you want to sit in a corner and get work done, being a designer who is coordinating relatively big teams on your vision is probably not the best job, when you work on a smaller team it becomes even more critical to communicate, I'm sure there are plenty of studios that assign task and you just execute, but I personally wouldn't go near them with a ton of bricks! Ultimately, it is up to me to decide how best to spend my time, flow happens when I need it to happen, but we're not grinding out content like slaves, we like to talk a lot and discuss options. This is especially true when you work on a new IP

I uploaded some videos of working with unreal's geometry tools, it's in the spotlight section on the right, Sid also produced some videos of his workflow, which is very different than me but a lot more traditional, I've built up a combination of Hammer, Unreal, Cryengine and Maya ... so a hybrid between all of these usually fits no matter what I need to design.

I want to add a little point that is overlooked, great tools allow you to make things faster, but guess what usually happens then, you get moved onto something else, so you will usually produce MORE work, but not necessarily BETTER work, the best companies will realise this and give you time to improve, but I just want to be clear in stressing that more efficient workflows doesn't actually make better content, out of the box, but it might produce it faster. It requires considerable commitment by management to understand this. As your game becomes more formalised, development times become even tighter, I can give an example of this. For Crysis 2, AI pathing used to take considerable time, as each point in buildings was hand placed, we later replaced it with an automatic solution for Crysis 3, what ended up happening is the time to work on the level dropped, and designers became lazier, before when doing the AI pass by hand we would carefully check that the space was good for the player and AI, afterwards it became something that was pretty much ignored. Now we could of added a task to make sure that everything was valid, but it was forgotten for time and convenience. Everyone wants things faster, but the realities is when things move at a certain velocity, mistakes are made and ignored, sometimes taking your time is a very, very good thing.

Wow... these are some insane observations to me! I kind of get where you're coming from, but it's such a completely different way of looking at a thing.

Yes, taking your time is a good thing - being forced to take your time because your tools are slow is not.

A lot of what you're saying seems to be... that if you improve your efficiency, your efforts are probably going to be undermined by bad project/office management and you end up no better off... so you're better off not trying?

Improvements to tools aren't supposed to make you lazy because things are taking less time, that saved time is time you can invest in the other stuff you're doing.