Feat/multiplayer

[mshaikh19]

Functions changed (the headline number)	7
Names of those functions	GameBoard::GameBoard(), GameBoard::play_game(), GameBoard::step(), GameBoard::handle_input(), GameBoard::prompt_name_and_save(), GameBoard::show_game_over_screen(), Food::spawn()
Files changed	include/Food.h, include/GameBoard.h, src/Food.cpp, src/GameBoard.cpp
Lines added / deleted	191 additions / 69 deletions
% of codebase touched	31.78%
Hours your group spent	2
LLM model + tool	GPT-5.6 Luna
LLM prompts to working code	5
What code you gave the LLM	Selected files/functions + relevant code snippets
Pasted this assignment doc into the LLM?	y

Analysis

1. Which functions did you have to change that are not about snakes at all? Why did a second snake reach them?

We had to change Food::spawn(), play_game(), prompt_name_and_save(), and show_game_over_screen(). These functions are not directly responsible for the movement of the snakes, but they still depended on the game having only one player. For example, Food::spawn() originally checked only one snake, so it had to be changed to prevent the fruit from spawning inside either snakes. play_game() had to handle the second snake and display both scores simultaneously. The game-over functions also had to show which player lost and display both scores.

2. Was there a single place where "there is exactly one snake" was written down, or was that assumption spread across the code?

The assumption was spread across the code. There was no single place defining that the game supports only one snake or anything like that. Instead, different functions directly used snake_ and score_ which led to assumption that there was exactly one snake in the game. Because of this, adding a second snake affected several areas such as input, movement, food spawning, rendering, scoring and collision detection with walls and with other snake.

3. Compare your Lecture 3 prediction to what actually happened. What did you miss, and why was it not visible from reading?

Our prediction included play_game(), step(), handle_input(), Food::spawn(), several Snake methods (occupies(), move(), reset(), collides_with_self()), and main.cpp.

In reality, the Snake methods and main.cpp did not need changes because we simply instantiated a second snake and called their existing behaviors. However, we missed the GameBoard constructor, prompt_name_and_save(), and show_game_over_screen(). We missed these because we focused purely on snake mechanics and movement, overlooking the UI adjustments required to announce who lost and reset both scores/snakes on a game restart.

4. What one design change would have made this a twenty-minute job?

A Player class or structure containing the snake, score, controls, and player state would have made this much easier for us to make changes in the code. The game could then store the players in a collection and use the same logic for each one of the snakes of the class or structure. Adding Player 2 would mostly involve adding another player instead of changing many separate functions such as snake2_, score2_, and the input logic.