What I Learned About Tools Development From Games Industry Legends

[Music] hi my name is david lightbaum and the name of this presentation is tools live longer than games do what i learned by interviewing john romero tim sweeney and other legendary game tools developers so before i begin i'll just tell you a little bit about me i work as user experience director for the technology group at ubisoft the technology group is a group that creates engine agnostic technology for all the different teams at ubisoft and basically i focus on the user experience of the tools and pipelines so before i worked in game development i worked in web and motion design so in the 1990s if you knew a little bit of html you had a pretty good chance getting a job working in the exploding uh

web design industry at that time and so i learned a lot about 2d design and user interface design and i also did a little bit of motion design because flash was getting very popular at that time as well and then in 2001 i had the opportunity to work uh in game development which i've been wanting to do for a long time i've been doing some 3d on the side at home and so i took it and i haven't looked back since so it's been about 20 years now that i've been working in game development which is pretty crazy so i've spoken at various conferences around the world on the topic of user experience design in game development tools so a couple of times at gdc um but also at siggraph atsetic at the ux summit at the montreal games summit so but yeah always on this topic that i'm very passionate about which is the user experience of game development tools and pipelines

specifically regarding gdc i co-organized the game tools summit formerly known as the game tools tutorial day with jeff evans and i also took over recently the tools design roundtables from robin yan storm so if you i don't know about those you should definitely check them out especially if you're into tools development so a little bit about this talk um why do i want to talk about this today well uh one of the reasons uh is about this about game post mortems at gdc so many of you may be aware that every year there for the last couple of years they've been these really interesting game post mortems at gdc so here are just a few you know missed diablo goldeneye robotron and many many many others and they're always really compelling and really really well received and uh it's really great to preserve the history of these things so that we can learn lessons from them because the people who did these games certainly learned a lot and they could pass that information on to other people that's what the the value of these talks

is uh often one of the things that occurred to me is that there's there have been none as far as i know uh tools post mortems or very few that really focus on the tools and in the same way as we can learn from the history of game development i think we can also learn from the history of game development tools post-mortems and really preserve that history and benefit from it and uh you know i think it's important for us to learn those lessons because often you know these these um these lessons can be still applied years later and that's because you could say that the people who forget the history of game development a game tools development are doomed to repeat it uh that's a quote i'm just gonna attribute to fix it felix just seems like something he might say so what i did uh is i decided to interview key people uh in the history of game development tools so a whole bunch of different people who have worked on really interesting and compelling historic tools that we consider you know

classic game development tools so uh one of the people i spoke to uh was john romero and we spoke about ted the tile editor i also spoke to tim sweeney about the first version of the unreal editor i spoke to chris norton about the dsx tools obviously there's a level editor but there are many other tools as well that were used to develop deus ex so we spoke a bit about that i spoke to john tim dan and mike about uh gambrio uh of course as many of you may know this was one of the first uh third-party available uh game engines that you could license and use as opposed to developing it in-house and finally a mark leblanc about dramad and shockhead so we'll get into all of these but just to to to first talk about how to all these different tools unreal editor tedxo and so on and so forth um this is this list you can you might be surprised to find out when you see this list that

most of these tools are still used today and yes there are some professionals maybe that use it it's a lot of hobbyists as well but that's it really still significant and important and i'm sure that most of the people and i can say from my interviews i can say this is true uh did not expect these tools to be still used today and that the decisions that they made back then they also didn't expect to still be something that people have to um to contend with and and deal with when they use these tools these days and that brings me to the main message of my talk and that main message is that tools live longer than games do um and i said this one's easy to attribute to somebody because it's what john romero said to me during our interview so obviously john romero needs no introduction working at id software for a long time um one of the interesting things though that you might not know about his history is that uh back before he he in the early days of his career

