Build a Player Profile Generator

Core path: 35 minutes

Week 3 is where programs stop being little scripts that only say what you typed into the source file. Now the program can receive information from somebody else, convert it, calculate with it, and produce a result.

That sounds simple until the first time input() hands you text and you try to treat it like a number.

This build makes the entire data path visible.

Decide what each input actually is

Before writing code, look at the information you want:

• player name;
• age;
• favorite game;
• hours played per week;
• skill rating.

Some of those values should stay text. Some need to become numbers because the program will calculate with them.

Start with:

player_name = input("Player name: ")
age = int(input("Age: "))
favorite_game = input("Favorite game: ")
hours_per_week = float(input("Hours played per week: "))
skill_rating = int(input("Skill rating (1-10): "))

Before running it, explain why player_name does not need int() while age does.

If your answer is just "because age is a number," go one step deeper: what operation will fail later if age remains a string?

Make the data do something

Calculate:

yearly_hours = hours_per_week * 52
next_year_age = age + 1

Now the program is doing more than storing values. It is producing new values from existing ones.

Trace one example by hand:

hours_per_week = 8.5
        ↓
8.5 * 52
        ↓
yearly_hours = 442.0

That arrow means the value is used to produce the next value. It does not mean Python magically "knows" what yearly hours should be.

Print a real profile

Use f-strings to make the output readable:

print()
print("===== PLAYER PROFILE =====")
print(f"Player: {player_name}")
print(f"Age: {age}")
print(f"Favorite Game: {favorite_game}")
print(f"Weekly Hours: {hours_per_week}")
print(f"Estimated Yearly Hours: {yearly_hours}")
print(f"Skill Rating: {skill_rating}/10")
print("==========================")

Run it with values you can calculate mentally. That gives you a quick way to tell whether the result makes sense.

Add two fields of your own

Add at least two original data points. Examples:

• favorite character;
• team name;
• controller type;
• tournaments played;
• practice sessions per week.

For each new field, decide:

1. variable name;
2. prompt text;
3. expected data type;
4. whether conversion is required;
5. whether the value will be used in a calculation.

Avoid mystery names like a or x here. A variable name should save the next reader from having to decode your program.

Break the type chain on purpose

Remove int() from the age input:

age = input("Age: ")

Then leave:

next_year_age = age + 1

Run it.

Do not fix it immediately.

Record:

• the value entered;
• the type Python actually stored;
• the operation that failed;
• the error message;
• the exact repair.

Then verify the repair by running the program again.

Inspect instead of guessing

Temporarily add:

print(type(player_name))
print(type(age))
print(type(hours_per_week))
print(type(skill_rating))

Those lines are diagnostic code. You are not adding a feature. You are asking the running program to reveal its state.

Week 2 gave you:

Where am I?
pwd
ls

Week 3 adds:

What value do I have?
print(value)

What type is it?
print(type(value))

That is how a troubleshooting toolkit grows: one useful question at a time.

One more calculation

Add:

daily_average = hours_per_week / 7
print(f"Average Daily Hours: {daily_average:.1f}")

Try hours_per_week = 14.

The displayed result should be 2.0, not simply 2, because division produces a floating-point result in Python 3.

You do not need to memorize every conversion rule yet. You do need to notice when the type of a value affects the operations the program can perform.

Success evidence

Your finished program should demonstrate all of these:

• at least five collected inputs;
• at least two original fields;
• meaningful variable names;
• both integer and floating-point conversion;
• at least two calculated values;
• formatted output;
• one preserved type-related failure and its repair; and
• temporary type inspection that you can explain.

If the final screen looks correct but you cannot explain where the numbers came from, the program is not finished yet.