Revised Analysis Report

 

1.        Game Overview

2.        System Proposal

            2.1 Functional Requirements

                        2.1.1 Starting the game

                                   2.1.1.1 Creating a new game

                                               2.1.1.1.1 Waiting Screen

                                               2.1.1.1.2 Race & Hero Selection

                                   2.1.1.2 Joining a game

                                   2.1.1.3 Loading a game

                                   2.1.1.4 Game options

                                   2.1.1.5 Getting help

                        2.1.2 Playing the game

                                   2.1.2.1 Game Components

                                               2.1.2.1.1 Units

                                               2.1.2.1.2 Castles and Buildings

                                               2.1.2.1.3 Gold, spells and specialties

                                   2.1.2.2 Game Screens

                                               2.1.2.2.1 Navigation Screen

                                               2.1.2.2.2 Function Specific Screens

                                                              2.1.2.2.2.1 Combat Screen

                                                              2.1.2.2.2.1 Hero Information Screen

                                                              2.1.2.2.2.2 Troop Sharing Screen

                                                              2.1.2.2.2.3 Castle Development Screen

            2.2 Non-functional Requirements

            2.3 System Components

                        2.3.1 Server side

                                   2.3.1.1 GameManager

                                   2.3.1.2 ServerProxy

                                   2.3.1.3 Player

                                   2.3.1.4 GameLoader

                        2.3.2 Client side

                                   2.3.2.1 ClientProxy

                                   2.3.2.2 ClientManager

                        2.3.3 Putting altogether

                                   2.3.3.1 Moving a Hero

                                   2.3.3.2 Casting a Magic

                                   2.3.3.3 Recruiting Units

                                   2.3.3.4 Constructing a Building

 3. Conclusion

 4. References

 

 

 

 

 

 

 

 

 

 

1. Game Overview:

 

Heroes of Might and Magic is a famous turn based strategy game developed and presented by 3DO Inc. The excitement and entertainment of the game is oriented from game’s interesting features. Since the original game is a very complex one, we decided to limit some parts as shown in Table-1.

The main objective of the game is to defeat the other player via capturing his/her castle. There are very important properties that distinguish Heroes of Might and Magic from other turn-based strategy games. The most important one is the variety of heroes and basic units. There are different races -namely Human, Elf, Undead and Evil- and different creatures which belong to these races. The details of the units are given in the Game Elements parts.

 

Original Game *

Our Game

Single and multiplayer game options

2-player game

128 different heroes. Limitless hero number for a player

16 different heroes. Maximum 3 heroes at a time for a player

Player can have more than one castle

A player can have only one castle

7 different races

4 different races

Various types of resources

Only gold resource

A lot of different magic types

Limited number of magic types

Lots of different hero specialties

Limited number of hero specialties

Various types of path elements

Only land, river, mud, tree and gold path elements

About 60 different unit types

Total of (4 races * 8 unit types =) 32 diffent unit types

A lot of screnarios and maps

3 scenarios

 

Table-1: Comparison of original game with our game

* Please refer to reference section

 

 As the name of the game implies, the most important components of the game are the heroes. A hero is the main unit which is seen on the game map. It can move, grab gold and carry combat units into battles. A hero has an army consisting of different creature troops. Properties of a hero is attack rate, defence rate, spell power, move rate, specialities, experince points, magics,which are valuable objects that changes hero’s power. The existence, magics and specialties determine the mental power of a hero rather than physical power, which is heavily influenced by mental power. Therefore, a good stratgey requires thinking the best combination of all properties, not only crowded armies.

There are various kinds of units of armies. The diversity of the units come from the diversity of unit creating buildings. Basically, the units differs in terms of their fight capabilities such as attack styles, attack eficiencies, defense rates and many other properties. 

Both the cunstruction of the buildings and the creation of new units require resource. We plan to limit the resource type with only gold to manipulate simplictiy in oppose to original heroes, where there are wood, cyristal, ore, etc. as resource.

To sum up, the vital strategy of winning the game is to developing heroes  and the castle as quickly as possible so as to hit the mortal fisk on the enemy.

 

 

2. System Proposal:

          

We will describe our project in three steps. Firstly, we will demonstrate the facilities that our game provides. Secondly, we will discuss the constraints that these facilities enforce and our solutions to these constraints. Finally, we will move on to the specification of the model of our game.

 

2.1 Functional Requirements:

 

