You have completed the observe game and play games subtasks of understand game.

Let's reveal the next task in the game creation process, create version.

The circular arrow next to create version

indicates that you must do this task one or more times.

We need to divide our game into versions because big problems are hard to solve.

So, we break a big problem into

several smaller problems called versions that are easier to solve.

Previously, we used experiential decomposition to decompose,

understand game into two sub-tasks,

observed game and play game,

based on the criteria called Level of Engagement.

Level of engagement is how much interaction a person has with a problem.

Observing has the least interaction,

playing has more interaction,

and describing or explaining has the most interaction.

Instead of experiential decomposition,

we will use a new kind of problem decomposition

called Feature Selection to break our game into versions.

The complete hacking game has a set of features that includes; displaying passwords,

guessing a password, using a window supporting

multiple password attempts, and providing hints.

It is easier to create a version of the game that only supports some of

the features instead of trying to develop all of the features at once.

The first version starts with a few features,

and each subsequent version adds a few

more until the last version has all of the required features.

This makes each version easier to create since we only need to

focus on a few changes at a time.

Feature selection is used when you learn most new skills.

For example, if you learn a new language,

you don't start by writing an essay or delivering a speech.

These activities require many linguistic features

such as difficult words and complex grammar.

Instead, you start by learning simple words and

short phrases before adding more complicated language features.

Feature selection determines the feature set that each version must implement.

Implementation effort should be balanced across the versions.

Therefore one of the criteria for future selection is balanced feature sets.

You should select features for each version that

require approximately the same amount of effort to implement.

For example, the Window feature alone is about as much effort as both

displaying passwords and guessing a password together.

Sometimes, it is useful to split a single feature

into multiple features to help balance the feature sets.

For example, using a Window involves both opening a Window and closing a Window.

However, the second criteria for feature selection is Feature Dependency,

since, some features depend on other features.

A Window cannot be closed if it has not been opened.

Unfortunately, it can be difficult to estimate feature effort without experience.

Therefore, in this course,

we will select diversion feature sets for you.

You will learn to recognize good feature sets as you use them.

After this course, you can use your experience to

create your own feature sets for your own projects.

Let's look at Create Version and again Creation Process.

Create Version is too complex to treat as a single task.

Therefore, I will apply a third form of problem decomposition

called Problem Refinement to create appropriate subtasks.

Problem refinements solves a problem by decomposing

a complete problem into a sequence of increasingly detailed solutions.

The criteria for problem refinement is level of detail, also called precision.

The first solution is complete but has the least detail.

For example, drawing a smiley face has a few details,

but it is a complete solution for the problem of drawing a face.

The rest of the solutions are increasingly precise.

The last solution is just as complete as the first solution,

but it has all of the details.

For example, details can be added to

the smiley face until the final sketches the most detailed.

Here is another example of problem refinement.

Let's plan a trip from the University of Alberta,

U of A, to the University of British Columbia UBC.

I can write detailed directions to start at the U of A and end at UBC.

This would be like writing a program one line at a time from start to finish.

There are over 10 detailed instructions

just to get from the U of A to the Edmonton airport.

However, after creating these detailed directions,

I may decide to take the trains that are flying.

All the detailed instructions are now useless.

I've wasted time by focusing on details too soon.

Instead, I would use problem refinement to create an imprecise but complete plan.

First drive from the U of A to the Edmonton airport.

Then fly from the Edmonton airport to the Vancouver airport,

and then drive from the Vancouver airport to the UBC campus.
We can then test this plan by researching costs and time before committing to it.

If we want to try a different plan,

such as taking a train from Edmonton to Vancouver.

It is easier to make changes to this short plan

than to change a long list of detailed directions.

After researching the cost and time required,

I can refine the plan by using it to create more precise directions by air or by train.

Similarly, it is unwise to write code before you know the general form of your solution.

You should plan your solution before you write the details as code.

In software, development plans are called designs.

Therefore I will divide Create Version into three tasks Create Design,

Create Program and Reflect.

Each task creates a problem solution that is more precise than the previous one.

Create Design produces an imprecise solution

which is an outline from one version of hacking.

Create Program converts this imprecise outline

into a precise program for that version of hacking.

The reflect task assesses

your knowledge of the programming language techniques you applied,

evaluates your solution and identifies improvements for the next version.

Reflection is refinement since reflecting refines your understanding of your solution,

your knowledge, and your skills to the highest level of detail required for this version.

In addition, reflection is similar to the explain or

describe component of experiential decomposition,

since your reflection is like explaining these ideas to yourself.

This highest level of engagement leads to

the most detailed understanding for this version.

This is the last refinement, since after reflecting,

you will have the most precise design,

code and understanding of your solution.

Let's return to Create Design.

How should we accomplish this task?

What about trying something new?

We could decompose it into sub-tasks.

I know that's not really new but it works.

Our goal is to keep subdividing our tasks until

the final sub-tests are so easy to solve that the solution is obvious.

Let's use Problem Refinement to create three sub-tasks.

Understand version, Create version test plan and Create algorithm.

Understand version probably looks familiar to you

since you have already seen the understand game task.

In fact, if we expand the understanding version task,

observe game corresponds to observe

game version and play game corresponds to play game version.

Remember that experiential decomposition has three components.

Observe, play and describe or explain.

Create version description corresponds to describe.

It is a new task that produces a written description of the game version.

This description is an artifact,

it explains what the game does including its features and player actions.

The description is imprecise because it provides the goals of our implementation,

but not the details of the implementation itself.

The next task in create design is create version test plan.

This task creates a test plan that checks if the feature set is implemented correctly.

This artifact is more precise than the game description because it more

explicitly considers multiple gameplay scenarios.

The description describes all possible outcomes but the tests

prescribe which sequence of player actions result in which game outcomes.

For example, the description indicates that as

success or failure outcome may be displayed,

but the test plan prescribes exactly how

the game must be played to experience each outcome.

The create algorithms task produces the most precise artifact of the design.
An algorithm is a sequence of steps that prescribe how the code should be written.

It is more precise than the tests since the algorithm is closer to the code,

each step corresponds to a few lines of code.

However, an algorithm should be independent of any specific programming language.

So, an algorithm is less precise than the code that implements it.

Now that all of the tasks in create design have been introduced.

It's time for you to return to the game creation process.

To start understand version,

watch a game play video for the first version of hacking.

Ask yourself the same questions you asked when you watch the full game.

What does the game look like?

When do things appear in the game?

and what actions does the player take?

You will need the answers to these questions to create your version description.