7 Sprints & Questions🔗

18 September 2024

Questions?

Information vs Data vs Information

7.1 Sprint Memos🔗

[30-45min, 5 + 10mins per?]

Work through abstractly: What is a sprint description? How to evaluate it with respect to what “we” discussed on the white board? About general principles of building software?

Let the students understand and evaluate each memo.

7.1.1 Evaluating Descriptions of Sprints🔗

show one at a time, discuss

The purpose of a sprint description is to sketch the work to be accomplished in a certain period of time, say, a week.

Here are obvious questions we can ask about any sprint description.

1. is the memo formatted properly?

2. does it suffer from superfluous prose?

3. does it clearly delineate three sprints?

4. does each sprint clearly state which components are to be constructed?

5. are the products of each sprint testable? does the team proceed bottom up?

6. can you match the sprints to the high-level architecture hint from lecture 3?

7. is each sprint a reasonable amount of work for one week?

It is unnecessary to include precise specifications of the desired components. That’s part of the work, based on a rough outline of the what, and perhaps even hints about the how, behind the component; these need not be included either.

7.1.2 Memo 1🔗

TO: The CEOs
FROM: A person and another person
DATE: September 12th, 2024
SUBJECT: Sprints

Sprint 1 First start prototyping the logic of the game. This should involve a protocol between the referee and the players.

Consider using TCP socket, hooked up to a JSON stream, for communication between the referee and the players. The referee should be able to send the following information to each player: - General Game Info - Client Info: Username, Score, Pebble Totals - Other Player Info: Username (Maybe?), Score - Bank Info: Number of Pebbles Left - Board Info: Visible Cards, Number of Face Down Cards, Equations

Design JSON commands for state-update messages and client turn interactions. Turn interactions involve: using an equation, buying one of the visible cards, and drawing a random pebble.

After designing the protocols, create a model of the game that the referee will control. The model should be able to handle any of the above client turn interactions and it should update its internal state. It should also handle malformed client turn interactions gracefully.

Sprint 2 Design the client GUI and the client code that reconstructs the game state locally. Also, design bots that play the game.

After this sprint, we can run one game – players, a referee, e.t.c. Write complete localhost integration tests, where the test spawns all players, and the referee server, and tests that a game works.

Sprint 3 Design a matchmaking system that allows a player (that is identified by their client token – use oauth) and collects players into games. In order to start a game, the matchmaking server should send thee unique game token to all of the players participating. Then the players connect to the referee with their game token to start the game.

Implement a countdown for each game that starts when at least two players in the assigned game connect to the referee. This coundown will act as the lobby for the game, we simply wait for 2-3 seconds for all players in the game to join, and if players don’t join that (maybe?) replace them with bots.

7.1.3 Memo 2🔗

To: CEO
From: a student and another student Date: 9/12/2024
Subject: Plan for the milestone

Sprint 1: Design Model For the Core Components on User End We are planning on creating a player-referee interface, Player class(AI player and Manual Player), Referee class, Observers class, Card class, and Equation class.

Sprint 2: Design View for the classes in Sprint 1 We will create a login box page which will direct to a waiting room page. Once the game starts, players will be directed to the game board page where the players, referee with visible cards, equations, pebbles for users, cards for users will be visible on a hexoganol table. When a player wins, the end scene will show up saying "Player XX wins!"

Sprint 3: Data representations For sprint 3 we will create data representation for the server to generate and send to user end, such as the equations, the bank, the player’s pebbles, game state, cards, etc. This will help us show how many of each pebbles, cards, players will be on the board for the view to display.

Sprint 4: Handle controller, connecting Model and View connecting what we do in first two sprints, and hander server message and user input.

7.1.4 Memo 3🔗

To: The CEOs
From: Someone and someone else
Date: Thu September 12, 2024
Subject: Sprint 1-3 Planning

Good evening amazing and gracious CEOs. Below is our outline for the upcoming first three sprints, and a high-level plan for the construction of our robust distributed multiplayer system.

Sprint 1: The Game Pieces - We will design and construct the basic game pieces (board, pebbles, cards, equations, bank). - We will test possible combinations and constructions of game objects.

Sprint 2: The Game State - We will design and construct a Gamestate, which exposes and handles game state manipulations. - The Gamestate will be composed of the components constructed in the previous sprint, and will also keep track of Player information, managing an order of Player "inventories", ID, points, and status (valid, eliminated). - We will design and implement a way to extract a summary of Gamestate information. - We will test the Gamestate and associated game state manipulations and summaries, relying on previous sprints tests being valid.

