TABLE OF CONTENTS

 

1. INTRODUCTION

        1.1 Purpose of the system

        1.2 Design goals

        1.3 DEFINITIONS

        1.4 Overview

2. Proposed software architecture

        2.1 current software architecture

        2.2 SUBSYSTEM DECOMPOSITION

            2.2.1 SERVER

                2.2.1.1 CONTROLLOGIC

                    2.2.1.1.1 SERVER MANAGER

                    2.2.1.1.2 GAMEMANAGER

                2.2.1.2 NETWORK

                2.2.1.3 SAVELOAD

                2.2.1.4 GAME

                    2.2.1.4.1 PLAYER

                    2.2.1.4.2 HERO

                    2.2.1.4.3 MAGIC

                    2.2.1.4.4 CASTLE

                    2.2.1.4.5 BUILDING

                    2.2.1.4.6 ARMY

                    2.2.1.4.7 TROOP

                    2.2.1.4.8 UNIT

                    2.2.1.4.9 MAP

                    2.2.1.4.10 TILE

            2.2.2 CLIENT

                2.2.2.1 GUI

                    2.2.2.1.1 ClientManager

                    2.2.2.1.2 MainGameFrame

                        2.2.2.1.2.1 PreGameFrame

                        2.2.2.1.2.2 InGameFrame

                            2.2.2.1.2.2.1 INFOBAR

                            2.2.2.1.2.2.2 GAMESCREEN

                2.2.2.2 NETWORK

                2.2.2.3 UTIL

        2.3 BOUNDARY CONDITIONS

3. CONCLUSION

 

 

 

1. INTRODUCTION

        This document describes important aspects of the implementation of the Heroes of Might and Magic game.

 

1.1 Purpose of the system

         Heroes of Might and Magic will be a turn-based strategy game that will be played over network.  The proposed system permits two players to play the game at once. In this document we will describe how to implement functional requirements while adhering to non-functional requirements.

 

1.2 Design goals

         Our system has 4 main goals that we will adhere to:

       ·    Developing reusable components that are easy to modify and maintain by paying attention to low coupling- high cohesion principle. We strongly believe that, using well-known design patterns can help us to attain this goal.

        ·     Developing efficient and reliable network components.

        ·     Providing users with an easy-to-use graphical user interface.

        ·     Developing a robust system that can handle errors such as network problems and invalid inputs and give meaningful feed-back to users.

 

 

1.3 DEFINITIONS

1.4 Overview

        Heroes of Might and Magic is a turn-based strategy game which can be played over network. The game should have a flexible design to allow the changes and extensions as much as possible, since changes will be needed to improve the game.  Design patterns were used in the design of Heroes to achieve a flexible, maintainable system.

        

2. Proposed software architecture

        The game will be played over the internet between two players at a time, so the Client/Server architecture is used.  Client/Server architecture supports reusability as it makes each system component visible.  The thin client model is used so the server maintains the game facilities while the client deals only with the graphical interface of the game.

 

2.1 current software architecture

         The system of the Heroes of Might and Magic consists of 2 machines, one of which is the host that has one of the clients and the server, and other is the second client. The server and client in the host machine will communicate in the same way as if they were in distinct machines using TCP/IP protocol.

             

 

 

Diagram-1: System architecture

 

Server is the main component of the game which manages the entire game and leads the other two clients by updating clients’ user interface. On the other hand, clients are responsible only for taking user inputs and displaying the results of the computations of the server based on these inputs. When they get a user input, they send a request to the server. The server processes the request, creates the corresponding response to that request and sends the corresponding response to the clients via the network. Note that, both clients are connected to the server via TCP/IP protocol.

            Heroes of Might and Magic has an event based control flow in clients and the server. The server is initiated by the client that wants to be the host. So the host machine runs two threads, namely Client and Server. When a user creates a new game, the server part of the system is created without waiting for the second client. Machine of the other client has only one thread, Client.

 

2.2 SUBSYSTEM DECOMPOSITION

            In the following sections system is portioned into subcomponents. Basically, at the highest level client-server structural architectural pattern is used. Moreover, in both client and server, Observable pattern is used so as to reduce coupling.

 

2.2.1 SERVER

Heroes of Might and Magic has a thin-client/fat-server architecture, therefore server is the main part of the game. All the data of the game is involved in the server, all the computations related to the specific game actions are processed and all the user-game interactions are handled in the server. The clients only deal with the graphical user interface part of the game and are commanded by the server via ‘Response’ messages which are sent to the clients over the TCP/IP protocol.

Architecture of the server subsystem is represented in high detail in the class diagram below.

 

