DYNABOMBER

Transcription

DYNABOMBER

University of Southern Denmark
D YNABOMBER
Project Software Engineering I
Jernej Virag
Michal Skuza
Etien Spirako
Alexandros Seresiotis
194679
194558
193546
193530
Supervisor: Peder Christensen
20. 5. 2010
Dynabomber – PSE1 Project
20. 5. 2010
ABSTRACT
This report describes results of a PSE1 project. The goal of the project was to recreate a 1983 Nintendo game Bomberman in such a way that could be easily
playable in multiplayer by anyone with a web browser. For that reason it was
designed with server-client architecture and Silverlight platform was chosen for the
client application with XML data as a protocol.
The end result is an entertaining game that anyone can play by simply entering the
correct URL in a web browser either on Windows or on MacOS platforms with
server-side application that can be run on Windows, MacOS or Linux platforms.
1
20. 5. 2010
PREFACE
This is the report of our project in Software Engineering. The report is intended in
explaining and describing in all possible detail but still in an understandable way
our goals, intentions and finally implemented work. Plus we are going to include
everything that we wanted but did not manage to create.
The group consists of four people each with a varying degree of knowledge in
programing, game designing, project managing and project documenting/reporting.
First is Jernej Virag, a student from Slovenia who is studding Computer and
Information Science. He has a surprising working experience that enables him to
have a high knowledge of programing and also project managing.
Second is Michał Skuza, a student from Poland who is studding Telecommunication
and Computer Science. He is very skilled and talented programmer in an impressive
number of languages and interfaces.
Next is Etien Spirako, a student from Greece that studies Applied Informatics in Management
and Finance. He has a moderate experience in programing but is very skilled at databases, project
management, project documentation and gaming design. Last is Alexandros Seresiotis also from
Greece, studying Automation. He is also has moderate experience in programing but has high
knowledge of project management, project documentation, game designing and he is more that he
would like to admit passionate gamer.
As a team we are connected by our common interest in the gaming scene, our desire to practice
what we study for so long in a project that we find fun and creative and also the desire to work
together with same minded people from other countries. This adds a complexity, as the language
is a heavy barrier, but also is an added motive to see how it is to work in an international scale.
Our expectations as a team were to first of all create something fun that we would be able to
enjoy playing afterward. Then we wanted for our work to be as professional, as complex and as
completed as possible given our capabilities and of course time. We wanted to create something
that almost everyone knew and liked but on the same time move it forward with it. Also apart
from the actual report, we wanted to have the chance to work together as a team. That stayed it
should be noted that not all students in all countries and universities have the chance to work
together with other students as all of their assignments are personal and not teamwork. So we
wanted to expand our knowledge of programing but also of our English language skills. We
wanted to improve our team project working capabilities but also see how students from other
countries are used to work.
2
20. 5. 2010
Table of Contents
Abstract .......................................................................................................................... 1
Preface............................................................................................................................ 2
Introduction ................................................................................................................... 5
Problem specification.................................................................................................. 5
Bomberman (1983) ..................................................................................................... 5
Technology choice ....................................................................................................... 6
Adobe Flash ............................................................................................................. 6
JavaFX ..................................................................................................................... 6
Silverlight ................................................................................................................ 7
Technology decision ................................................................................................. 8
Group member responsibilities .................................................................................. 8
Initial requirements....................................................................................................... 9
Basic requirements ..................................................................................................... 9
Architecture .............................................................................................................. 10
Game mechanics ....................................................................................................... 11
Database model ........................................................................................................ 11
Design document ......................................................................................................... 13
Vision statement ....................................................................................................... 13
Target audience, platform and marketing ............................................................... 13
Legal analysis ........................................................................................................... 13
Gameplay .................................................................................................................. 14
Game level ............................................................................................................. 14
Controls ................................................................................................................. 14
Technical implementation ........................................................................................... 16
Client – server architecture ..................................................................................... 16
System requirements................................................................................................ 16
Communication protocol ........................................................................................... 16
Client protocol ....................................................................................................... 17
Excerpt from client communication ...................................................................... 17
Server protocol....................................................................................................... 17
Server application..................................................................................................... 19
3
20. 5. 2010
Security authentication server.............................................................................. 21
Client application ..................................................................................................... 22
State management ................................................................................................ 22
Performance .......................................................................................................... 22
User interface ........................................................................................................ 22
Collision detection ................................................................................................. 25
Project timeline ............................................................................................................ 26
Initial planning ......................................................................................................... 26
Readjustments and execution .................................................................................. 27
Planning stage ....................................................................................................... 27
Active development stage ...................................................................................... 27
Bug fixing and testing stage ................................................................................. 28
Collaboration and version control ............................................................................ 29
Subversion revision control system ...................................................................... 29
Planning and development software used ............................................................... 30
Conclusion .................................................................................................................... 31
Further work and missing features ......................................................................... 31
Team feedback ............................................................................................................. 32
Alexandros Seresiotis ............................................................................................... 32
Etien Spirako ............................................................................................................ 32
Michal Skuza ............................................................................................................ 32
Jernej Virag .............................................................................................................. 33
References .................................................................................................................... 34
Works Cited and bibliography ..................................................................................... 34
Table of figures ............................................................................................................ 35
Table of pictures .......................................................................................................... 35
Appendix A: Deployment instructions .......................................................................... I
Server application....................................................................................................... I
Client application ....................................................................................................... I
Appendix B: Client keyboard controls .......................................................................... II
4
20. 5. 2010
INTRODUCTION
Problem specification
Since members of our group enjoyed playing 1983 game Bomberman in multiplayer
mode on one computer and there was no modern version of it that would easily allow
us to play the game over internet or local network, we decided to re-create the game
with multiplayer game mode in mind.
The goal was to create a Bomberman clone that could be set-up as easily as possible
and would not require any special installation procedures for players to use. That
game would have to support 2-4 players at once and would also track statistics and
scores of each individual player. Those statistics could then be compared and viewed
in a separate website.
Bomberman (1983)
Bomberman is a strategic, maze-based computer and video game franchise originally
developed by Hudson Soft. The original game was published in 1983 and new games
in the series are still being published to this day. Today, Bomberman is featured in
over 60 different games being commercially successful, with over 10 million units of
games sold.
The general goal throughout the series is to
complete the levels by strategically placing
bombs in order to kill enemies and destroy
obstacles. Exploding bombs can set off other
bombs, kill or injure enemies and destroy
obstacles. However, they can also kill or
injure the player character, destroy
powerups, and sometimes "anger" the exit,
causing it to generate more enemies. Most
Bomberman
games
also
feature
a
multiplayer mode, where other Bombermen
act as opponents and the last one standing is
Picture 1: Dynablaster (Bomberman PC port) ,
the winner. In this mode, powerups are
1990
plentiful. Although most games in the Bomberman series use the same type of mazebased levels established by the original game, some are Zelda-like adventure games,
Mario-like platformers, Tetris-like puzzle games, and kart racers. It is considered to
be a classic franchise by many video game players. (Wikipedia 2010)
Our main focus in the creation of this remake was to, on one hand, remain as close
as we could to the original concept of the game but on the other hand, try and take
the idea to another level.
5
20. 5. 2010
Technology choice
As stated by the goal, the game had to be as easily accessible as possible for
everyone. That’s why we decided to base the client (player) side of the architecture in
a web browser. Consequently that meant that we had to choose between several
browser-based architectures.
Adobe Flash
Adobe Flash (formerly Macromedia Flash) is a multimedia platform used
to add animation, video, and interactivity to web pages. Flash is
frequently used for advertisements and games. More recently, it has been
positioned as a tool for the so-called "Rich Internet Application" ("RIA").
Flash manipulates vector and raster graphics to provide animation of text,
drawings, and still images. It supports bidirectional streaming of audio and video,
and it can capture user input via mouse, keyboard, microphone, and camera. Flash
contains an Object-oriented language called ActionScript.
Flash content may be displayed on various computer systems and devices, using
Adobe Flash Player, which is available free for common web browsers, some mobile
phones and a few other electronic devices (using Flash Lite). (Wikipedia 2010)
The downside of using Adobe Flash was the fact that we would have to use
proprietary development tools, which are not available for free to the students. Also
stability of browser plugin is questionable and team members did not have any
experience with Flash programming. Additionally, in comparison to other platforms
is the least powerful of them.
JavaFX
JavaFX is an expressive rich client platform for creating and
delivering rich Internet experiences.
The JavaFX platform gives unparalleled freedom and flexibility to create expressive
content across multiple screens, including mobile devices, desktops, televisions, and
other consumer devices. It combines the best capabilities of the Java platform with
comprehensive, immersive media functionality into an intuitive and comprehensive
one-stop development environment.
The JavaFX platform empowers content developers by enabling them to focus on
creativity instead of coding. It enables developers to create game-changing
applications and engaging content with maximum market penetration opportunities.
(JavaFX 2010)
6
20. 5. 2010
The problem with JavaFX platform was that it was too new and untested.
Consequently most users do not have required plugins installed (large percentage of
users do not even have Java plugin installed), which would mean they would have to
install the plugin before playing the game. That however would go against our goal
to make installation as simple and hassle-free as possible.
Silverlight
Microsoft Silverlight is a web application framework that provides
functionalities similar to those in Adobe Flash, integrating
multimedia, graphics, animations and interactivity into a single
runtime environment. Initially released as a video streaming plug-in,
later versions brought additional interactivity features and support for CLI
languages and development tools.
Silverlight provides a retained mode graphics system and integrates multimedia,
graphics, animations and interactivity into a single runtime environment. In
Silverlight applications, user interfaces are declared in Extensible Application
Markup Language (XAML) and programmed using a subset of the .NET Framework.
Silverlight makes it possible to dynamically load Extensible Markup Language
(XML) content that can be manipulated through a Document Object Model (DOM)
interface, a technique that is consistent with conventional Ajax techniques.
Silverlight exposes a Downloader object which can be used to download content, like
scripts, media assets or other data, as may be required by the application. With
version 2, the programming logic can be written in any .NET language, including
some derivatives of common dynamic programming languages like IronRuby and
IronPython. (Wikipedia 2010)
The advantage of Silverlight over others is that it’s by far the most modern platform
with C# language as a back-end, which allows modern language constructs for fast
and efficient programming (LINQ, 2nd order functions, etc.). It is also has the least
hardware strain of said platforms. The next benefit is that (because of the required
tight coupling with server-side), we would have to write the server-side application
in C#, which is from the other options (Java, C++) the most efficient in terms of
programming.
The downsides of this platform are similar than those of JavaFX: it is a rather new
platform and a lot of users still do not have the required browser plugin installed.
However, Silverlight plugin installation is noticeably easier (most browsers are
capable of installing it automatically) than JavaFX plugin (which first requires
whole Java JVM installed on the system). The other downside is that Silverlight is
officially supported only on Microsoft Windows and Apple MacOS platforms, even
though an open-source Linux implementation named Moonlight exists.
7
20. 5. 2010
Technology decision
Taking in consideration all the downsides of each platform, we have chosen to go
with the Silverlight platform. It offers the most agile and efficient working platform
with C# language, the team had experience working with the language and most of
the potential users would have little problems installing the required plugin. Also
because we wanted to use some advanced coupling technologies (like serialization)
when communicating with clients, which require the same platform on server-side,
this gave us opportunity to use C# to write the server-side application.
C# is the language most of the team was familiar with and offers the most language
features for fast efficient programming.
Group member responsibilities
Jernej Virag – Protocol, interoperability and server application design
Michal Skuza – Client application design
Etien Spirako – Database, graphics and documentation work
Alexandros Seresiotis – Documentation work
8
20. 5. 2010
INITIAL REQUIREMENTS
After the choice of goal and technology to, we gathered the basic set of requirements
our finishing game would have to support and implement. The initial requirements
specification was as follows:
Basic requirements
2 – 4 player multiplayer
The game is only available for multiplayer gameplay and will only start with 2 or
more players available. It is able to hold up to 4 concurrent players playing in one
round.
Generated level
The terrain is a square type room surrounded with walls; the player cannot pass
through the walls so the movement is strictly within the room, also there are two
types of brick obstacles inside the terrain. The first type is the permanent brick
witch the players cannot break and they are there to stay during the whole game,
they are the core elements so they basically define the terrain. The second type is
the brick that the player can break with his bombs and can pass them. The two
types differ by color.
Player movement
There are four available commands for the movement and the game play, the first
set is attached to four buttons that can move the player through four different
directions (left, right, up, down) and the second set is attached to one button that
allows the players to plant bombs and another to trigger them.
Setting bombs
Bombs are the most important object in the game, the player plants a bomb and
then there is a time until the bomb explodes, the bombs explodes in all directions
(the range of the explosion can be different sometimes due to powerups) the
explosion can eliminate the planter if he is within the range or the opponent player,
or destroy some of the second type bricks. The player can only plant limited number
of bombs at once (depending on powerups he has collected) and has to wait for them
to explode before planting more.
9
20. 5. 2010
Powerups
During game players can encounter items called powerups which change their
abilities. The powerups can be divided into groups: The first group enhances abilities
therefore players can take advantage of other players. The other group gives
negative features to the players which results in more difficult gameplay.
Powerups are randomly placed on map in place of any destroyed second type brick
and can be accessed by all players. Powerups affect players' abilities either
temporarily or permanently.
Powerups which can be found in game are as follows:





