Sorry! I already had to cut so much good stuff when building the talk, and things had to go. Generally I'm still happy what the talk gave out as an idea, but originally I went over all 5 editors on each chapter. I loved doing this, and going into full detail, but sadly the time wasn't there. Even with those cuts, and talking super fast, I barely made it into 50 minutes. Please let me know what was erroneous though! I am not perfect, I do not know everything, and I'm always willing to learn.
Yep, time constraints and cuts sadly had to happen, but as a general idea to share this knowledge (especially something I rarely hear people talk about) I'm still happy with it.
True! I work the same way in hammer. One of the first iterations of the talk actually had me build the exact same house/room in each editor to show different workflows, but this was much too time consuming, and made it difficult to compare the editors as there was a lot of time inbetween the different features. This resulted in the final format, which in this way meant the creating of the brush & the editing/copying/moving of the brush were split up. So I do talk about both placing and copying/edit to create sections (Or if it feels like I didn't, please let me know if that wasn't clear!) the two topics are so separate it doesn't look like normal level design workflow. Thanks for letting me know, I did not realize that until now!
It doesn't have to be easy to pickup, no. There is time to work with it and get used to it, but the section where I talk about the 'ok' button vs the 'x' button in the Skyrim Creation Kit (SCK) is exactly about this. "If you do something, you'll know for the future" is not always true. Many editors & tools have a problem that there are solely tool programmers involved and not designers, creating scenarios where the technical action is possible (pressing 'ok' or 'x') but the physical action of pressing them varies within a huge editor. The SCK is definitely not the only one to do this, of course. UX needs to focus more on what you are continually doing, again and again, and to make that smooth. Sure, level designers also need to deal with problems and bad tools sometimes, but if that goes too far, which it often does, then you reach that point of "Deal with it." and "A good designer/artist/developer doesn't blame their tools, and comes up with cool stuff regardless." which is incredibly detrimental both physically, mentally, and qualitatively, as I discuss in the talk.
I think that reality can change. It will be slow, it will take incredible time and effort, but the end result will be worth it both for game developers and for game players.
This is something I'm sad about that I did not mention it. This is the answer I would've loved to give to the question at the end concerning finding a tool for a game that has thousands and thousands of props: To find the right tool, and the right tool UX, you need to look at: Your company, the genre you're building, your publisher relations, your developer workflows, your time limit, the studio culture, the country culture, your budget, etc etc. and then make an informed decision with all of those factors in mind.
I disagree, and this is where I think change needs to happen. Tools affect the end result of developers, both of experienced and inexperienced ones. If a badly placed exit button makes you lose 30 minutes of work, then your production, mood, and creative quality have just gone down. I won't say tools are everything anyone needs to make something awesome, but I also won't say tools matter less than the developer experience. If working with the editor is annoying enough to get a developer out of a good mood, it's not the fault of the developer, it's the fault of the tool. And we can fix tools. Telling developers to deal with bad UXd tools is reasonably okay, up to a point, but that point should not be 'running into the tool programmers room asking what the hell is going on', but should be 'getting annoyed over a consistently repeated action'. Again of course studio culture, time limit, budget, etc come into play, but the argument of how to do something becoming trivial and what to do becoming important is, in my opinion, not entirely accurate. It's missing a critical element. It's not just how to do something, or what to do, but in what way is it being done? If you have an awesome idea (what) and you know how to do it (how) but then you need to wrestle with a bad UXd editor to make it work (in what way) then you might not act on that awesome idea, or your creative energy will stop flowing because you will start to get annoyed, and then you might instead produce a less awesome idea in the end. Now the game is in a worse state purely due to bad editor UX. Experience might help here, but it's not a catch-all for these problems. In the end developers are only human. Bad tools can bring down amazing ideas and awesome games. You can punch through bad tools, and come out with awesome games, if you have enough willpower, force, budget, or time, but many times the sacrifices in final quality are not worth the small time it would take to fix a UI/UX issue. @Skybex's post also brought this same argument to light, and it's exactly how I feel, what I've heard, and what I've experienced in the industry. Amazing projects & ideas have been lost, just due to bad tools that human beings could not healthily deal with. Anything might be technically possible in an engine or editor, but it also has to be humanly possible.
Thanks! And that's why I wanted to say in the above point: I disagree. I think it's useful to say that publicly, even though I may be talking to someone with more years of experience and a more senior position. I'm going to keep fighting for better tools & editors, not only so that developers enjoy work more, but also so I can play even better games!