Diagram-2: Server Decomposition

            Below is the class level static decomposition of the server side. Note that, to maintain simplicity some of the lowest level components are left to be eloborated in the following sections.

           

Diagram-3: Server Side class diagram

2.2.1.1 CONTROLLOGIC

            This package contains the managers that control communication within server and perform all computations related to the game.

 

2.2.1.1.1 SERVER MANAGER

           Server Manager is the brain of server side in the sense that it organizes communication within the server. It is a bridge between GameManager, ServerProxy and SaveLoadManager.

There are two types of messages that are sent over the TCP/IP protocol from server to clients or from clients to server. Request massages are sent from clients to the server and requests some kind of response from the server for a user generated event in the client side. The server handles the Request by making the corresponding computation and change of data in the server side and by constructing the corresponding Response to update the UI of the clients. The other message, Response is a server generated message that is transmitted from the server to clients and that handles UI changes in the clients.

At this point, it will be beneficial to elaborate the Response\Request handling mechanism in general. Response\Request objects both contain a list of arguments. The first of these arguments is the type argument that is used to determine who the receiver is. This argument is checked by ServerManager\ClientManager to determine the address of the receiver. Once a response or a request is delivered to the destination, the receiver partitions the argument list in a type specific manner, depending on what is expected in the content of the receive Response\Request.

 

 

Diagram-4: Activity diagram of system-wide communication process

 

The Observable pattern best suits for the relation between ServerManager, ServerProxy, SaveLoadManager and GameManager. When the ServerProxy gets a Request from the ClientProxy, it notifies the ServerManager so that the request is checked whether it is a save game request, a load game request or any other kind of request. If the incoming request is a save or load request, then the message is transmitted to be processed by SaveLoadManager. All the other messages except these two are sent to be processed by the GameManager.

When any of the GameManager or the SaveLoadManager constructs a Response, the ServerManager is notified and the response to send to the ServerProxy.

 

2.2.1.1.2 GAMEMANAGER

GameManager is the most functional part of not only the server side, but the whole system. It is the part of the server side which holds almost all the data of the game and players, performs all the computations.

 

2.2.1.2 NETWORK

            This package contains only the ServerProxy, which is the communication interface between the server and the clients. It is the door through which all Request objects that are sent by the ClientProxy enter the server side or all the Response objects that are created within the server leave the server side.

 

 2.2.1.3 SAVELOAD

            As the name implies, this package is responsible for save\load functions and contains the SaveLoadManager, which saves or loads a game. When SaveLoadManager is faced with a load request, it loads the specified game and sends the data of the previously saved game to the GameManager. Similarly, when SaveLoadManager is faced with a save request, it saves the current game to the host machine.

 

2.2.1.4 GAME

            This package contains game elements.

 

2.2.1.4.1 PLAYER

            The player is the representation of the user of the game. The player object has heroes (at least 2, at most 4 for now) and a castle (the city of the selected race). Since the maximum number of heroes is predefined by the GameManager, it is better to use an array to hold the heroes. The GameManager process requests of a user via using his/her corresponding Player object.

 

2.2.1.4.2 HERO

            The hero is the most crucial game element. The player can navigate the map and attend battle only via the heroes. The path that is determined after the user input is taken kept as an attribute of the hero. Since the length of the path varies we decided to use an ArrayList to hold the heroes potential path. Every hero has a spell book that is composed of a limited number of spells, which that hero can cast on the troops of his army or the troops of the enemy. As a result, the spells of a hero are kept in an array.

 

2.2.1.4.3 MAGIC

             A magic is a spell that can be casted in the battles on either friend troops or enemy troops.

 

 

Diagram-5: Magic hierarchy

 

2.2.1.4.4 CASTLE

            A castle is the representation of the city of a race which has different buildings in it. The building list of a castle is kept in a constant array, since the number and type of the buildings are defined for each castle. Each race has different buildings allowing different types of units to be recruited. One of the most important properties of the castle is the defensive walls, which are used for the protection of the city in case of an invasion. The number of the castle walls are determined as four, so a constant array is used for them.

 

2.2.1.4.5 BUILDING

           Buildings are used to construct different types of game elements such as magic, unit, other buildings and hero. As a result there exists a building hierarchy shown below. In order to construct some buildings there is a prerequisite list of other buildings which is a constant static array. 

 

Diagram-6: Building hierarchy

 2.2.1.4.6 ARMY

            Army represents a collection of different troops, which are assumed to be composed of the same units. Every hero has an army and every army has at least one -at most 10- troop. In a battle, only one of the troops of the army can be active at a time.

            Since the maximum number of troops that an army can possess is fixed, the troops are hold in an array.

 

