#AltDevBlogADay

Or,questions for engine teams to ask to avoid common traps.

This is easy to fall in to. Everyone has an opinion. Everyone has stuff they think is critically important for success, in their opinion. But ultimately you have to realize that you simply can't give everyone, everything. If you try, you will never be able to give anyone, anything (good.) Accept it. Embrace it. Know what problems you're trying to solve and stick with those. However, be careful not to ignore issues, either! What can I say? It's a balance. That's not sexy and it's not a hard rule, but there you go, man.

If you ask anyone on an engine team what they want to do, you're very likely to get a specific technical feature in response. That's okay. I know I've certainly been known to get really excited about technical features now and again ;) But is that really the most interesting question? Or the most important one? Ultimately, we're all here to serve the players. As engine teams, we often do that indirectly through our production teams. For me, some of the most interesting questions are: What can we give the player? What can we inspire in the player? What do we want the players to feel? What can we learn from the players? How can we help the production team give the players more?  Technical features answer those questions, but we have to be careful not to simply do things for the sake of doing them. There is always a reason. Sometimes it's just not a good one. Let's make sure it is.

We all want to put our stamp on the world. I know there's a general fear out there of Not Invented Here Syndrome, but honestly doing stuff for yourself is how you learn and definitely how you advance the state of the art. Someone has to do it, and it might as well be you. If, and only if, you can do it better. Not just different. You have to be answer what better means. Is it faster? Cheaper? Does it give something new to players? Does it allow the production team to do something no one else can do? Does it serve the central vision better? Don't move forward without knowing the answer.