In this part, we describe the facilities offered by our game and step-by-step demonstrate how to use this facilities. Let’s see facilities of our game.

Figure-1: Use cases of the game

 

2.1.1. Starting the Game:

 

When users start Heroes of Might and Magic, the main menu will appear on the screen, allowing them to create a new game, join an existing game, load a game, set game options and get help. Below we will describe each main menu function.

 

Screenshot-1: Main Menu

 

2.1.1.1 Creating a New Game:

 

Upon pressing “Create Game” button in the main menu, the “Create Game” screen (Screenshot-2) will appear on the screen, in which the player can set the global settings of the game such as the map. The password field is required for using save and load options. User can select the game map by looking at specific scenario associated with each map. Local settings such as race selection and hero selection can only be done after both players are connected to game, which will be discussed later.

Upon pressing the “Create” button, the system will try to connect server and the user will see the waiting screen. If user presses on the “Back” button, player will be directed back to main menu.

 

Screenshot-2: Create Game

 

 

2.1.1.1.1 Waiting Screen:

 

This screen shown during waiting of player for the second player. If two players are connected, the system will automatically direct the user to race & hero selection menu.

 

 

Screenshot-3: Waiting Screen

 

 

2.1.1.1.2 Race & Hero Selection:

 

            At this step users make strategically crucial decisions, namely the selection of race and initial hero. The screen comes up with a default race and hero, but users are free to choose whatever race and hero they want.

            The rival's choice is not shown so as to enforce strategy and chance factors, therefore players must make a good choice.(Screenshot-4) Having selected the race and hero, users must confirm their selection by clicking the check box. When both users are ready, the server starts the game and the game screen is opened.

 

Screenshot -4: Race & Hero Selection

 

 

2.1.1.2 Joining a Game:

 

            Upon pressing “Join a Game” option in main menu, users will see the below screen (Screenshot-5) and are required to fill in the fields. Having pressed the “Connect” button, the system will try to connect to server. If the parameters are correct and a game waiting for the second player exists, the user will be directed to select race and hero, as mentioned in the previous section. If there is no game in the server, the user will be informed and will be directed to main menu. However, in the case of wrong password entry, the user will be forced to reenter password and this procedure will repeat until the user enters a valid password.

 

Screenshot-5: Joining a Game

2.1.1.3 Loading a Game:

 

            Having pressed the “Load Game” button in the game menu, users will see the below screen (Screenshot-6), in which user is asked for selecting the game to be played. To select the game, user must press the “Select File” button and navigate files via a file chooser, which will be activated after pressing search button. Having pressed load button, the user will be directed to play the game. In case of error loading the game, the user will be informed about the reason and directed to main menu. Similarly, if user presses “Cancel” button, s\he will be directed to main menu.

 

Screenshot-6: Load Menu

 

2.1.1.4 Game Options:

 

            Upon pressing “Game Options” users can set game options such as listening to Heroes of Might and Magic Soundtracks and level of the sound via the below menu (Screenshot-8). If user clicks on “Cancel” button old settings will remain, but if user clicks on “Confirm” button new settings will be saved and user will be directed to main menu.

Screenshot -7: Game options

 

2.1.1.5 Getting Help:

 

            Upon pressing on “Help” button, users will see the “Help Guide” which is an HTML document as can be seen below (Screenshot -8).

 

Screenshot-8: Help Document

 

 

2.1.2. Playing the Game:

 

Players start with a hero and a dark map. Moving their heroes players can navigate map, collect gold, declare war, develop city, attack enemy and share army, thus develop to defeat the rival. In the following subsections we describe game elements, game screens and their functions, but before advancing more let’s see the in-game facilities of the game (Figure-2).

Figure-2:  In-game Use Cases

2.1.2.1 Game Elements:

 

2.1.2.1.1 Units:

            As the name of the game implies heroes are the actors of the game. They have armies consisting of troops of units. To support strategic and visual diversity, our game introduces 4 races, namely the Human, Elf, Death and Evil races. Each race has specific heroes, castles and soldiers. When the game starts, each player is given the chance of choosing an initial hero and a specific race. During the game, the player can recruit new heroes -with a maximum of 4- and develop them by enlarging armies and gaining specialties such as experience and spell knowledge.

 

            Moreover, our game introduces variety of units. For example, each race has its own kind of archers, swordsman and dragon. Basically, Elf race and Human race have different kinds of archers. Elf archers are stronger than Human archers, but Human swordsmen are stronger than Elf swordsmen. This trade-offs forces players to think strategically.

 

           Units are organized into troops and troops are organized into armies, which are under control of heroes. The players cannot move individual units during map navigation, but hero’s movement represents the movement of army as well as movement of the hero. However, during the combat the player can move troop of units. To summarize the troop actions, let’s see the state diagram of a troop.

