Transcript ppt

Busta’ Sandwich
Life Cycle Architecture
Specifications
Game State Transitions
Game Layout
Objective
Player – Obtain highest score
possible by fulfilling as many sandwich
orders as possible before the chef
explodes from eating too many leftover
sandwiches.
 Single
 Multi
Player – Be the last chef standing!
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.
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.
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.
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.
Architecture
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
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.
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.
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..
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.
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
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
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.
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
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.
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
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