Game

Karl, The Muscular Man

Page 1
Table of Contents
1 Project Plan of “Karl the Muscular Man”……………………………………………...……
1.1 Gaming in the field of Computer Science ……………………….………………………………….
1.2 Background of this project…………………………………………………….…………………………..
1.3 Scope of our game……………………………………………………………………..………………………
1.4 Project Scheduling ………………………………………………………………………….…………………
2 Software Requirement Specification of “Karl the Muscular Man”………………
2.1 Introduction …………………………………………..………………………………………………………….
i. Purpose of this chapter…………………..……………………………………................
ii. Document Conventions……………………….………………………………………….....
iii. Intended audience and reading suggestions.…………………………………......
iv. Scope of this document……………………………….……………………………………...
2.2 General Description…………………………………………………………..……………………………….
i. Product and Business perspective of the game…………………………………….
ii. System environment…………………………………………………….………………………
iii. Quality Function development of “Karl the Muscular Man”……………….…
iv. User story of our game……………………………………………………..………………….
2.3 Specific Requirement……………………………………………………………..............................
i. External interface Requirements of the game………………………..…………….
ii. User characteristics of the game……………………………………………….…….……
2.4 Analysis model of our game project…………………………………………………………….……..
2.5 Requirement Change Management of our system………………………………………………
3 Design & Implementation of “Karl the Muscular Man”………………………………
3.1 Product design terms…………………………………………………………………………………….……
3.2 Plot……………………………………………………………………………………………………………….……
3.3 System features of our game……………………………………………………………………….…….
3.4 Construction of our game………………………………………………………………………….……….
3.5 Key resource requirements of the project……………………………………………….………..
3.6 Implementation tools required……………………………………………………………….…………
3.7 Implementation code required……………………………………………………………….…………
4 Testing of “Karl the Muscular Man”………………………………………………..…………
4.1 Testing Case 1 Animation……………………………………………………….………………………...
4.2 Testing Case 2 Interaction between objects…………………………….………………………..
4.3 Testing Case 3 Dialogue box…………………………………………………….………………………..
5 User Manual of “Karl the Muscular Man”……………………..…….……………………
5.1 Playing Procedure……………………………………………………………………….…………………….
5.2 Some Snapshots………………………………………………………………………….…………………….
6 Conclusion…………………………………………………………………...……….…………………
6.1 The Obstacles……………………………………………………………………..………….………………..
6.2 The Achievements…………………………………………………………………………….……………..
6.3 Future Plan………………………………………………………………………..……………….…………...

Page 2
 6.4 Last few words………………………………………………………………….……………………………
7 Appendix………………………………………………………………………………………………..
7.1 References……………………………………………………………………………………………………..
7.2 Abbreviation & Acronyms……………………………………………………………………………….

Page 3
Chapter -1: The Project Plan of “Karl the
Muscular Man”

Page 4
This chapter covers the project proposal and feasibility of the proposal along with
background study, product and business perspective, the scope and some preliminary idea
of our game.

1.1 Gaming in the Field of Computer Science

In the fast growing field of computer science and development and even more rapidly
growing sector of game development of the future is hard to predict. The computer
science and game development combined major focuses on the specific skills needed to
succeed in the highly competitive game industry. As a part of our degree we choose this
type of work for doing better with development cycle, development period, graphics,
scripting and animation.
In a game project, the product is a game but here come the point: a game is much more
than just its software. It has to provide content to become enjoyable. Just like a web
server: without content the server is useless, and the quality is not measured. This has
an important effect on the game project as a whole. The software part of the project is
not the only one, and it must be considered in connection to all the other parts: the
environment of the game, the story, character, game plays, the artwork, and so on.

1.2 Background of this project

Background is the set of events invented for a plot, presented as preceding and leading
up to that plot. In our project it’s a single player game that run on a procedurally
generated path. Tactical organization and execution are necessary, and the game
creator usually places the decision making skills and delivery of commands in the
player’s hand.

Page 5
1.3 About the Project

