gamedevlessons — videogames: the blog

I thought it would be a fun exercise to reflect back on some of the games I’ve worked on and think about some things that the experience taught me, or that in retrospect had interesting things to learn. To keep it focused, I’m going to stick to 5 things, but I may do more in the future!

Context: I was the first QA tester at Obsidian on Neverwinter Nights 2, eventually became lead tester when the QA team expanded, and by the end of the project moved into production as an assistant producer. So these aren’t really design lessons so much, though they are development lessons!

Teach Producers to do stuff - Producers are support folks, true. But producers should learn some aspects of your tools and development process for two important reasons:

Understanding how people do their jobs makes you a better producer and helps you make better decisions.
Producers being able to pick up the slack in implementation can be a huge help in the 11th hour. On NWN2, the executive producer and I took over most of the implementation of the front-end GUI in XML, and our ability to do that meant that other, much more challenging aspects of the UI, were able to be implemented. Without us handling that, the people who were more capable to do the heavy lifting couldn’t have dedicated their time to more important things.

Being a Lead is hard - Managing people is really, really hard. This is where I personally came face to face with the Peter principle - the idea that people get promoted until they hit a job they are incapable of doing. In the game industry, you can learn that when you promote your best programmer to Lead Programmer, you lose your best programmer and get a mediocre lead in his place.

In my case, I went from a skilled, experienced tester to the manager of a team of almost 20 people, many of whom had no QA experience, and I had basically no training or management experience. That was hard and I did not do a very good job. I feel bad for the testers that worked under me.

I don’t know that there was a better option in my case, but it definitely made me respect the idea that there should be a path for promotion for folks who excel at their job but don’t make good managers, or who don’t have the managerial training or experience to manage a large team.
Copy the right things - After I became a producer, I was assigned to work on the UI. Because we didn’t have a real UI designer, and we were getting very negative feedback on the UI, I was assigned to work with engineering to see what we could do to improve things in the time we had.

The first thing I did? Open WoW and figure out why dragging buttons to different hotbar slots felt fine in WoW and was awful in our game. It felt extremely finicky, and you’d drag an icon went you meant to use it all the time.

Turns out, there’s a dead zone in WoW - about 50% of the size of the icon - outside of which you have to drag your cursor with the button held down in order to “pick up” the icon. Windows has this, too, but it’s much smaller (and clicking and dragging feel worse in Windows than in WoW for this reason IMO). This dead zone makes the difference between a click and drag and a click to use the ability much more pronounced, and stealing it fixed the problem.

When you have a problem that is tricky to solve, you should figure out the “state of the art” solution before you try to roll your own. Copying is okay, as long as you copy the right things.
Feedback is King - There were major feedback problems with NWN2 before ship (and after ship, but before ship is was far worse). Because NWN2 simulates D&D, and characters are running turn timers every X seconds, players would often select an action (like casting a spell) and the characters wouldn’t actually do anything until their next round came up. The game felt broken as a result because you would click to cast a spell, and not tell whether the game ate your input or whether you were just waiting for the next turn.

The solution ended up being to add a UI element that shows the next queued action - your queued action icon would change when you gave a new command, which was all the information that you needed to know that the game did hear you and was just waiting for your next turn.

The gameplay feedback that we got after implementing this was massively more positive - and it was the first of many times I learned that UI, sound, and animation feedback in response to actions is as if not more important than issues like game balance, cool loot, and great story.
Nobody Reads Design Docs - This was the first time I learned another lesson that would be repeated over and over again - if a design doc is more than a page or two, nobody will read it. It can be useful for yourself to catalog what you were thinking, and you can send it to a publisher to sate their hunger for milestone deliverables.

But almost nobody actually reads docs, whether to comb through them to distill a list of actual actionable, or to get all the implementation details you’ve put in there - you still have to go explain and discuss everything you want with them anyways.

Maybe your experiences are different, but this was the first time of many that I learned that generating a doc to “throw over the wall” at implementers - or to get meaningful feedback on the possibility of implementing the documented content - doesn’t work.