The Effective Developer: Part 2
/Introduction
Last month, I applied principles from "The Effective Executive" to game development. I found this to be a valuable exercise, so I wanted to continue with where I left off last post. As such, here are 3 more take-aways from the book.
Focus on Contribution
"The focus on contribution turns the executive's attention away from their own specialty and toward the performance of the whole."
That's a good looking doorknob, but is it worth a week of work? (Click for source)
Focusing on contribution means looking up from the actual work and outward towards your (and your team's) goals. It is to focus on results, rather than on effort. Why spend valuable time developing certain aspects of your game when you could buy a plugin that does it even better? This allows you to spend a fraction of that time integrating the plugin, then moving on to the next task. You are focusing on contributing to the final product, rather than reinventing a wheel.
As anyone at Synersteel would be quick to tell you, none of your game's players will care about your effort. They will only care about the results. It doesn't matter that the AI took 3 months to implement, all that matters is whether it is fun. You can spend an entire week modeling a doorknob, but it won't matter if nobody ever stops to admire it. We've experienced this first-hand when we first delved into selling our games. We priced them according to how much work they took, rather than how much value the players would get from them. Big mistake.
There is, of course, an argument to the contrary to be made here. What if spending 3 months on AI results in terrible enemies, but a huge learning experience? What if that week-long modeling jaunt will lead to immense insights? In these cases, you are still focusing on contribution. However, your goal is likely not a finished, marketable product. Instead, it is to learn. The point is to set your goal from the outset, and then focus on contributing only to that goal, whatever it may be.
Make Strength Productive
"Organization is the specific instrument to make human strengths redound to performance while human weakness is neutralized and largely rendered harmless."
Jon Blow played to his design strengths: puzzles. He didn't try to avoid his design weaknesses.
When working in a team, it is vital to focus on strengths rather than weaknesses. We should be promoting each other's strengths within the organization. We should not be trying to make up for each other's weaknesses. Unless, of course, one person's strength is another person's weakness. In that case, working together is as win/win as it gets.
Peter Drucker points out that one should not ask "What can a person not do?" but instead ask, "What can that person do uncommonly well?" If you have a single coder on your team who is great at whipping together puzzle mechanics but hates writing the most basic UI, then focus on the puzzles. Try to drop UI from your design entirely so your coder's abilities can shine through. This will result in a much better and more polished game. The same can be said for art. Is your artist uncommonly good at environment modeling but won't touch animations with a 10 foot pole? Then your puzzle game should be taking place in a remote wilderness, devoid of life. But wait! The writer specializes in dialogue, so what do we do now? Pepper recordings of dialogues all around the wilderness, hinting at why nobody is around anymore.
In contrast to the above, what if every team member was trying to make up for each other's weaknesses? You end up with the coder doing procedural animations, the artist drawing UI elements, and the writer describing scenes through prose. While this isn't exactly a terrible idea, it would likely not result in as polished a game as if each member was playing to their strengths.
Readers vs Listeners
"It is generally a waste of time to talk to a reader. It is equally a waste of time to submit a voluminous report to a listener."
The most thorough GDD in the world is useless if nobody wants to read it.
There are 2 types of people in the world: Readers and Listeners. Well, perhaps a lot more than that. But other classifications are not as important in terms of communication.
Readers often prefer multi-page reports over a lengthy discussion. They would rather take the time to fully process information and then react (perhaps in the form of comments on the report) than have a back-and-forth. Listeners, on the other hand, would rather have a quick meeting than deal with an issue over email. They think better on their feet and often thrive when ideas are being tossed around.
This is probably no surprise to anyone reading this, but it can be helpful to classify each team member. Is the majority of the team Listeners? Then it might not make sense to have a lengthy Design Document. A gathering of notes, drawings and prototypes may serve the team better. If everyone are Readers, then it could be extra helpful to pass around an agenda before every meeting. This way, the attendees have time to think through the contents.
Conclusion
Focusing on contribution, making strength productive, and understanding the difference between Readers and Listeners can boost the effectiveness of any game developer. While these ideas are most valuable to teams, it is important for even solo developers to understand them.