um uh he one of the first experiences he had was playing this game called pegasus um 2 on the apple 2gs or the apple 2 rather and it had not only a game but it also had a terrain generator which he could use to build levels for the game which he had never seen before and he was really attracted and compelled by this i'm sure many of us have had the same experience as well as tools developers um and so of course you know john worked on uh you know wolfenstein and uh and doom and uh and quake et cetera et cetera um the tile editor was used to make uh a whole bunch of games um and so you can see here a couple of examples you know dave and the dangerous dave in the haunted mansion wolfenstein arise the triad and in the bottom right hand corner in fact you can see uh slurtax which was uh the first game that that the first version of ted the tile editor uh was used to make that game um and what you may also not be aware of is that this is a great example of a tool that lived longer than the game did in the sense that you can see how on the left in the case

of commander keen um how the tiles you can see how you know they were placed to build up the different blocks of the level and sort of it's like a side camera projection you can see how those were placed and when it came time to build wolfenstein they decided well you know what we're just going to use ted from a top view and whenever we place a block it's going to be kind of like a cube or like a square in our in our environment so um and apparently this is a decision that was made very quickly so they used the tile editor ted the tile editor to to build uh uh to build the environments from multiple games in fact ted was used for um 33 different game titles over the years which is a lot so definitely something that lived longer than the game did and ted is still used today see these two pages here are uh very recently updated tutorial pages um for how to use ted the current the latest version being version five that was the one that uh id software made and and just it's been the same version that's been used for years and years and years so ted is still used and still alive

today so we can tell obviously tools live longer than games do but why is it important for you to remember that and to keep that in mind as you're developing your tools well the reality is that we sometimes have time to do just enough tools development to ship the game and we we do that we get the tool done the game ships you know we're able to to provide functionality for the content creators to build the game and we say okay we did it we shipped the game we're done it was good just for that one game but the thing is that game the game that we use the tool for often then becomes the next game and then the next game and the next game and that tool continues to get used when it was really only intended to make that one game in the first place and doesn't really scale well over time and you don't really have a choice in this even though if you don't want people to use it or you don't think it was ready because you might change teams you might change companies someone else might try to keep it alive or keep it going you know and and you might say well this is not at all how i expected this to work i didn't expect people to use it for this long

this is something certainly that um mark leblanc experienced when we did our interview and he found a community on discord that was using dramed years later and he did not expect to have a community this size and this active so tools live longer than games do and it's important for you to keep that in mind and the other reason why is because you want your tools to be an accelerator right you don't want them to be a hindrance you don't want people to use them because they have to you want people to use them because it it helps them it makes their lives their jobs better it helps them create content for the game you want your tool to stand the test of time and one of the things that we can do to try to ensure that our tools stand the test of time because tools live longer than games do is we can learn from tools development history which is why i wanted to preserve it and one of the things i did in all of my interviews was i asked this question what advice would you give to tools developers today and the answers to those uh to that question led me to come up with three

different questions that you should ask yourself as as tools developers when you're developing a tool because tools live longer than games do um so let's go over those three questions the first question is that you should ask yourself and these are you know the three main takeaways that i feel you should take away from this talk first is what is the second question you should ask yourself is what can you learn from other tools that solve the same problem and finally you should be asking yourself how do people use your tools and how do they fit in with their other tools so let's start off by talking about that first question what is the problem that the users want to solve so tell me if this sounds familiar you're sitting around a table uh you're a tools developer let's say or you're you know you're responsible for organizing that organizing the tools development pipeline development and there are people around the table also who are

people who might use the tools and somebody either yourself or somewhere else someone else in the meeting might get frustrated during the meeting before or maybe after and and say to themselves like why can't they just tell us what they want you know why can't they tell us what how they want this tool to work um the reality is that people who use the tools are not necessarily experts in making tools especially not user interfaces right um and so it's something to keep in mind is that it's not always the user's responsibility to tell you how they want the tool to work okay but it is the user's responsibility to tell you what problem they want to solve and that touches on something i spoke about with chris norton so chris norton worked at looking glass studios and origin in the past before working at ion storm which is probably the studio he's hit the work at the studio he's best known for which is where he worked on deus ex as the lead engineer and oh he took on a whole bunch of different roles in fact um now for those of you who have played around with some of the development

