Últimos assuntos
Student Project Disasters! How to Turn Knowledge From Failed Games Into a Boon For Your Career
Página 1 de 1
Student Project Disasters! How to Turn Knowledge From Failed Games Into a Boon For Your Career
If you're in school to learn how to make games, it's a pretty safe bet that one of the student games you'll work on could be charitably described as a complete disaster. Though the sting of defeat may take a while to subside, it's useful to remember that difficult projects can be a much more valuable learning experience than the ones that go smoothly.
The experience of a "failed" game can even give you an advantage in job interviews - if you know how to approach the topic. As Darius Kazemi, a game developer who has mentored students at Full Sail University explains, "In almost every interview you'll ever go to, you'll get asked about a time when something went wrong with a project and how you reacted. Setbacks are great to talk about in interviews if you have some intelligent analysis to go along with it."
Completing a project postmortem will help identify the issues that plagued your project, but your "intelligent analysis" of those events is another crucial part of the process. In this article, we'll examine some common failures of student games and how to reflect on those challenges in a forward-looking way.
Scopes Gone Wild
Everyone knows about scope issues, but narrowing down your game's focus is always easier said than done. It's so easy to overestimate the amount of work that can be done in a short amount of time that it's almost a given that your first few games will be overly ambitious. The time required for testing, tuning, and iteration is surprisingly long and easy to overlook during planning, especially when you're trying to cram in as many features as possible. If you don't plan correctly, you'll likely wind up with an unfinished game, as many students do.
"On my first student game, we all had very little idea of what we were doing," recalls Brenton Woodrow, a recent graduate of the Game Design program at Champlain College. "We completely over-scoped, dove in headfirst, and fell flat on our faces."
It would be easy to say that the lesson here is to be less ambitious at the start, or to multiply every work estimate by some factor to compensate for the time incurred by iteration and debugging. However, while more realistic time estimates can help, they're only one part of the equation. It's a fact of game development that no matter how padded the schedule, things will still go awry at some point.
Because schedule and scoping issues are a more a matter of "when" and not "if," the real lesson is learning how to prioritize and cut features. We'll discuss the art of prioritization in the next section, but first-the dreaded cut.
Learning to let go can be difficult, especially in the early stages of a game development career. You're in love with your idea or the geometry you built and the thought of it not making it into the game is difficult to entertain. But getting too attached to specific pieces of work can often work at cross-purposes to the overall quality of the game. It takes perspective to step back and to see that. Doing so will demonstrate that you're a developer with an experienced, mature view of how games are made.
Technical Nightmares
Another problem that bedevils a lot of student projects is technology that proves to be a mismatch with the team, assets, or both. We've all seen projects where piles of beautiful art sat around in Photoshop or Maya waiting to be implemented until the very last moment-when it suddenly came to light that those assets wouldn't work as built because they were mismatched to the engine.
This is where we get to task ordering and prioritization, a crucial body of knowledge especially for those studying programming or production. Daniel Young, Adjunct Professor at Richland College (and a designer on Doom 4 at id software) notes, "There's a huge temptation to do the ‘fun stuff' first, at the expense of answering those important technical questions."
Playing around with higher-order systems like combat mechanics or player upgrades can be great fun because the rewards are so plainly in view. But working on those at the expense of determining how you're going to load those systems in the first place can-and often will-lead to trouble. Learning this means getting used to the fact that the first parts of many game development projects are often lacking in impressive looking, demo-friendly features.
No matter how short the project development cycle actually is, there's just no getting around the initial stage of work that proves how feasible your technology is in terms of getting the game working. The sooner this gets done, the faster you can get to the fun stuff.
Sometimes that means setting your original sights a little lower in terms of technical aspirations and deciding to focus on aspects that often get short shrift in student games, like balance and polish. "On one of my later projects, we chose a very simple goal: to make an arena combat game with one level and four characters, using a preexisting engine," says Woodrow. "Some of the other students criticized us for having low ambitions. However, that choice meant we could spend a lot of our time playtesting characters and weapons, tuning the actual gameplay. It ended up being one of the best, most fun games we ever produced."
Woodrow's arena combat game was very simple, using an existing engine and just four characters, which left a lot of time and room for tuning and balance.
The Bad Egg
Sometimes a person's work just doesn't cut it. A programmer may claim his code was just a couple lines away from being fully functional, when in fact it was a broken mess. An artist might be the quiet type-so quiet that he doesn't speak up and say he thought the amount of art he agreed to do was actually impossible. Or one of the students on your team might have decided to switch into criminal justice or culinary school after this class, and can't be bothered with this game, particularly.
While it's frustrating to work with these people, it's important to resist the urge to lay the blame on others-especially when describing the problem in an interview later. Remember that the vast majority of game development is a team effort and that these kinds of problems are difficult to avoid any time you have a large group of people. Being able to describe the way the project failed while avoiding personal attacks or recriminations will not only show your ability to professionally deal with the kinds of challenging situations faced by game developers every day, but also demonstrate that you're thinking ahead, not stuck in the past.
Instead of framing your experience as a lesson to "not trust what your programmer says," think of it as an education in the necessity of possessing a flexible backup plan. Even the best designers, programmers, and artists can make mistakes and may fail to come through for a variety of reasons. Having options to fall back upon helps ensure your project's success even in the face of unpredictable circumstances. Producers call this "mitigating risk," and it's something you can start doing just as soon as you allow yourself the freedom to change course if you encounter headwinds in your original direction.
Prismatic Visions
"During one postmortem session of a student project that I watched," says Woodrow, "everyone seemed to understand that the game was intended to be a slow-paced tactical shooter. Suddenly one guy looked surprised-‘Really?' he said. ‘I thought we were making an action combat game.' The teacher just facepalmed at that moment."
Making sure that every team member understands the game's vision can be a surprisingly tricky thing. Just when you think everyone's agreed that the game is meant to be a certain way, people tear off in their own directions and only reconcile their goals after it's too late. (This effect can be compounded in school because students sometimes feel they have little incentive to follow the project direction, especially if that direction is weak to begin with.)
In order to make sure everyone has the same idea of what "success" for the project means, communication has to happen at all times, not just at the beginning. It's tempting to want to spend the bulk of your available time cranking out assets and writing code, especially when trying to put something together on short notice. But the limited development time actually means constant communication is all the more important because there's so little room for error.
But of course you do also need to have that clear vision at the start of the project. A good vision isn't about determining everything down to the letter in advance. In fact, at first there may be few answers as to how the vision will be achieved. But if you're comparing every step of the way to coherently articulated goalposts, each individual contributor's work will find itself gravitating toward a central locus, and your game will benefit from that coordinated effort.
Discipline Blinders
A video game is a combination of many different elements, and only works as a game when all those pieces are in concert with each other. Neglecting any one of those aspects can cause problems for the game as a whole. "Sometimes, my students will start building levels without thinking about what the gameplay is going to be inside those spaces," Young says. "Or, they'll spend time coming up with a character, a story, and a world, but don't get around to developing anything that addresses the game mechanics."
If you've been on a project where an area of the game you weren't involved with held back the result, educating yourself on the jobs of your other team members will help you understand what went wrong, and also teach you some of the warning signs that may indicate a problem the next time around.
In today's era of large teams, specialization often presents itself as a viable option. But specializing too early can potentially limit your career. To take a longer view, the move to larger teams makes coordination at the interdisciplinary level more vital than ever before. Because of that, an understanding of all aspects of game development can only help you. Don't pass up the opportunity to learn about them while you're still in school.
At some studios, you may be encouraged to believe that what happens in other departments is not your concern. But games are not just a few systems or pieces of art in a vacuum. If you're modeling a character, you have to think about how that character will be used in the game. If you're designing a weapon, it's absolutely necessary to consider the design's impact on art and engineering. Being able to interface with all disciplines is key, and if you can bring up your concerns in a respectful, polite way, you'll help ensure the success of your project.
Onward, to victory!
A lot can be gleaned from postmortems, and those you read in Game Developer or Gamasutra can give you an idea of how to perform your own. While it's important to remember to not point fingers too much, you should be honest in your assessment of what went right and wrong with your project, and truly learn from it. Many developers keep making the same mistakes over and over, due to the simple fact that game development is a very complex process with a lot of moving parts.
This article describes just a few of the ways that game projects run into trouble, of course. But hopefully they've given you some food for thought in terms of determining what happened, and also how to interpret and discuss those results to people who ask you about them. The courage to describe your failed project honestly, combined with the curiosity to dig to the bottom of why it didn't turn out the way it was supposed to be will serve you well in your interviews and far beyond.
Fonte:gamecareerguide
The experience of a "failed" game can even give you an advantage in job interviews - if you know how to approach the topic. As Darius Kazemi, a game developer who has mentored students at Full Sail University explains, "In almost every interview you'll ever go to, you'll get asked about a time when something went wrong with a project and how you reacted. Setbacks are great to talk about in interviews if you have some intelligent analysis to go along with it."
Completing a project postmortem will help identify the issues that plagued your project, but your "intelligent analysis" of those events is another crucial part of the process. In this article, we'll examine some common failures of student games and how to reflect on those challenges in a forward-looking way.
Scopes Gone Wild
Everyone knows about scope issues, but narrowing down your game's focus is always easier said than done. It's so easy to overestimate the amount of work that can be done in a short amount of time that it's almost a given that your first few games will be overly ambitious. The time required for testing, tuning, and iteration is surprisingly long and easy to overlook during planning, especially when you're trying to cram in as many features as possible. If you don't plan correctly, you'll likely wind up with an unfinished game, as many students do.
"On my first student game, we all had very little idea of what we were doing," recalls Brenton Woodrow, a recent graduate of the Game Design program at Champlain College. "We completely over-scoped, dove in headfirst, and fell flat on our faces."
It would be easy to say that the lesson here is to be less ambitious at the start, or to multiply every work estimate by some factor to compensate for the time incurred by iteration and debugging. However, while more realistic time estimates can help, they're only one part of the equation. It's a fact of game development that no matter how padded the schedule, things will still go awry at some point.
Because schedule and scoping issues are a more a matter of "when" and not "if," the real lesson is learning how to prioritize and cut features. We'll discuss the art of prioritization in the next section, but first-the dreaded cut.
Learning to let go can be difficult, especially in the early stages of a game development career. You're in love with your idea or the geometry you built and the thought of it not making it into the game is difficult to entertain. But getting too attached to specific pieces of work can often work at cross-purposes to the overall quality of the game. It takes perspective to step back and to see that. Doing so will demonstrate that you're a developer with an experienced, mature view of how games are made.
Technical Nightmares
Another problem that bedevils a lot of student projects is technology that proves to be a mismatch with the team, assets, or both. We've all seen projects where piles of beautiful art sat around in Photoshop or Maya waiting to be implemented until the very last moment-when it suddenly came to light that those assets wouldn't work as built because they were mismatched to the engine.
This is where we get to task ordering and prioritization, a crucial body of knowledge especially for those studying programming or production. Daniel Young, Adjunct Professor at Richland College (and a designer on Doom 4 at id software) notes, "There's a huge temptation to do the ‘fun stuff' first, at the expense of answering those important technical questions."
Playing around with higher-order systems like combat mechanics or player upgrades can be great fun because the rewards are so plainly in view. But working on those at the expense of determining how you're going to load those systems in the first place can-and often will-lead to trouble. Learning this means getting used to the fact that the first parts of many game development projects are often lacking in impressive looking, demo-friendly features.
No matter how short the project development cycle actually is, there's just no getting around the initial stage of work that proves how feasible your technology is in terms of getting the game working. The sooner this gets done, the faster you can get to the fun stuff.
Sometimes that means setting your original sights a little lower in terms of technical aspirations and deciding to focus on aspects that often get short shrift in student games, like balance and polish. "On one of my later projects, we chose a very simple goal: to make an arena combat game with one level and four characters, using a preexisting engine," says Woodrow. "Some of the other students criticized us for having low ambitions. However, that choice meant we could spend a lot of our time playtesting characters and weapons, tuning the actual gameplay. It ended up being one of the best, most fun games we ever produced."
Woodrow's arena combat game was very simple, using an existing engine and just four characters, which left a lot of time and room for tuning and balance.
The Bad Egg
Sometimes a person's work just doesn't cut it. A programmer may claim his code was just a couple lines away from being fully functional, when in fact it was a broken mess. An artist might be the quiet type-so quiet that he doesn't speak up and say he thought the amount of art he agreed to do was actually impossible. Or one of the students on your team might have decided to switch into criminal justice or culinary school after this class, and can't be bothered with this game, particularly.
While it's frustrating to work with these people, it's important to resist the urge to lay the blame on others-especially when describing the problem in an interview later. Remember that the vast majority of game development is a team effort and that these kinds of problems are difficult to avoid any time you have a large group of people. Being able to describe the way the project failed while avoiding personal attacks or recriminations will not only show your ability to professionally deal with the kinds of challenging situations faced by game developers every day, but also demonstrate that you're thinking ahead, not stuck in the past.
Instead of framing your experience as a lesson to "not trust what your programmer says," think of it as an education in the necessity of possessing a flexible backup plan. Even the best designers, programmers, and artists can make mistakes and may fail to come through for a variety of reasons. Having options to fall back upon helps ensure your project's success even in the face of unpredictable circumstances. Producers call this "mitigating risk," and it's something you can start doing just as soon as you allow yourself the freedom to change course if you encounter headwinds in your original direction.
Prismatic Visions
"During one postmortem session of a student project that I watched," says Woodrow, "everyone seemed to understand that the game was intended to be a slow-paced tactical shooter. Suddenly one guy looked surprised-‘Really?' he said. ‘I thought we were making an action combat game.' The teacher just facepalmed at that moment."
Making sure that every team member understands the game's vision can be a surprisingly tricky thing. Just when you think everyone's agreed that the game is meant to be a certain way, people tear off in their own directions and only reconcile their goals after it's too late. (This effect can be compounded in school because students sometimes feel they have little incentive to follow the project direction, especially if that direction is weak to begin with.)
In order to make sure everyone has the same idea of what "success" for the project means, communication has to happen at all times, not just at the beginning. It's tempting to want to spend the bulk of your available time cranking out assets and writing code, especially when trying to put something together on short notice. But the limited development time actually means constant communication is all the more important because there's so little room for error.
But of course you do also need to have that clear vision at the start of the project. A good vision isn't about determining everything down to the letter in advance. In fact, at first there may be few answers as to how the vision will be achieved. But if you're comparing every step of the way to coherently articulated goalposts, each individual contributor's work will find itself gravitating toward a central locus, and your game will benefit from that coordinated effort.
Discipline Blinders
A video game is a combination of many different elements, and only works as a game when all those pieces are in concert with each other. Neglecting any one of those aspects can cause problems for the game as a whole. "Sometimes, my students will start building levels without thinking about what the gameplay is going to be inside those spaces," Young says. "Or, they'll spend time coming up with a character, a story, and a world, but don't get around to developing anything that addresses the game mechanics."
If you've been on a project where an area of the game you weren't involved with held back the result, educating yourself on the jobs of your other team members will help you understand what went wrong, and also teach you some of the warning signs that may indicate a problem the next time around.
In today's era of large teams, specialization often presents itself as a viable option. But specializing too early can potentially limit your career. To take a longer view, the move to larger teams makes coordination at the interdisciplinary level more vital than ever before. Because of that, an understanding of all aspects of game development can only help you. Don't pass up the opportunity to learn about them while you're still in school.
At some studios, you may be encouraged to believe that what happens in other departments is not your concern. But games are not just a few systems or pieces of art in a vacuum. If you're modeling a character, you have to think about how that character will be used in the game. If you're designing a weapon, it's absolutely necessary to consider the design's impact on art and engineering. Being able to interface with all disciplines is key, and if you can bring up your concerns in a respectful, polite way, you'll help ensure the success of your project.
Onward, to victory!
A lot can be gleaned from postmortems, and those you read in Game Developer or Gamasutra can give you an idea of how to perform your own. While it's important to remember to not point fingers too much, you should be honest in your assessment of what went right and wrong with your project, and truly learn from it. Many developers keep making the same mistakes over and over, due to the simple fact that game development is a very complex process with a lot of moving parts.
This article describes just a few of the ways that game projects run into trouble, of course. But hopefully they've given you some food for thought in terms of determining what happened, and also how to interpret and discuss those results to people who ask you about them. The courage to describe your failed project honestly, combined with the curiosity to dig to the bottom of why it didn't turn out the way it was supposed to be will serve you well in your interviews and far beyond.
Fonte:gamecareerguide
![-](https://2img.net/i/fa/m/tabs_less2.gif)
» People Make Games
» RUN OF FIRE - Virtools project 3D for Wii
» Opinion: Why You Might Want To Consider Java And/Or Clojure For Your Next Project
» The Good of Games
» Off Book: Video Games
» RUN OF FIRE - Virtools project 3D for Wii
» Opinion: Why You Might Want To Consider Java And/Or Clojure For Your Next Project
» The Good of Games
» Off Book: Video Games
Página 1 de 1
Permissões neste sub-fórum
Não podes responder a tópicos
» Lista Actualizada de Empresas Portuguesas 14/11/2013
» Restart - Game Design
» ZombieApocalift
» Nova GamePlay
» Programador Procura Conselhos
» Unity 4 -Serie: Crie Seu Jogo de RPG 3D
» Videojogos portugueses - Portugal Aqui Tão Perto
» Rayman Origins
» Last of Us
» Lista de todas as empresas portuguesas
» Chrome World Wide Maze
» Brigade - Real-time path tracing engine - WIP
» Novo jogo da Battlesheep: Bounty Monkey
» Unreal Engine 3
» Where can I sell my Indie PC game?
» When Players Make the Rules: On Memes and the Meta-Game
» Electronic Arts COO Fights to Lead the New Game Industry
» Miniclip - Game Designer
» Miniclip - Studio Manager