DEV Community: Chukwuemeka Ngumoha

Fixing “Property 'user' does not exist on type 'Request'” in Express + TypeScript

Chukwuemeka Ngumoha — Sat, 25 Apr 2026 20:45:41 +0000

If you’ve ever tried adding req.user inside Express middleware while using TypeScript, you’ve probably run into this error:

Property 'user' does not exist on type 'Request'

I hit this while building authentication middleware for my API with JWT and Prisma.

The issue is simple: Express’ default Request type only knows about built-in properties like body, params, and headers. It has no idea about your custom user property.

The Fix

You need to extend Express’ Request interface using declaration merging.

Step 1: Create a type declaration file

src/types/express/index.d.ts

Step 2: Add this definition

import { JwtPayload } from "jsonwebtoken";

declare module 'express-serve-static-core' {
  export interface Request {
    user ?: string | JwtPayload,
  }
}

export {};

NOTES:

declare module 'express-serve-static-core' is relevant if you're using the newer versions of express in your project. Otherwise, change that line to declare namespace Express.
The export {} is important — without it, TypeScript may not properly recognize the file.

Step 3: Update `tsconfig.json`

Make sure TypeScript can see your custom types:

{
  "files": ["./src/types/express/index.d.ts"],
  "compilerOptions": {
    ...
    "typeRoots": [
      "./node_modules/@types",
      "./src/types"
    ],
  },
  ...
}

Step 4: Restart TypeScript + Dev Server

Sometimes VS Code and nodemon cache old types.

Restart your TS server
Stop and restart your dev server (e.g nodemon)

Result

Now this works cleanly:

req.user = decoded;

No IntelliSense errors. No compiler complaints.

Final Note

This issue looks small, but understanding declaration merging is one of those TypeScript moments that makes backend development much smoother. Anyway, I hope this was helpful. Feel free to leave your thoughts in the comments. Have fun building !!!

Just commenced a new blog series on common mistakes and ideas beginners miss in React. Check it out.

Chukwuemeka Ngumoha — Thu, 18 Sep 2025 17:51:31 +0000

Chukwuemeka Ngumoha

Sep 18 '25

React: State vs Props

#react #tutorial

Comments

3 min read

React: State vs Props

Chukwuemeka Ngumoha — Thu, 18 Sep 2025 17:50:22 +0000

What started out in 2013 as a small effort by a team at Facebook (now Meta) to simplify the process of building performant web applications, slowly but surely has morphed into one of the most used web technologies on the planet today and has even gone beyond the web into adjacent fields like Mobile Development with React Native e.t.c.

Not only did React improve the way we write code for the web, it also gave us a new way to think about structuring web sites and apps: Components. This paradigm has gone on to influence almost every other web framework/library in existence today. Everybody has adopted the Component paradigm.

Despite it's widespread adoption, React is still a technology with it's rules and quirks which, if not properly understood, could lead to some very funny errors A.K.A Gotchas.

So in this series, we'll be exploring some of the most common Gotchas. Starting with the most basic Gotcha: The difference between Props and State in React and when to use which. This will be the focus of this post.

DISCLAIMER: This blog post assumes you already have some experience working with React. If you don't, check out this resource before proceeding with the rest of the post.

Alright, let's dive in !

Let's consider a hypothetical scenario:

We're building an app to keep track of the number of cars we see on the road. The app comprises of only two U.I elements: A button and a text element. When the button is clicked, the number in the text element increases by one. The code for such an app would look something like this:

import React, { useState } from 'react';

export function App() {

  return (
    <div className='App'>
      <Counter buttonText="Increment"/>
    </div>
  );
}

export function Counter(props) {
  const [count, setCount] = useState(0);

  const increment = () => setCount((count) => count + 1);

  return (
    <>
      <h1>{count}</h1>
      <button onClick={increment}>{ props.buttonText }</button>
    </>
  )

}

State

So, what do we mean by State in React ?

In React, the State of a component refers to the data held or stored within that component which it can manipulate or adjust in order to change it's appearance on the screen. i.e Data owned and manipulated by the component.

Props

If the State of a component is data held by that component, then:

Props are data passed into a component from outside, usually from a parent component, which is aimed at adjusting the characteristics of the component. i.e Data given to a component to make it behave or appear a certain way.

In this case, it's very clear that Props are not supposed to be modified by the component which receives them. They're in fact read-only and should not be modified.

In a Nutshell

The State of a component refers to data stored and controlled by that component which affects it's behavior or appearance while it's Props are the data passed into it in order to modify it's behavior or appearance.

The critical difference lies in the fact that while the State of a component is controlled by that component, the Props passed into it are not under it's control.

When to use which ?

Use Props when:

You want to pass data from a parent to a child component.
The data is read-only for the child (the child doesn’t change it).

From our example, we see that Counter relies on a buttonText prop passed into it from the parent App component and uses that to modify the label on it's child button element. This is a good use of Props.

Use State when:

The data needs to change over time inside the component.
The component should re-render when that data changes.

From our example above, we notice that our Counter component maintains a count state which is updated whenever the button is clicked. The Counter component has full control of count and can modify it however it wants hence the need to represent it as a State.

I hope this helps. Thanks for reading.

[Boost]

Chukwuemeka Ngumoha — Wed, 03 Sep 2025 16:06:55 +0000

Chukwuemeka Ngumoha

Sep 3 '25

Building Chrome Dinosaur Game in Pygame (Part 6: Press Pause ⏸️)

#python #pygame #gamedev #tutorial

Comments

4 min read

Building Chrome Dinosaur Game in Pygame (Part 6: Press Pause ⏸️)

Chukwuemeka Ngumoha — Wed, 03 Sep 2025 16:06:38 +0000

If you’ve been following this series, you know we’ve come a long way — from setting up Pygame, to making the Dino jump with gravity, to scrolling horizons, and even adding randomized obstacles. 🎉

At this point, I originally planned to dive into collision detection, but I realized something important: trying to build the game and explain every step in a tutorial format was slowing me down. Instead of dragging things out, I’d like to pause here and wrap up this mini-project by sharing what I’ve learned so far.

This way, you still get the value (and a complete game skeleton to build on), and I can move on to exploring even bigger and better projects in Pygame and learning more in the process. We all win

In this post, I’ll:

Recap the main things we built together

Highlight the key Pygame concepts I learned

Point you toward how you can handle collision detection on your own

Share what’s next for me

Alright, let's dive in one last time !

Our game so far

Even as a work in progress, our game is still awesome. In the course of the series, we were able to:

Set up the game project and installed relevant dependencies. In the process:
- We learned how to install Pygame
- We learned what Pygame is all about
Started working with Pygame:
- Learning how to work with a simple Pygame boilerplate. Specifically, what each part of the boilerplate does.
- Ran the code and saw the canvas for the first time.
- Got introduced to the concept of Surfaces and changing the background color of the canvas.
Created a progressively unfolding pathway for the Dino. In the process:
- We learned about the Coordinate system in Pygame and it's use in positioning game elements on the canvas.
- We learned how to display images on the canvas.
- We learned about the concept of a Refresh Rate and how to control it in Pygame.
- We learned about using offsets to push game elements along the horizontal x axis on the canvas, giving an illusion of motion.
Placed our Dinosaur on the open road and let it run wild. In the process:
- We learned how to scale the width and height of images we display on the canvas.
- We learned about Events and how we can create custom events and read them within the event checking loop.
- We also learned how to repeatedly send events on to the event queue and used that knowledge to make the Dino move it's legs. That was a really cool lesson.
- We also used all we learned to ensure that game play only starts once the user presses the SPACE key.
We made our Dinosaur jump in order to avoid obstacles. In the process:
- We learned how to asynchronously listen to key presses on the keyboard. And then, we used this functionality to vary how high the Dinosaur jumped based on how long the SPACE key was pressed.
- We also learned how to create bounding boxes around game elements in order to be able to use these bounding boxes to dynamically control the positions of said elements.
Finally, we added the deadly obstacles on the Dino's path. In the process:
- We worked with the pygame.event.Event() object and learned how to trigger Pygame events based on a condition.

Look at us! We’ve covered a lot, and you now have a neat little game skeleton you can keep building on.

Why I'm pausing the series

When I started this series, my goal was simple: learn Pygame by building something fun and familiar — a Chrome Dino clone — and share that journey step by step. Along the way, I discovered that writing each post in a full tutorial style while still figuring things out for myself was slowing me down more than I expected.

Instead of staying in the flow of building, I often found myself splitting focus between coding mode and teaching mode. That back-and-forth made progress on the actual game feel slower, and I realized I was spending more time explaining every detail than experimenting, failing fast, and moving forward.

So, rather than drag out the series and burn myself out, I decided to call this post an intermission. The game in its current form already demonstrates a lot of Pygame fundamentals — events, image handling, motion through offsets, and obstacle generation. That’s a strong foundation, and it feels like a natural point to pause.

This doesn’t mean I’m done with Pygame. Quite the opposite. I want to take what I’ve learned here and channel it into a bigger, more ambitious project where I can dive deeper without the pressure of writing a tutorial for every step.

Forgive me, dear reader — for even I could not escape the limits of being human.

If you’ve been following along, thank you — I hope you picked up some insights you can use in your own projects. And don’t worry: I’ll still be sharing what I build next, just in a format that works better for both me and you.

To access the complete codebase for this project, please check out the Github repo. Give the repo a star ⭐ if this series has helped, entertained or educated you in any way. And for now:

Thanks for reading.

[Boost]

Chukwuemeka Ngumoha — Wed, 03 Sep 2025 13:54:42 +0000

Chukwuemeka Ngumoha

Sep 3 '25

Building Chrome Dinosaur Game in Pygame (Part 5: Deadly Cactus)

#python #pygame #gamedev #tutorial

Comments

7 min read

Building Chrome Dinosaur Game in Pygame (Part 5: Deadly Cactus)

Chukwuemeka Ngumoha — Wed, 03 Sep 2025 13:54:24 +0000

In the last post, we successfully implemented the Jump functionality for our Dino so it could avoid deadly obstacles on it's path and in the course of doing that, we learned a bit about creating bounding boxes and listening for key presses asynchronously. In this post, we're going to be adding those deadly obstacles the Dino is going to need to avoid.

But before we go any further, I need to make it clear that I'm assuming the following things about you:

You understand basic English. Trust me, this is not a given.

You possess basic knowledge of the Python programming language. If not, check out this coding resource to learn.

You're following along on a Mac, Linux or Windows Laptop or Desktop. You can't use your smartphone for this I'm afraid.

You can comfortably create bounding boxes to aid in dynamic postioning of elements on screen. If you can't, then quickly checkout the previous post before proceeding with this one.

Alright, let's dive in!

Displaying Obstacles

We've covered much of the core functionality of our game. All that's left now is adding the Cacti that will serve as obstacles for our Dino:

Our codebase is currently too big to be displayed in it's entirety any longer. So with that in mind, I'll only be displaying the snippets most relevant to what we're currently working on. To see the full code from the last post, check it out on Github.

Now, let's talk about the obstacles in our game. A quick peek at the final game above reveals a few characteristics of the obstacles in our game:

They all have varied heights. i.e Some are tall while others are short
They are all of equal width.
They randomly appear on the screen alone or in a cluster of two or three cacti.
They always appear at an interval that ensures enough space for our Dino to jump over each set without bumping into the next.
Once they appear, each set seems to scroll across the screen with the horizon.

Bearing these in mind, let's get busy implementing all these features into our game.

To keep things clear, we'll take it one step at a time:

Varied Height, Equal Width

To display a cactus on the screen, we need to import our Cactus image:

...
CACTUS = pygame.image.load(os.path.join(
    'Assets', 'sprites', '1_Cactus.png')).convert_alpha()

...
def draw_window(play, dino):
    ...

...

def main():
    ...

...

NOTE: The convert_alpha() is a pygame image method which converts the imported image into the image format of your game while preserving it's original per-pixel transparency values.

Notice from the main game that each set of obstacles is always displayed as a group of one to three members. This suggests that we can represent each set as a collection. i.e An array or list which houses the set of obstacles currently being displayed.

Also take note of the fact that the number of cacti in each set is always random with each set having cacti of similar height.

As a first step, let’s display our obstacles at the right edge of the screen and make sure that each time we restart the game, the number of cacti are randomized. Here's how I accomplished exactly that:

...
CACTUS = pygame.image.load(os.path.join(
    'Assets', 'sprites', '1_Cactus.png')).convert_alpha()
...
CACTUS_WIDTH = 30  # Defines the uniform width of all cactus

...

def draw_window(play, dino, obstacles):
    ...
    # Displaying the obstacles
    for obstacle in obstacles:
        cactus_image = pygame.transform.scale(
            CACTUS, (obstacle.width, obstacle.height)).convert_alpha()
        WINDOW.blit(cactus_image, (obstacle.x, obstacle.y))
    ...

...

def main():
    ...
    cacti = []

    num_cactus = random.randint(1, 3) # Generate either 1, 2 or 3 cactus
    cactus_height = random.randint(50, 80)
    for i in range(num_cactus):
        # Determine both the x and y positions of each cactus
        cactus_y_pos = HORIZON_Y_POS - cactus_height + cactus_height//4
        cactus_x_pos = SCREEN_WIDTH - 300 + i*CACTUS_WIDTH # i*CACTUS_WIDTH ensures that each cactus is displayed standing on it's own

        # Add a new cacti bounding box to the group
        cacti.append(pygame.Rect(
            cactus_x_pos, cactus_y_pos, CACTUS_WIDTH, cactus_height))

    while game_running:
        ...
        while play:
            ...
            draw_window(play, dino=dino, obstacles=cacti)

        draw_window(play, dino=dino, obstacles=cacti)

    pygame.quit()
...

NOTE: Unlike the Dino image assets, where we called pygame.transform.scale() as soon as we loaded them, the cactus images are scaled at the point of display. This is because the Dino has a fixed, uniform height, while the cacti vary in height. We therefore need to scale them only once the variable height values are known.

Now, run your code. You should see something like this:

Cactus scrolls across the screen

Our obstacles are now on screen. But, we need to figure out how to make them move across the screen in unison.

We’ve actually done something similar with the horizon: by using an offset_x variable that keeps increasing, we subtract it from the horizon’s x-value to continuously push it left, creating the illusion of motion..

So, we just need to do that for our obstacles, right ?

Yes, for the most part. Although it's worth taking into consideration that unlike offset_x which had to be reset to 0 whenever it's absolute value exceeded the screen's width, our new obstacle_offset_x will be allowed to grow indefinitely, producing continuous leftward motion without a wrapping effect.

It’s also a good idea to move the logic for creating a new set of cacti into its own function. That way, you can easily reuse it whenever the program needs to generate cacti. I'll call this new function: generate_cacti() and it'll receive a single argument: starting_point which will prove useful later.

Alright, let's take a look at the code with all these changes in place:

...
CACTUS = pygame.image.load(os.path.join(
    'Assets', 'sprites', '1_Cactus.png')).convert_alpha()
...
CACTUS_WIDTH = 30  # Defines the uniform width of all cactus

...
obstacle_offset_x = 0  # The offset for moving obstacles along horizon
...

def draw_window(play, dino, obstacles):
    ...
    global obstacle_offset_x
    ...
    # Displaying the obstacles
    for obstacle in obstacles:
        cactus_image = pygame.transform.scale(
            CACTUS, (obstacle.width, obstacle.height)).convert_alpha()
        WINDOW.blit(cactus_image, (obstacle.x + obstacle_offset_x, obstacle.y))

    if play:
        ...
        offset_x -= HORIZON_VEL
        obstacle_offset_x -= HORIZON_VEL

        ...
    else:
        ...
    ...

def generate_cacti(starting_point = 0):
    cacti = []

    num_cactus = random.randint(1, 3) # Generate either 1, 2 or 3 cactus
    cactus_height = random.randint(50, 80)
    for i in range(num_cactus):
        # Determine both the x and y positions of each cactus
        cactus_y_pos = HORIZON_Y_POS - cactus_height + cactus_height//4
        cactus_x_pos = starting_point + SCREEN_WIDTH + i*CACTUS_WIDTH # i*CACTUS_WIDTH ensures that each cactus is displayed standing on it's own

        # Add a new cacti bounding box to the group
        cacti.append(pygame.Rect(
            cactus_x_pos, cactus_y_pos, CACTUS_WIDTH, cactus_height))

    return cacti

def main():
    ...
    cacti = generate_cacti()

    while game_running:
        ...
        while play:
            ...
            draw_window(play, dino=dino, obstacles=cacti)

        draw_window(play, dino=dino, obstacles=cacti)

    pygame.quit()
...

NOTE: Both obstacle_offset_x and offset_x are updated by the same value, HORIZON_VEL. This keeps the horizon and obstacles moving left at the same rate, creating the illusion that the Dino is running forward along a fixed but continuously unfolding path.

Now, run your code. You should see something like this:

New cacti are born when old ones die

Now, we need to make it possible for our game to generate a new set of obstacles as soon as the old set scrolls off the screen.

To create the feeling of new obstacles being revealed as the game unfolds, I generate new obstacles only after the current ones have moved off-screen. I do this by creating a custom user event, GENERATE_OBSTACLES, and posting it to the event queue with pygame.event.post() whenever the last cactus in the list goes off the screen (i.e. when obstacles[-1].x + obstacle_offset_x < 0).

Once the GENERATE_OBSTACLES event is added to the queue, we handle it by retrieving the x-position of the last cactus, clearing the old obstacles, and generating a new set starting from that position. This makes the new obstacles scroll in naturally from the right edge of the screen.

Alright, here's the code with these new ideas incorporated:

...
CACTUS = pygame.image.load(os.path.join(
    'Assets', 'sprites', '1_Cactus.png')).convert_alpha()
...
CACTUS_WIDTH = 30  # Defines the uniform width of all cactus

...
# User Events
SWITCH_FOOT = pygame.USEREVENT + 1
GENERATE_OBSTACLES = pygame.USEREVENT + 2

...
obstacle_offset_x = 0  # The offset for moving obstacles along horizon
...

def draw_window(play, dino, obstacles):
    ...
    global obstacle_offset_x
    ...
    # Displaying the obstacles
    for obstacle in obstacles:
        cactus_image = pygame.transform.scale(
            CACTUS, (obstacle.width, obstacle.height)).convert_alpha()
        WINDOW.blit(cactus_image, (obstacle.x + obstacle_offset_x, obstacle.y))

    # Determine: If left-most obstacle is completely off the left edge
    if (obstacles[-1].x + obstacle_offset_x) < 0:
        # Then, generate a new set of obstacles:
        pygame.event.post(pygame.event.Event(GENERATE_OBSTACLES))

    if play:
        ...
        offset_x -= HORIZON_VEL
        obstacle_offset_x -= HORIZON_VEL

        ...
    else:
        ...
    ...

def generate_cacti(starting_point = 0):
    cacti = []

    num_cactus = random.randint(1, 3) # Generate either 1, 2 or 3 cactus
    cactus_height = random.randint(50, 80)
    for i in range(num_cactus):
        # Determine both the x and y positions of each cactus
        cactus_y_pos = HORIZON_Y_POS - cactus_height + cactus_height//4
        cactus_x_pos = starting_point + SCREEN_WIDTH + i*CACTUS_WIDTH # i*CACTUS_WIDTH ensures that each cactus is displayed standing on it's own

        # Add a new cacti bounding box to the group
        cacti.append(pygame.Rect(
            cactus_x_pos, cactus_y_pos, CACTUS_WIDTH, cactus_height))

    return cacti

def main():
    ...
    cacti = generate_cacti()

    while game_running:
        ...
        while play:
            ...
            for event in pygame.event.get():
                ...

                if event.type == GENERATE_OBSTACLES:
                    last_obstacle_x = cacti[-1].x

                    cacti.clear()  # Remove all obstacles in initial set

                    cacti = generate_cacti(starting_point=last_obstacle_x)
             ...
            draw_window(play, dino=dino, obstacles=cacti)

        draw_window(play, dino=dino, obstacles=cacti)

    pygame.quit()
...

NOTE: Our custom event, GENERATE_OBSTACLES, is first wrapped in a pygame.event.Event() object and then posted to the event queue with pygame.event.post(). From there, it behaves like any other event we can read later in the game loop.

Go ahead and run your code — the game should now be more exciting and look something like this:

Check out the full code for this part of the project on Github.

Alright, we've successfully added obstacles to our game. Our game is really beginning to shape up and become playable. Feel free to share what you've built so far with your friends. I'm sure they'll be amazed at your programming brilliance.

Although, our Dino still doesn't die when it collides with the obstacles. We would like it to die when that happens.

So, in the next post, we'll be learning about collision detection and how we can implement that in our game. But for now:

Thanks for reading.

Hi there, ever wanted to learn how to make a game in Python. Here's the 5th post in my series that teaches you how to do exactly that.

Chukwuemeka Ngumoha — Mon, 01 Sep 2025 15:10:51 +0000

Chukwuemeka Ngumoha

Sep 1 '25

Building Chrome Dinosaur Game in Pygame (Part 4: Jumping Dino)

#python #pygame #gamedev #tutorial

Comments

9 min read

Building Chrome Dinosaur Game in Pygame (Part 4: Jumping Dino)

Chukwuemeka Ngumoha — Mon, 01 Sep 2025 15:09:29 +0000

In the last post, we learned a little about pygame events: What they are, how to create them and how to use them to achieve the effect of moving the Dino's legs as it runs. In this post, we'll be concluding our work on the Dino by giving it the ability to jump whenever it wants to avoid bumping into a deadly Cactus on it's path.

But before we go any further, I need to make it clear that I'm assuming the following things about you:

You understand basic English. Trust me, this is not a given.

You possess basic knowledge of the Python programming language. If not, check out this coding resource to learn.

You're following along on a Mac, Linux or Windows Laptop or Desktop. You can't use your smartphone for this I'm afraid.

You can create your own custom pygame event without much fuss. If you can't, then quickly checkout the previous post before proceeding with this one.

Alright, let's dive in!

Quick Reality Check

Our game is beginning to shape up:

The game starts up when we hit the SPACE key, causing our Dino to move it's legs as it runs across the unfolding path. Let's take a quick look at the final game:

We see that eventually, we're going to need Cactus to show up at random points on the unfolding path as deadly obstacles to the Dino. Life is no fun without obstacles right ?

With that in mind, we're going to need the Dino to be able to jump over those obstacles as they appear in order to stay alive. That's our focus in this post.

Our codebase right now (Yours should be an exact match):

import pygame
import os

pygame.init()

# Constants
FPS = 60
HORIZON_VEL = 0.8
SCREEN_WIDTH, SCREEN_HEIGHT = 720, 400
DINO_WIDTH, DINO_HEIGHT = 80, 80
WHITE = (255, 255, 255)

WINDOW = pygame.display.set_mode((SCREEN_WIDTH, SCREEN_HEIGHT))
clock = pygame.time.Clock()

pygame.display.set_caption("Gino")

# Fetch the images
HORIZON = pygame.image.load(os.path.join('Assets', 'sprites', 'Horizon.png'))
HORIZON_Y_POS = SCREEN_HEIGHT//2 + SCREEN_HEIGHT//6

DINO_STANDING = pygame.transform.scale(pygame.image.load(os.path.join(
    'Assets', 'sprites', 'Dino_Standing.png')), (DINO_WIDTH, DINO_HEIGHT))
DINO_LEFT = pygame.transform.scale(pygame.image.load(os.path.join(
    'Assets', 'sprites', 'Dino_Left_Run.png')), (DINO_WIDTH, DINO_HEIGHT))
DINO_RIGHT = pygame.transform.scale(pygame.image.load(os.path.join(
    'Assets', 'sprites', 'Dino_Right_Run.png')), (DINO_WIDTH, DINO_HEIGHT))
DINO_Y_POS = HORIZON_Y_POS - DINO_HEIGHT + DINO_HEIGHT//4

# User Events
SWITCH_FOOT = pygame.USEREVENT + 1


# Global variables
offset_x = 0
left_foot = True