tools in deus ex you know that uh unreal engine was used on unreal editor was used for level design but there's also a bunch of other tools that come with it like uh con edit the conversation editor and so on and so forth a bunch of exporters as well um and one of the things that chris said to me one of the things that he learned was this listen to your customer don't ever write tools in a vacuum they talked about how he talked about how this was an important lesson that he learned and it speaks to that idea of understanding what is the problem the users want to solve and john romero echoed this as well saying a lot of times tools programmers don't go far enough asking the questions about why do you want that what is it that you're actually trying to do so i'll give you another scenario another example uh that might also be familiar um let's imagine that you get a uh a request from a user and they say you know we really want uh the no button in the user interface to be read well uh one of the mistakes that's often made is that we don't often dig deep enough and to understand

why that's the problem why why that's the case and that we miss an opportunity to really be able to provide a great tool a great user experience and great value for the user using it as opposed to just blindly implementing what they're asking for let's imagine we ask them why do you want the no button to be read and they might say well because i keep clicking on it by mistake and then you might ask why again why do you keep clicking on it by mistake and they might say well it's because i click on it by accident because it's next to the yes button okay but why is it bad to click no and they might say well because if i click no by accident when the editor asks me to save i lose my work so the real problem here is that either they need some sort of protection for their file or they need an automatic backup of their file the problem is not to solve it's not that they want the button to be read but the problem to solve is that they're losing their work okay so important whenever you get a request to always ask why why why to dig into that to understand what is the real problem that the users want

to solve so that's the first question to ask yourself what is the problem that the users want to solve second question that you can ask is what can you learn from other tools that solve the same problem so those of you who work in a studio that have um concept artists i don't know if you've ever watched a concept artist work but one of the things that i experienced and one of the things that i realized while watching really professional like the best concept artists um in the world uh are that they use a lot of references and you might find this counter-intuitive you might think that well if you're a really good artist you don't need to use as many references right it's all on your brain you know exactly how to do everything but what i feel that one of the things that makes them so good is that they use more and more references than somebody might think they use references in fact some of the concept artists that that um that i've seen

even need special tools to help organize and to lay out you know mood boards of their different references help them to copy and paste those images into their into their uh into their their software that they're using to to draw their concept art in so um it's interesting to think that concept artists one of the things that makes them so good in fact i think is the fact that they look at other stuff so much and that's something that i feel in game tools development we don't do enough of we don't take the time to really look at other tools so looking at other tools that solve the same problem can make your tools better and that's something that um i spoke about with mark leblanc during our interview so mark leblanc also worked at a looking glass and origin uh you may know those uh the looking glass of course in those studios from the system shock series of games or from thief um and many many other titles as well of course um and the editor uh that was that mark helped to develop for those games was called uh dramed or

shocket depending upon the game um and you can see here is an example of it uh on the left um one of the things that's really interesting about and that was different about dramad was as as mark said during our interview was that uh the world is made of media in other words there are a lot of other engines at that time were using you know classic boolean you know subtractive kind of geometry and environment building um whereas one of the things you could do with dramad is that you could fill an area with a kind of media kind of material in other words you could fill it with water or fill it with dirt or things like that so uh for example if you know you were how you were holding a torch or there was fire and it would interact with an area that you'd filled with water well the fire would go out um or things would be flammable or for example if you were walking on something like hard tile it would make a lot of noise whereas if you're working on something soft like grass it would make less noise and so on and so forth so it was quite innovative at the time actually uh this editor

and just a little fun fact by the way uh that you may not be aware of is that chris actually worked with mark for a period of time um on on this engine which i think in early stages was called the the dark engine so mark said this to me during our interview look at the old tools and ask why people were doing what they were doing and this brings me to something that i uh that i talk about a lot and that i think about a lot which is the natural selection of game tools or game tools interfaces what does that mean when something in a user in a game development tool works well it tends to stand the test of time and then other people will see that and use that in their tools and it'll give them the idea of making their tools work that way as well so if there are elements of game tools that don't work well over time they will kind of naturally be removed from the ecosystem so to speak and so there's this natural evolution of what works best in tools what works best in the user

