Game Design Zen

As a software engineer, it is unbelievably easy to get lost in the world of ‘least memory’, ‘most elegant solution’, or my all-time favorite, ‘fewest clock-cycles’. All of these ideas simply mean to maximize the performance of the code. This idea permeates the world of software development and eventually leads to the conclusion that the best engineer is the one that builds the fastest, most elegant, least resource intensive solution. The idea is drilled into our heads, starting in the first days of programming 101. So, it is no surprise that by the time our bright young developers enter the professional work force, it has morphed into almost a religion.

Simply stated, developer’s always want to reduce the amount of resources they are using: use less processing time, less energy, less memory, and even fewer lines of code. Less is better! Least is best! While there are certainly cases where this in fact the most important consideration, I’m going to offer a different perspective.

Which Resource Matters Most?

The problem of focusing on the number of resources our code uses, is that we usually neglect the most important resource of all: the number of engineering hours it takes to do something. Neglect is a strong word and means exactly what it implies: we neglect how valuable our own time is as engineers. We are ever so eager to consider how much CPU time our code takes, but ironically, we don’t like to think about the most important time of all – our own. In reality, engineering time is the most limited resource we have. Engineers are expensive and honestly, we never have enough of them.

Now, this might not be so bad, but there is another problem that complicates things. In general, engineers have trouble predicting how long it takes to implement something. Over time, this has become somethinf of a cliché. Take the engineer’s estimate and double it (2x), or triple it (3x), or even multiply it times ten (10x). Engineers will argue that they tend to estimate correctly, but there are usually complicating factors. And, in fact, they may be right. The problem is not so much that we can’t estimate time. The real problem is in terminology.

Done-Done!

When engineers estimate time, they try to think of what it takes to get ‘er done, but they rarely think of what it takes to get ‘er ‘done-done.’  ‘Done-done’ is an expression that evolved over time and points out the problem of terminology. Just one ‘Done’ can mean all kinds of things, depending on exactly what question you ask. Is the basic algorithm done? It the demo done? Is the integration with other members of the team done? Are all the boundary cases done and is the check in done?

Over time, I began to ask if something was ‘done-done.’ This is a different question. It asks if they are completely and 100% done in every possible way: the code compiles, it runs, it does what it’s supposed to, it is tested and integrated, and it is even checked in. If you say ‘yes’, then you better be completely finished and ready to move onto something else. When we estimate tasks, we usually think about how long it takes to be ‘done’, but we rarely factor in how long it takes to be ‘done-done’ – and that takes much longer.

Conclusion

So, with those 2 problems in mind, we can now go back to where we started – the idea of making the code as awesome as it can be. It’s almost in our blood to want our code to be stylish, efficient, and use the latest uber-efficient algorithm. That’s part of the fun, it makes us proud of our work, and sometimes it even helps us feel smart! But, now consider what happens when you mix in the idea that we don’t think of our time as the most important resource and the idea that we rarely think in terms of getting things, ‘done-done.’ Now, we have the ingredients for disaster. And, that is the source of the clichés and the 2x, 3x, and 10x multipliers.

This is exactly the case that Jonathan Blow makes in his speech, ‘How to Program Independent Games .‘ Jonathan Blow is the award winning developer of Braid, founder of a successful independent game company, and generally, one of the smartest engineers you are ever likely to meet. His advice is that being the best engineer is not about using the least number of computer resources, it is about using the least number of developer resources. He explains that it is more important to get it done quickly, simply, and truly finished (aka ‘done-done’). His talk is deep on many levels and offers a perspective we rarely consider. As he explains, being a good engineer is not about being smart – it is much harder than that. Being a good engineer is about truly understanding the value of our own time. And that is not ‘smarts.’ That is what is known as wisdom.

Direct Link To Paper: Creating Flow, Motivation, and Fun in Learning Games.  (PS – some external sites do not like direct links to a PDF format, so I used this blog post instead).

In a 2010 Ted conference, Ali Car-Chellman offered this harsh criticism: “Most of the educational games that are out there today are really flash-cards. They are glorified drill-and-practice. They don’t have the depth and rich narrative that really engaging video games have” (Car-Chellman, 2010). She concludes with this challenge: “We need to design better games.” This chapter will address her challenge.

The chapter was written by 4 game developers: two from entertainment (Michael Guerrero, Kerry Moffitt) and two from learning games (Curtiss Murphy, Dustin Chertoff). This chapter is part of the book, The Design and Development of Training Games, which is in the final-final stages of preparation and should be published later this year.

Topics include:

• Flow – overview and use in games
• Tasks – explicit, implicit, and player driven
• Feedback
• Balancing Difficulty with Skill
• Dynamic Difficulty Adjustment
• Simplicity
• Paradox of Choice
• Intrinsic vs Extrinsic Motivation
• Control, Baseline Rewards, and Achievements
• Scarcity
• Zeigarnik Effect
• Experiential Design
• Types of Fun
• Fun in the Rules
• Presence

The chapter is made available with permission of Cambridge University Press and the authors.

Direct Link To Paper: Why Games Work – The Science of Learning. (PS – some external sites do not like direct links to a PDF format, so I used this blog post instead).

A few months ago, I had a realization. At first, it didn’t seem like much. A little side-step from what I was writing about. But, as I worked on it, I realized it was something more: a new idea. It sent chills up my arms. After much research, I couldn’t find many papers on the topic, so… I wrote my own.