Figure-3:  Troop States

 

2.1.2.1.2 Castle & Buildings:

 

        Each player has a castle, which must be developed and defended against enemy attack. If the user looses the his\her castle, s\he will be defeated, therefore castles are strategically very important, and so are its components. Castles consist of buildings, which have different functions such as creating hero, creating unit, constructing building and producing gold. Since player’s race also determines the building types, players should consider the building factor during race selection. Basically, each castle has similar buildings with some trade-offs. For example, Elf buildings produce more units than Undead buildings in a period of time but their work cost is very expensive.

 

2.1.2.1.3 Gold, Specialties & Spells:

 

        To advance strategic thinking, our game provides specialties and spells. Specialties are associated with heroes and they represent the mental strength of a hero rather than the physical strength. Players need to consider the fact that, mental strength is the key for managing physical strength. For example, with the help of experience and morale a hero can defeat its enemy with better attack rate and less cost than if it attacks merely with crowded army without morale and experience. Spells also increase the attack rate of heroes with providing alternative attack strategies. For every casted spell, the “mana” of the hero which is the spell power of the hero, is decreased.

    Of course, gold empowers the player economically. Specialties and spells can be gained from wars or collecting experience boxes that are randomly distributed over the map, which are randomly distributed over the map. The income of gold is provided from the city itself, owned mines or randomly distributed gold. The castle gives the player specific amount of gold, depending on the type of the castle,  each turn according to the development level of the city. Another way to gain gold is to capture mines. The most common way is gathering random gold distributed on the map randomly. So, this provides the luck factor on our game which is similar to real life conditions.

 

2.1.2.2 Game Screens:

 

Below is a sample game screen from the game (Screenshot-9). Basically, the screen is divided into two parts. At the right is the information bar and at the left is the navigation screen. Moreover, there also other screens, which we call upper screens that will be functional during specific times according to game flow such as combat screen, castle screen and troop sharing screen.

 

On the information bar, player can see the small map, his\her active heroes,  remained move credit. Information bar  is visible during whole game, irrespective of the type game flow.  At a given time a player has only one active hero but s\he can change the active hero by clicking on the image of the new active hero. Moreover, by pressing the buttons, player can go to castle development menu, end turn, save game and exit the game. In case of exiting the game the user will be asked whether s\he wants to save the game, providing that the player is the host because only hosts can save the game. Saving the game is quite straightforward, player only need to click the button and the game is saved into a default saved games directory.. When the turn ends, this screen along with the navigation screen is disabled, meaning that all functional buttons will be disabled until the rival player’s turn ends.

 

 

Screenshot-9: Game Screen

 

2.1.2.2.1 Navigation Screen:

 

Figure-4:  Navigation Screen Facilities

 

This screen is the mostly used one. The game starts with a dark map except the regions where the castles are located. To open the map, players need to move their heroes through the map. The map is a tile based map and each part of the map has characteristic friction rate which may prevent hero’s movement completely or partially by costing more move credit (Figure-5). As the map is discovered, both the map screen and the small map on the information bar will be updated.

            It is enough for players to select the target location to move hero. If the system finds an   available path, the path will be highlighted. If the path is a usual one then hero just moves. However if there are obstacles, other heroes or gold along the path, the move action may result in different cases as depicted in Figure-2, namely the combat, troop sharing and castle development.

 

2.1.2.2.2 Function Specific Screens

            These screen are specific ones for specific actions such as battling, seeing hero information, manipulating heroes and developing castles. When active, a function specific screen will cover navigation screen and disable it until the screen is exited. Let's see these upper screens in detail.

 

2.1.2.2.2.1 Combat Screen:

 

Player can declare war against the enemy hero by click on the target enemy hero as the target location. In case of entering a combat, the navigation  screen will  be covered wit the upper battle screen and all menus of info bar and navigation screen will be disabled until the combat ends. (Screenshot-10)  In this screen, both players’ heroes and their armies are shown.

 

Screenshot-10: Combat screen

 