interface and the user experience of tools and what you see in the majority of other tools is likely not a fluke it's likely because over time it has been kind of arrived at as one of the best if not the best solution to that problem and i think it's really important to keep that in mind and that's why it's really useful and really powerful for all game tools developers to learn from other tools that solve the same problem so going out and once you understand the problem the users want to solve going and finding other tools that even if it's just a small part of the tool going and finding other tools that solve that same problem and looking at it and learning from it it doesn't mean copying it out right but it means at least being aware of it and being inspired by it and trying to design your user interface around that there's so much value it's a really big benefit to your time it's time very well spent take the time and go and look at other tools and how they work i mean i could think of much more

complex examples but just to give you a really simple example that you can then extrapolate to other parts of game development tools think about the contextual menu the way that it was originally implemented on the xerox alto in 1973 is almost unchanged over the years you can see that it works pretty much exactly the same way because it works well because it's fit for its purpose and there's no need to rethink it right but by going out and looking at other tools that solve the same problem you will come upon these solutions while you'll go oh yes of course of course it should work that way and that's going to be very natural for your users as well because if it resembles another tool they've used in the past it'll immediately be familiar to them now an example of something that mark says that he regrets doing was using wxsd as opposed to wasd to move around the environment now this is a decision for sure that was made because the game also had the same hotkeys but years later now he was talking about that discord uh community you know all the people there

uh he feels like he wishes that he had considered you know what a lot of other people were doing at that time to try to follow conventions as opposed to coming up with something different and chris said something about this as well he said you look at a lot of the professionally designed tools and they're usually pretty consistent there are design guidelines for how those things should work now he's talking about probably things like design guidelines like the fluent design system from microsoft or spectrum from adobe or carbon from ibm there are design guidelines out there that you can reference that tell you how these user interfaces are are most often supposed to work now you can either go and look at how other companies have done this or you can develop your own guidelines as well that will be similar to the tools that you have internally within your company so really important to consider uh how other tools solve the same problem because it can save you tons and tons of time and also it can lead to you designing tools that are more natural and more

intuitive and more familiar for your users to use so that's number two what can you learn from other tools that solve the same problem and now let's move on to the final question you should ask yourself number three how do people use your tools and how do they fit in with their other tools how well do you know the users and tools environment at your studio if you were to walk around the studio could you name all the other tools that the users who use your tools also use at the same time what are the other tools in their tool belt that they reach for back and forth right do you know all of them because um in the majority of cases people don't necessarily spend all day long in your tool they spend a portion of the day in other tools as well and those tools will be familiar to them and it's important for you to understand

what those other tools are so you can see how they interface with yours and also it's very important for you to understand the people to go and sit with and watch and understand the problems and the the challenges that these people have and what their work environment is like and this is something that tim sweeney spoke about during our interview obviously you know tim sweeney from epic games and the unreal uh editor when i spoke with him we spoke about the first version of the unreal editor unreal engine one which the user interface uh believe it or not was made with um uh with uh visual basic a very early version of visual basic and of course that was replaced over the years but a very impressive package at that time because not only did it have to produce amazing graphics at that time but also it had a very user-friendly interface for the tool and here's something that tim said there's this iterative process where the engine team is out creating new ideas and then sharing them with the game teams and getting constant feedback on what works

and what doesn't work now there's some key words in there iterative process and constant feedback and he's kind of talking about the user center design process this is the iso certification image of that where you understand the problems that the users have you get constant feedback and then you iteratively improve it and then you get feedback again and you go on over and over again this is one of the secrets to having a better user experience in your tools and something else that came up as well on the interview about gambrio with john tim dan and mike gambrio of course you may know the earlier versions of it uh you know when it was previously called net immerse as well you may have heard of a dark age of camelot or a prince of persia 3d um that was for an earlier version of gambrio was used for that before it evolved into a gambria when it was rebranded um and of course uh you probably know uh about its association to um games like oblivion and morrowind um

