Topic 10

Topic 10

Ruby source files are converted directly from the English source tree.

Overview

Why this topic matters 💡

This topic teaches development as a sequence of small, testable iterations rather than a single "build the whole game" task. Rock-paper-scissors is intentionally simple as a domain, which makes it a good vehicle for discussing rules, round resolution, score tracking, and dependency injection.

Learning outcomes 🎯

By the end of this topic, students should be able to:

Assessment focus ✅

Students should be able to explain why the game is split into rules, round, and match concerns rather than collapsed into one script.

Short Note

A tiny game is useful because the rules are easy to understand, so students can focus on design decisions:

This topic is not about making a flashy game. It is about practicing disciplined iteration. Students should feel the benefit of building one slice at a time.

Ruby beauty in this topic:

Ruby caution in this topic:

Reflection prompt:

Worked Examples

Example 1: Rule engine before game flow 💡

It is tempting to write "if/else" game logic inside the main game object. A better teaching move is to separate the rule engine first:

rules . winner ( "rock" , "scissors" ) # => :player_one worked_examples.md ruby Why this is useful:

Example 2: Deterministic testing of a game loop 💡

Games often involve randomness, but tests should not.

If the computer move comes from an injected collaborator, the test can control the sequence:

source = instance_double ( "MoveSource" ) allow ( source ). to receive (: next_move ). and_return ( "scissors" , "rock" ) worked_examples.md ruby This is the most important design lesson in the topic: isolate unstable behavior.