In this video we are going to go through all of the core pieces of a world-class game development
project plan so that you can be sure to impress potential stakeholders and financiers and
get the support you need for your project.
Welcome back!
If you’re new to Ask Gamedev, we make videos to help you learn about the games industry
so that you can elevate your games and Inspire others.
If you’re on a gamedev journey, consider subscribing.
We’d love to help you along the way.
One of the biggest challenges in making video games can be securing external financing to
pay for development costs.
Building a thoughtful and well-structured development plan is the backbone of any pitch
for investment.
So what will potential financiers want to know from your game proposal pitch?
Ideally that you have a great game concept, and a well thought out plan on how to build
it on time, on budget, and at a high quality level.
This can be achieved through a variety of ways, and should always be customized to the
intended audience - but there are a few customary elements to any plan that you would be well
served to include in your pitch.
The first part of any good plan is to get your audience excited about the game concept.
A detailed game design pitch is a deep topic that we’ll probably tackle in another video
- but we’ve found that a good strategy is to cover the pillar features of your game,
why your idea is better or more interesting than competitor titles, and what the opportunity
is based on market data for rival games.
Beautiful concept art or early prototypes can be great to showcase your design vision.
With design pitches - It’s usually better to show than tell.
Once you have your game design outlined, the next part of your planning is to show the
relative “costs” of each feature of the game - or what the industry calls your project
‘scope’.
The scope is typically detailed in days of work needed to get the feature to a point
where it is representative of the final design, and fully open for testing by quality assurance.
Achieving ‘fully open for testing’ status can be referred to by many names, but the
term “Alpha” or “Feature Complete” are common naming conventions used in the
industry.
Scope estimates are typically broken down by all of the team members that will need
to participate in the development for that particular feature.
For example, let’s consider a hypothetical run mechanic for a character.
A designer, a character modeler, an animator, and an engineer may all be required to help
out in efforts to get a character to run in engine - and we would make estimates for each
discipline’s participation in man-days.
Estimates are best guess and are often revisited throughout development as more is learned
about the work and the team’s speed of execution.
You’ll want to repeat this estimation process for all features in your game - and then group
the tasks in a smart way so that you can see the relative time ‘costs’ of each major
feature.
Once this is complete, you have defined your project scope!
Next, Team and Capacity
Now that you have your scope defined, the next task is to detail your staffing plan
to address that work.
This involves listing all of your proposed team members, when they can start work on
the project, and when the team plans to be at Alpha or Feature Complete.
This is your development period.
Once you have those start and end dates, you will want to calculate the amount of work-days
within that period, while accounting for holidays and any non-work days.
This is your team capacity - and you will want to have it broken out by all of the major
team disciplines that are meaningful in your development.
Typical discipline categories might include engineering, 3D modeling, 2D Art, Animation,
or design.
You will then take the anticipated scope and calculate it as a percentage of the capacity.
You’ll want to see your scope at something less than 100% given that your staff will
inevitably miss some development time due to unforeseen commitments or sick time.
If you scope is greater than 100% of capacity, then you will either have to reduce scope
or add more resources to your team.
Now lets talk about Schedule.
So now you have defined your project scope, and the team capacity you will need to address
that work.
The next step is to take all of your scope tasks and put them in order of expected completion.
This is your project schedule - often referred to as a Gantt chart - and it is typically
put on a calendar timeline.
Microsoft Project.
Hansoft, Jira, and many other project management toolsets can be used for this purpose.
We’ll have links to each of these in the description.
First note that the recommendations in this video will focus primarily on Waterfall development
principles - despite the fact that many studios in our industry have embraced agile development.
At a high level, waterfall is very predictive and planning intensive, while Agile is more
fluid and embraces iteration.
The debate around the merits of each methodology rages on and that topic would need its own
video...
So we won’t go deep into that topic other to say that we choose to focus on Waterfall
because it typically aligns well with the predictability that financiers expect to see
in an initial pitch.
Moving to agile when development actually starts is an option that you can always consider.
There is no hard rule regarding what order you use for execution on your features, but
it is generally accepted that you will want to address the key product pillars first,
with specific focus on proving out any pipelines or tool-sets that will be needed for when
your team ramps to full staffing.
So focus your early development on whats matters most in the game, and what tools unblock teams
members from adding to productivity.
The schedule is a critical step to ensure the validity of your plan, as you may have
some tasks that have dependencies that could cause key dates to be missed.
For example, you may have three tasks that fit into your total capacity - but if one
cannot be started until a different task is completed, you could overshoot your expected
feature complete date.
These situations can be common when the team is dependent on delivery of certain items
from external partners - and when you see them you may need to shuffle the order of
operations of your tasks, add additional capacity, or reduce project scope.
Now lets talk about milestone deliverable's and themes
So you have you schedule fitting and all of your scope is accounted for.
The next step is to break your plan into milestones and define the work that will be done in each.
Milestones can be any length and should be customized to your particular development
goals - but monthly or 4 week milestones seem to be common in professional studios.
Milestones are typically where team leadership takes account of how they have progressed
against plan, to date, and determine any changes that need to be made to the go-forward plan.
Now let’s talk about how game development works from a timeline perspective.
Typical development plans use a two phased approach that has been borrowed
from the film industry
Specifically, the first phase of development is called pre-production and is usually staffed
with a small team of core experts.
This phase is commonly used to build a first prototype or virtual slice of the experience
to make sure that the development plan is solid.
Once this happens, the project moves into full development - or the ‘production period’.
This is when the team typically grows in size and operates at full capacity.
Gameplay depth and content creation are usually the goals of this period.
At the end of production, the game is usually at an alpha state - where are features are
complete and open for testing, the art and audio content are representative of final
quality.
The quality assurance efforts usually ramp up at the alpha stage, with testers hammering
on the game to ensures it is solid.
Once the build is relatively bug-free and solid, a beta version can be provided to a
small sample of consumer for some live feedback.
After addressing any final issues, a release candidate can be achieved that can act as
the final version that will be released to the public.
So now that you understand what each development phase looks like - you need to pencil in milestones
for each phase, including deliverables.
Giving each milestone a “theme” allows stakeholders to understand the main purpose
of that period of development.
Themes are also a good way to rally your team around a collective purpose for that phase
of development.
Once your deliverables are defined, QA can test your game against those goals and provide
feedback on your team efficiency - and external stakeholders can review this feedback to gauge
your likelihood of hitting the goals of your development plan.
The process of setting deliverables and reviewing progress at the end of a milestones, happen
frequently throughout development - and the specifics on the plan can change frequently.
A final piece of your development plan is to define the project risks.
Risks are things that could affect the cost, duration, or quality of development output.
Every project has risks, and the best development constantly review their risks and how to mitigate
them.
So what is a risk?
A good test is to ask yourself if the team has complete control over that issue.
If the answer is yes - then it probably isn’t a risk.
It might be just ‘difficult’ and something that financiers will expect the team to navigate.
A risk is commonly something that is out of control of the development team, like an external
piece of technology that will be needed, Typical examples of a risk might include the delivery
of a necessary piece of technology by an external team, or a unclear first party ruling on the
acceptability of one of your features.
When you define your project risks - the key things to determine are what specifically
are the possible implications of the risk, how you plan to mitigate the risk, what your
contingency plan is if you can’t mitigate it, who ultimately owns the mitigation of
the risk, and at what date you plan to either close the risk or have a significant update.
Having a clear and thoughtful understanding of the project risks shows a financier that
you’ve thought deeply about how to execute development and reduce the chances of not
delivering on expectations.
So now you know the pieces of a professional grade development plan.
You can use this format to pitch for investment money - or to provide milestone updates when
already in development.
Let’s get a conversation going and help our fellow channel subscribers with your thoughts
on how to develop a development plan.
What do you think are the key elements of a plan?
What do you think differentiates and make a plan stand out?
Let the community members know your thoughts in the comments and we call all learn together
on this topic.
Thanks for watching, we are Ask Gamedev, and we make videos on games, the game industry
and more.
If you like our content, please subscribe!
We’ll be back next week with a new video.