In this episode I take a basic look into the simple basics of the waterfall methodology.
Why is project management important?
In the most simplistic terms, all project management is, is structured planning.
To get to the answer of this, you must first understand and appreciate why it is important to plan.
To understand the importance of planning, let’s take a look at some quotes about planning:
“All have the will to win, few have the will to prepare”
“A perfect plan is like a unicorn, everyone can describe one, but no one has actually seen one”
“Planning is useless, but planning is everything”
In essence, all planning does is minimize risks and therefore all project management aims to do is
find a structure in which you can plan projects out that will have minimum possible rate of failure.
To summarize, project management minimizes risk for failure and does not guarantee a projects' success.
The Common Project Lifecycle/Stages
There are many definitions and charts used to explain the basic backbone of the project lifecycle, however
I like to use the following:
Definition
Planning
Execution
Monitoring
Closure
Definition
Think of this stage as drawing out your forest. Before you start on any project, it is always in your best
interest to visualize what you want to create.
In the definition stage, all you are attempting to do is find the direction for your given project.
In programming this would be the stage in which you find your project goals, objectives, and risk.
In game development you would also try to find in this stage the basic core concept of your game, which
includes the game genre, core game design concepts, story logline, and even the basics of worldbuilding will
fit into this stage.
Planning
If the definition stage is drawing out your forest, then the planning stage is drawing out each individual tree of
your forest.
This basically amounts to planning out your tasks for the project.
In game development this would be the stage in which you flesh out all your game design theories, have a more
rounded world building design, and fleshing out the story of your game.
In general the planning stage is where you try to find the errors in planning, as it is cheaper to catch errors
in planning on this stage than it is in any of the other stages.
Execution
The execution phase is the simplest to understand. All you worry about doing in the stage is finding and
planting your trees to build out your forest.
In programming this would be where you start coding for your project.
In game development, this would be where you start testing out with your team whether your game design
ideas are clicking (although this could also be done in the planning stage as well).
Monitoring
As your project is executing, it is also important to make sure that your team or yourself are keeping to the
schedule.
The biggest problem solo/indie game developers have is adding more features that originally planned.
The point of monitoring is to avoid that problem by making sure nothing is added unnecessarily.
In general if you are ahead of schedule, add more features; if you are behind schedule, remove features.
The main goal of monitoring is to stay on schedule for your desired release date.
Closure
Lastly you just have to know when to say stop.
In a perfect world, this would be the phase where you have finished adding all your features and your
project is ready for release.
In the realistic world, our plans are never perfect.
You can never fully estimate when a project will finish by
and sometimes if you are behind schedule, you just have to say “no more, it is ready to release”.
How much time should be spent on executing a project?
The general rule is that 20% of total project time should be spent on planning a project; 80% of the total
project time should be spent on executing a project.
Starting from the top, you start with Game Concepts. In this “phase” you work out all the requirements
expected from you at this phase. What is expected from you depends entirely on what you need done on this phase,
or an established procedure set by the company.
In this case the game concept phase should be the cheapest “phase” wherein if you had to redo this phase,
you don’t lose out on a lot of time and money.
Once the game concept phase has been completed, you will then move onto the game design phase which entails
more expensive procedures and processes of game development than the game concept phase, but is still cheaper
to redo than the coding phase.
When a “phase” has been completed, you move onto the next part of the waterfall method.
Pros and Cons of the waterfall method
The waterfall method does come with its pros and cons, something to keep in mind is that no single project
management is perfect and will add or remove some parts of project management to favor other parts.
Pros
Clear structure for development
End goals are set at the beginning
Requirements of the game are clear before coding
Milestones of the project are laid out
Cons
Bigger Projects are costlier to change in later stages of the development lifecycle
Lack of flexibility when requirements need to change
Testing is not done after coding and art designs have been finalized (music, animation, art)
Longer delivery times if changes are made in the later stages
When I say big projects, I mean projects at the scope of creating a game such as Jak and Daxter versus a game
a solo developer would typically make.
Lastly I would say that the waterfall method is a great intro into project management, but the waterfall method
at its purest form is completely outdated and if you were to start your own project, to take a look at a hybrid
project management methodology that combines the agile method with the waterfall method.
I will take a look at this in a future series.
Transcript
Hello and welcome to the Pong Gdscript Basics Series. In this episode, we will be taking a look at the basics of the Waterfall methodology. Godot Tutorials is not sponsored by or affiliated with the Godot game engine. In this episode, we will be taking a look at why project management is important. The basics of the Common Project life cycles. The waterfall methodology, and lastly, the pros and cons of the waterfall method.
Now, why exactly is project management important? Well, project management is just another word for structured planning. The better question is why is planning important to find this answer? Let's go ahead and take a look at some common quotes about planning. The first one is all have the will to win for you, have the will to prepare. The second quote is A perfect plan is like a unicorn.
Everyone can describe one, but no one has actually seen one. And lastly, planning is useless, but planning is everything. Basically, this boils down to planning does not guarantee success. All it does is minimize risk. And all project management really is is about minimizing risks. Let's go ahead and take a look at the Common Project lifecycle.
Different people have different ways of defining the project lifecycle. However, I like to define it in five different steps.
The first step is definition. The second, this planning. Third is execution. Fourth is monitoring and last is closure. Think of project life cycles as creating your own forest. Before you create your own forest, you must first on paper draw out how you would like the forest to look like. After you have drawn out what your forest looks like, you then go ahead and draw what your individual trees will look like.
Once you've finished drawing all the individual trees out in your project, you move on to execution, which is just basically planting your trees while people are planting trees. You must then monitor to make sure that all your tree planters are keeping to this schedule. And lastly, to finish the project, you have to know when to say stop the forest is big enough. We are done now.
In reality, each step has clear and concise goals you try to keep. So, for example, in the first step definition, what you're really trying to do is outline your project goals, your objectives, the risks and your project scope. After you have defined everything, you move on to creating tasks. Basically, you take your project goal and create requirements that you need to fulfill. After you have created your requirements, you move on to the execution step and this is simply creating your product and testing your product out while execution is happening.
You're also monitoring the execution. Basically, if you're ahead of schedule, you may want to add more requirements and if you are behind schedule, you may want to remove requirements. And lastly, the project cannot continue on forever and must properly close. And so at some point you must say that the product we have now is good enough. We should end the project. Now, in terms of game development, the first step will be game design.
Basically, all your game designers will get together and confirm what the definition of the project is next. When creating requirements, it is common that game designers and programmers get together to see what the requirements are and possibly calculate how long it may take to develop certain requirements. Once everyone has agreed on a direction, everyone moves on to the execution phase. This would include programming, creation of our assets and testing.
And while execution is going on, there will be people to monitor, usually referred to as project managers, and their job is just to make sure that the game design and programming are on schedule and again adding and removing requirements when needed. And lastly, you need to know when to end your project and send out your game for release. Basically making sure that your game is good enough for people to buy and leave good reviews. Now, there is no set rule on how much time should be spent on which phase of the project life cycle.
However, most people generally agree that 20 percent of your total project time should be dedicated to the definition and planning phase, and the other 80 percent should be dedicated to the execution phase, which includes creating your product and testing your product out. One type of project management methodology is the Waterfall Methodology, which was written and theorized in the 1970s and popularized in the 1980s and 1990s.
The Waterfall methodology states that the best and most productive format of creating large software systems is to categorize software projects in two phases, starting with the phase that is the cheapest to produce and once fully complete, move on to another subsequent phase that is a little more expensive. Let's go ahead and take a look at a basic example of the waterfall methodology you may find yourself using in game development.
Let's start with game concept. Game concept would be considered your definition phase and the project management lifecycle. In the game concept phase, you are basically setting up your project goals. This would include what game genre are remaking? What consoles are we going to develop the game for? Who are we selling our game to? How many people would it take to create this particular game?
Basically, in the game concept phase, what we are doing is fleshing out our idea of the game we want to make.
Once we have a direction on the type of game we want to make, we need to put pen to paper and finally decide the game design theory of our game. This process can take months to years depending on the project scope. But regardless of game design, although being more expensive in the process than creating a game concept is still cheaper than coding. And so therefore, if your game doesn't make sense, it is beneficial that you figure that out during the game design phase.
The game design phase would be creating documentation on your game play concept and on top of that, what your core mechanics will be for the game. In essence, if something doesn't feel right, it is cheaper to find that out during the game design phase than it is in any of the other phases in the game development lifecycle. Once you've figured out a game design, you will then go ahead and execute and this will be the coding phase.
In the coding phase, you are basically coding out whatever you have fleshed out in your game design phase. On top of that, you're going to do minor debugging on your code during the coding phase to make sure that your game is running right. However, once you're completely done coding the entirety of your video game, you are going to go ahead and do what is called player testing and focus group testing. Basically, you're going to show your game to the general public or a closed test group to make sure that your game is indeed fun to play.
Now, at this part of the game development phase, if your game completely sucks, it is going to cost a lot more to change direction on this part of the waterfall methodology because we have to restart the process from the game design phase in order to fix the problems that you found from your player testing group. However, if your game is indeed fun to play, you will move on to releasing your game to the general public.
And because you went through each individual phase in the game development process using the waterfall methodology, you have minimized risk by making sure you did in fact create a fun game to play and tested that it was fun to play before releasing and therefore we can expect at least to make profit.
But again, success is not guaranteed. All the Waterfall methodology does is make sure that we minimize risk by having a process where we start out with phases that are. Cheap to throw away or redo in this case, game concepts and game design is cheaper to redo because all we are dealing with are game ideas, whereas the coding and testing part of the process is a little more expensive to redo because you've got to put a little more effort into it.
And so, again, the further down we go in the waterfall methodology, the more expensive it is to change our requirements. Now, the pros and cons of the waterfall method, are they following the positives of the waterfall method, is that we do have a clear structure for our development process. This means that end goals are set at the beginning, meaning that everyone on our team knows exactly what kind of requirements are needed to make this game on.
Top of that, requirements are laid out before the coding phase, along with certain milestones that our game development team needs to achieve. The negatives are that bigger projects are costlier to change in the later stages of the development lifecycle, using the waterfall method on top of that for bigger projects, Waterfall method does lack flexibility when you need to change requirements. And this is because we have to go back to the beginning of the process.
On top of that, testing is not done until, after all, coding and art designs have been finalized. This would include music, animations and art. One thing to note is that art is one of the more expensive things in game development. And lastly, for bigger projects, longer delivery times are needed if changes are made in the later stages. Let's go ahead and take a look at a few game examples. The first espec men from the 1980s, Pacman was created by a single developer at Nemko, and this game had a production cost of 100000 dollars.
The Pacman game took about six months of production time. And for a game of this scope, you don't really need anything formal. However, if you do need something, the waterfall method would be something to look at next. Let's go ahead and take a look at the USA Super Mario Brothers three game for the Nintendo Entertainment System. This game was released in nineteen ninety one. So about eleven years after PPacmanwas released, Super Mario Brothers three took two years of development time.
Keep in mind that this project is still considered small. This project took 10 people to make with a budget of about under one million to keep everyone on task. A formal project management style is needed. This is because teams need organization. The waterfall method is OK for a project of this size. Now let's move forward another ten years and we are looking at the game called Jakin Daxter for the PlayStation two in two thousand and one now.
The Jak and Daxter game would be considered a big project. One hour of animation in this game require six full time animators and four support animators. The JJakand Daxter game had a budget of fourteen million dollars. The entire game required thirty five full time staff over the period of three years to complete a pure water form. Methodology will crumble a game project of this size.
Now let's go ahead and take a look at why the Waterfall methodology will not work for a game of the project size of Jak and Daxter. Now, for JJakand Daxter, the game concept alone could take a week, a month or even a year to flesh out. Keep in mind that the game concept is basically just an idea. It may be jotted down in notes. However, no one is taking the game design seriously at the game concept phase.
Now, after the game concept has been finalized, the game moves onto the game design phase.
Now, keep in mind that game design is not game coding. This means that we don't really have something tangible yet to show other players or even ourselves. And yet, for a game at the project scope size of the Jak and Daxtar game, the game design process could take months or even years. However, once requirements and game design documentation have been finalized, we then move on to the game coding phase, which alone could take months or years, depending on the.
Game design documentation, again, keep in mind that more features means more cost and more production time. However, regardless, we don't know whether our game is fun to play until we do player testing. However, this is where the problem happens. Imagine if our game does poorly during the player testing phase. Imagine if player testing showed that our core gameplay and game design for Jak and Daxter sucks. This means we need to restart the process again from the game design phase because we need to redo our game design documentation.
Now, in this case, player testing lets us know that if we take our game to market the chances of success for our game. In this case, the testing phase minimizes risks that we don't put out a game that doesn't make money. Now, as you can see here, the pure waterfall methodology for bigger game projects will, in fact, bankrupt. Now, what I mean by that is if we keep failing the testing phase over and over again, after having to completely finish our game design documentation and completely finish our coding phase, at some point we will run out of money.
And this is the worst case scenario for the waterfall methodology when dealing with large projects. Now, when you have a game project or a software project of this size, the solution will be to adopt a more agile type of development project lifecycle. Well, that's all I have for you in this episode. Thank you so much for joining me. Thank you for clicking the like button. And thank you for clicking the subscribe button.
00:16:39:27 - 00:16:49:17
If you'd like to join my weekly newsletter, please feel free to visit my website. I look forward to seeing you in the next episode. Have an amazing day.
Why bother learning project management?
Project management is a great skill to have especially if you have any desire to become a solo or indie developer.
Understanding project management can help you understand what is and what is not possible to make with a game idea you have.
Resources
Winston W. Royce 1970 Paper on the Waterfall Methodology:
