Lesson Objective: Students will create a multi-level platformer game in Kodu that includes interactive obstacles, a scoring system, and clear win/lose conditions.
Target Audience: Middle School (Grades 6-8)
Materials:
Computers with Kodu Game Lab installed
This lesson plan and assignment sheet
Before touching the computer, students will plan their game. This is a crucial step for building a logical and well-structured project.
Brainstorming: Have students think of a theme for their platformer. Is the player a robot escaping a factory? A knight climbing a castle? An alien navigating a space ship?
The Hero: Choose the main character. What does it look like? How will it move?
Obstacles & Hazards: List at least three different types of obstacles. For example:
Stationary: Lava pits (red terrain), spike traps (rocks).
Moving: A patrolling enemy (Puck or Blip).
Interactive: A laser that turns on and off.
Goals & Scoring: How does the player win?
Primary Goal: Reaching a final destination (e.g., a Castle).
Secondary Goal: Collecting items (like Apples or Stars) for a high score.
Now, students will bring their design to life using Kodu's visual programming.
Setting up the World:
Open a new world and use the Terrain tool to shape the ground and create floating platforms.
Use the Paint tool to add visual flair, like water for a moat or lava for a hazard.
Programming the Hero:
Add the main character.
Right-click on the character and select Program.
Create the basic movement and jump rules:
WHEN: Keyboard -> Arrows, DO: Move
WHEN: Keyboard -> Space, DO: Jump
Add a WHEN: Bumped -> Rocks, DO: Boom rule to make collisions with hazards dangerous.
Programming the Obstacles:
Add the first obstacle. Right-click on it and select Program.
For a moving enemy, a simple rule might be: WHEN: Always, DO: Move -> Wander.
For a projectile-firing obstacle: WHEN: See -> Kodu, DO: Shoot -> Star.
Win/Lose Conditions:
Add a final Castle or other object at the end of the level.
Program the main character to win: WHEN: Bumped -> Castle, DO: Win
Create a "lose" condition. If the player falls into the water: WHEN: Bumped -> Water, DO: Game -> Lose.
The game is not done until it's been tested.
Play Test: Have students play their own games and look for bugs. Is the jump height right? Do the enemies behave as expected?
Peer Review: Have students swap games with a partner. They should offer positive feedback and constructive criticism.
"I love how your character jumps!"
"Maybe the moving platform could be a little slower."
Debugging: Use the feedback to fix any issues. Debugging is a fundamental part of programming and is just as important as writing the code.
Great work! This lesson plan will give students a solid foundation for building more complex games in the future. Once they've mastered the basics, they can move on to even more advanced techniques.