About 1.2 billion people are playing games worldwide. It’s a complete strategy game
with different levels. Karl is the main player of the game. He is a muscular man. He lives
in a small village with his pet Boo near a jungle. He was a criminal but his life change
after marriage. His enemies kidnapped his wife Kathe. His mission is to look for
kidnappers and safe his wife. There are several levels and in each level Karl face the
hurdles and fight with knights (guardians of the castle) to complete his mission.
Most of the previous developed games are endless running games and fighting games.
Our idea is to mesh the 3 popular games that are (Temple Run, GTA Vise City and MYST).
In our game the player has a mission to complete.it will be an interesting game and keep
the player engaged. We would like to implement AI in the game because it would be
nice for the player to be able to play the game by himself.

1.4 Scope of Our Game

This report describes all the requirements for the project. The purpose of this research is
to provide a virtual image for the combination of both structured and unstructured
information of our project “Karl the Muscular Man”. “Karl the Muscular Man” is a single
player strategy game on the computer platform. The player will progress through levels
which require precise manipulation of the environment, through the game encourages
creativity and daring via branching pathways. The episodic structure of the game
facilitates the pace of the story. We demonstrate the action flow between inputs, script,
display (output). We are working mainly with story, level, objects, animation, graphics,
script, game engine facilities. We are not working Web Launching, free hand
programming, cartoon making.

Page 6
1.5 Project Scheduling

Project states and

Start Date Last Date
Objective
Project Proposal, meeting
April 15 April 25 with supervisor about our
idea
Planning, thinking about
April 26 May 15 game story, levels &
learning technology
Start SRS(Software
Requirement Specification)
May 16 June 07
Document, choose tools &
environment
Start designing &
June 08 June 20
Implementation
Developing, testing &
June 21 July 08 enhancement running with
writing the document
Final revision of the project
July 09 July 28 & testing on the
construction levels
September 29 Project submission

We have found the planning of this project here which now leads us to the specifications
part of the project.

Page 7
Chapter -2: Software Requirements
Specifications of “Karl the Muscular
Man”

Page 8
This chapter covers the requirements specification of our game” Karl the Muscular Man”, it
includes the specification of this documentation with general description, specific
requirements and analysis of models. It also includes changes management of this
requirement specification in case of any changes.

2.1 Introduction

In this section the documentation of this report is specified. It specified the document
convention, document scope and also provides a suggestion for the readers of the
document.

2.1.1 Purpose of this chapter

This Software Requirement Specification (SRS) part is intended to give a complete overview
of our Project the game” Karl the Muscular Man” including the action flow initial user
interface and story. The SRS document details all features upon which we have currently
decided with reference to the manner and importance of their implementation.

2.1.2 Document Conventions

This document will freely interchange the pronoun “we” with the team’s acronym. As the
Development team is responsible for the SRS document, no ambiguity arises from its usage.
There is a clear distinction, however, between the use of the words “player/gamer” and
“Character.” The “player” is the human being interacting with the game in the real world,
while the “character” is the in-game player avatar being manipulated.

Page 9
2.1.3 Intended Audience and Reading Suggestion

The SRS document also gives project managers a way to ensure the game’s adherence to
our original vision. Although the document may be read from front to back for a complete
understanding of the project, it was written in sections and hence can be read as such. For
an overview of the document and the project itself, see Overall Description. For a detailed
description of the game-play elements and their interaction with the character, read System
Features. Readers interested in the game-play interface and navigation between different
front-end menus should go through External Interface Requirements. Technical standards to
which the team will hold the project are laid out in Other Non-functional Requirements. The
development schedule, meanwhile, will be maintained in the Key Milestones.

2.1.4 Scope of this document

The Software Requirement Specifications (SRS) describes the functional and non-functional
requirement of the project. As we said before the purpose of this research is to provide a
virtual image for the combination of both structured and unstructured information of our
project “Karl the Muscular Man”. Project “Karl the Muscular Man” was conceived by the 3
of our team members as having an anticipated development cycle greater than the length of
the semester. The team wishes to carry on the project until its completion. The game will
continue to grow until we feel it satisfactory for open-source distribution.

2.2 General Description

This section includes the perspective of our product and the system environment it requires.
It specifies the QFD (Quality Function Deployment) of our game and also the User Story of it.

2.2.1 Product and business Perspective of the Game

Software product development is a paradigm shift from routine application maintenance