At each turn one troop will attack to enemy, and player can see the properties of the hero or the troop by clicking on it. The shaded area is the attack range of a specific troop. If there is no enemy within the range of the attacking troop, the troop only advances towards the enemy so that in the next turn it can make an attack. The heroes do not fight but do cast magic. When all the troops of one of the heroes are destroyed the other wins and gains some specialties as the gift of the victory. The details of all combat actions are described below in Figure-6.

 

Figure-5: Combat Activity Diagram

 

Castle combats are special ones. If the combat is a castle siege, than the in the combat screen there will appear the ramparts, which can be destroyed only with a castle destroyer. However, ramparts do not impose any constraints on flying units. When the castle is captured, the attacker player wins the game and the game terminates.

 

2.1.2.2.2.2 Hero Information Screen:

 

            Upon pressing "See Hero Info" button on the information bar, this screen will be shown. In this screen player can only see current situation of the active hero. To see other heroes' information, the active hero must be changed by clicking on the desired hero and then the player can see the new hero's information.

 

 

Screenshot-11: Hero Information Screen

 

 

2.1.2.2.2.3 Hero Manipulation Screen:

 

      Heroes of Might and Magic game provides the players with the facility of sharing military resources between two allied heroes. If player wants to share troops between specific heroes for strategic purposes, then player needs to bring these specific heroes next to each other by moving one of the heroes next to the other. When the allied heroes encounter each other, then hero manipulation screen is shown which covers the info bar and navigation screen and disable their menus as happen in entering battle case. with troop sharing screen as depicted below (Screenshot-11). Player needs to specify the troop being transferred by clicking on the image of specific troop and the amount of transfer operation. The user will be informed about the result of operation, which may result in failure due to the capacity restrictions on heroes.

 

Screenshot-12: Troop transfer screen

 

22.1.2.2.2.4 Castle Screen:

 

Figure-6: Castle Screen Facilities

 

Castle development is one of the most strategic operations. This screen can be accessed by clicking on the “Castle” button on the information bar, which is available on info bar. Upon pressing the button or upon entering the castle by moving the hero, castle screen will cover the navigation screen and disable its menus until exiting from castle screen, in which the constructed buildings are displayed. By clicking on each a constructed building player  can see how many creature of that building can be created and also can create units. Moreover, by clicking an unconstructed  building the player can construct the building providing that s\he has sufficient funds.  When units are created, they will join to the army of the active hero.  Note that, players can construct limited number of buildings. Player will be informed of results of all operations.

 

Screenshot-13: Castle development screen

 2.2 Nonfunctional Requirements:

            Heroes of Might and Magic’s target audience is the strategy game addictives. The users are not required to have any pre-requisite experience or knowledge. In case of any problem users will be informed about the possible reasons of the problem and are strongly encouraged to consult the help document which is available via the main menu of the game. We will also provide users with a “how to play” document in which users will be guided to develop good strategies.

            The user interface of the game is very straightforward as can be seen in the user-system interaction demonstration above. The simplicity of user interface decreases the time of the player spent to interact with the system thus gives more time to user so that s\he can be focused on the game, rather than application’s constraints such as complex menu transitions. Moreover, the simplicity of user interface also prevents users from making errors.

            Since the game is term-based, it will be quite fast when compared to a real time strategy game.           Our client-server architecture assumes small data exchanges, which is very important in terms of performance. Unfortunately, we impose some constraints on the game such as capacity limits on number of heroes of a player, number of troops of an army, number of units of a troop and number of buildings of a castle. This is because in real life nothing is limitless. As a result, our constraints agree with the real life phenomena. However, these constraints provide the game with the increase in performance.

            Last but not least, reliability is one of the key factors for our game. Incase of connection problems, the both users will be informed and asked for whether they want to save the game. Later when the connection is re-established both players are enabled to resume the game. 

2.3 System Components

2.3.1 Server Side

 

Server Side is the main part of the game where all the processing related with the specific game actions are done, all the data of the game is held and most of the user- game control interactions will be handled. The client side only deals with the manipulation of the user interface of the game. So the thin-client, fat-server architecture is used for the game’s server-client architecture.

 

Client side handles the user actions by sending the appropriate commands to the server. Server responses them by sending the required changes for the user interface via its update packages. Command and update packages are transmitted via proxies, which are explained in more detail in the following pages.

 

