This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
Concept Development Risks
Many teams still don't properly understand pre-production and concept development. It is really hard to properly develop the concept for a new project while working on another project. Most teams don't have the resources to allow a dedicated team to concept a new project while trying to finish the old one. This actually is one of the biggest problems in game development today; as it means that many projects get off on the wrong foot and start down a bad path from day one.
In a perfect world, a team which is developing the concept for a new project should be relatively small and given the time to really get their ideas down and proven before turning on the big faucet of a full team.
What tends to happen is that a project will finish, and the team members are often burned out from crunching, but need to start working on the next project after a short break.
Often the worst thing you can do from day one is to give a team a hard ship date, team size, budget and project requirements. Unless you have something to go off of, this can all be speculation and just put a team into a box it can't escape from.
A large game could easily require three to six months of concept work before it is ready for a larger team start work on it. If a team has to roll over from one project to another, you have to be ready for the transition. The design team is therefore often under too much pressure from day one, and forced to cut corners and either not properly design parts of the game or move forward on stuff that they will inevitably have to redo later.
In other words, the problem with the conception and pre-production of projects is generally a staffing and scheduling problem. It can generally be avoided by either having a small dedicated concept team which can work on new ideas and have them ready for production when needed, or by restructuring your team to either allow for a more flexible team structure, so you aren't forced to jump into production prematurely.
If you utilize a lot of outsourced or in-sourced labor (especially artists), have some standardized technology which doesn't require a large engine programming team, and have a flexible design team which is able to wear a lot of hats, so your team may be able to adapt much more easily.
Along with the concept and pre-production phase risks, there are also a lot of risks associated with building a prototype -- and even more with not building one properly. Prototypes should exist to minimize risks in the project.
What development risks exist need to be proven in the prototype stage. The prototype should prove any risky design elements, new or risky technologies, any production pipelines or anything else which need to be proven before the full game production begins.
Just doing a prototype isn't mitigating enough risk for a project anymore. What you are prototyping needs to be carefully evaluating to minimize the most risks possible. You should evaluate what the project and team risks are and make sure those are addressed. From a design perspective, you need to prove any mechanics which have either a risk of not being fun or a risk of being to difficult to do for production reasons or other reasons.
By the time you finish your prototype, you need to make sure you are ready to go into production, and have a plan to deal with any remaining known risks in the project.
Simply stated, the development process of a game is the way in which the game will be developed. It is the steps which will be taken to ensure that nothing is forgotten, and that everything happens in the order it should. It will dictate things like how much documentation is created, how things are approved, how the team is structured, what the overall workflow will be, if you are using an agile development model, and so on.
It is also important to understand how having a good development process is also critical to avoiding risk. If you don't have a clear roadmap of where you want to go, and how to get there, you face a major risk. Having a very clear process includes not only documenting the individual features themselves, but the entire pipeline for how the game will get made, how decisions will be made and so on. Having a process requires you impose some standards, and taking a stand on how things need to run in order to get done on time and on budget.
The development process is also important to understand in relation to the requirements from a publisher, a licensor, or other external factors which may be involved in the project. There are often requirements from outsiders who have final say on things in the game, and it is important that you understand what they will need and when they will need it during the production of the game.
For example, we often don't schedule extra time to create a special E3 demo, or to create a demo that will be distributed to players before the game ships. We also often underestimate how many demos will need to be delivered to the publisher and how much time will be needed to wait for and address publisher feedback each month (or whatever interval). I have worked for publishers that have regular reviews, and at each review, your game could be killed if it looks bad or doesn't show progress.
I have worked on projects where approximately 20 percent of the total project resources and personnel were dedicated to just making demos -- which contributed very little to the overall game. It killed me to see this small dedicated demo team which just made demos to keep the project going. It was better to do that, however, than distracting the entire team for two or more weeks every few months to put together a demo for a review.
It is also important to understand when, where, and how your development process may be broken. Maybe you brought your development processes over from a larger company where you used to work, or maybe you used it on a previous project. Regardless of where the process came from, you also have to make sure that you aren't stubbornly sticking to it, if you realize it is broken and actually hurting the project.
There are no hard right and wrong answers to having a great process, but I have found that if the process isn't defined and refined, that this will be the biggest risk. I also have found that any process which is poorly documented and poorly followed is also a risk. So, in the end, you really need to understand your development model and process, or you will face major risks in many areas of the project.