and support in the software industry. Development a game/software product from scratch
is a significant challenge for any organization. It requires considerable investments in terms
of effort and cost and also confirms client involvement, knowledge about client market

Page
10
(example: Google play). We have compiled some interesting articles from the web for you
which should form the basis for a concluding public discussion about the future of the game
industry. Please feel free to interrupt us any time and contribute your ideas. This will make
our game much more lively and interesting. Here this report product perspective describes
the overall description.

2.2.2 System Environment

Gamer
Input Manager

Keypad/game pad)

Script

(Compile)

Renders

(Display)

Gamer can interact with system by giving input (press key to start game) to the system.
System give those inputs to script, if any change occur (if the value is changed) this object
send to renders to display the things (a character can change its place).

Page
11
2.2.3 Quality Function Deployment of “Karl the Muscular Man”

Quality Function Deployment is a technique that translates the needs of the customer into
technical requirements for software/game. It concentrates on maximizing customer
satisfaction from the Software engineering process .With respect to our project the
following requirements are identified by a QFD.

 Normal Requirements
 Expected Requirements
 Exciting Requirements

Normal Requirements

Normal requirements consist of objectives and goals that are stated during the meeting with
the actor/gamer/relevant people. Normal requirements of our project are:-

1. User friendly efficient and lucrative system.

2. Minimum maintenance cost (may be graphics definition).
3. Availability of expected requirements within the PC configuration.
4. Easy to operate.
5. They observe our game as this is build with professional manner.
6. The game with measured coding, professional thinking.

Expected Requirements

These requirements are implicit to the system and may be so fundamental that the
actor/gamer/ relevant people does not explicitly state them .Their absence will be a cause
for dissatisfaction.

1. Develop system within limited cost.

2. Maximum high definition.
3. Minimum hardware requirements which is relevant for this game.
4. Design whole system with efficient manner.

Page
12
Exciting Requirements

These requirements are for features that go beyond the customer's expectations and prove
to be very satisfying when present:
1. We may provide some cheat codes.
2. Maximum high regulation with minimum hardware.
3. We may provide an international player rank list.
4. Easy to update.

2.2.4 User Story of Our Game

“Karl the Muscular Man” is a strategy game. It is a multi-platform game which is supported
by PC. So the gamer can use any of these platforms to run the game. After running the
game, the UX view of the game will appear on the screen. The term UX means User
Experience which is used to explain all aspects of a person’s experience with a system.

However, then the gamer can directly select “Start” from the “Main Menu” and start
playing the game or may go to “Level Selection Menu” and select his/ her desired level.
Gamer can also turn sound on/ off or change graphical settings. Gamer can also check
controls of the game by going to “Control Menu” and see the “About Menu”. A “Story” is
also provided with the game to understand the game objective. However, after starting a
level the player will find helpful tips on the side of the screen and he/ she can follow it and
enjoy the game. He/she may also interact with “Pause Menu” by pressing “Escape”. If
he/she loses he/she can replay the level by pressing “Restart” or exit game by pressing
“Quit” in the “Game Over Menu”. After finishing the game also, he will get option to “Play
Next Level” or simply “Quit”.

The story behind the game is about a man who’s name is Karl. He lived in a small village
near a jungle with his wife Kathe and pet boo. He was a criminal but his life change after
marriage. His enemies kidnapped his wife Kathe. His mission is to look for kidnappers and
safe his wife. As mentioned earlier the gamer will find tips in different steps which will help
him to go to the finishing stage. Player face many hurdle’s in every level of game. There will
be gems/food/coins here and there which will raise the score point of the gamer if
collected. Basically, this game is meshed by 3 popular games GTA vice city, Temple run and
myst. Our game is endless game and game is finished if player exit or hit with hurdle.

Page
13
2.3 Specific Requirements
This section covers the project external requirements of our game and also indicates the
user characteristics for this project.

2.3.1 External Interface Requirements of the Game

2.3.1.1 User Interface

Every game must has a menu so is can be user friendly enough and gamers can easily fulfil
their need. Menu is also an important thing while creating the SRS document section. In this
SRS document part; we have used the menu snapshots in the user manual part. These
snapshots are based on the menu of the game.

2.3.1.2 Hardware Interface