# Timer to switch foot
pygame.time.set_timer(SWITCH_FOOT, 125)


def draw_window(play):
    global offset_x
    global left_foot

    horizon_tiles = 2
    horizon_width = HORIZON.get_width()

    WINDOW.fill(WHITE)  # White

    for i in range(horizon_tiles):
        WINDOW.blit(HORIZON, (horizon_width * i + offset_x, HORIZON_Y_POS))

    if play:
        if left_foot:
            WINDOW.blit(DINO_LEFT, (30, DINO_Y_POS))
        else:
            WINDOW.blit(DINO_RIGHT, (30, DINO_Y_POS))

        offset_x -= HORIZON_VEL
        if abs(offset_x) > SCREEN_WIDTH + 100:
            offset_x = 0
    else:
        WINDOW.blit(DINO_STANDING, (30, DINO_Y_POS))

    pygame.display.update()


def main():
    """main code for the game.
    """
    global left_foot

    game_running = True
    play = False

    while game_running:

        # Poll for events
        for event in pygame.event.get():
            if event.type == pygame.QUIT:
                game_running = False

            # Start playing game when SPACE pressed
            if event.type == pygame.KEYDOWN and event.key == pygame.K_SPACE:
                play = True

        while play:
            clock.tick(FPS)
            for event in pygame.event.get():
                if event.type == pygame.QUIT:
                    game_running, play = False, False

                if event.type == SWITCH_FOOT:
                    left_foot = not left_foot

                # FIXME: experimental feature: testing pause functionality
                if event.type == pygame.KEYDOWN and event.key == pygame.K_RETURN:
                    play = False

            draw_window(play)

        draw_window(play)

    pygame.quit()


if __name__ == '__main__':
    main()

Jump Dino, Jump !

So, how to do we go about making the Dino jump ?

Looking back to when we talked about Coordinates, it's clear that in order to create the effect of the Dino jumping whenever we hit the SPACE key, we're going to need to find a way to change the Dino's coordinate value along the y axis.

But first things first, how do we enable our game to know when the SPACE key is being pressed ? And most importantly, long presses ?

If you've been paying attention in previous posts, I'm sure the first thing that comes to your mind right now would be to use the event checking loop from earlier posts. something like this:

...
for event in pygame.event.get():
    if event.type == pygame.KEYDOWN:
        if event.key == pygame.K_SPACE:
            # Cause Dino to jump at this point.
...

If these were your thoughts, then you're not wrong. But for this particular case, this approach may not work very well. Because, we want this key press event to be handled in a way that does not stop the rest of the game loop while handling our long key press. i.e We want the key press events to be handled Asynchronously so that even if we hold down on the SPACE for hours, all resulting events will be handled while the rest of the program runs as expected.

To achieve this, we'll be making use of the in-built pygame.key.get_pressed() method which returns a dictionary from which we can fetch the key we pressed by name. So, our code for listening to key press events for the SPACE key will be something like this:

...
def main():
    """main code for the game.
    """
    ...

    while game_running:
    ...
        while play:
            ...
            keys = pygame.key.get_pressed()

            if keys[pygame.K_SPACE]: # Listen for SPACE key pressed
                # Make Dino jump

            draw_window(play)

        draw_window(play)

    pygame.quit()
...

Alright, that's all well and good. But, we're still back where we started in terms of making the Dino actually jump ?

An idea we could explore would be adjusting the Dino's y coordinate value each time. But this would create no noticeable change. The reason for this can be found in our discussion on the Refresh rate of the game and how to control it. i.e The Surface of the game is being replaced about 60 times every second. This makes it that even if we change the y value directly, that change is never shown because the Surface where that change happened is very quickly replaced before we can see it. Yeah, it really happens that fast.

So, we're going to need to tackle this using two approaches in conjunction:

We need to establish a bounding box using the in-built pygame.Rect class. This bounding box will make it possible to control the positioning of the Dino on the screen dynamically:

...

def draw_window(play, dino):
    ...

    if play:
        if left_foot:
            WINDOW.blit(DINO_LEFT, (dino.x, dino.y))
        else:
            WINDOW.blit(DINO_RIGHT, (dino.x, dino.y))

        ...
    else:
        WINDOW.blit(DINO_STANDING, (dino.x, dino.y))

    pygame.display.update()

...

def main():
    """main code for the game.
    """
    ...
    # Help us manage Dino's position dynamically
    dino = pygame.Rect(DINO_X_POS, DINO_Y_POS, DINO_WIDTH, DINO_HEIGHT)


    while game_running:
    ...
        while play:
            ...

            draw_window(play, dino=dino)

        draw_window(play, dino=dino)

    pygame.quit()
...

Then, we need to have a vertical offset value which we can increase continuously even as the Surfaces are replaced to give the illusion of continuous upward motion. We'll make this a global variable for now so it's value is easily accessible:

...
offset_y = 0  # Global vertical offset
...

def draw_window(play, dino):
    global offset_y
    ...

    if play:
        if left_foot:
            WINDOW.blit(DINO_LEFT, (dino.x, dino.y - offset_y))
        else:
            WINDOW.blit(DINO_RIGHT, (dino.x, dino.y - offset_y))

        ...
    else:
        WINDOW.blit(DINO_STANDING, (dino.x, dino.y - offset_y))

    pygame.display.update()

...

def main():
    """main code for the game.
    """
    global offset_y
    ...
    # Help us manage Dino's position dynamically
    dino = pygame.Rect(DINO_X_POS, DINO_Y_POS, DINO_WIDTH, DINO_HEIGHT)


    while game_running:
    ...
        while play:
            ...
            keys = pygame.key.get_pressed()

            if keys[pygame.K_SPACE]:
                # Make Dino jump
                offset_y += 25

            draw_window(play, dino=dino)

        draw_window(play, dino=dino)

    pygame.quit()
...

Now, when you run the program and press SPACE while the Dino is running along the plain, you see something like this:

But now we have a new problem:

Our Dino goes up but never comes back down — And I'm pretty sure the law of gravity isn't to happy about being ignored.

So to fix this, we want our program to be able to take note of when the Dino is not on the ground and then gradually lower it to the ground. Sounds easy enough, I think the following code should do the trick:

...
def main():
    """main code for the game.
    """
    ...

    while game_running:
    ...
        while play:
            ...
            keys = pygame.key.get_pressed()

            if keys[pygame.K_SPACE]:
                # Make Dino jump
                offset_y += 25

            # If Dino is not yet on the ground, lower it to the ground gradually
            if (dino.y - offset_y) < DINO_Y_POS:
                offset_y -= 5

            draw_window(play, dino=dino)

        draw_window(play, dino=dino)

    pygame.quit()
...

Now run your program and as your Dino runs on the plain, press SPACE. You should see something like this:

Alright it goes up rapidly and then comes down gradually, gravity would be pleased. But we still have a problem.

From the original game:

We see that the Dino can't jump past a certain point on the screen and when it approaches that point, it waits a tiny bit and then begins to fall back to the ground regardless of whether you're holding down the SPACE key or not. So, how do we accomplish this ?

After some thinking, I came up with the idea of using a flag to indicate when the Dino is falling to the ground. So, whenever the Dino achieves maximum height, the flag is activated and all subsequent SPACE key presses are totally ignored until the Dino is completely on the ground.

Here's my implementation:

...

dino_falling = False  # Flag to indicate that Dino is falling.

...
def main():
    """main code for the game.
    """
    global dino_falling
    ...

    while game_running:
    ...
        while play:
            ...
            keys = pygame.key.get_pressed()

            if keys[pygame.K_SPACE] and not dino_falling:
                # If we're not yet at max height, keep going up
                if (dino.y - offset_y) > 20:
                    offset_y += 25
                else:
                     pygame.time.wait(20)  # Wait 20 milliseconds
                     dino_falling = True   # Then, start falling

            # If Dino is not yet on the ground, lower it to the ground gradually
            if (dino.y - offset_y) < DINO_Y_POS:
                offset_y -= 5

                # If we're on the ground, stop falling
                if (dino.y - offset_y) >= DINO_Y_POS:
                    dino_falling = False

            draw_window(play, dino=dino)

        draw_window(play, dino=dino)

    pygame.quit()
...

Go ahead and run the program now — It should look something like this:

Although, we've achieved the core jumping functionality, there's one more minor bug in how our Dino jumps which defies human and animal anatomy.

Take a look at the final game once again:

Notice that whenever the Dino jumps up, it's always doing so in the standing posture. i.e It's legs are not moving

So, how do we get our program to work the same way ?

At this point, I decided to take the simpler approach and just use another global flag. The aim of this flag will be to indicate when the Dino jumping. I should mention that this is a bit of a quick-and-dirty technique. In future posts, we’ll refine this idea and explore cleaner approaches. In fact, I encourage you to look for better alternatives if you're up for it. However, let's proceed:

...

dino_falling = False  # Flag to indicate that Dino is falling.
dino_jumping = False  # Flag to indicate that Dino is jumping.

...

def draw_window(play, dino):
    global dino_jumping
    ...

    if play:
        if dino_jumping:
            # Don't move legs
            WINDOW.blit(DINO_STANDING, (dino.x, dino.y - offset_y))
        else:
            # Move legs
            if left_foot:
                WINDOW.blit(DINO_LEFT, (dino.x, dino.y - offset_y))
            else:
                WINDOW.blit(DINO_RIGHT, (dino.x, dino.y - offset_y))

        ...
    else:
        WINDOW.blit(DINO_STANDING, (dino.x, dino.y - offset_y))

    pygame.display.update()

def main():
    """main code for the game.
    """
    global dino_falling, dino_jumping
    ...

    while game_running:
    ...
        while play:
            ...
            keys = pygame.key.get_pressed()

            if keys[pygame.K_SPACE] and not dino_falling:
                dino_jumping = True
                ...

            # If Dino is not yet on the ground, lower it to the ground gradually
            if (dino.y - offset_y) < DINO_Y_POS:
                offset_y -= 5

                # If we're on the ground, stop falling
                if (dino.y - offset_y) >= DINO_Y_POS:
                    dino_falling = False
                    dino_jumping = False

            draw_window(play, dino=dino)

        draw_window(play, dino=dino)

    pygame.quit()
...

Now run the program one more time:

Alright, you've made real progress.

Congrats on making it this far, all that's left right now is the aesthetic polish of the game and adding those deadly obstacles we've been dying to add.

I encourage you to check out the full code on Github as I made a few small changes that weren’t covered in this post.

In this post, we tried to make our Dino jump on command and in the process of doing that, we learned a little bit about listening to key presses asynchronously using the in-built pygame.key.get_pressed() method and using the in-built pygame.Rect class to generate a bounding box that we can used to control game element's positioning on the screen more dynamically.

In the next post, we'll start adding those life threatening cacti I talked about earlier. But for now:

Thanks for reading.

Building Chrome Dinosaur Game in Pygame (Part 3: Running Dino)

Chukwuemeka Ngumoha — Fri, 29 Aug 2025 05:23:21 +0000

In the last post, we coded up the infinite scrolling horizon upon which the Dino runs and in the process we learned how to display images on the canvas, how coordinates work in pygame, how to use the pygame.time.Clock class in controlling the Refresh rate of the video game among a few other lessons. In this post, we'll code up the Dino and give it the ability to run for dear life.

But before we go any further, I need to make it clear that I'm assuming the following things about you:

You understand basic English. Trust me, this is not a given.

You possess basic knowledge of the Python programming language. If not, check out this coding resource to learn.

You're following along on a Mac, Linux or Windows Laptop or Desktop. You can't use your smartphone for this I'm afraid.

You can comfortably change the Refresh rate of our game without breaking a sweat. If you can't, then quickly checkout the previous post before proceeding with this one.

Alright, let's dive in!

Who left a dinosaur on the open road ?

In our previous post, we left our code base looking something like this (adjust your code to match what is displayed):

import pygame
import os

pygame.init()

# Constants
FPS = 60
HORIZON_VEL = 0.8
SCREEN_WIDTH, SCREEN_HEIGHT = 720, 400
WHITE = (255, 255, 255)

WINDOW = pygame.display.set_mode((SCREEN_WIDTH, SCREEN_HEIGHT))
clock = pygame.time.Clock()

pygame.display.set_caption("Gino")

# Fetch the image
HORIZON = pygame.image.load(os.path.join('Assets', 'sprites', 'Horizon.png'))
HORIZON_Y_POS = SCREEN_HEIGHT//2 + SCREEN_HEIGHT//6


# Global variables
offset_x = 0


def draw_window():
    global offset_x
    horizon_tiles = 2
    horizon_width = HORIZON.get_width()

    WINDOW.fill(WHITE)  # White

    for i in range(horizon_tiles):
        WINDOW.blit(HORIZON, (horizon_width * i + offset_x, HORIZON_Y_POS))

    offset_x -= HORIZON_VEL
    if abs(offset_x) > SCREEN_WIDTH + 100:
        offset_x = 0


def main():
    """main code for the game.
    """
    # global offset_x

    game_running = True

    while game_running:
        clock.tick(FPS)
        # Poll for events
        for event in pygame.event.get():
            if event.type == pygame.QUIT:
                game_running = False

        draw_window()

        pygame.display.update()

    pygame.quit()


if __name__ == '__main__':
    main()

So, the first order of business today will be to display the Dino on the canvas. And using what we did in the previous post as a reference, it's clear we're talking about displaying an image using the WINDOW.blit() method. So, let's do that:

...

DINO_WIDTH = 80
DINO_HEIGHT = 80

DINO_STANDING = pygame.transform.scale(
     pygame.image.load(os.path.join('Assets', 'sprites', 'Dino_Standing.png')),
     (DINO_WIDTH, DINO_HEIGHT)
)
DINO_Y_POS = HORIZON_Y_POS - DINO_HEIGHT + DINO_HEIGHT//4

# Global variables
offset_x = 0


def draw_window():
    global offset_x
    horizon_tiles = 2
    horizon_width = HORIZON.get_width()

    WINDOW.fill(WHITE)  # White

    for i in range(horizon_tiles):
        WINDOW.blit(HORIZON, (horizon_width * i + offset_x, HORIZON_Y_POS))

    WINDOW.blit(DINO_STANDING, (30, DINO_Y_POS))

    ...


 ...

A lot of this code should be familiar to you by now. But if you take a closer look, you'll notice that we passed the pygame.image.load(...) method as an argument to a pygame.transform.scale(...) method. This method does what it's name suggests: Scales the width and height of the loaded image to meet specific values which we passed in as a tuple of the DINO_WIDTH and DINO_HEIGHT constants defined above, both set to a value of 80. You'll also notice that the position of the Dino on the y axis is also calculated based on the initial HORIZON_Y_POS from the last post and assigned to a constant DINO_Y_POS which is used when displaying the DINO_STANDING image loaded earlier through the use of WINDOW.blit(). This is so that the Dino will appear as though it were standing on the horizon

When you run the program, you'll get something that looks like this:

Wow, our Dino looks good !!!

But it does not seem to be moving. Actually, it's be standing still while the rest of the world moves past it. We don't want that, so how do we fix it ?

Essentially, all we need to do is create the illusion of motion. And, the best way to do that is by getting it's legs to move. But, how do you get the legs of an image to move ? Is that even possible ?

Well, it's not. But we can switch between two images of the Dino so fast that it would appear as though the Dino were indeed moving it's legs. And luckily for you, we have two images in the Assets/ directory in our project that can be useful in achieving this:

Assets/sprites/Dino_Left_Run.png: An image of the Dino with it's left leg extended.
Assets/sprites/Dino_Right_Run.png: An image of the Dino with it's right leg extended.

And we'll use both of these to achieve our goal soon. But right now, you may be thinking: how do we signal to the Dinosaur to switch between two images of itself fast enough to create the illusion of motion ?

In order to achieve this, we need to learn about two new ideas:

Events

An event in pygame is a message that tells your program something has happened — like a key being pressed, the mouse moving, or the game window closing.
You can think of it as a notification system: whenever a specific action occurs, Pygame generates an event. By listening for these events, your program knows when and how to respond.

We've actually already worked with events in our code:

...

def main():
    """main code for the game.
    """
    ...

    while game_running:
        ...

        # Poll for events
        for event in pygame.event.get():
            if event.type == pygame.QUIT:
                game_running = False

        ...

    pygame.quit()

...

In the example above, we were listening for the pygame.QUIT event which tells us when the user hits the ❌ on the game window. pygame comes with a lot more events that we can use and it also gives us the ability to define custom events when the need arises:


EVENT_NAME = pygame.USEREVENT + n

where n is any number from 1 upwards. At the end of the day, pygame.USEREVENT is really just a constant containing a unique number. So, when we add to that number, we're creating a more unique number to act as our event ID. That's essentially, how that line works behind the scenes. Now, EVENT_NAME can now be caught within the event checker loop like all other events:

for event in pygame.event.get();
    if event.type == EVENT_NAME:
        # Do something in response to that event here

Learn more about pygame events here and here

Repeating events with `pygame.time.set_timer()`

Earlier on, we used the pygame.time.Clock class to create an instance which used the tick() instance method to control the Refresh Rate of our game. So, now let's take a brief look at it's cousin: pygame.time.set_timer()

The pygame.time.set_timer() method basically takes two arguments:

An Event: The event we want to repeat
A number: The time in milliseconds over which that event is repeated

And then pygame.time.set_timer() will emit the specified event for every interval of time as specified by the second argument:


# Dispatch EVENT_NAME every second
pygame.time.set_timer(EVENT_NAME, 1000)

This is really convenient because it's exactly what we need in order to make our program work as intended:

...
DINO_STANDING = pygame.transform.scale(
     pygame.image.load(os.path.join('Assets', 'sprites', 'Dino_Standing.png')),
     (DINO_WIDTH, DINO_HEIGHT)
)

DINO_LEFT = pygame.transform.scale(
    pygame.image.load(os.path.join('Assets', 'sprites', 'Dino_Left_Run.png')),
    (DINO_WIDTH, DINO_HEIGHT)
)

DINO_RIGHT = pygame.transform.scale(
     pygame.image.load(os.path.join('Assets', 'sprites', 'Dino_Right_Run.png')),
     (DINO_WIDTH, DINO_HEIGHT)
)

DINO_Y_POS = HORIZON_Y_POS - DINO_HEIGHT + DINO_HEIGHT//4


# Defining event
SWITCH_FOOT = pygame.USEREVENT + 1


# Global variables
offset_x = 0
left_foot = True   # We'll use this to switch between left and right foot

# Send SWITCH_FOOT event every 125 milliseconds
pygame.time.set_timer(SWITCH_FOOT, 125)

def draw_window():
    global offset_x
    global left_foot

    horizon_tiles = 2
    horizon_width = HORIZON.get_width()

    WINDOW.fill(WHITE)  # White

    for i in range(horizon_tiles):
        WINDOW.blit(HORIZON, (horizon_width * i + offset_x, HORIZON_Y_POS))

    # WINDOW.blit(DINO_STANDING, (30, DINO_Y_POS))

    if left_foot:
        WINDOW.blit(DINO_LEFT, (30, DINO_Y_POS))
    else:
        WINDOW.blit(DINO_RIGHT, (30, DINO_Y_POS))

    ...


def main():
    """main code for the game.
    """
    global left_foot

    ...

    while game_running:
        ...
        for event in pygame.event.get():
            if event.type == pygame.QUIT:
                game_running = False

            if event.type == SWITCH_FOOT:
                left_foot = not left_foot

        ...

    pygame.quit()
...

A few things to take note of:

We use the left_foot variable to determine when to switch between foots. So whenever the SWITCH_FOOT event is detected, the line left_foot = not left_foot simply inverts the initial value of left_foot i.e if it was False, then it becomes True and vice versa.
We commented out the line WINDOW.blit(DINO_STANDING, (30, DINO_Y_POS)). This is only a temporary measure. We'll fix it soon

Alright, run your code ! your Dino should now be running for dear life:

Controlling game play

But, we don't want the game to start playing by itself whenever we start it. Actually, we want it to start only when we hit the SPACE key on the keyboard. So, I re-engineered the code to make this possible:

"""
main.py: Gino game.
"""
...

def draw_window(play):
    ...

    if play:
        if left_foot:
            WINDOW.blit(DINO_LEFT, (30, DINO_Y_POS))
        else:
            WINDOW.blit(DINO_RIGHT, (30, DINO_Y_POS))

        offset_x -= HORIZON_VEL
        if abs(offset_x) > SCREEN_WIDTH + 100:
            offset_x = 0
    else:
        WINDOW.blit(DINO_STANDING, (30, DINO_Y_POS))

    pygame.display.update()


def main():
    """main code for the game.
    """
    ...
    play = False

    while game_running:

        # Poll for events
        for event in pygame.event.get():
            ...

            # Start playing game when SPACE pressed
            if event.type == pygame.KEYDOWN and event.key == pygame.K_SPACE:
                play = True

        while play:
            clock.tick(FPS)
            for event in pygame.event.get():
                if event.type == pygame.QUIT:
                    game_running, play = False, False

                if event.type == SWITCH_FOOT:
                    left_foot = not left_foot

                # FIXME: experimental feature: testing pause functionality
                if event.type == pygame.KEYDOWN and event.key == pygame.K_RETURN:
                    play = False

            draw_window(play)

        draw_window(play)

    pygame.quit()


if __name__ == '__main__':
    main()

Essentially, I nested a new loop inside the game loop. This new loop will control when the game starts playing: So now, when we start the game, everything stays static until the SPACE key is pressed, at which point, the game play resumes as usual. A few things to note:

We introduce a new play variable to control when the game is in play mode and when it's not. This variable is then passed into the draw_window() function and used to determine when to display a moving or standing dinosaur and also when the horizon should scroll leftward and when it should not.
Also, we used two pygame.KEYDOWN events at the two modes of the game so we can know when the user hits the SPACE or ENTER keys to start or stop game play respectively.

Now with these changes, we're done. Run the program and see your Dino obeying all your commands:

Congrats !!! you just successfully tamed a Dinosaur.

View the full code for this stage of the project on Github

So in this post, we learned a little bit more about events in pygame, how to create a custom event, how to make an event repeat after a specified time period, and we achieved our goal of displaying the Dino and making it move on the canvas.

In the next post, we'll explore how to make the Dino jump as it tries to avoid Cactus on the road. That would be a great idea, I think. But for now:

Thanks for reading.

Building Chrome Dinosaur Game in Pygame (Part 2: Infinite Horizons)

Chukwuemeka Ngumoha — Thu, 28 Aug 2025 15:08:55 +0000

In the last post, we took a look at a basic boilerplate for pygame and then we learned how to change the background of our game's canvas. In this post, we're going to start coding up the elements in our game. Specifically, we'll be working on coding up the infinite plain surface or horizon that our Dino seems to be running on:

But before we go any further, I need to make it clear that I'm assuming the following things about you:

You understand basic English. Trust me, this is not a given.

You possess basic knowledge of the Python programming language. If not, check out this coding resource to learn.

You're following along on a Mac, Linux or Windows Laptop or Desktop. You can't use your smartphone for this I'm afraid.

You can change the background color of the canvas to pink if asked to do so. If You can't, then quickly checkout the previous post before proceeding with this one.

Alright, let's dive in!

Step 1: display the horizon

So let's pick up where we left off. We currently have a blank white screen staring at us whenever we run our program. But, we would like to see an infinite horizon displayed on that white screen. After all, Our Dino needs to run on something. So the question is: How do we do that ?

Your mind's likely revisiting the work we did in the last post where used a new Surface to introduce a new background color on the screen. If so, congrats ! you're beginning to get the madness. Not yet ? don't be too hard on yourself, it takes some time to get used to these ideas.

YES. We'll indeed be using Surfaces. But we're not layering a new color this time around. On second thought, where do we get an infinite horizon from ? Are we using images ?

If that's what you're thinking, then YES, we'll use an image. And lucky you, the image you need is right where it needs to be: In your project directory. Specifically, it's in the Assets/ directory which is on the same level as the main.py where we've been writing all the code so far. If you look in that directory, you'll find a Horizon.png image located in Assets/sprites/ subdirectory as demonstrated below:

├── main.py
└── Assets
    ├── sprites
    │   └── Horizon.png

Alright, now we have our image, how do we layer that image in a new surface on the canvas ?

Well, just as the canvas WINDOW came with a fill() method for layering colors, it also comes with a blit() method for displaying images. Don't ask me why they chose to call it that though (I got no clue).

So, from the previous post, our code should look something like this:

pygame.init()
SCREEN_WIDTH, SCREEN_HEIGHT = 720, 400
WHITE = (255, 255, 255)

WINDOW = pygame.display.set_mode((SCREEN_WIDTH, SCREEN_HEIGHT))

pygame.display.set_caption("Gino")


def main():
    """main code for the game.
    """
    game_running = True

    while game_running:
        # Poll for events
        for event in pygame.event.get():
            if event.type == pygame.QUIT:
                game_running = False

        WINDOW.fill(WHITE)  # White
        pygame.display.update()

    pygame.quit()


if __name__ == '__main__':
    main()

So we're ready to add a horizon. Right ?

Well, not so fast. unlike when we added a background color meant to cover the whole canvas, an image will need to be placed at a specific point on said canvas. To do this, we need to understand the concept of Coordinates in pygame.

In general, the Coordinate of a thing is simply a way to describe the location of that thing on a surface e.g The earth's surface, the surface of your graph book in maths class e.t.c. For most purposes, the coordinate is usually described in terms of two directions

The horizontal or left-to-right direction. Known as the x axis
The vertical or top-to-bottom direction. Known as the y axis

This same idea is used in pygame for positioning elements on the canvas. However, there's a small twist in the way pygame represents coordinates:

Whereas, the starting point (0, 0) of the coordinate is usually located in the center:

In pygame, that same coordinate would be located at the top-left corner:

In essence, pygame elements are positioned relative to the left and top of the canvas respectively.

Now that we've covered all the theory, let's start building. The first step is to load the image into our program:

import os
...

pygame.init()
...

# Load Horizon image
HORIZON = pygame.image.load(os.path.join('Assets', 'sprites', 'Horizon.png'))


def main():
    ...

The pygame.image.load() makes the image available. I make use of the os.path.join() method because I want the path Horizon.png file to be correct regardless of the Operating System being used to run the code at any point in time. However, I've seen some people using raw strings here. Although, I don't advise that.

Now that we have the horizon's image, we need to display it on screen. The WINDOW.blit() method takes the image to be displayed (HORIZON in our case) and then it's coordinates are passed in as a tuple:

...
def main():
    """main code for the game.
    """
    game_running = True

    while game_running:
        ...

        WINDOW.fill(WHITE)  # White
        WINDOW.blit(HORIZON, (0, SCREEN_HEIGHT//2))

        pygame.display.update()

    pygame.quit()


if __name__ == '__main__':
    main()

When you run the code, you'll get something like this:

From the image above, we can see that the horizon is positioned in the center of the screen or y = SCREEN_HEIGHT//2 and spans the full width of the screen from the left or x = 0. But for our game, we want the horizon closer to the bottom of the canvas. So, let's make some changes:

...
HORIZON_Y_POS = SCREEN_HEIGHT//2 + SCREEN_HEIGHT//6

def main():
    """main code for the game.
    """
    game_running = True

    while game_running:
        ...

        WINDOW.fill(WHITE)  # White
        WINDOW.blit(HORIZON, (0, HORIZON_Y_POS))

        pygame.display.update()

    pygame.quit()


if __name__ == '__main__':
    main()

Now when you run the code, you should see something like this:

So, mission accomplished ?

Almost, we still have to make the horizon scroll.

NOTE: In all the snippets above, the line WINDOW.fill(...) is always written before the line WINDOW.blit(...). Doing otherwise, would cause the white background to be displayed on top of the layer with the horizon thus erasing the horizon and displaying a white screen. i.e The order of the code matters

Step 2: Making the horizon scroll

When take a look at the final game again:

We notice that the Dino doesn't actually move. Actually, it's environment moves left towards it while it jumps up regularly to avoid being hit by the approaching Cactus. It is a part of the moving environment.

In order to make the horizon scroll to the left, we'll take advantage of the fact that the game loop repeats forever and we'll try moving the horizon image a bit to the left every time the game loop repeats. A good way I found to accomplish that was to introduce an offset along the x axis which would increase with each rep:

...

# Global variables
offset_x = 0

def main():
    """main code for the game.
    """
    global offset_x

    game_running = True

    while game_running:
        ...

        WINDOW.fill(WHITE)  # White
        WINDOW.blit(HORIZON, (offset_x, HORIZON_Y_POS))

        offset_x -= 1

        pygame.display.update()

    pygame.quit()


if __name__ == '__main__':
    main()

offset_x is declared as a global variable and the line global offset_x is placed at the top of the main function so we can modify this global variable within it instead of creating a local variable with the same name. Using global variables is never a good idea but we'll address that concern in a future post. Right now, let's just keep trying to hack together a solution that works.

Essentially, the line offset_x -= 1 causes the x axis of the horizon image to shift ever so slightly to the left with each game loop iteration. When we run the program now, we should see something like this:

Wow, it scrolled !!!

But it's going too fast. Why is it behaving like that ?

Well it turns out that the reason it moves so fast across the screen is a result of how fast the current surface of the canvas are being replaced by a newer surface. This rate of change in the surfaces is what is known as the game's Refresh Rate and it's a common fixture of every video game. It's measured in terms of frames per second or fps for short. Most games run at the industry standard rate of 60 fps. So, it's a good idea to calibrate our game to use that rate as well. But how ?

The way the pygame documentation recommends is through the use of the pygame.time.Clock class which comes with a tick() method which takes the fps value we want as an integer and slows down our game loop so that it repeats enough times to satisfy our specified refresh rate. Here's our code with these changes included:

...
FPS = 60
clock = pygame.time.Clock()

# Global variables
offset_x = 0

def main():
    """main code for the game.
    """
    ...

    while game_running:
        clock.tick(FPS)
        ...

    pygame.quit()


if __name__ == '__main__':
    main()

NOTE: the line clock.tick(...) must always be located within the body of the main game loop. Otherwise, it would have no effect on the refresh rate of the game.

Now when you run the game, you get a much slower scroll:

Congrats, the horizon is now scrolling to the left at a more approachable pace. But, we don't want it to ever go off the screen. Instead, we want it to scroll leftward infinitely. How do we accomplish this ?

Well, I have an idea:

Firstly, we need to have more than one image of the horizon displayed on the screen in sequence. Considering the fact that the horizon image already spans the full width of the canvas, I decided to layer two horizon images in sequence:

...
def main():
    """main code for the game.
    """
    ...
    horizon_width = HORIZON.get_width()
    horizon_tiles = 2

    while game_running:
        ...

        WINDOW.fill(WHITE)  # White

        # Displaying the two horizon images back to back
        for i in range(horizon_tiles):
            WINDOW.blit(HORIZON, (horizon_width * i + offset_x, HORIZON_Y_POS))

        offset_x -= 1

        pygame.display.update()

    pygame.quit()


if __name__ == '__main__':
    main()

Finally, we need to reset the horizon images to their original positions when the first one goes off the screen by a considerable margin. Here's how I would achieve that:

...

def main():
    """main code for the game.
    """
    ...
    while game_running:
        ...

        if abs(offset_x) > SCREEN_WIDTH + 100:
            offset_x = 0

        pygame.display.update()

    pygame.quit()


if __name__ == '__main__':
    main()

Now run the program. You should have an infinite horizon on your canvas:

Congrats !!!, you just successfully added the very first game element. View the full code on Github.

But, don't limit yourself to my code and ideas. Go ahead. Tweak the code. Break things. That's how you learn best.

So in today's post we learned how to:

Display images on the canvas.
Work with the coordinate system in pygame and use it to effectively position game elements on the canvas.
Control the game's refresh rate using pygame's inbuilt pygame.time.Clock class and why it's important to do so.

And we achieved our goal of creating an infinite horizon for our Dino to run on in future posts. It will be so happy to see all the good work we've done.

Speaking of the Dino, in the next post we'll focus on adding it to the canvas and making it move those adorable little legs. But for now:

Thanks for reading.

Building Chrome Dinosaur Game in Pygame (Part 1: Code init & startup)

Chukwuemeka Ngumoha — Wed, 27 Aug 2025 08:52:36 +0000

In the last post, we got introduced to what pygame is, a few facts about it, an overview of the game we will be making and then a basic development environment setup for working through the series. In this post, we'll start building a video game with pygame.

But before we go any further, I need to make it clear that I'm assuming the following things about you:

You understand basic English. Trust me, this is not a given.

You possess basic knowledge of the Python programming language. If not, check out this coding resource to learn.

You're following along on a Mac, Linux or Windows Laptop or Desktop. You can't use your smartphone for this I'm afraid.

You've setup a basic development environment and are ready to get coding. If not, then go through the previous post before proceeding with this one

Alright, let's dive in !

Pygame boilerplate.

To get started making a game in pygame, the first step is always to initialize and setup pygame to work in our local environment. If you successfully downloaded and added the starting folder from the previous post, then all you have to do is open the main.py file at the root of the project's directory structure. You should see the following boilerplate:

import pygame

pygame.init()
SCREEN_WIDTH, SCREEN_HEIGHT = 720, 400
WINDOW = pygame.display.set_mode((SCREEN_WIDTH, SCREEN_HEIGHT))

pygame.display.set_caption("Gino")


def main():
    """main code for the game.
    """
    game_running = True

    while game_running:
        # Poll for events
        for event in pygame.event.get():
            if event.type == pygame.QUIT:
                game_running = False

        pygame.display.update()

    pygame.quit()


if __name__ == '__main__':
    main()

Let's quickly walk through what each of the weird new functions on the screen right now actually does:

import pygame: tells the Python interpreter to add everything in the pygame package into our file when it begins executing this file.
pygame.init(): is a pygame method (function) which sets up all the modules we need before we can begin using them in our program. i.e it “starts up” pygame so we can begin working with things like graphics, sound, and input. This should always be placed at the top of the file, right after the import statements.
WINDOW = pygame.display.set_mode((SCREEN_WIDTH, SCREEN_HEIGHT)): creates a blank canvas (screen) where we can start building our game and sets it's width and height to the values of the constants SCREEN_WIDTH and SCREEN_HEIGHT respectively. Feel free to change the values of these constants to whatever you want them to be, this is your game after all.
pygame.display.set_caption('Gino'): sets the title of the game window that will be displayed. This should ideally be the name of the game you want to make. In my case I'm going with Gino, but feel free to come up with a different name.
I decided to package the main gameplay loop and logic inside a custom function called main. I must stress that this is a personal decision on my part and not a rule that you must follow in your own projects. Also, if you choose to follow my idea, your function doesn't have to be called main. You can use a different function name.
Within my main function, the line while game_running: helps to setup a game loop that will run forever (if you let it). And within that loop, the line for event in pygame.event.get(): enables our program to look into the pygame event queue for any event we want. Then, the line if event.type == pygame.QUIT helps our program know when the player hits the ❌ on the game window and then we terminate the game loop by setting game_running = False and the game ends without any issues. We'll discuss the _pygame event queue in more detail in future posts_
The line pygame.update.display(), adds a new Surface on the canvas at every cycle (loop). This concept is explained a bit more later on in this post.
The line if __name__ == '__main__': tells the python interpreter to run our main function only when the main.py file is executed as a standalone program. Click here to learn more about how that works.

Alright, now that we're done with the walkthrough, let's run the code and see what happens. Open your terminal (or Command Prompt / Powershell if on Windows) and type in either of the following commands:

python main.py

OR (mostly for Linux users)

python3 main.py

then hit the ENTER key on your keyboard. You should see something like this:

Let's make the background white

Our game has a white background, so naturally we need to make the background color of the screen WHITE. To achieve this though, we have to tell the blank canvas earlier named WINDOW to create a new Surface with it's background color set to white.

I'm sure you're now thinking about all or one of the following questions:

Why is this Surface thing he keeps mentioning ?
Why do we need a new Surface ?
How do I actually do that ?

To answer the first question:

A Surface is the most basic layout unit in Pygame. i.e Everything displayed on the screen is displayed as a Surface

For your second question, it would be helpful to imagine the pygame canvas as a pile or stack of sheets of paper, each displaying a different variation of a particular drawing that can not be erased (Assume we made this drawing with a pen instead of a pencil). With in mind, it becomes clear that the only way to make any changes in what is displayed would be to add sheet of paper or, in our case, a new layer or Surface at the top of the stack. Here's something to help your imagination:

This process of adding a new Surface on top all others is essentially the function of the pygame.display.update() shown earlier. In a nutshell:

All new changes on the canvas in pygame are achieved by layering newer Surfaces with slight variations in what is drawn on them over the older ones.

Lastly, in order to actually do this in our code, we simply have to call the fill() method on our canvas WINDOW and pass it a tuple representing the RGB value of our the color we want. So within our main function, we'll simply add the following line:

...
def main():
    """main code for the game.
    """
    game_running = True

    while game_running:
        ...
        WINDOW.fill((255, 255, 255)) # White
        pygame.display.update()
    pygame.quit()

...

NOTE: You can also pass the name of the color as a string. i.e WINDOW.fill('white') would work as well.

It's a good idea to refactor the color out into it's own constant so it's more reusable. Remember, being lazy is part of your job as a developer and making things reusable helps you stay lazy:

...
WHITE = (255, 255, 255)


def main():
    """main code for the game.
    """
    game_running = True

    while game_running:
        ...
        WINDOW.fill(WHITE)
        pygame.display.update()
    pygame.quit()

...

When you're done making these changes, run your code again and you should see something like this:

That's it, we're done. View the full code on Github

Alright, today we got to initialize and setup pygame in order to build our game, We learned a little bit about Surfaces and how pygame handles the process of updating the canvas during game play and finally, we changed the color of our game's canvas (screen) from the initial black color to a more appropriate white.

Congrats !!! we just got pygame to run on our computer. You're an even more badass Pygamer now.

Ready to level up ? In the next post, we'll begin to look at ways to display game elements on the screen. But for now:

Thanks for reading

DEV Community: Chukwuemeka Ngumoha

Fixing “Property 'user' does not exist on type 'Request'” in Express + TypeScript

The Fix

Step 1: Create a type declaration file

Step 2: Add this definition

Step 3: Update tsconfig.json

Step 4: Restart TypeScript + Dev Server

Result

Final Note

Just commenced a new blog series on common mistakes and ideas beginners miss in React. Check it out.

React: State vs Props

React: State vs Props

State

Props

In a Nutshell

When to use which ?

[Boost]

Building Chrome Dinosaur Game in Pygame (Part 6: Press Pause ⏸️)

Building Chrome Dinosaur Game in Pygame (Part 6: Press Pause ⏸️)

Our game so far

Why I'm pausing the series

[Boost]

Building Chrome Dinosaur Game in Pygame (Part 5: Deadly Cactus)

Building Chrome Dinosaur Game in Pygame (Part 5: Deadly Cactus)

Displaying Obstacles

Varied Height, Equal Width

Cactus scrolls across the screen

New cacti are born when old ones die

Hi there, ever wanted to learn how to make a game in Python. Here's the 5th post in my series that teaches you how to do exactly that.

Building Chrome Dinosaur Game in Pygame (Part 4: Jumping Dino)

Building Chrome Dinosaur Game in Pygame (Part 4: Jumping Dino)

Quick Reality Check

Jump Dino, Jump !

Building Chrome Dinosaur Game in Pygame (Part 3: Running Dino)

Who left a dinosaur on the open road ?

Events

Repeating events with pygame.time.set_timer()

Controlling game play

Building Chrome Dinosaur Game in Pygame (Part 2: Infinite Horizons)

Step 1: display the horizon

Step 2: Making the horizon scroll

Building Chrome Dinosaur Game in Pygame (Part 1: Code init & startup)

Pygame boilerplate.

Let's make the background white

Step 3: Update `tsconfig.json`

Repeating events with `pygame.time.set_timer()`