2.2.1.4.7 TROOP

            A troop consists of units that are of the same type. The number of units that a troop can possess is not restricted so an ArrayList is chosen to hold the units of a troop, since an ArrayList would do well in such a dynamic structure. Every troop can be exposed to a spell in a battle, and the spell casted on a troop is held in ‘castedMagic’ attribute.

 

 2.2.1.4.8 UNIT

            Units are the elements that form troops. Every unit has different properties [such as attack rate, health etc.] that depend on the race of the unit. As a result, one can only recruit a specific unit from one of four different types of castle in our game. There is also a hierarchy of the units according to their properties like RangedFighter and CloseFighter, which is given in the class hierarchy below. Unit is the last element that is used to evaluate the requests of the users in many different situations.

Diagram-7: Unit hierarchy

 

 2.2.1.4.9 MAP

            Map is the base that is composed of tiles. Double array(Tile) is used as the structure of the map. Also another double array(Char) is used for keeping track of the elements that has special responsibilities on the map(Gold,Hero etc)

 2.2.1.4.10 TILE

            Tiles are single elements that forms the map. Each type of tile has a different characteristics like move rate, picture and id.

 2.2.2 CLIENT

Diagram-8: Components of Client Side

 

As can be see from the figure, the client side is a thin one and contains just two packages, one of which is responsible for graphical user interface and the other is responsible for communication with server. Client side do not have any computational functionality, it’s just an interface.

Note that in the following sections, when we explain any GUI component, we will also give the lists of requests and responses that can be created and processed during the time interval in which the control of the flow is under that specific component. We believe that this will provide consistency and enable the reader to step-by-step identify communication protocol of the system.

Below is the subsystem decomposition of the client side. Note that contents of PreGameFrame and InGameFrame is further eloborated in the following subsections.

 

Diagram-9: Client subsystem decomposition

2.2.2.1 GUI

            Basically this package’s components are responsible for taking input from the user, creating corresponding requests to be sent to server and updating graphical interface components according to the responses taken from server.

 

2.2.2.1.1 ClientManager

             This class is the brain of client side and stands as a bridge between GUI components and ClientProxy. Note that ClientManager observes all the lowest level GUI components. If a request is created in any of the GUI component's listener, ClientManager is notified immediately and takes required action.

            To sum up, from the start to the termination of the execution, ClientManager is responsible from the management of communication transfer within the client and global control flow in client side such as transitions among windows, hence plays a similar role with ServerManager of server side. It has 5 methods;

·        interpretRequest: Interprets a request object created by any of the GUI components and determines whether the request is need to be sent or to be handled by client.

·        transferRequest: Takes a request created by any of the GUI components and transfers it to Proxy.

·        processRequest: This method is for special request, in which a request is created by a GUI component, can be processed by client and has nothing to do with the server, such as setting music and sound of the game.

·        interpretResponse: This method takes a server response from ClientProxy, interprets it and according to the result of interpretation delivers the response to the GUI component of interest or to processResponse method.

·        processResponse: Not all responses are directly transferred to GUI components.  because sometimes the responses may require system-wide process, such as closing the connection and terminating the game, which is the job of  this method..

·        update: This method is inherited from java.Util.Observer interface and triggers corresponding action in case of being notified by an observable object.

 

2.2.2.1.2 MainGameFrame

            This is the top level container for all GUI components at any time. It initially contains the PreGameFrame component and after a successful game creation or join, it changes its content into InGameFrame.

 

2.2.2.1.2.1 PreGameFrame

            This is the high level container for all low level GUI components that perform pre-game functions such as creating a new game, joining a game, selecting local and global elements and setting game options.  Below is the subcomponents of PreGameFrame.

 

 Diagram-10: PreGameFrame Subcomponents

 

             Below are the pre-game GUI components with corresponding requests and updates that take place when the control is in that specific GUI component. For detailed information about  functions of this components, please refer to the specification report.

 

Component

Created Request(s)

Corresponding Response(s)

Processor(s) in Client Side

MainMenuWindow

Request connection for new game or loaded game

 

Request exit

Server initialized

 

 

Connection closed, terminate

ClientManager

 

 

ClientManager, PreGameFrame

GameOptionsWindow

Change options

Options are set

ClientManager

ConnectionWindow

None

Connection is established

PreGameFrame

RaceSelectionWindow

Cancel connection

Connection closed, display main menu

PreGameFrame

Inform server that player is ready

Game is started, display in-game frame

MainGameFrame

LoadGameWindow

Request load

   

Game is loaded, display in-game frame

MainGameFrame

       

Cancel connection

Connection closed, display main menu

PreGameFrame

JoinGameWindow

Request join

 

Join accepted, display race selection window

PreGameFrame

Cancel connection

