Team #
7: JORBA
Michael Seto mseto@andrew.cmu.edu
Ian Kalinowski igk@andrew.cmu.edu
Jeremy Ng jwng@andrew.cmu.edu
Wee Ming Choon wmc@andrew.cmu.edu
Team Roles
(testing, reliability, application, documentation):
|
Mike |
Jeremy |
Ian |
Wee Ming |
Database |
|
|
|
X |
Game Server |
X |
X |
|
|
Client Module |
|
|
X |
|
Real time analysis |
X |
X |
|
|
Reliability analysis |
|
|
|
X |
Performance analysis |
|
|
X |
X |
CORBA development |
X |
X |
|
|
Project
Title:
Super Borbaman
Baseline
Application Description:
Fault-Tolerant Real-Time Bomberman-inspired videogame. Bomberman is an interactive multi-player game where players
navigate a grid, and blast their way through fun-filled 2D graphics to combat
other opponents.
Configuration:
CORBA, Linux/SDL, C/C++
Third-party software,
if any (databases):
MySQL
Baseline
Application Features (3-10 high-level bullets):
Required:
-
Allows a client
to play with other clients
-
Up to 4 clients (Borbamen) per game
-
A client may only
belong to one game
-
A server may
support multiple games
-
If a game does
not contain the required 4 players, it will block until there are 4 players
available.
Optional:
-
Login screen and
lobby for clients to interact before game starts
-
Rankings for top Borbamen
Reliability
Requirements (3-10 high-level bullets):
-
Preserves current
game state under single server failure
o
Coordinates of
players, and player state
o
Bomb locations,
timers
o
State of map
o
Score
-
Switch from
failed server to another server within 1 second
-
Players who
“drop” may rejoin game within 2 seconds
Real-Time
Requirements (3-10 high-level bullets):
-
Player’s actions
affect the server state within 100ms of execution
-
Clients receive
server updates concurrently every 50ms
-
Updated game
state is saved within database in 25ms
Performance
Requirements (3-10 high-level bullets):
-
Handles 50
concurrent games (4 Borbamen, 10 sprites)
-
Handles 200
concurrent Borbamen
-
Game begins 1
second after all clients are ready
January 28, 2005
-
Architectural
diagram (first draft) has been prepared (link here)
-
Interfaces (first
draft) has been prepared (link here)
February 9, 2005
-
Checkpoint 1 Code
is now available. (link here)
o
Allows Client to
find Server via a IOR published in a file
o
Client may
transmit a single key-press to the server, which will reply to the client with
the same information after storing it in the SQL database
o
TODO: Add naming service
Finalize database structure
Add missing interfaces / Update current
interfaces for the type of data we’ll need to be sending.
February 16, 2005
-
Checkpoint 2 Code
is now available. (link here)
o
Updated “Game”
interface: Includes new methods – IsGameStarted(), ExitGame()
o
Added new “GameServer” interface: JoinGame()
o
Database
structure designed
o
Database is not currently
integrated with this code, but we will have it working before the demo
o
Client program
functionality added
o
Added basic game
logic to the server
February 20, 2005
-
Baseline Demo
(Checkpoint 3) is now available. (link here).
o
Usage
instructions available in /src/README. Or the (link here)