The paper is: Why Games Work – The Science of Learning. It will officially be published/presented at the Modsim World 2011 Conference in October. But I want to open it up to get early feedback. Maybe I missed something. Maybe it’s been covered already. Help me refine the idea. Shout out and let me know.

Here’s the idea in a nutshell: the things that are known to improve learning are almost exactly the reasons why games work. In other words, games work because of the laws of learning.

Near the end of Daniel Pink’s book, Drive, I found this quote:

“Being a professional, is doing the things you love to do, on the days you don’t feel like doing them.”  – Julius Irving.

It’s wonderfully insightful and is exactly the inspiration I needed. Even though I love what I do, sometimes, I just don’t feel like doing it. Sure, I work on games for a living, but it’s still work. Sure, I’m passionate about learning as much as I can every day, but sometimes, I just want to watch True Blood with my wife or mix it up in League of Legends with my son.

So this quote, from Dr J is just perfect. First, it reminds me that it’s okay to have those off days. Failure isn’t imminent just because I’ve lost the motivation to work out the kinks in an interface or do more research for a new design. And then, at the same time, it gives me just the slightest kick in the pants. It reminds me that a true professional will get in there and do it anyway.

It reminds me that mastery is a lifelong journey. And a choice we make each day.

I was reading Csikszentmihalyi’s Flow and I came across something new. Or, maybe it just seemed new the 2nd time. Whatever the reason, I had one of those, ‘holy cow!’ moments that sends chills up my arms. His words inspired me to realize something new. Something I want to share. Here’s what I learned.

Many of the self-help management books of the 80s, 90s, and even early 2000s like to stress the importance of ‘learning to delegate.’ It’s a simple idea that is a part of management-101 courses everywhere. On the surface, the idea seems pretty sound. After all, managers have a lot to do and they can’t take everything upon their shoulders. There’s not enough time in the day – you’ll be overburdened and burn out. Therefore, as a manager, the first thing you need to learn to manage is your own time. Somehow, this idea then leads to the conclusion that managers should spend a lot of time learning how to delegate to subordinates. Pick through your tasks and assign them to your people and tell them how you want it done. Then, setup measurement and tracking systems and make sure everything happens accordingly. Setup meetings and agendas that help inspire people to achieve your goals. After all, as the manager, you are the visionary and the leader and that makes it your job to delegate.

So, that’s the old school of thought. I’ve seen this explained in a dozen ways. But, today, I had an inspiration. A bunch of ideas that had been bouncing around my brain suddenly congealed into a single revelation. I realized that there is something profoundly flawed with the idea of ‘Learning to Delegate’. It’s not that there isn’t some kernel of wisdom there, it’s that it completely and deeply misses the much more powerful wisdom of, ‘Learning to Empower.’

LEARNING TO EMPOWER

Empowerment? “What’s he talking about? Empowerment? That’s idealistic blubbery!” After all, by its very definition, in order to empower your employees, you have to sacrifice control. Empowerment means that my employees can take on actions, make decisions, act with authority, and do whatever they think needs to do, however they see fit. “If I sacrifice control, how will I make sure things get done? That’s crazy talk and scary, that’s what that is.”

But, it’s only scary because there’s a flaw in the underlying assumptions. The idea of learning to delegate assumes that people don’t want to work and are only productive when you setup a system of rewards and punishments. Carrots and sticks. Measures and rewards. “That’s how it works. … Right?”

Fortunately, no. Over the last 20 years, this idea has been well and thoroughly debunked. In fact, many of the advances in modern psychology directly refute this flawed premise. Daniel Pink refers to this old-school way of thinking as ‘Motivation 2.0’. In his book, Drive, he describes how Motivation 2.0 became popular with the rise of factory labor. It came along with the idea that an assembly line is just a machine made of human parts. Oil the machine with rewards to keep it running smoothly.

But Pink isn’t the only one. In fact, the advances in psychology come from a wide range of sources. From Csikszentmihalyi’s Flow, to Edward Deci’s Intrinsic Motivation, to Schwartz’s Paradox of Choice, to Pink’s Motivation 3.0, and finally, to Seligman’s concept of Well-Being. Here’s the cliff-notes version: we are most creative, most productive, most engaged, and most happy when we are doing activities that challenge us, allow us to exhibit mastery, and are within our control. (Hey!  that sounds a like a typical night playing video games!)

CONCLUSION

With that in mind, let’s look again at the phrase, ‘Learning to Delegate.’ Underlying this expression is the belief that ‘I am in control of everything and I must delegate tasks to my subordinates or we will fail.’ Now, compare that to the phrase, ‘Learning to Empower.’ At the heart of this expression is the idea that ‘I want to help my subordinates learn that they are responsible for all of our success, so they are in control and can use their skills to make stuff happen.’  These two ideas are not the same. Not the same at all.

In hindsight, it’s been kind of fun applying this to game design and development. The realization of ‘learning to empower’ is something I can directly apply to both managing game projects and game design. For me, the implication is that managing game projects isn’t about delegating tasks, it’s about empowering teams to achieve success! And, game design is not about delegating tasks to players. It’s about empowering them.

After all, “we’re born to be players, not pawns.”   (Pink)