Starting Top Down

When I was younger, I used to get so annoyed at my English teacher that would insist on having us outline our paper before actually getting to any writing. To me, writing was productive, and outlining, especially when the papers were relatively simple, would just be repetition of what I wanted to write, just in bullet point form. I mean, she wasn’t wrong, it really is a good practice to outline writing ahead of time. I think what I missed from the exercise was the why of outlining. Writing at that time felt like a chore and whatever I could do to get it done faster was my preferred approach.

I’m still not great about outlining my writing, in fact, most of these posts and articles on LinkedIn are pretty stream-of-consciousness thoughts that go through my head. The only difference is that I’ve been percolating on them for so long that I’ve managed to organize my thoughts into something vaguely coherent. (At least, I hope it’s coherent.)

When I went into art, I had the same problem, that I wanted to draw small details first. Every artist has that moment when they’re just so good at drawing eyes. It wasn’t until I got to a figure drawing class that I was really taught to focus on blocking out shapes, to rough in the visuals with shapes until it was time to focus on details.

I find it the same with design and designers. We see a problem and we want to solve it. And the first instinct is to jump right into the problem and start thinking of solutions. But oftentimes, that’s not the right approach. Sure, it’s fun to noodle on the problem at hand, but it’s also an easy way to get stuck in the weeds, and it’s an easy way to get work thrown out.?

Starting at a higher level than the immediate problem can help focus on what work needs to be done. Say for instance that you need to create a bunch of characters for a game (something I’ve had to do many times). It’s a fun task when making games because depending on the flexibility of the system, you can make some really cool stuff. I’ve definitely had moments where I just jumped into the problem and came up with something, only to find myself designed into a corner, which is not a pretty place to be. You end up making up strange one-offs and special cases to accommodate issues, and the engineers curse your name at night.?

The more productive approach is to take a step back and make a matrix of the verbs and nouns that you want the character to do, and also take that time to consider what you might want future characters to do. And the verbs can be similar, just a difference in degree or effect. In Last Epoch, they do a great job of having each of the damage types deal damage on hit, over time, or apply some sort of debuff.?

Once that’s been defined, you have a finite space to work within, but hopefully with enough blank spaces in it for character growth. The finite space is a place where both designer and engineer can execute with some assurance.

One of the worst things that I’ve done as a designer when asked by an engineer if I’ll want a particular feature is to give a wavering, “possibly?” I’ll confess that when I said that to the engineers that I was working with, I was trying to hedge my bets because I didn’t know the full scope of the feature or the context around it, either because I was ignorant, or I wasn’t informed by someone higher up. To be fair, unless information is communicated well, it’s easy to not know the extent of what needs to be designed.?

On the implementation side, I totally commiserate with all those engineers who have been asked to implement something without it being mostly nailed down. The frustration that arises as things that weren’t accounted for initially start to become major issues as the project progresses. Granted, in my last article, I talk about the fractal nature of things and how work keeps appearing. But a good designer should have answered many of the questions, and at least have a default answer for edge cases.

When defining the space, it’s an interesting question and maybe one that speaks to the way promotion levels work. Is it reasonable to expect an associate designer to think about all the possibilities in a matrix? I don’t really think so. As you go up in level, I think you start to see the bigger picture and how things should fit together, and it’s your responsibility to communicate that information to everyone in the org, so that there’s no surprises in the way it comes together.?

Another sin that I remember committing as an associate designer would be “hand-waving”, where I didn’t know how something worked, didn’t have a design in mind, but wanted to get through the design doc, and so we’d purposely avoid it, hand-waving it away until it became a problem. Looking back on it now, I can see that it’s actually a greater sin than not considering all the edge cases because I was actually forcing an issue to appear in a place that didn’t need to have any issues had I thought it out more. Specifically, I was working on an endless “run to the right” game that had the character with a shotgun to shoot things. A majority of the enemies came from the left and right of the character, and the animation to shoot the enemies was fine. The issue was when the enemies would go above and below the character and the player tried to shoot them. For some inexplicable reason, I chose to ignore this situation and ignored what the character should do at that moment. Either I was naive that I thought it wouldn’t happen very often, or I was embarrassed to ask the artists for more work. In either case, the issue that I didn’t account for became an issue that then needed to be addressed later and at greater cost.

A note about embarrassment, because it’s held me back several times from doing the correct thing. Leave your ego at the door. Yes, games are a passion industry, and everyone has their hearts poured into it, but there really is no room for ego. You are not always going to have the answer. You are not always going to implement something correctly. You may break the build constantly. It doesn’t matter how you feel about it. Fix the issue and move on. Everyone on the team is trying to accomplish the same thing and if you spend your time playing politics, peacocking, or making excuses, it’s hard for me to say that you’re doing anything productive.?

So to summarize, when you start any project, start at the highest view you can get and understand why things are the way they are. Seeing problems at that level can help formulate better solutions that relate to each other in ways that make sense. Once solutions have been formulated, then go down a level and examine those solutions and see if the implementation of the solution addresses everything that the solution said it would address. Don’t get hung up on whether the implementation is “yours”, that’s not important. An aside: obviously keep track of what you worked on, because of those “all-important” annual reviews. ?? More accurately, keep track of what you worked on for your portfolio. But in the context of getting the project done, keep your ego out of it.