Like it or not (and well, you should like it because that's the way it is), our work is ephemeral in the extreme. Nothing you do will survive very long. If I look back at the games I made ten or fifteen years ago, for example, there's virtually no one playing them today in any capacity (some people are a lot luckier than me – but still it's rare.) And certainly all the actual work I did is gone and would require quite a feat of digital archeology to dig it up and get it to compile again. The point is: The same is true of what I do today. The world is changing and the work that we do now reflects the world of today. We need to understand what's happening so that we can do this moment justice. Because in twenty years it just won't matter anymore. Pay attention to what's happening in games, and in technology, for sure. But look outside too. I mean damn, ten years ago? Where was the internet? Where was social media? Where were our freaking cellphones? Where was CG in movies? Don't fool yourself into living inside a little sandbox and believing that what's happening in the world doesn't make a difference to what you do. Reflecting the world is what you do.

Don't ask for the solution. Ask for the problem. Be especially vigilant about this. Certainly you should appreciate people's suggestions for what you might want to do or how you might want to accomplish it. But really, you are responsible. You are the one that is supposed to understand the problem at hand from all the angles. Considerations for performance, and usability and direction and memory, etc. etc. But to do that you must understand the problem. If someone makes a suggestion, any suggestion, it's your responsibility to figure out exactly why they thought that. What problem are they really trying to solve? Their suggestion may honestly be the best answer, but unless you thouroughly understand the problem you simply cannot know that. And if you don't know that, you simply can't do a good job. Who wants that? So for any issue, always stop and figure out how you can understand the real problem better first, before you decide on any solutions.

Sometimes it's tricky to see when you're falling in this trap. But let's look at an example. Customization. If you find yourself saying "well, we'll allow them to customize it, so it's cool" then you know there's a problem. That can be simple things like hotkeys or what values are displayed.  The default answer needs to be the right answer. At least most of the time. Right means usable. Right means expected. Right means predictable. Right means performant. If you have different types of users, find out who they are, how they work and provide solutions that work for them.

Ah. A classic. Programmer philosophizing. I'm sure you've been into one of these traps. "Oh, but will that work in this situation?"  "What if aliens come down with new technology that we can't even imagine – how will we handle that?!" Listen closely: You cannot solve all problems. More than that, you don't want to solve all problems. You want to solve the important ones. You want to solve the common ones. You want to solve the ones that will ultimately matter to the player. Solve the common case really well. Handle the outliers separately. If you find your system becoming more and more complicated because of all the different problems you are trying to solve, you know you've fallen in this trap. Systems that solve the common problems well (and first) get simpler as they mature, not more complex.

Momentum is hard to overcome. But you solve hard problems. This is just one more that you have to solve. If "the way things are done" isn't getting the job done, you owe it to yourself (and the project, and the players) to push to change that. The status quo may have solved yesterday's problems, but you have to ask: Will it solve tomorrow's? Don't wait for someone to ask you what problems you see and what ideas you have for solving them. Be pro-active. Make a difference.

Okay. You didn't think I'd leave this one off did you? Look at the data. Understand it. Visualize it. The only thing you do is transform data from one form into another. Understand what that actually means. Here's an exercise: Take any function. It doesn't matter which one. Output every data change throughout a some reasonable run of the game or level or assets or whatever. Every change. Every parameter that's passed. Every value that's stored. Every variable in the function. Dump them all. Then look at the values. Then find a different way to look at the values. I guarantee there will be surprises that will change the way you understand the problem and change the way you think it should be solved. You simply cannot write good solutions without understanding the data, at least on some level. And the better you understand it, the better solutions you'll be able to provide.

This can be a GUI for tools or even a programmer API (which is just a text-based UI.) Every UI influences the behavior of the one that uses it. Sometimes in subtle ways. But the only way to know is to pay attention, experiment and evaluate results. Take Twitter, for example. Here's my theory: I think a lot of sites tried to do what Twitter did. It wasn't the first micro-blogging solution. And granted, they certainly had some innovations in the space. And they really didn't fall into the trap of trying to please everyone, which is great. But I think others did that too, and I don't think that's why it caught fire. I believe it caught fire because of the "Fail Whale." (WTF? I hear you saying. How could their infamous early, well and if we're honest, continuing, server scaling problems have helped them succeed?) It's because of that one image. It's was the UI for failure. They took that one thing, which is too often just the default server message, and turned it into something fun and compelling. It made people want to come back. That, I think, is the secret to Twitter's success. So take a look at your UI and see what it says to your users. But more generally: Find the worst thing about any system you're working on and turn it into something compelling. It doesn't have to be complicated (just a simple image in that example), but it can make a world of difference.

I mean, really, truly, used. Day to day. Or do you just have a rough idea? Or just a guess? Find out. Two things for me have been enlightening experiences. (1) Usability testing. Do it as often as you can. Put a real user in front of the system, whether it's a GUI for the tools or a programmer, and just watch them tackle a task. You can't get all the answers in this kind of environment, but you can get a lot. It's absolutely worth every minute. And (2) Shadowing sessions. Just sit behind someone and watch them do what they normally do. Try to be hyper-aware of all the little workarounds and frustrations and patterns of behavior that the user isn't even aware of (or has forgotten about because they're so used to it.) And ask them "why?" – Why are you doing that? What is it that you really want to do? And ask them how they would describe what they want to do in their own terms.

Sigh. "The right way" is usually just another way to say "the way I was taught" or "the way I'm used to" or "the way some guy on the internet said it should be" – What is the right way? What are your real constraints? What are you really trying to solve? If it's "right" then it's provably right. If it's not provable then it's probably just opinion at best and nonsense at worst. So if you find yourself saying you want to do this in this way because it's "the right way" you need to first figure out how you would actually demonstrate that it accomplished that. "Right" is not even interesting. Faster, better, cheaper, more compelling, more value, more usable – those are much more interesting and valuable. What does "right" mean to you?

You need a test. You need a way to judge the value of an idea or feature or choice. Those are the central principles of the project. I can't really stress this enough: If you don't know what the central principles (or values) of your project are, you cannot make good choices. Decisions will be arbitrary. And inconsistent. If you don't know what those principles are, if you don't know how to judge an idea and on what merits, find that out. Right. Now.

Cut ruthlessly. Much, much better to solve fewer problems really well than more problems poorly. Or as our own Joe Valenzuela (@jvalenzu) says: