Problem Decomposition Guide: Hamurabi Game

1. Understanding the Problem Domain

First Steps: Read and Analyze

Before writing any code, spend time understanding what you’re building:

Questions to Ask Yourself:

• What is the core gameplay loop?
• What decisions does the player make?
• What are the consequences of those decisions?
• What data needs to persist between turns?
• What are the win/lose conditions?

Exercise: Write a brief summary in your own words of what the game does. Don’t look at the requirements - just explain it like you would to a friend.

2. Identifying the Key Components

Data You Need to Track

Think about what information changes throughout the game:

State Variables to Consider:

• What resources exist in the game?
• What changes from year to year?
• What information do you need to make decisions?
• What information do you need to show the player?

Exercise: Make a list of all the “things” (nouns) mentioned in the game description. These often become your variables.

Actions and Events

Consider what happens in the game:

Player Actions:

• What choices can the player make?
• In what order do these choices occur?
• What limits these choices?

Game Events:

• What happens automatically each turn?
• What random events can occur?
• How do events affect the game state?

Exercise: Make a list of all the “actions” (verbs) in the game. These often become your methods.

3. Breaking Down the Game Flow

The Main Game Loop

Think about the structure of one complete turn:

Year starts → Show status → Get player decisions → Process decisions → 
Calculate outcomes → Check game ending conditions → Next year or end

Planning Questions:

• What happens at the start of each year?
• What information does the player need to see?
• What decisions happen in what order?
• What calculations need to be performed?
• When do you check if the game should end?

Decision Flow

For each player decision, consider:

1. Input Phase

   • What question do you ask?
   • What makes an answer valid or invalid?
   • How do you handle invalid inputs?

2. Validation Phase

   • What resources limit this decision?
   • What error messages might you need?
   • Should you re-ask the question or move on?

3. Update Phase

   • How does this decision affect your game state?
   • What needs to be recalculated?

4. Method Decomposition Strategy

Single Responsibility Principle

Each method should do ONE thing well:

Good Decomposition Example:

• Method 1: Get input from player
• Method 2: Validate the input
• Method 3: Update game state
• Method 4: Calculate result

Poor Decomposition Example:

• Method 1: Get input, validate it, update everything, and print results

Method Categories to Consider

1. Input Methods

   • Getting player decisions
   • Handling invalid input
   • Providing feedback

2. Calculation Methods

   • Computing outcomes
   • Generating random events
   • Updating resources

3. Display Methods

   • Showing game status
   • Displaying results
   • Final summary

4. Game Control Methods

   • Main game loop
   • Checking end conditions
   • Coordinating other methods

5. Planning Your Implementation

Start Simple, Then Add Complexity

Phase 1: Core Mechanics

• Just the basic buy/sell/plant cycle
• Fixed values (no randomness yet)
• Minimal error checking
• Simple display

Phase 2: Add Validation

• Input validation
• Resource checking
• Error messages

Phase 3: Add Random Events

• Harvest variability
• Rats
• Plague

Phase 4: Polish

• Better formatting
• Final scoring
• Edge cases

Testing Strategy

Test Each Component Separately:

1. Test calculation methods with known inputs
2. Test input validation with edge cases
3. Test game flow with a shortened game (2-3 years instead of 10)

Common Test Scenarios:

• What if the player enters negative numbers?
• What if the player tries to buy more than they can afford?
• What happens when resources hit zero?
• Does the game end properly?

6. Common Pitfalls to Avoid

State Management Issues

• Forgetting to update variables after decisions
• Using the wrong variable in calculations
• Not maintaining consistent state between methods

Input Handling Problems

• Not handling non-numeric input
• Accepting impossible values
• Getting stuck in infinite loops

Logic Errors

• Wrong order of operations
• Off-by-one errors in calculations
• Incorrect random number ranges

7. Problem-Solving Exercises

Exercise 1: Dependency Mapping

Draw a diagram showing which methods need information from other methods. This helps you understand the flow of data.

Exercise 2: Edge Case Brainstorming

List 10 things a player might do to “break” your game. How would you handle each?

Exercise 3: Simplification Practice

Take the harvest calculation. How would you implement it:

• With no randomness?
• With simple randomness?
• With the full complexity?

Exercise 4: State Tracking

At the end of year 3, list every variable and its value. Can you reconstruct how you got there?

8. Debugging Strategies

When things go wrong (and they will!):

1. Add Print Statements

   • Print variable values at key points
   • Trace the flow through your methods
   • Verify calculations step by step

2. Test in Isolation

   • Run individual methods separately
   • Use hardcoded test values
   • Verify each piece works alone

3. Simplify the Problem

   • Comment out complex features
   • Test with smaller numbers
   • Run shorter games

Remember: Think Before You Code!

The most important skill in programming is not writing code—it’s breaking down problems into manageable pieces. Spend more time planning than coding, and you’ll save time overall.

Final Tip: If you’re stuck, explain your problem out loud to a rubber duck (or a patient friend). Often, the act of explaining helps you see the solution!