Busta’ Sandwich

1. Busta’ Sandwich Life Cycle Architecture

2. Specifications

3. Game State Transitions

4. Game Layout

5. Objective • Single Player – Obtain highest score possible by fulfilling as many sandwich orders as possible before the chef explodes from eating too many leftover sandwiches. • Multi Player – Be the last chef standing!

6. Game Play Elements • Game board: A 5x5 grid of sandwich ingredients. • Cursor: Highlights currently selected ingredient in the grid. Player can choose to swap this ingredient horizontally or vertically. • Chef Icon: A sprite of a chef that represents the “life” bar of the player. Chef gains weight as player has to eat sandwiches from unfulfilled orders and eventually explodes if chef grows too fat.

7. Game Play Elements, cont. • Tip Jar: As orders are fulfilled the tip jar fills with money, once filled the player can use the self submit button to eat a sandwich with restorative powers. • Order queue: A set of 3 orders from customers with sandwich ingredients and time to fulfill request. As orders are fulfilled they drop out of the queue and new ones are added. • Score: The current score of player.

8. Game Play Elements, cont. • Self Submit button: Ingredients from bottom row of grid are fed to chef. • Customer Submit button: Ingredients from bottom row of grid are matched to a customer order, if no order exists that matches the ingredients chef has to eat sandwich.

9. Multi-Player Elements • Current Opponent window: Shows a selected opponent’s chef icon, game board, tip jar and order queue. • Opponent Submit Button: Ingredients from bottom row of grid fed to current opponent. • Opponent Icons: For games with more than two players, chef icons for all opponents will be displayed along with cursor highlighting which opponent is on the Current Opponent window.

10. Architecture

11. Engine • Coordinates all operations of the game. • Basic Operations (Single-Player & Multiplayer): • 1. Handles user input • 2. Checks for legal move by player • 3. Updates models • 4. Call to Graphics • Multiplayer Operations: • Process network queue • Send updated model to server

12. Engine – User control • Captures user input and then processes input; calls appropriate engine subroutines to handle specific user input • Uses built-in SDL event capturing functions to capture user input. By polling for events, can ensure that all user input is handled and processed in order.

13. Models • GameState: A structure that contains all the information required to store the state of the game at any point. Contains instances of other model types, including Customer queue, Ingredient matrix, score, Chef state, Tip Jar, etc.

14. Graphics • The entire game will be sprite-based. • The graphics engine provides the following functions for the game engine to display the game. • These methods draw the game according to the content in GameState. • drawSPGame(GameState gs): • drawBoard(gs.board) • drawChef(gs.chef) • Etc..

15. Graphics • drawMPGame(GameState gs, MPGameState opponentsBoard) • Other screens are drawn using these methods: • drawMainScreen(...) • drawChefSelelection(...) • drawHighScores(...) • Etc… • The engine will provide all the necessary information to draw things correctly.

16. Networking • Utilizes a Client/Server Model across TCP/IP • Clients are built into the game while there is a dedicated server • When a move is made the client sends its new game state to the server • The server tracks which opponent each client is currently viewing

17. Networking, cont. • Periodically, game states of connected clients are sent to one another: • Summarized information of all other connected clients • Full information of the client currently being tracked • The server is also a relay for the special sandwiches that will be sent

18. Team Structure • Engine Team: Jennifer, Rohit • Network Team: Ross, Frederick • Graphics Team: Julian, Tom • One or both members of the networking team may join the other teams, since the major networking milestones occur early in development. • Each meeting we will reassess the workload of each team and shift workloads accordingly.

19. Team Schedule Part I • 7/15/05 (F) 10:00p • Graphics: Draws colored blocks and a layout to the screen. • Engine: Handles keyboard/mouse input. • Network: Client connects to server, sends state, server sends states, disconnects. • Engine: Models/Data Structures constructed. • 7/18/05 (M) Noon - Team Meeting. • 7/19/05 (Tu) 10:00p - Zero-feature Release

20. Team Schedule Part II • 7/26/05 (Tu) - Team Meeting • Network: Client queue implemented. • Network: Sever sending data structures. • Graphics/Network: Connect GUI screen. • Graphics: Grid working. • Engine: Updating grid, checking moves. • 8/02/05 (Tu) 10:00p - Beta Release • All: Single player done.

21. Team Schedule Part III • 8/9/05 (Tu) - Team Meeting • Graphics: GUI menus done. • Graphics: Sprites complete. • Engine: Process all network messages, i.e. multiplayer • All: Everything but animations and sound. • Network: Network balance done. • 8/12/05 (F) – All: Game complete. • 8/14/05 (Su) 10:00p - Final Release

22. Test Plan • Platform: CSE Lab WinXP Machines, 100Mbps Ethernet • Unit Testing: Each development team will test its module heavily before committing to CVS • Integration Testing: Each team must make sure their new modification doesn’t break the system. • Bug Tracking Tool: Bugzilla • “Public” Release: August 9. Release to friends to test game play