Sprint 3: The Referee - We will begin designing and constructing a Referee, which manipulates Gamestates from the previous sprint. - We will focus on the Referee responsibilities of Gamestate manipulation, as we don’t yet have a Player design or other higher components. - We will be testing the interactions between the Referee and the Gamestate, which are calls to the Gamestate manipulations, relying on previous sprints tests being valid.

7.1.5 Memo 4🔗

To: CEO, Dot Game Company
Date: September 12, 2024
Subject: Development Sprints Overview for Bazaar Game

Overview The purpose of this memo is to outline the first three development sprints that the team will undertake to build the foundational components for the Bazaar game. Each sprint will focus on critical parts of the game system that are necessary for creating a functional, scalable game architecture. The main focus for the initial phases of development will be the game logic and referee implementation. Below is a breakdown of the activities for each sprint, along with the reasoning behind the prioritization of these tasks.

——————————————————————————————————————————————————————————————–

Sprint 1: Define the Game Logic and Data Structures

Objectives:

In the first sprint, the team will focus on defining the basic game entities and rules of the game. This involves establishing the core components of the game that will be referenced in all future implementations.

Tasks:

Define the game entities: Card, Pebble, Equation, Bank, and Player. Model the rules for:

• Purchasing cards

• Exchanging pebbles via the equations

• Scoring based on the remaining pebbles

• Conditions for ending the game

Reasoning:

The game logic is the heart of the system. Without a clear and structured definition of the rules and game objects, it would be impossible to implement more advanced features or enable interactions between the players, bank, and cards. By defining the game entities early, we ensure that the foundation is solid for further development, making future work more efficient and easier to test.

——————————————————————————————————————————————————————————————–

Sprint 2: Extend Game Logic Development

Objectives:

Given the complexity of the game rules and interactions, this sprint will continue to refine and expand the game logic. The goal is to ensure that all edge cases and game scenarios are addressed, allowing the game to handle various player strategies and outcomes.

Tasks:

Finalize the game rules to cover all scenarios, including:

• Complex trading strategies between players and the bank

• Edge cases for scoring and player eliminations

• Game ending scenarios (multiple conditions)

• Integrate these rules with the game entities defined in Sprint 1.

Reasoning:

Game logic development is a multi-phase task, as the rules of Bazaar involve several intricate mechanics like trading and scoring. This additional sprint ensures that all game mechanics are fully realized and functional. By spending more time on the logic, we avoid potential pitfalls and complications during later stages of development.

——————————————————————————————————————————————————————————————–

Sprint 3: Implement the Referee System

Objectives:

The third sprint will focus on developing the Referee system, which is responsible for enforcing the game rules and managing game flow. This system is critical for game operations as it will interact with players, manage turns, and enforce rules.

Tasks:

Implement the Referee class to:

• Set up the game (initialize players, cards, bank, and equations)

• Oversee player actions, ensuring rule compliance

• Handle illegal actions and eliminate players where necessary

• Track and update player scores

• End the game when winning conditions are met (e.g., points threshold or resource depletion)

• Ensure integration between the Referee and game logic entities developed in previous sprints.

Reasoning:

The referee is the cornerstone of game management. Once the game logic is established, the next step is to ensure the game can be properly supervised and progressed. The Referee will act as the controller for all game activities, making sure that every action taken by players follows the game rules. Its early implementation allows for a smoother transition when developing player and multiplayer interactions in future sprints.

——————————————————————————————————————————————————————————————–

Conclusion

The outlined steps for the first three sprints reflect a logical progression, ensuring that each layer of the system is built on a strong foundation. Starting with core game logic and data structures will allow us to scale up to more complex features like referee management and, later, player interaction. By prioritizing the most essential components first, we aim to deliver a stable and well-structured game system for Bazaar.

Should you have any questions or require further details, feel free to reach out.

7.2 Questions🔗

[5min]

7.3 C🔗

[10-15min]

Spec. Emphasize re-use.

Demo. Two terminals is fine. Navigate in both to Code/C:

$ pwd .../Code/c $ ./xtcp $

$ pwd .../Code/c $ ./nc 127.0.0.1 45678 "query"  {} $

Don’t forget to install nc. Also see the spec of C, which explains this demo.

Code. Re-wire the streams. That’s it.

Total: 45-60 mins (which does not include the Q&A period)