DEV Community

Tehreem Fatima
Tehreem Fatima

Posted on

Building the Higher or Lower Game: A Fun Way to Practice Python Fundamentals

#learning #python #gamedev #programming

Introduction

I'm on Day 14 of Dr. Angela Yu's "100 Days of Code" course, and today I built something that was actually fun to play with while learning Python concepts. The game is simple: compare Instagram followers between two celebrities and guess who has more. It sounds easy, but building it taught me valuable lessons about data structures, game logic, and user experience.

GitHub Repo: Higher or Lower Game

What I Built

A command-line game where:

  1. The computer randomly picks two celebrities/brands/athletes
  2. You see their name, profession, and country
  3. You guess who has more Instagram followers (A or B)
  4. You keep playing and building your score until you guess wrong
  5. One wrong guess ends the game

Simple concept. But the code behind it? That's where the learning happens.

The Data Structure Challenge

This project introduced me to a data structure I hadn't really used deeply before: a list of dictionaries.

data = [
    {
        'name': 'Cristiano Ronaldo',
        'follower_count': 215,
        'description': 'Footballer',
        'country': 'Portugal'
    },
    # ... 50+ more profiles
]
Enter fullscreen mode Exit fullscreen mode

This is different from my previous projects. In my student management system, I used a dictionary with student names as keys. Here, I'm working with a list of dictionaries—each entry is independent, and I randomly pick from the list.

The difference matters:

  • Dictionary with keys: Great for lookups by name
  • List of dictionaries: Better for iterating, random selection, collections of similar data

This is a subtle but important distinction that will come up a lot in real-world programming.

Game Logic: The Interesting Part

The core logic has three steps:

Step 1: Format and Display
I created a format_participant() function to display each profile consistently:

f"{data['name']}, a {data['description']}, from {data['country']}"
Enter fullscreen mode Exit fullscreen mode

Clean, reusable, easy to read.

Step 2: Compare Followers
The follower_count() function compares two participants and returns who has more followers:

if participant1["follower_count"] > participant2["follower_count"]:
    return participant1
else:
    return participant2
Enter fullscreen mode Exit fullscreen mode

Simple comparison logic, but it's the heart of the game.

Step 3: Check User's Guess
The compare() function maps the user's input (A or B) to the actual participant objects:

if guess == "A":
    user_choice = participant1
else:
    user_choice = participant2
Enter fullscreen mode Exit fullscreen mode

Then I compare if the user chose correctly.

What Made This Different from My Previous Projects

Before: I built management systems (student tracker, book store, pharmacy inventory)

This: I built a game

Management systems are CRUD (Create, Read, Update, Delete). They follow a predictable pattern. Games require different thinking:

  • Win/lose conditions
  • Score tracking
  • Continuous flow until failure
  • User engagement and fun

This project made me think about user experience, not just functionality.

What I Learned

1. Random Selection and Game Flow 

participant2 = random.choice(data)
while participant2 == participant1:
    participant2 = random.choice(data)
Enter fullscreen mode Exit fullscreen mode

I had to ensure the two participants are always different. This is a common pattern: keep trying until you get a valid result.

2. Breaking Logic Into Functions

Instead of one massive game loop, I separated concerns:

  • Formatting display
  • Comparing values
  • Mapping user input
  • Running the game

Each function does ONE thing. When something goes wrong, I know exactly where to look.

3. Input Validation Without Crashing 

while guess != "A" and guess != "B":
    guess = input("You type incorrect value. Type 'A' or 'B': ").strip().title()
Enter fullscreen mode Exit fullscreen mode

This loop ensures the user enters valid input before proceeding. No crashes, just re-asking.

4. Screen Management 

print("\n" * 25)  # Clear screen
Enter fullscreen mode Exit fullscreen mode

Small detail, but it makes the game feel polished. After each round, the screen clears so it doesn't get cluttered.

The Difference Between Theory and Practice

When I first learned about functions, it seemed abstract. "Why break code into functions?"

Building this game, I felt the difference:

  • If the display format changes, I update ONE function (format_participant())
  • If the comparison logic needs to change, I update ONE function (follower_count())
  • If I want to add a new feature, I know where to add it

This is why professional developers structure code this way. It's not just about looking good—it's about maintainability.

What Surprised Me

I thought building a game would be harder. But because I:

  1. Separated concerns into functions
  2. Validated input properly
  3. Thought about the flow before coding

...it came together quickly and worked on the first try.

The surprise wasn't that it was easy. The surprise was that good planning makes coding easy.

Next Steps

This game works, but here's what I could add:

  • Save high scores to a file
  • Add difficulty levels
  • Track statistics (correct answers, most guessed celebrity)
  • Implement a leaderboard
  • Add more celebrities

But for now, I'm happy with v1.0.0.

What This Taught Me About Learning

I'm 14 days into a 100-day journey. I've built 10+ projects. I'm not a professional—I'm still a beginner.

But I'm noticing something: the more I build, the faster I learn.

When I started, writing functions felt tedious. Now, I naturally break problems into functions before I start coding.

When I started, validation seemed annoying. Now, I automatically add it.

This is how learning works. Not through tutorials, but through building things and seeing patterns emerge.

Challenge to Other Learners

If you're learning to code:

  1. Don't just watch tutorials
  2. Build projects that interest YOU
  3. Don't aim for perfection—aim for "working"
  4. Break your code into functions
  5. Think about the user experience, not just the code

I built this game because I thought it would be fun. And it was. That engagement matters more than any tutorial.

Let's Connect

If you're also learning to code, I'd love to hear about your journey. What projects are you building? What surprised you most about learning to code?

Drop a comment below!

Project Links:

Author: Tehreem Fatima

Learning Journey: Day 14 of 100 Days of Code

Current Focus: Python Fundamentals & Project-Based Learning

Top comments (1)

Some comments may only be visible to logged-in visitors. Sign in to view all comments.