“Karl the Muscular Man” is a desktop gaming application designed specifically for the
desktop version and is functional on both computer and laptop. Gaming application data is
stored locally on the game engine elements. “Karl the Muscular Man” has been developed
for computer developed version and all subsequent releases. In future we release in the
android platform.

2.3.1.3 Software Interface

“Karl the Muscular Man” has been developed using a series of game development tools.

Working tools and languages:

Tools:

 Unity 3d
 Photoshop
 Illustrator
 Blunder

Languages:

 C#
 JavaScript

Page
14
2.3.2 User Characteristics for the System

There is only one user at a time in this software and the user interacts with the game
(system) in different manner. So, Gamer is the only one who communicates with the system
through playing the game. And this gamer can be any person. The primary requirement is
that, the gamer must read the playing procedure provided by us (developers).

2.4 Analysis Model of Our Game Project

This section describes the Software Requirements Specification of our project by analyzing
the proper models of requirement engineering.

2.4.1 Scenario Based Model

This Model depicts how the user interacts with the system and the specific sequence of
activities that occur as the software is used.

2.4.1.1 Use Case Scenario

The following table summarizes the use cases of the system. We have created the use cases
based on the UX view (mentioned in “User Story Part”) of the game. The swimlane diagram
connects UX with background programming which are the two important views of a game
SRS (Details of these two terms are in section 3.1).

Page
15
 Level-0 Level-1 Level-2

New Game

Play Resume Game

Select Level
Exit Game
Show Control
Change
Game(Karl the Muscular Options Configuration(Graphic)
Man) Change Sound/Music
Volume
View Score
Score Board
Reset Score Board
Story View Story

Quit

Page
16
 2.4.1.2 Use Case Diagram with Use Case Description

Game (Karl the

System
Muscular Man)

Player

Fig 1: Level 0 for Game

Play

Options

Score Board

Story
Player

Quit

Action Object

Fig 2: Level 1 for Game UX

Page
17
 New Game

Resume Game

Select Level

Exit Game

Player
Action Game

Fig 3: Level 2.1 (Play) for Game UX

Page
18
This Diagram of Level 2.1(Fig 3) leads us to the “Play” module of the use cases. These use
case descriptions are given here –

Play

i.

Use case: New Game

Primary Actors: Any one playing the game

Goal in context: To start a new game

Precondition:

1. System supports the game configuration

2. The file has been triggered to run and the game screen has appeared

Triggers: The player needs to start a new game

Scenario:

1. Go to the main menu of the game

2. Click new game button

3. New game is loaded on system

Exception: Game crushed

Priority: Essential, must be implemented

When Available: First increment

Page
19
ii.

Use case: Resume Game

Primary Actors: Any one playing the game

Goal in context: To resume game from previous play

Precondition:

1. Game was played before

2. Game supports to have a checkpoint to start from

Triggers: Need to resume game

Scenario:

1. Go to the main menu of the game

2. Click the resume game button

3. Game is loaded from the last checkpoint

Exception:

1. Level cannot be loaded

2. Game crushed

Priority: Essential, must be implemented

When Available: First increment

Page
20
iii.

Use case: Select Level

Primary Actors: Any one playing the game

Goal in context: To load the game from a required level

Precondition:

1. Required level has been unlocked

2. Game supports loading levels

Triggers: Need to load a level

Scenario:

1. Go to the main menu

2. Click the select level button

3. Select a level

4. The level is loaded for play

Exception: Level cannot be loaded

Priority: Essential, must be implemented

When Available: First increment

Page
21
iv.

Use case: Select Level

Primary Actors: Any one playing the game

Goal in context: To load the game from a required level

Precondition:

3. Required level has been unlocked

4. Game supports loading levels

Triggers: Need to load a level

Scenario:

5. Go to the main menu

6. Click the select level button

7. Select a level

8. The level is loaded for play

Exception: Level cannot be loaded

Priority: Essential, must be implemented

When Available: First increment

Page
22
v.

Use case: Exit Game

Primary Actors: Any one playing the game

Goal in context: To exit from the game level

Precondition: A game level is being played

Triggers: Player needs to exit from the game level

Scenario:

1. Press game pause