Connection closed, display main menu

PreGameFrame

NewGameWindow

Request new game

Display connecting window

 

ClientManager, PreGameFrame

Display race selection window.

PreGameFrame

                                                                             

Figure-1: Lowest level pre-game GUI components and communication flow

 

2.2.2.1.2.2 InGameFrame

            This is the high level container for lower level GUI components that perform in-game functions such as navigating the map, attacking enemy, manipulating heroes and developing the castle. Below is the subcomponents of PreGameFrame.

 Diagram-11: InGameFrame Subcomponents

 

           Below are the in-game GUI components with corresponding requests and updates that take place when the control is in that specific GUI component. For detailed information about  functions of this components, please refer to the specification report.

 

2.2.2.1.2.2.1 INFOBAR

            This frame is always visible during playing the game process. It consists of 3 subcomponents.

 

Subcomponent

Created Request(s)

Corresponding Response(s)

 

Processor(s) in Client Side

SmallMapWindow

 Request zoom

Zoom location received, display

NavigationScreen

-

  Hero moved, update view

SmallMapWindow, NavigationScreen

HeroesWindow

Change active hero

  Active hero changed, display new active hero

HeroesWindow, NavigationScreen, SmallMapwindow

See active hero information

 

Display received info in hero information screen

 

GameScreen

 

InGameMenuWindow

End turn

 

Turn ended, disable menus

GameScreen

Save game

 

Game saved, no response

-

Enter castle

 

Display castle screen

GameScreen

Exit game

Connection closed, terminate

ClientManager

   

Figure-2: Lowest level InfoBar components and communication flow

 

2.2.2.1.2.2.2 GAMESCREEN

            This frame is the container for the 5 screens of the 5 main in-game functions. Depending on the user actions and server responses, this frame sets only one of the 5 screens at a time.

            Below are these 5 screens with corresponding requests and updates that take place when the control is in that specific GUI component. For detailed information about  functions of this screens, please refer to the specification report.

 

Subcomponent

Created Requests

Corresponding Response(s)

 

Processor(s) in Client Side

NavigationScreen

Move hero

Hero moved, update view

NavigationScreen, SmallMapWindow

HeroInfoScreen

Request unit info

Display received information

HeroInfoPanel

HeroManipulationScreen

Request unit info

Transfer unit

Display received information

Unit transferred, update view

HeroInfoPanel

HeroInfoPanel

CastleScreen

Request building info 

Display received info

 

CastleScreen

 

Create unit

Unit created, update view

Create building

Building created, update view

Create hero

Hero created, update view

BattleScreen

Request surrender

Surrendered, active hero changed, display navigation screen

GameScreen, InfoBar

Move troop

Creature moved, update view

BattleScreen

Request spell book info

Spell book is received, display

BattleScreen

Pass turn

Turn passed, disable buttons

BattleScreen

Cast spell

Spell casted, update view

BattleScreen

Request ranged attack

Ranged attack is performed, update view

BattleScreen

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure-3: Lowest level GameScreen components and communication flow

2.2.2.2 NETWORK

             This package contains only the ClientProxy, which is the communication interface between the client and the server. It is the door through which all Response objects that are sent by the ServerProxy enter the client side or all the Request objects that are created within the client leave the server client side.

 

2.2.2.3 UTIL

            This package contains only GameSound class, which is responsible for sound effects of the game. Note that, as we will add more utilities in our game this package will contain more utility classes.

 

 

2.3 BOUNDARY CONDITIONS

 

3.CONCLUSION

            In our system, we tried to apply Object-oriented approach and have low coupling and high cohesion . In order to achieve this goal, we used suitable design patterns since the use of design patterns are crucial and since their successes have been proved in O.O.Aproach. We used “Observer Pattern” in both the client and the server part to separate the use of components and to lower the coupling. The “Delegation Pattern” is used especially in the server part during the process of transmitting the client’s requests and servers responses. The decomposition of the system is made logically and the aim is to achieve classes, which are highly, logically related. As a result, in both the ServerManager and the Client Manager part, the low level system components are unaware of the fact that upper layer components use them. Also the client and the server, with all of their high level and low level components, are only dealing with the use of request and response messages. So even if the server or the client side is redesigned while remaining respectfull to the request-response-message comprimise  then the system will still be consistent. This implies the low coupling and the high cohesion of the whole server-client architecture. In this way, we would be also able to handle the complexity of our system.

            Making our game as maintainable as it could be was one of the most crucial motives of our design process, and the use of the mentioned patterns helped to sustain this motive. The future expansions and the maintenance of the project will be quite easy since the general design decisions about the game is taken while obeying the constraints of this non-functional requirement.