a gambria was used for early versions of that but bethesda really over time replaced large parts of that so to the point where there's probably almost nothing left over uh of the original uh gambrio inside that what's now called the creation engine that was used for those games although and they were joking about this in the interview that gabriel gets flack sometimes for oblivion and morrowind even though the the systems that they're talking about like ai have nothing to do with game brio at all um anyway but one of the things that mike said is this and when they were comparing themselves to epic who they were kind of in competition with each other right gabriel versus unreal engine editor uh at epic the artist was king gambrio was very engineer centric and he's kind of talking about that that you know user-centered design loop um and that's one of the things that epic does is going out and getting feedback from their their users internally and he went on to say this we never had enough content and users in-house to know whether what we were making was going to be useful and this is something as well a really interesting point that came up with

chris when we were talking about the conversation editor that really hammers home the point that you can't understand what your user's reality is unless you go and sit with them at their desk and watch them work he said this lead writer sheldon piccati had rsi repetitive straight injury so he couldn't type he did almost all of deus ex with dragon dictate voice transcription so for those of you who've played deus ex you might be surprised to know that a lot of that dialogue was put in using a dragon dictate now if you're somebody working on a tool you might not even it might not even occur to you that somebody might be entering their data in a way that you didn't expect but i love this this diagram from microsoft about inclusivity and accessibility where you know when we think about the limitations for people in touch uh sight hearing and speaking we often think about these permanent things like having one arm being blind being deaf or non-verbal but remember there are also temporary limitations like an arm image injury or a cataract for

revision or situational like a new parent for those of you who who know you're you know holding the kid with one hand and you only have one hand free or a distracted driver or temporary limitations to hearing and speaking like an ear infection or laryngitis or situational like a bartender not being able to hear or somebody with a heavy accent finally chris said this and i think it's really important as an engineer you think a certain way and you think oh i can use the tool this way and that's the most efficient way so that's the way i'm going to write it you're almost always wrong it's important for you to really understand how people use your tools and how they fit in with their other tools so go and sit with people and watch them work to understand what their environment is like because you'll never understand those sorts of things that i just gave examples of unless you go and watch them work so that's the third and final question that you should ask yourself how do people use your tools and how do they fit in with their other tools so what is your takeaway from this

presentation well it's important again to remember that you have to ask yourself those three questions because you don't know how people are going to use your tools you don't know how long they're going to survive for you don't know how long they're going to be used and you don't know in which context they're going to be used so even though we only have often just enough time to be able to develop the tool that's just good enough to ship the game it's always a good investment of your time to take a bit of time to do these three things number one ask what is the problem that the users want to solve and we saw that in all the different interviews understanding that again it's not the user's job to tell you how they want the tool to work but it is their job to tell you the problem they're trying to solve and that often helps us to really get to the heart of finding the best possible tool and user interface to solve that problem number tool and number two what can you learn from other tools that solve the same problem so

once you understand the problem go out there and look at all the other tools from other companies look at tools from adobe from autodesk from microsoft from other tools out there that maybe the users already know and might already even be familiar with and you might be surprised to find that there are a lot of really great ideas that are already solved problems that you can then just take and save a lot of time and you can save a lot of time for those really hard problems that may not be covered by the tools out there but there are a lot of a lot of things that you'd be surprised to find that there are good solutions to those things that we can learn from and then thirdly how do people use your tools and how do they fit in with their other tools very important for you to understand this as well to see what the work environment is like what are the other tools that people use how well do you know the other tools that they use what else is familiar to them and what other kind of limitations do they have whether they be temporary or permanent or situational what do you know about their work environment and how can you use that to try to provide the best possible tools

that will stand the test of time and that's again because tools live longer than games do thank you very much you