Server is initiated by the host player. A user becomes ‘the host’ after clicking “Create a Game” or “Load a Game” buttons. In the same way, the server is initiated right after one of these buttons is clicked. One of the scenarios, the creating a NewGame is described below via a sequence diagram.

 

Figure-7: Creating a New Game

 

The server-side possesses 4 main parts: GameManager, ServerProxy, Player, GameLoader etc.

2.3.1.1 GameManager

 

     GameManager is the most crucial part of the whole system. It processes all the specific game actions, runs specific algorithms. Basically it sets the game up as showed above, manipulates all data and runs specific algorithms. It creates update packages to be sent to clients as the result of action it performs.

2.3.1.2 ServerProxy

      Server Proxy is the communication interface between the server and the clients. All command packages coming from the clients are sent to ServerProxy by the ClientProxy and are delivered to the required components of the Server via this component. In the same way all the update packages which should go to the clients are sent to them via this component.

2.3.1.3 Player

In our system, server has two player objects. Player component includes all data of a player including heroes, armies, troop, units, buildings of a player. Player’s heroes, armies, troops and buildings are kept and manipulated in this component.

2.3.1.4 GameLoader

      Game Loader is the component which loads a game and sends the loaded game’s data to the Game Manager. To continue a saved game, the user should click on the LoadGame button. Then the server is initiated, the connection is established between the server and the client, and the system gets the ‘game to load choice’, username and password of the user. Then it’s the part where GameLoader takes place. It loads the saved game and sends all the data to the GameManager. Then the game is ready for the both players to be connected and played. The details of the LoadGame scenario are described below as a sequence diagram.

 

 

Figure-8: Loading a Game

 2.3.2 Client Side

 

As Heroes has ‘thin-client’ server-client architecture, the client only deals with the graphical user interface part of the game. It does not process any data, set any properties of the objects in the game. Its main functions are to show the game-screen to the client, to establish the player-game interaction by sending the user-inputs to the server as command packages to control the game and to lead the client-side until it connects to the server side while joining a game.

 

To play a game every client connects to a server to join a newly created or a loaded game. To join to a loaded game every client has to enter a username and a password that they entered to the game during the new-game setup. This username-password system will ensure that the players, who started that game, will continue it. Below is the sequence diagram to join a loaded game.

 

 

 

 

Figure-9: Joining a game

2.3.2.1 ClientProxy:

            Client Proxy is the communication interface between a client and the server. It, sends player actions to the server as command packages and receives corresponding update-packages to be shown to the player in the game-screen. Client Proxy only deals with the ServerProxy in the server-side and vice versa.

2.3.2.2 ClientManager:

ClientManager is the component which deals with the UI change according to the updates that are sent to the client by the server. It creates, enables or disables the frames in the client side when the frame which should be active is changed by the server-side.  .

2.3.3 Putting Alltogether:

Having  discussed the system model, let’s see how the system behaves internally for specific actions of the main in-game use cases.

2.3.3.1 Moving a Hero:

Below is the diagram for a successfull grabbing gold action during a hero movement.

Figure-10: Moving a hero

 

2.3.3.2 Casting a Magic:

      Below is the diagram for a successfull magic casting of a hero during a combat.

Figure-11: Casting a magic

2.3.3.3 Recruiting Units:

      Below is the diagram for a successfull unit creating operation.

Figure-12: Recruiting a creature

 

2.3.3.4 Constructing a Building:

      Below is the diagram for a successfull building creating activity during castle development.

Figure-13: Creating a building

3.Conclusion:

            Heroes of Might and Magic is a sub-version of the famous “Heroes of Might and Magic 3” game which is a well-organized strategy game that has been developed by the professionals of 3DO Inc. Since the original game has a wide broad of facilities presented to the users, in our game most of these facilities are restricted, some of them are abandoned, the way these facilities are applied-by –such as the network, the graphics, and the load-save operations etc. - are simpler than the ones of the original game, expectably. On the other hand, there also some properties in our game which doesn’t exist in the original game, such as our civilian units –healers & monks.

For future versions of our game, we plan to expand some facilities which had been restricted in the first version:

● The number of heroes, races, resources, magic’s, unit-types, scenarios, maps etc. will be increased.

● 4 Player will be able to play the game

● A player will be able to have more than 1 castle

● A Map Editor will be able to be used to construct maps

● Graphic & Network Systems may be replaced with better application ways, new technologies etc.

4. References:

For further information: http://www.bestsitez.com/aoh/h3fere.html