Additional bomb: Players can plant one bomb more.
Time span: permanent.
Manual trigger: Bombs can be set off manually.
Bomb range: Range of explosion is increased.
Movement Speed: Player moves quicker.
Time span: temporary.
Scrambled Controls: Control buttons are changed which results in a more

difficult game.
Kick bomb: Allows players to move bombs over walls
Architecture
Login for players
The user will have to enter his personal username and password. These two are
sent to the main server for validation and if they are right, the server sends the
client the o.k. needed to proceed.
Statistic tracking
After the end of each match, statistics about each player will be saved on the server.
These statistics will be:







Lifetime Number of Kills
Lifetime number of Deaths
Lifetime Number of Dropped Bombs
Lifetime Number of Won Games
Lifetime Number of Lost Games
Won/Lost Games Ratio
Lifetime Number of Picked Up Power-ups
10
20. 5. 2010
Tournament support (optional)
Server-side support for automatic ranking and organization of players into
tournaments with end ranked results. It was deemed as “optional” because it was
highly unlikely we would be able to implement this feature within required
timeframe.
Game mechanics
Round based gameplay
Last player still alive wins the round. If last players die at once (death by the same
triggered bomb) the round is considered as a draw.
Games
Player winning 4 rounds is considered to win one game.
Database model
As the requirements stated, that we want to track player statistics, create
tournaments and identify players by login, we had to store collected data. We
decided to store it in a normal relational database and we created a database model
to store the data in.
11
20. 5. 2010
The Games table stores individual completed games, list of players participating and
statistic results. The Player table stores player login data and their play statistics
during all the games they played.
It is worth noting, that because of time constraints, login and statistics tracking
were dropped during development because of time constraints.
12
20. 5. 2010
DESIGN DOCUMENT
In game development, design document is a highly descriptive document describing
all aspects of the game in depth to the last detail. It is approximately analogous to
the Software Design Description document in other software design. It is created in
the pre-production phase and is thus the result of planning of the game
development.
Because of the nature of game design development, the design document has to be
often updated to reflect current game status, so it always describes accurate
functionality for the developers to document. It is the primary document to describe
the specification of the developed game.
Dynabomber design document with all standard chapters follows.
Vision statement
The general idea of the game is 4 players is a 2D platform fighting with each other
via bombs and special abilities in a free for all modes until there is only one left.
The arrows keys move the player through the desired position and each players sets
a bomb witch after a specific amount of time it goes off and if the opposite player is
within range than he loses.
The players and can enhance their bombs and movement through special powerups.
Target audience, platform and marketing
The game is created only for multiplayer mode , since it is a very classic game the
target audience can be between 10 – 99, almost nearly anyone regardless the age can
play , also is recommend for people who don’t want to spend a large amount of time
in a game and just play an arcade type game.
The game will be loaded up in the player’s internet browser, it can be played by any
platform supporting Silverlight 3.0 as long as it has internet connection and internet
browsing abilities. Currently (as of 25. 5. 2010) this includes Windows 2000,
XP/2003, Vista, 7 with Internet Explorer 6SP1, 7, 8, Firefox 3, Safari, Opera or
Google Chrome and Apple MacOS X Intel 10.4/10.5 with Firefox 3 or Safari.
Since the game is non Profit made and only for educational purposes there would be
no marketing.
Legal analysis
Game idea and sprites are copyrighted from the original makers of the game, we are
not promoting this product like our own it’s only for educational purposes. The
copyright to the game sprites and game idea belongs to Hudson Soft Company, Ltd.
13
20. 5. 2010
Gameplay
Game level
The map is a square room. This square room is in fact little squares stacked
together. The length is 15x15 squares. These squares can be one of 3 types, a solid
impassable/non-destroyable one, a solid impassable/destroyable one and a plain field
one which is the only kind of terrain the player can move on.
These will be identified by colors. The impassable/non-destroyable will have a rock
gray color, the impassable/destroyable a brick texture and the plain field a grass
green color.
All the squares from the first and last line and the first and last row, as well as
every second square starting from the first and last line and the first and last row
are the solid impassable/non-destroyable kind of squares. At random squares, other
than the already used ones for the solid impassable/non-destroyable ones, we will
have the solid impassable/destroyable kind of squares. These will be randomly
selected at the start of every new game. All the remaining squares will be of the
plain field type so the player can move on them.
Controls
Player movement and keys
The players will have 6 available commands bound to 6 keyboard buttons. These will
be move up, move down, move right, move left, place bomb and manual trigger. The
player is only able to move in the plain field squares. If a movement key is pressed
and quickly released the players character will move one square towards the
specified direction. If by the time the player character reaches the next square the
movement key is still pressed, the character will continue to the next square until
the key is released.
Bombs
Pressing the place bomb key, a bomb will be placed at the characters current square.
The bomb will have a timer of 2 seconds. After the 2 seconds the bomb will explode.
The explosion will cause all the squares on the left, right, up and down of the bombs
square and with a radius of 2 squares in each direction to be turned to fired up
squares for 0,5 seconds.
If a player’s character is in one of those squares at the time of explosion, the
character dies and the player loses the match. If an impassable/non-destroyable
square is in the trajectory of the explosion then the fire stops at the previous square
and does not continue its normal path. If an impassable/destroyable square is in the
14
20. 5. 2010
trajectory of the explosion then this square is turned into a plain field square and
the fire stops not continuing its normal path. Each player can only place one bomb
and has to wait for it to go off before he can place a new one.
Power ups
When destroying an impassable/destroyable brick, there is a 25% chance that a
power up will appear. Power ups are objects that any player can take by walking on
them. These power ups are either beneficial for the taker or harmful for the enemies
of the taker. The power up will randomly be one of the following. Extra Bomb,
Manual Trigger, Bomb Range and Scrambled Controls. All powerups have the same
probability of appearing.
Available powerups are as follows:
Extra Bomb
This power up will last until the end of the match. This power up will allow the
taker to place one additional bomb, even if the first one is still waiting to explode.
The effect will be stacking so if the player takes the same power up during the
match, he will have 3 bombs etc.
Manual trigger
This power up will last until the end of the match. This power up will make the
takers bombs not explode after 2 seconds. It will also give the taker the option to use
the manual trigger button. Using this button will detonate all the players placed
bombs.
Bomb range
This power up will last until the end of the match. This power up will add one more
square, in all directions, to the takers bombs exploding radius. The effect will be
stacking so if the player takes the same power up during the match, another 2
squares will be added for a total of seven etc.
Scrambled controls
This powerup will last for 15 seconds. This will cause the collecting player to have
his controls switched (pressing up will move the player down, pressing left will move
the player right).
15
20. 5. 2010
TECHNICAL IMPLEMENTATION
Client – server architecture
For communication between players the system uses basic client-server architecture.
Instance of server application manages multiple games and also all game details.
Clients connect to the server via a webrowser with Silverlight plugin installed.
Silverlight application is then downloaded and ran in the browser, which connects
back to the server application to the hosting server.
Game server
server application
HTTP server
Clients playing game 2
Clients playing
game 1
Figure 1: Dynabomber client-server architecture
System requirements
Server application requires .NET Framework 3.5 installed and free access to ports
943 and 4502 from the outside. It also runs with the latest version of Mono on Linux
operating systems.
Clients require a compatible web browser with Silverlight 3.0 plugin installed on
Windows or MacOS systems. Game has been seen run with Moonlight 3.0 preview
on Linux systems, however it was unstable and buggy.
Silverlight applications are only capable of making socket connections to the same
server they were served from, so the HTTP page including the game has to be served
from the same server as the server application is running on.
Communication protocol
To reduce synchronization and lag issues and also to simplify the architecture, all
game logic and details (excluding the player collision detection) is handled on the
server. This ensures that all clients display the same state at almost the same time.
Clients only send to server their local player position data, bomb set and bomb
trigger messages, so the protocol is kept simple for easy decoding and low bandwidth
usage.
16
20. 5. 2010
However, server has to send noticeably more details and game state information, so
that format is unsuitable for server to client communication. Since Silverlight
includes only XML deserialization for complex data and developing our own
deserialization infrastructure would be too time-consuming, the server sends player
all state data in form of XML.
Client protocol
Client protocol knows only few keywords, because most of the processing is done on
the server:
POS X Y Direction Moving - Reports current player position to the server with
indication of facing direction and movement animation
BMB X Y
- Reports that player is attempting to set the bomb on
location
TRG
- Reports that player is attempting to trigger his bombs
Excerpt from client communication
…
POS 516 416 Down False
BMB 516 408
POS 516 416 Down False
TRG
…
Player position is (516, 416), looking down, not moving
Player set bomb on (516, 408)
Player triggered his bombs
Server protocol
Server protocol communicates with client by sending XML data with game updates.
Almost all game updates are accompanied by all player position data and additional
attributes. The players are identified by their respective assigned colours when
processing the data.
XML was chosen because C# (and its subset in Silverlight) offers built-in methods
for serializing objects into C# constructs. Because of this it’s easy to extend the
protocol with new functionality, also the communication is easily readable, which
allows other people to write their own clients. The downsides are noticeably larger
CPU and bandwidth usage in comparison to plain text/binary message formats.
The main classes are:
Basic player update
<Player Color=”color” X=”x” Y=”y” Direction=”direction” Moving=”moving” />
17
20. 5. 2010
Game status update
<StatusUpdate>
<Players>
List of <Player..> updates
</Players>
<Command>
StartGame, PlayerUpdate, BombSet, ClearPowerup or ScrambleControls
</Command>
<X> x </X> <Y> y </Y>
</StatusUpdate>
StartGame - Server notifies client that the game is starting
PlayerUpdate – Server is just sending new player position coordinates
BombSet – New bomb was set at X, Y position
ClearPowerup – Some player collected powerup at X, Y position
ScrambleControls – Local player collected scramble controls powerup, switch input
controls
Player death
<Death PlayerColor=”color” />
Game over
<GameOver Winner=”color” />
Map data
<Map>
<SizeX> x </SizeX>
<SizeY> y </SizeY>
<TileData>
…
<Tile> Brick, grass, wall </Tile>
...
</TileData>
</Map>
Bomb explosion
<BombExplode X = ”x” Y = ”y” Range=”range”>
<DestroyedBricks>
…
<Brick X = “brick X” Y = “brick Y” Powerup = “spawned powerup”
…
</DestroyedBricks>
</BombExplode>
/>
Range – denotes range of bomb explosion for drawing
Powerup – denotes powerup to be spawned in place of the destroyed brick
18
20. 5. 2010
Server application
Server application manages client connections into several games and then manages
game logic for each game.
Picture 2: Running server application window
The main part of the server application is the game manager. The keeps track of all
running games and make sure, that there is at least one idle game waiting to accept
new players. As the manager detects that all idle games have started, it creates a
new idle game to dispatch new players to.
Also it listens to incoming connection and dispatches new clients to the idle games
waiting to start.
Game manager
1
2
Running game
Running game
3
Waiting game
New client
Clients waiting
for game 3
Clients playing game 1
Clients playing
game 2
Figure 2: Server game manager architecture
19
20. 5. 2010
The other important part of the server application is the Game class, representing a
single running game. The game class handles the game logic and client
communication when the game is running. It can exist in several states, according to
the current game state. In the beginning it’s waiting for the clients to connect. When
new client connects, it then sends the client the current level information and
designates a player colour to it. After that it waits for the client to send their ready
command. Once at least two clients are connected and all of them have sent the
ready command, it switches to the game running state, where it runs the main game
logic and receives player information from clients, processes it and returns the
correct updates back to the clients according to the previously specified protocol.
When all except one player are dead, it sends the game over command to all clients
with winner information and after that safely disconnects them.
If there is a connection problem between server and clients when the game is in its
running state, the game is killed immediately, since without all players the game
cannot normally continue.
At least 2 clients connected, all clients are ready
Waiting for
clients
Game in
progress
All except one player dead
Connection problem or other error
Game over
Game manager creates game
Game killed
All clients confirmed game end
Game manager removes game
Figure 3: Single game state diagram
20
20. 5. 2010
Security authentication server
Silverlight applications have built-in security measures, which prevent them from
being used as clients for a DDoS attack. One of those is (already discussed)
limitation, that Silverlight client application may only connect to server it was
served from.
The other noticeable security feature is that before establishing a TCP socket
connection, Silverlight application attempts to connect to port 943 on the target
server, to receive security policy data. Security policy data describes to which hosts
and ports is the Silverlight application allowed to connect.
Since we wanted to make the game deployment as simple as possible, it was decided
to implement our own security authenticator server in the server-side application.
Thus the end-user that would want to use the server wouldn’t have to install
Microsoft IIS server for authentication.
The server application thus includes a security authentication service on port 943,
which authenticates the Dynabomber Silverlight application and serves it a policy
file, which allows the client to connect to server.
21
20. 5. 2010
Client application
Client side is responsible for displaying graphical content of the game, reading user
input as well as handling collision checking. As it was mentioned before it
communicates with server side by using XML serialization.
State management
Client application also includes multiple states: Menu state, Main game state and
Game over state. The client application is connected to server only in the main game
state, while in all others it’s only displaying the game information or waiting for
player input to switch to another state.
Performance
Client side consists of two threads. The main thread is responsible for
communicating with server side i.e. serializing and deserializing data and updating
game states. The second Thread is responsible for displaying user interface, collision
checking and handling user input.
User interface
Initial screen
Picture 3: Initial Dynabomber screen
Initial browser game startup screen, at this moment player is not connected to the
server yet and needs to press a key to initiate server connection.
22
20. 5. 2010
Picture 4: Game waiting for player to be ready
Player connected screen. After the player has connected and received map data, he
is presented with this screen, which shows assigned player color and waits for player
to press key to note his readiness status. The game does not start until all connected
players are ready.
Game screen
Picture 5: Game in progress
This screen shows game in progress. The different type of level bricks are visible,
with two “additional powerup” icons, two players and explosion in progress.
23
20. 5. 2010
Game over screen
Picture 6: Game ended, cyan player won
When the game ends, the player is presented with the game over screen. The
winning player character is displayed with a trophy in hands and the local players
character is depicted with sad character. If the local player is the winner, the 2nd
character is missing and if the game was drawn, all characters are missing from the
screen.
Player character
This is the controllable character; each player has one controllable character for
each level. The whole concept of the game is being realized through the movement of
the controllable character, the controllable character and his features are the core
essence of the game.
Each player has a different colored character (the player colors are cyan, red, green,
blue) from each other so there won’t be any confusion while playing, although all
playable character are completely equal and there is no difference in abilities.
24
20. 5. 2010
Collision detection
The main idea of checking if two objects are colliding is to verify if the two
rectangles, which can represent these two objects, are overlapping.
h1
Rect1
P1
w2
Rect2
h2
P2
wrectangles
2
Figure 4: Collision detection with
x1 – horizontal coordinate of point P1 of 1st rectangle
y1 – vertical coordinate of point P1 of 1st rectangle
x2 – horizontal coordinate of point P2 of 2nd rectangle
y2 – vertical coordinate of point P2 of 2nd rectangle
w1 – width of 1st rectangle
h1 – height of 1st rectangle
w2 – width of 2nd rectangle
h2 – height of 2nd rectangle
In order to check if two rectangles overlap the following expression is calculated:
(
)
(
)
(
)
(
)
If it is true the rectangles overlap, otherwise not.
Figure 5: Player colliding with wall
(rectangles used for collision checking are
shown )
25
20. 5. 2010
PROJECT TIMELINE
Initial planning
Following is the initial timeline plan diagram set right after first goals were
collected.
Start
25.3.2010
19.5.2010
Finish
5d
6d
6d
45d
Duration
Stefan
Jernej;Michael
4.4
18.3.2010
5d
28.3
18.3.2010
1.4.2010
25.3.2010
5d
2
3
4
Week 1
Initial design spec
Week 2
22.4.2010
5d
20d
15d
19.5.2010
19.5.2010
14d
29d
21.3
18.3.2010
1.4.2010
mar 2010
26.3.2010
1.4.2010
Alex
14.3
26.3.2010
5d
Task Name
26.3.2010
15d
ID
Clientside display and movement
1.4.2010
Bomberman project
Database design
22.4.2010
1
5
2.4.2010
26.3.2010
29.4.2010
5d
9.4.2010
Michael;Jernej;Alex;Stefan
6
Design document
2.4.2010
8.4.2010
Week 3-4
2.4.2010
29.4.2010
30.4.2010
apr 2010
11.4
Alex;Stefan
7
2.4.2010
8
23.4.2010
Serverside login and connection
Graphics and detailed
documentation
Powerups
Week 6-7
14d
9.4.2010
28.4.2010
Additional documentation
Week 5
Working bombs
9
11
10
12
13
14
15
18.4
25.4
Jernej;Michael
2.5
Jernej;Michael
Alex;Stefan
maj 2010
9.5
16.5
23.5
Jernej;Michael
Figure 6: Initial project timeline Gantt chart
26
20. 5. 2010
As we were making a remake of an existing game, we could skip certain stages of a
game pre-production phase. That allowed us to start client-side development before
the full design document was finished, since some graphical and functionality
changes were already pre-set by the work we were trying to re-make.
Readjustments and execution
As it turned out, the initial plan was overly optimistic, because we failed to consider
some outside factors (other projects of team-members and extended holiday visits),
which have created noticeable delays in our project execution. After few initial steps
we had to considerably alter our proposed timeline because we were running as
much as a month behind the actual schedule.
Therefore we shifted the whole schedule behind and readjusted milestones so we
could reach them. The end result (and the actual timeline) follows.
Planning stage
11. 3. 2010
Creation of initial timeline schedule (shown on page 26) and setting of
team roles
18. 3. 2010
Finished full outline of project plan and initial requirements (shown
on page 9). Started to prepare full design document.
25. 3. 2010
First design document version complete. Active development starts.
Active development stage
25. 3. 2010
Local player movement and animation code completed, basic graphical
interface working. Created basic game manager code in server
application.
30. 3. 2010
Finished database model design.
Inactivity period because of unavailability of team-members.
15. 4. 2010
Running behind schedule, readjustment of goals and dates. Set new
milestone deadlines. Removed planned login and database systems on
server side because of time constraints. Removed player statics
gathering because of time constraints. Updated design document to
reflect new feature changes.
22. 4. 2010
Server-side map generation and client handling framework complete.
Client-side collision detection and movement improved.
27
20. 5. 2010
28. 4. 2010
Finished collision detection code. Updated client-server protocol
specification to reflect encountered problems with server-client
communication. Added interoperability framework.
3. 5. 2010
Finished bomb and brick client-side animations and added required
graphical sprites.
5. 5. 2010
Implemented security policy manager. Implemented server-client
protocol coupling and error control. Client and server communication
is working.
7. 5. 2010
Implemented bomb explosion graphics, fixed problems with
communication and implemented start-of-game level and player info
receive communication.
11. 5. 2010
Implemented transfer of player information
13. 5. 2010
Implemented full server/client communication for player movement,
setting bombs and bomb explosions
15. 5. 2010
Implemented powerup handling. Improved communication reliability
and fixed collision detection problems.
18. 5. 2010
Added in-game menus and other GUI elements. Implemented gameover detection and communication. Implemented player animation
and direction sending. Features deemed complete, starting testing and
bug fixing phase.
Bug fixing and testing stage
21. 5. 2010
Fixed several communication problems, decided to implement game
start with player ready signals
23. 5. 2010
Fixed several noticeable graphical and reliability bugs.
24. 5. 2010
Deemed code ready for release and distribution.
28
20. 5. 2010
Collaboration and version control
Because we were working on a non-trivial project which required communication
between team members even if they were not available in person, we decided to use
an online collaboration system.
We used Google Code as our project hosting. Google code includes a Wiki editable
system, we used for coordination of tasks and collaborative writing of
documentation. Also we used the downloads system to easily pass documents
between team members.
The code itself was checked into the Subversion versioning control system repository
hosted on Google Code servers.
Subversion revision control system
Because of the rather large scope of the project it was quickly apparent, that we
would have to use some kind of revision control system to manage code written by
team members.
Purpose of a revision control system is to provide a central code database, that keeps
track of all checked-in revisions of the written software. That allows members to see
the changes of all code files during the whole development process, allows members
to undo possible serious coding mistakes and acts as a central backup system. Also it
is capable of smartly merging code from different team-members and thus allows
several people to work on the same software at the same time. Consequently it also
helps in code distribution when team-members are working remotely.
When choosing a revision control system we had several currently popular choices:
Subversion, Git, Mercurial and some others. However since most of the teammembers were not familiar with revision control systems, we decided to use the one,
that is the most stable and easy to set-up.
That was Subversion, which is the oldest of the listed ones, is hosted on Google Code
servers and has the most stable and simple GUI tools for Windows.
Mercurial is noticeably more advanced, but it is distributed repository system and
relative newness meant, that tools to use it are complicated and thus not fit for
people which are just begging to use revision control systems.
Git, while slightly more advanced than Subversion, is still a new system with
unstable GUI tools for Windows operating systems. Also, Google Code does not host
Git repositories, which meant that we would have to move all code to GitHub or
similar public repositories, which was at the beginning deemed unnecessary.
29
20. 5. 2010
The project repository, along with all the tracked changes for Dynabomber is
available on http://code.google.com/p/dynabomber/ .
Planning and development software used
For brainstorming and selection of initial requirements we used a plain simple
blackboard and and paper. For most of the other documentation we used the most
common Microsoft Office suite.
We set-up initial time-schedule with help of Microsoft Project 2010, which allowed
us to visually display our selected schedule timeline, distribute tasks according to
team-members time and also it allowed us to calculate slack we had for each task at
hand.
For development itself, we have chosen Microsoft Visual Studio 2010 with help of
Microsoft Expession Blend 3. The reason for this choise was, that Visual Studio with
Expression Blend is currently the only available development environment for
Silverlight 3.0. Also, it is the most advanced IDE for C# language at the moment
(recongnising and helping with newest C# language features and better code
completion and refactoring support than competing products, eg. MonoDevelop). It is
available through Microsoft Development Network Academic Alliance (MSDNAA)
for student work for free, so it was a natural choice.
To interface with Google Code Subversion repository, we used TortoiseSVN, which is
a free Windows front-end with simple GUI that integrates into Windows Explorer.
For Visual Studio integration, we used AnkhSVN plugin, which is also free and
allows the usage of SVN features from within the VS2010 IDE.
And finally, for sketches and figures to support our development, we used Microsoft
Visio 2010.
30
20. 5. 2010
CONCLUSION
At the project we managed to finish our primary goal: creating a remake of a popular
game in multiplayer capable of easily running on wide range of computers and is
completely playable. The full initial requirements have however proven to be too
optimistic for the time-frame we had to finish our project, so several of planned
features did not make it to the final implementation. In the course of the project we
got a lot of experience about dividing and planning teamwork, we found out just how
tricky setting deadlines can be and which traps and pitfalls lie when developing
software. Also in the course of development we managed to get valuable working
experience with Silverlight platform and C# language in general.
Further work and missing features
There is a number of possible upgrades that can occur to our project in the future
and they are listed below.
Player Login
Each player will be able to register with his own username and password and all
information about his game statistics (game won, defeats, number of games played
etc) will be stored in a database. Player statistics will be viewable by the player
himself or possibly by other players too.
Game Lobby
The user after his login he will be viewing the available games he can choose to join,
the games may have different options from each other (number of players
participating, games powerups allowed etc) and the user will be able to join the
game that suit his preference the most.
Game Additional Features
More additional powerups will be added to game mode. The first is “Speed”, which
increases the character movement speed during the game allowing the character to
outmaneuver his opponents and plan his game strategy much easier. The second is
“Kickbomb” witch will allow the character “kicking” his bomb and bypassing any
obstacle is his way and the landing the bomb in locations and distances he wasn’t
able to do before.
31
20. 5. 2010
TEAM FEEDBACK
Alexandros Seresiotis
My personal expectation was mainly to experience team work. In my home
university all the assignments are personal so you don’t really have the chance to
work with other people in order to accomplice something higher. I always wanted to
work on a software engineering project that had some significance and an actual
result that I could use afterwards. I was very happy that the team decided to create
a game and even more a game loved by me. So what did I learn? I have to admit that
my teammates were much more skilled and experienced in programming than me so
my part in the actual programming was limited (we wanted a good result after all).
The thing that I learned more is teamwork. I learned how it is to be assigned in a
particular job, how to cooperate, how to rely on others, how to follow deadlines. I
learned that a successful project is not only about skillful programming. It is equally
if not more a matter of communication, coordination and cooperation of individuals.
That said I’d like to thank my teammates for the experience they offered me and
also for the patience they sowed at my slight delays.
Etien Spirako
My expectations of our project they were quite significant , this was the main
semester project i had to work on, and it was the first time i had to cooperate with
other students to complete our goals for the project. My gains in experience weren’t
so much in technical aspects as they were in teamwork, i had to learn had to put in
use the experience i had in my previous studies for the benefit of the team , making
a full use of my knowledge in order to make the project happen . I gained a lot of
experience in teamwork , dividing the project tasks, collaborating our ideas,
implementing our ideas in the project and taking responsibility for a task to
complete in order for the fellow team members to move on.
Michal Skuza
I have chosen Software Project Engineering in order to develop my communication
skills in working in a group, gain experience in working in new technology and last
but not least practice my programming skills. Even though it was not the first time I
was working on software project it was very enriching experience. In my opinion this
project helped me to practice new technology - Silverlight, which is quite innovative
and worth learning. Another technological thing I have learned, was practical way of
using version control, which is now an essential part of programmer’s work. I also
practice team working skills as well as effective communications with team
members.
32
20. 5. 2010
Jernej Virag
My expectations of project were pretty big initially, however it has gotten quickly
apparent that in the limited timeframe for project completion we did not have time
to finish all goals. That’s why it was slightly disappointing we couldn’t finish our
starting visio, howevery I’m still very satisfied with the final result of the project. In
the way of development I’ve learned a lot about Silverlight and .NET 3.5 platform,
which will undoubtly help me in the future.
33
20. 5. 2010
REFERENCES
The game sprites, idea and artwork is courtesy of Hudson Software, Limited.
WORKS CITED AND BIBLIOGRAPHY
JavaFX. 2010. http://javafx.com/about/overview/ (accessed May 20, 2010).
MSDN. 2010. http://msdn.microsoft.com/ (accessed 2010).
Silverlight Games 101. 2010. http://www.bluerosegames.com/silverlight-games-101/
(accessed 2010).
Snow, Michael. Game Programming in Silverlight. 1st edition. Course Technology
PTR, 2009.
Troelsen, Andrew. Pro C# 2008 and the .NET 3.5 Platform. 4th edition. Apress,
2007.
Wikipedia. 08 May 2010. http://en.wikipedia.org/wiki/Bomberman_(series) (accessed
May 20, 2010).
Wikipedia. 19 May 2010. http://en.wikipedia.org/wiki/Adobe_flash (accessed May 20,
2010).
Wikipedia. 20 May 2010. http://en.wikipedia.org/wiki/Microsoft_Silverlight (accessed
May 20, 2010).
34
20. 5. 2010
TABLE OF FIGURES
Figure 1: Dynabomber client-server architecture ....................................................... 16
Figure 2: Server game manager architecture ............................................................. 19
Figure 3: Single game state diagram .......................................................................... 20
Figure 4: Collision detection with rectangles .............................................................. 25
Figure 5: Player colliding with wall ............................................................................ 25
Figure 6: Initial project timeline Gantt chart ............................................................. 26
TABLE OF PICTURES
Picture 1: Dynablaster (Bomberman PC port) , 1990 ................................................... 5
Picture 2: Running server application window ........................................................... 19
Picture 3: Initial Dynabomber screen ......................................................................... 22
Picture 4: Game waiting for player to be ready .......................................................... 23
Picture 5: Game in progress ........................................................................................ 23
Picture 6: Game ended, cyan player won .................................................................... 24
35
20. 5. 2010
APPENDIX A: DEPLOYMENT INSTRUCTIONS
Server application
On Windows, the server application requires .NET Framework 3.5 installed to run.
On Linux and MacOS X operating systems, it requires at least Mono 2.6 installed.
Also, to serve the client application to clients, an HTTP server (Apache, IIS,
LightHTTPd or any other) has to be installed. In its configuration the MIME type
for .xap files has to be set to application/x-silverlight-2.
Prerequirements
Server application communicates through ports 943 for authentication and 4502 for
game data. Those ports need to be accessible from the clients. Also the server needs
to serve the client application over port 80 through a web server.
Windows
1. Copy index.html and DynaBomberClient.xap file to HTTP server’s public
folders (c:\inetpub for IIS)
2. Run DynaBomber Server.exe
Linux/MacOS X
1. Copy index.html and DynaBomberClient.xap file to HTTP server’s public
folders (/var/www for Apache)
2. Run mono DynaBomber Server.exe
Client application
Clients trying to play the game need to only have Silverlight plugin (available from
http://www.microsoft.com/getsilverlight/ ) of version 3.0 or newer.
1. Open the server webpage, on which the “index.html” from server-side is
served.
I
20. 5. 2010
APPENDIX B: CLIENT KEYBOARD CONTROLS
Player movement
Set bomb
Trigger set bombs
II

DYNABOMBER

Transcription

Similar documents

ExamView Player

Is your player Tour Series ready?

Untitled - West Ham United

CUSL Roster Instructions

Step by step instructions for players registering for Pelada FA

Land Before Time Make A Match Rules

the program flyer

Youth Basketball League - Olympia School District

Flyer 2015 - Moreton Bay Boys` College

GestureXtreme