2. When Pause Menu appears, click Return to Menu button

3. Game is exited and Title screen appears

Priority: Essential, must be implemented

When Available: First increment

Page
23
 Show
Controls

Change
Graphics

Change Sound
/Music Volume
Player

Action Object

Fig 4: Level 2.2(Options) for Game UX

Page
24
This Diagram of Level 2.2(Fig 4) connects with the “Option” module of the use cases. These
use case descriptions are given here –

Options

i.

Use case: Show Controls

Primary Actors: Any one playing the game

Goal in context: To know the controls of playing the game

Precondition: Game provides control information

Triggers: Player needs to know the controls to play the game

Scenario:

1. Go to the main menu

2. Click the Options button

3. When Option menu appears click the show control button

4. Game controls are being showed

Exception: No control information

Priority: Essential, must be implemented

When Available: First increment

Page
25
ii.

Use case: Change Graphics Configuration

Primary Actors: Any one playing the game

Goal in context: To change the graphics configuration of the game

Precondition:

1. Player is allowed to change configuration

Triggers: Player has a need to configure graphics

Scenario:

1. Go to the main menu

2. Click on Options button

3. Click on Graphics slider and set the required value

4. Game is updated

Exception: System doesn’t support given graphics configuration

Priority: Expected

When Available: Second increment

Page
26
iii.

Use case: Change Sound/ Music Volume

Primary Actors: Any one playing the game

Goal in context: To change the sound or music volume

Precondition: Player is allowed to change volume of game

Triggers: Player has a need to change volume of the game

Scenario:

1. Go to the main menu

2. Click on Options button

3. Click on Music/ Sound Slider and change the value

4. Music or Sound Volume is changed

Exception: System is in mute mode, cannot increase volume

Priority: Expected

When Available: Second increment

Page
27
 View

Reset

Player
Action Objects

Fig 5: Level 2.3 (Score Board) for Game

This Diagram of Level 2.3(Fig 5) connects with the “Score Board” module of the use cases.
These use case descriptions are given here –

Score Board

i.

Use case: View Scores

Primary Actors: Anyone playing the game

Goal in context: To see the score board

Precondition:

1. Game has been programmed to save scores in database

2. Game has a prepared rank list for the players

Trigger: Player needs to see the game scores

Page
28
Scenario:

1. Go to the main menu

2. Click Score Board

3. Select a level

4. Scores of the level is shown in ranking order

Exception:

1. No Scores (Game is not played once yet)

2. Score Board has been reset

Priority: Expected

When Available: Second increment

Page
29
ii.

Use case: Reset Score Board

Primary Actors: Any one playing the game

Goal in context: To reset the score board

Precondition:

1. Game has a score board

2. Players are allowed to reset the score board

Trigger: Player wants to reset the scores of the game

Scenario:

1. Go to the main menu

2. Click on Score Board button

3. Click reset Score board

4. Score board is reset

Exception:

1. No Scores in Score board

Priority: Expected

When Available: Second increment

Page
30
We can see a module for “Story” in Figure 2 which is the Level 1 of Use Case Diagram. The
Use Case for it is given below:

Story

i.

Use case: View Story

Primary Actors: Any one playing the game

Goal in context: To watch the game story

Precondition:

1. Game has a back ground story

2. Story is prepared for the gamers

Trigger: Player wants to see the game story

Scenario:

1. Go to the game menu

2. Click Story button

3. Story of the game is played

Priority: Expected

When Available: Second increment

Page
31
There is another module for “Quit” in Figure 2 which is the Level 1 of Use Case Diagram. The
Use Case for it is given here:

01. Quit

Use case: Quit

Primary Actors: Any one playing the game

Goal in context: To Exit from the Game Process

Precondition: Player has entered in the game process

Triggers: Player needs to exit from the game

Scenario:

1. Go to the main menu

2. Click Quit button

3. Game is exited

Exception: Something went wrong. Cannot exit now.

Priority: Essential, must be implemented

When Available: First increment

Page
32
2.4.1.3 Activity Diagram

Fig 6: Activity Diagram for “New Game” module of “Play” (Fig 3)

Fig 7: Activity Diagram for Resume Game” module of “Play” (Fig 3)

Page
33