Get the latest Education e-news
 
  • A Plushy Knight’s Tale

    [01.08.13]
    - Jeremiah Graves
  • Plushy Knight was the product of eight months of work by twenty student developers at the Florida Interactive Entertainment Academy, a graduate program at the University of Central Florida.

    Plushy Knight is a game about a little girl who loses her father. It is a short story full of heartbreaking tragedy and tense combat and breathtaking visuals. From the beginning, our team said it was a game about emotion. Some games make you angry, some make you scared, and some make you laugh. We wanted our game to make you cry.

    Much like comedy in a movie, when emotion in a video game misses, it misses pretty wide. Student game development has that same potential (from what I have seen). No doubt this is one byproduct of our inexperience. However, often it is not ahuge mistake that sends a project hurtling out of control. Nor is it often one fatal flaw that kills a game. A friend of mine calls it death by a thousand cuts. I think we as students make a lot of small mistakes.

    In preparation to write this article, I found myself reading a couple dozen student postmortems from this site and being able in nearly every case to sympathize with the author. We all seem to make similar mistakes. What I have tried to distill both from those postmortems and my own experience are what I believe to be three issues at the root of these mistakes.

    I'd like to talk a bit about them in the context of our time making Plushy Knight.

    A Very Plushy Prologue

    On a very high level you have people.

    They exist in the ether, high above and barely seen, and we categorize them as customers, users, subscribers, and players.

    As you travel lower, you find things like sales and marketing and publishing, beta and alpha testing, and quality assurance and maintenance. Even lower, into the breathable air, you descend toward assets and audio, scripts and code, game engines and development software, and product and project management. Closer to the surface you have creativity and talent and structure and design and vision.

    The level below that is the foundation, the underpinning, the bedrock, and the heart of it all.

    On a very low level you have people.


    Here begins the Knights Tale: The Knight of Gloves

    It is December 28th, 2011. I am sitting across the table from a guy who wears black cotton fingerless gloves, and I have never seen him take them off. No one understands him. Some would say no one likes him, but I think that's too harsh. People misinterpret him. They have the wrong impression of him. I have the wrong impression of him.

    "Do I think you kick puppies? This is what I ask myself."

    I'm looking right into his eyes. He stares back at me with this face that is sort of a mixture of sour stomach and upside down smile (which is not the same as a frown).

    Continuing my point, "Do I think that you steal candy from children or sell discount liquor to the homeless or something?"

    A whole little speech has been playing around in my head for about a week because I'm afraid that this guy is going to be trouble. At this point, I have been the project lead on Plushy Knight for ten days. All I want is not to screw up.

    "The answer to all these questions," I say arriving at my point, "is no."

    Then we talk for a while. And we are just honest with each other. We talk about why we came to FIEA. We talk about people and perceptions. We talk about job fulfillment and development methodologies and life and ambition and expectations and communication.

    In my experience, it is a rare individual that actively looks to be a problem. More often people don't understand each other. More likely it is easier for us to invent villainy than to seek understanding. Understanding stems from knowledge. That first conversation was about getting to know each other. It was an attempt to answer a question.

    Over the next eight months, this guy will become - in my opinion - the single most valuable person on our team. He is all about process and scope. He is analytical and data-driven and always in search of a solution. Yet he mothers us. He nods in understanding when we complain. He listens more than he speaks. He has a sincere desire to see us succeed, and he bends over backwards to help us do so. He makes everyone around him better.


    How do you manage people you can't fire?

    "Relationships - as fuzzy as this is, it's something we set out to do from the start. The result meant that we had multiple layers of commitment to the project. One the one hand, we wanted Plushy Knight to be the best it could be, but on another hand, we wanted to make sure everyone on the team was realizing their potential. Trust comes into play here, as well. We felt confident in letting people own specific parts of the project. ‘Patrick and Brian, you have 48 hours to make death happen, or we cut it.' I knew they wouldn't want to let their friends down."

    - Skotty Bechara
    Lead Designer

    What should you do with people who negatively impact your team but who cannot be removed for whatever reason? I asked this question of an EA executive after a presentation. He said, "You fire them." Everyone laughed.

    Still, I think the comment was interesting for two reasons.

    First, the graduate program at FIEA presents a setting in which a group of peers leads a project. They do not pay you and cannot fire you - thus eliminating the two primary motivating mechanisms in a real world scenario. These are the stick and the carrot of a professional environment. Student project management takes away both. What are left are the fundamentals of leadership - vision, communication, and motivation.

    Second, at the core of the gentleman's comment was the idea that nothing is more important than the team. In fact, he spoke at some length on this point. No matter how talented, skilled, or integral a single member of a project might seem, one person does not make a game. This is something that every team member should understand.

    It was part of my job to get to know people, to talk with team members about what they wanted to work on for the next seven months, to talk to them about their hopes and their ambitions and their desires, and then to look at the needs of the project and too see where all those things overlapped. It wasn't my job to make people happy, but that doesn't mean I didn't think about it.

    Management is not the only part of the team that benefits from developing professional relationships or from learning how to motivate. The way I look at it, part of teamwork is knowing what motivates people. Company presidents have motivations, and rookie interns have motivations. Everyone in the middle is the same way. It helps if you can be sincere while trying to learn these motivations. It helps if you really care about the people with whom you are working. At the very least, it helps if you understand that you never appeal to someone else based on what is in your own best interest (first semester economics).

Comments

comments powered by Disqus

UBM Tech