Zahid Ali

THE SUPERIOR UNIVERSITY, LAHORE
ASSOCIATE DEGREE PROGRAMS
Final Year Project

PROJECT REPORT
Interactive Traffic Signs
Project ID: FYP-ADP-F21-017
Project Team
Student Name Student ID Program Contact Number Email Address
Muhammad Zahid Ali ADCS-F21-088 ADP-CS 03019345599 zahidalisiddique1@gmail.com
Rao Ahtasham ADCS-F21-081 ADP-CS 03065778859 raoa38456@gmail.com
[Project Supervisor]
Sir Touseef.
(Lecturer)
Project Report: Interactive Traffic Signs
Project Report
Interactive Traffic Signs
Change Record
Author(s) Version Date Notes Supervisor’s Signature
Muhammad Zahid 1.0 17/5/2023 This project is a 3D

Ali Interactive car game
used to teach players
about various traffic
signs.
Sir Touseef 1.1 04/6/2023 Advised to create a
Gear System in order
to better miimic a
real-life driving
experience.
Sir Rauf 1.2 19/6/2023 Advised to use a
different car controller
for better car
movement and
control.
Rao Ahtasham 1.3 07/7/2023 Advised to separate
levels by signs rather
than difficulty level.
Muhammad Zahid 1.4 21/7/2023 Final draft where
Ali every system is
working as intended.
Faculty of CS&IT, Superior University Lahore, Pakistan ii

APPROVAL
PROJECT SUPERVISOR
Comments:
Name:
Date: Signature:
PROJECT MANAGER
Comments:
Date: Signature:
HEAD OF THE DEPARTMENT

Comments:
Date: Signature:
Faculty of CS&IT, Superior University Lahore, Pakistan iii

Dedication
This final project report is devotedly dedicated to Allah Almighty, The Holy
Prophet Muhammad (S.A.W.W), our respective Parents and Teachers who
have been our constant source of inspiration. They have given us the drive and
discipline to tackle any task with enthusiasm and determination. Without their
love and support this project would not have been made possible.
Faculty of CS&IT, Superior University Lahore, Pakistan iv

Acknowledgements
It is incumbent upon us to express our fervent gratitude to almighty ALLAH the most
compassionate and merciful for giving us the courage to achieve this task in the field of
Game Development.
We are indeed respectfully grateful to the Holy Prophet Muhammad (S.A.W.W) who is
forever a source of guidance and idea for all mankind.
We would like to express our immense gratitude to our instructor Sir Abdul Wahab for his
regular support and motivation that has encouraged us to come up with this project as well
as our project supervisor Sir Saqib Ali Ahmad.
We are also thankful to our teachers and friends who have provide their whole-hearted
support at all times for the successful completion of our project “Interactive Traffic Lights.
May GOD almighty Allah infuse us, with the energy to fulfill their gracious objectives and
expectations and to further enlighten our competence!
Faculty of CS&IT, Superior University Lahore, Pakistan v

Executive Summary
Video Games not only provide fun and entertainment but they can also be used to spread
knowledge. The following project aims to teach the general public about the importance of
traffic signs and educate them on the various signs, their use cases, and the consequences
of not following them through the help of an interactive and fun-to-play video game.
Faculty of CS&IT, Superior University Lahore, Pakistan vi

Table of Contents
Dedication..................................................................................................................................... iv
Acknowledgements........................................................................................................................ v
Executive Summary.......................................................................................................................vi
Table of Contents.........................................................................................................................vii
List of Figures................................................................................................................................. x
List of Tables.................................................................................................................................. xi
Chapter 1....................................................................................................................................... 1
Introduction................................................................................................................................... 2
1.1. Background......................................................................................................................2
1.2. Motivations and Challenges............................................................................................ 2
1.3. Goals and Objectives....................................................................................................... 2
1.4. Literature Review/Existing Solutions...............................................................................2
1.5. Proposed Solution........................................................................................................... 3
1.6. Gap Analysis.................................................................................................................... 3
1.7. Project Plan..................................................................................................................... 4
1.7.1. Work Breakdown Structure.........................................................................................4
1.7.2. Roles & Responsibility Matrix......................................................................................5
1.7.3. Gantt Chart.................................................................................................................. 6
1.8. Report Outline.................................................................................................................7
Chapter 2....................................................................................................................................... 8
Software Requirement Specifications............................................................................................9
2.1. Introduction.....................................................................................................................9
2.1.1. Purpose........................................................................................................................ 9
2.1.2. Document Conventions................................................................................................9
2.1.3. Intended Audience and Reading Suggestions..............................................................9
2.1.4. Product Scope............................................................................................................ 10
2.1.5. References................................................................................................................. 10
2.2. Overall Description........................................................................................................ 10
2.2.1. Product Perspective................................................................................................... 10
2.2.2. Product Functions...................................................................................................... 10
2.2.3. User Classes and Characteristics................................................................................10
2.2.4. Operating Environment..............................................................................................10
2.2.5. Design and Implementation Constraints....................................................................11
2.2.6. Assumptions and Dependencies................................................................................11
2.3. External Interface Requirements...................................................................................11
2.3.1. User Interfaces...........................................................................................................11
2.3.2. Hardware Interfaces.................................................................................................. 12
2.3.3. Software Interfaces....................................................................................................12
2.3.4. Communications Interfaces.......................................................................................13
2.4. System Features............................................................................................................ 13
2.4.1. Opening the initial UI.................................................................................................... 13
2.4.1.1. Description and Priority..........................................................................................13
2.4.1.2. Stimulus/Response Sequences...............................................................................13
2.4.1.3. Functional Requirements....................................................................................... 13
2.4.2. Driving........................................................................................................................13
Faculty of CS&IT, Superior University Lahore, Pakistan vii

2.4.2.1. Description and Priority........................................................................................133

2.4.2.2. Stimulus/Response Sequences...............................................................................14
2.4.2.3. Functional Requirements.......................................................................................14
2.4.3. Consequense System.................................................................................................14
2.5. Other Nonfunctional Requirements..............................................................................14
2.5.1. Performance Requirements.......................................................................................14
2.5.2. Safety Requirements..................................................................................................14
2.5.3. Security Requirements...............................................................................................15
2.5.4. Buisness Rules............................................................................................................15
2.6. Other Requirements...................................................................................................... 15
2.6.1. Cloud Ready............................................................................................................... 15
2.6.2. Loosely Typed............................................................................................................ 15
2.6.3. Open Source...............................................................................................................15
2.6.4. Platform Independent................................................................................................16
Chapter 3..................................................................................................................................... 17
Use Case Analysis......................................................................................................................... 18
3.1. Use Case Model.............................................................................................................18
3.2. Use Case Descriptions....................................................................................................19
Chapter 4..................................................................................................................................... 25
System Design.............................................................................................................................. 26
4.1. Architecture Diagram.................................................................................................... 27
4.2. Domain Model...............................................................................................................28
4.3. Class Diagram................................................................................................................ 29
4.4. Sequence / Collaboration Diagram................................................................................30
4.5. Component Diagram..................................................................................................... 31
4.6. Activity Diagram............................................................................................................ 32
4.7. State Transition Diagram...............................................................................................33
4.8. Deployment Diagram.....................................................................................................34
Chapter 5..................................................................................................................................... 35
Implementation............................................................................................................................36
5.1. Components, Libraries, Web Services and stubs...........................................................36
5.2. Deployment Environment..............................................................................................36
5.3. Tools and Techniques.................................................................................................... 36
5.4. Best Practices / Coding Standards.................................................................................37
5.5. Version Control..............................................................................................................38
Chapter 6..................................................................................................................................... 39
Testing and Evaluation................................................................................................................. 39
6.1. Use Case Testing............................................................................................................40
6.2. Data flow testing............................................................................................................40
6.3. Equivalence partitioning................................................................................................40
6.4. Boundary value analysis................................................................................................ 40
6.5. Unit testing.................................................................................................................... 41
6.6. Integration testing.........................................................................................................41
6.7. Performance testing......................................................................................................41
6.8. Stress Testing.................................................................................................................41
Chapter 7..................................................................................................................................... 42
Summary, Conclusion and Future Enhancements........................................................................43
Faculty of CS&IT, Superior University Lahore, Pakistan viii

7.1. Project Summary........................................................................................................... 43

7.2. Achievements and Improvements.................................................................................43
7.3. Critical Review............................................................................................................... 43
7.4. Lessons Learnt............................................................................................................... 43
7.5. Future Enhancements/Recommendations.....................................................................43
Reference and Bibliography......................................................................................................... 45
Index............................................................................................................................................ 47
Faculty of CS&IT, Superior University Lahore, Pakistan ix

List of Figures
1.1 Gantt Chart 5

2.2 Use Case Model 17
4.1 Architecture Diagram 26
4.2 Domain Model 27
4.3 Entity Relationship Diagram 28
4.3 Entity Relationship Diagram 28
4.4 Class Diagram 29
4.5 Sequence / Collaboration Diagram 30
4.6 Component Diagram 31
4.7 Activity Diagram 32
4.8 State Transition Diagram 33
4.9 Deployment Diagram 34
Faculty of CS&IT, Superior University Lahore, Pakistan x

List of Tables
1.1 Roles & Responsibility Matrix 3

3.1 Use Case Table 1 18
Faculty of CS&IT, Superior University Lahore, Pakistan xi

Chapter 1
Introduction
Chapter 1: Introduction
The Project “Interactive Traffic Signs” is an interactive 3D game that seeks to teach about
various traffic signs through a fun little game. The game consists of levels and in each level,
the Player has to drive a car to reach his destination. On the way, there are many traffic
signs. The Player is told about what each of the signs mean and that he/she must change
his/her mode of driving accordingly.
1.1. Background
While most Traffic signs are made simple using basic shapes so that the person can easily
interpret the meaning the behind the sign. Sometimes important information is lost in this
simplicity and one cannot tell its meaning with a simple glance. Other times people are
unaware of the dangers despite knowing what the sign is warning them about. Such cases
lead to reckless driving and accidents in worse case scenarios.
1.2. Motivations and Challenges

Our motivation for choosing this particular idea as our project was to educate people on the
uses of Traffic Signs, what the various different signs mean and why they are important for
safe driving by highlighting the consequences of not following them in a family-friendly
manner. The only challenge we are facing is the lack of expertise in Game Development but
with the help of our Instructor we are making good progress.
1.3. Goals and Objectives

A huge number of people, especially the younger generation, are unaware of the many
types of traffic signs. Signs such as the “Give Way Sign” and the “No Overtaking Sign” are
often easy to misinterpret. Unfortunately, anyone rarely makes the effort to actually learn
all the signs and their meaning. Our goal is to make learning traffic signs fun and much
easier than simply looking at them once and hoping one will remember them.
1.4. Literature Review/Existing Solutions

Currently, no system aims to provide a solution like ours. The existing systems that seek to
teach people about various traffic signs are only guidebooks and MCQs-based games. There
is no system that actively lets you experience the use of traffic signs while you would be
driving a car similar to how you would experience them in real life. The MCQs-based games
Faculty of CS&IT, Superior University Lahore, Pakistan 2

contain some game-like elements like UI and a “Health System” but other than that it has no
resemblance to our product much less a real game.
1.5. Proposed Solution

Our solution is to teach people the meaning as well as the importance of these signs
through the use of an interactive 3D game. The game will be comprised of multiple levels
with each level made up of different tracks. The tracks would be similar to roads that a
person may encounter in the real world and along the sides of the tracks would be various
traffic signs. Each time the driver/player encounters a new sign he/she would be told its
meaning and importance. The next time the player encounters that sign he must act
accordingly. Keeping check of the signs the player must reach his/her destination.
1.6. Gap Analysis

Gap Analysis for the Interactive Traffic Signs Game Project:
1. Current State Assessment:
Current traffic sign education lacks interactive and engaging methods for learners to
understand and effectively apply knowledge. Traditional methods such as textbooks
and still images may not fully capture the dynamic nature of real-world driving
scenarios.
2. Learning Experience Gap:
Current learning experiences fail to provide an engaging and practical environment
for learners to develop a comprehensive understanding of traffic signs. Lack of
opportunity to apply theoretical knowledge in real driving situations. The lack of
interactive feedback systems and real-time assessment hinders the ability to assess
learner progress and identify areas for improvement.
3. Technological Gap:
Current educational resources and tools cannot fully utilize the potential of
technology to enhance the learning experience. The lack of interactive, immersive
and visually appealing platforms limits learner engagement and motivation.
4. Integration Gap:
There is a gap between existing traffic information and its integration into simulated
driving. Students often find it difficult to bridge the gap between theoretical

knowledge and practical applications. This difference is heightened by the lack of

games that integrate traffic awareness, interpretation, and appropriate responses.
5. Comprehensive Content Gap:
Existing solutions may not include all traffic signs, including less obvious or region-
specific signs.
1.7. Project Plan

The Project is to be completed as we are learning about Game Development in our class so
the project must be planned accordingly.
1.7.1. Work Breakdown Structure

1. Scripting
1.1. Coding.
1.2. Testing.
1.3. Simulation.
2. Assets
2.1. Asset Collection
2.2. Sign Design
2.3. Road Design
3. 3D Models
3.1. Levels
3.2. Designing
3.3. Quality Check

1.7.2. Roles & Responsibility Matrix

WBS WBS Deliverable Activity # Activity to Duration Responsible Team
Complete the (# of Days) Member(s) & Role(s)
#
Deliverable
1 Coding. 7 14 Muhammad Zahid Ali
2 Testing. 8 50 Rao Ahtasham
3 Simulation. 9 21 Rao Ahtasham
4 Asset Collection 3 5 Muhammad Zahid Ali
5 Sign Design 4 7 Muhammad Zahid Ali
6 Road Design 5 21 Rao Ahtasham
7 Levels 1 10 Muhammad Zahid Ali
8 Designing 2 20 Muhammad Zahid Ali
9 Quality Check 6,10 2 Muhammad Zahid Ali

1.7.3. Gantt Chart

1.8. Report Outline

This report consists of the following main points:
 Introduction.
 Software Requirement Specifications.
 Use Case Analysis.
 Implementation
 Testing Evaluation.
 Conclusion.
 References.

Chapter 2
Software Requirement
Specifications

Chapter 2: Software Requirement Specifications
2.1. Introduction
Our projects revolves around creating dynamic and immersive games that combine fun with
valuable learning opportunities. Using the power of interactive gameplay and realistic
driving scenarios, we aim to impart important knowledge about traffic signs and promote
safer driving habits among players.
2.1.1. Purpose
The main goal of this project is to develop a game that effectively teaches players about
traffic signs, their meaning and the appropriate reaction when encountered on the road. By
providing an engaging and interactive learning environment, we aim to deepen players'
understanding of traffic sign laws and encourage responsible driving behavior.
2.1.2. Document Conventions

In this document we used Calibri(body) style with 12 fount size for paragraph and 14 for
heading text alignment justified and line spacing is 1.5 and we used different kinds of shapes
for diagrams.
2.1.3. Intended Audience and Reading Suggestions

This SRS is Intended for product developers and the university committee. The university
committee, representing the academic institution, will review the SRS to assess whether the
project meets educational goals, adheres to university guidelines, and evaluates potential
educational impact. They evaluate the scope, purpose, and specifications outlined in the SRS
to ensure that the project meets academic standards and aligns with the university's
mission.
2.1.4. Product Scope

The scope of the project encompasses the design, development, and implementation of a
fully functional game that simulates driving scenarios and incorporates a comprehensive

collection of traffic signs. The game will offer intuitive controls, engaging gameplay
mechanics, accurate sign representation, and interactive feedback to ensure an immersive
and effective learning experience.
2.2. Overall Description

2.2.1. Product Perspective
This product does not exist in the market and is a completely new concept. The only product
that seeks to educate on traffic signs are applications that ask MCQs based questions
related to the topic.
2.2.2. Product Functions

Some of the functions that the project must provide are:
 The game will provide not only education but also entertainment.
 When the user first opens the game application he will be greeted with a UI and the
user will start the game by clicking on the button.
 The game will provide various levels with various challenges.
2.2.3. User Classes and Characteristics

The main user class this project is aimed at is young children and teenagers. First of all,
young children are at their first learning age and anything taught to them at that age will
remain with them for their life. Also, the simple yet colorful environment of the gamewill be
much easier for them. Secondly, there are teenagers whom for the most part consider it a
bit tedious to to go through all the traffic signs and their meanings. Our game will teach this
aspect in a much entertaining way. The user class that we are least aiming towards is
“Middle-Aged Adults”, since most people at the age are not fond of video games. But our
project still provides them with a good alternative.
2.2.4. Operating Environment

The minimum requirements for a good operating environment for the game are as follows:
 1.3 GHz Processor

 512MB RAM
 Internet Connection
 Smart phones with minimum 4.0.0 version of android Operating system.
2.2.5. Design and Implementation Constraints

There is not a very huge library of free Low-Poly 3D Models, so some of the models must be
developed ourselves. Developing a 3D game can take a toll on low end PC so it is necessary
to be careful especially on the testing phase since some bugs may cause the game to crash.
2.2.6. Assumptions and Dependencies

 The user will not be able to play the game on an operating system other than/higher
than Android 4.0.
 Also, if the user has another program running in the background than he/she may
not be able run the game in an ideal condition.
 If the user is a developer and he/she has altered the graphic settings of the system,
then the game may appear unusual.
2.3. External Interface Requirements

2.3.1. User Interfaces
This project will have a total three main Graphical User Interfaces(GUI):
1. When the user opens the game application he will be greeted with the first UI
which will give him the options to either start the game, change the settings or exit
the game.
2. Upon selecting the “Start” option he will go to the next screen where he will be
given the option to continue progress from the next level or replay a completed
level.
3. While playing the level he can pause the game to exit the level, restart the level or
change the volume options.

2.3.2. Hardware Interfaces

Since the game’s platform is android, it will be played using the Touch Screen of the
smartphone. Android supports a variety of touch screens and touch pads, including stylus-
based digitizer tablets. Touch screens are touch devices that are associated with a display
such that the user has the impression of directly manipulating items on screen.
2.3.3. Software Interfaces

Unity already implements several established gamedev patterns, saving you the trouble of
writing them yourself. These include:
 Game loop: At the core of all games is an infinite loop that must function
independently of clock speed, since the hardware that powers a game application
can vary greatly. To account for computers of different speeds, game developers
often need to use a fixed timestep (with a set frames-per-second) and a variable
timestep where the engine measures how much time has passed since the previous
frame.
 Update: In your game application, you’ll often update each object’s behavior one
frame at a time. While you can manually recreate this in Unity, the MonoBehaviour
class does this automatically. Use the appropriate Update, LateUpdate, or
FixedUpdate methods to modify your GameObjects and components to one tick of
the game clock.
 Prototype: Often you need to copy objects without affecting the original. This
creational pattern solves the problem of duplicating and cloning an object to make
other objects similar to itself. This way you avoid defining a separate class to spawn
every type of object in your game.
 Component: Most people working in Unity know this pattern. Instead of creating
large classes with multiple responsibilities, build smaller components that each do
one thing.

2.3.4. Communications Interfaces

The Google Mobile Ads Unity plugin enables Unity developers to easily serve Google Mobile
Ads on Android and iOS apps without having to write Java or Objective-C code. The plugin
provides a C# interface for requesting ads that is used by C# scripts in your Unity project.
This will make our game profitable and allow us to earn revenue. The project will need an
internet connection which is used by Unity through the TCP/IP protocol. The Internet
protocol suite, commonly known as TCP/IP, is a framework for organizing the set of
communication protocols used in the Internet and similar computer networks according to
functional criteria.
2.4. System Features

2.4.1. Opening the initial UI
When the user opens the game application, he must be greeted with the initial UI which will
give him access to all the options he/she can perform in the game.
2.4.1.1. Description and Priority
This feature is of the highest priority as without a UI to interact with the user cannot
navigate about the game application.
2.4.1.2. Stimulus/Response Sequences
This feature must simply be activated with the opening and each single time the game
application is opened.
2.4.1.3. Functional Requirements
The functional requirements of the above-mentioned feature are given below:
REQ-SF1-1: The game must be opened.
REQ-SF1-2: There is enough memory available.
REQ-SF1-3: The basic system requirements are met.
2.4.2. Driving
The player needs to be able to contol the vehicle he/she is driving through the controls
available on the screen.
This feature is also of extreme importance as driving is the main gameplay of our
project.


This feature is loaded as soon as the player loads any level of the game.
REQ-SF2-1: The game level must be loaded.
2.4.3. Scoring System

The game system will allocate score points depending upon the time it takes to reach the
destination and it will also deduct points for not following the traffic signs.
This feature is a core part of the gameplay as it will encourage the player to follow the
rules and the Traffic Signs in order to achieve a higher score.
This player must not follow any one of the rules on the Traffic Signs.
REQ-SF3-1: The traffic sign is not followed.
2.5. Other Nonfunctional Requirements

2.5.1. Performance Requirements
When Application is made to start up it shouldn’t take more than 10 second to load initial
screen. Also, it should be made sure that app will not hindrance to the user Input. When the
user data(caches , stored data etc) increases app should be capable of handling them
without delay by optimising the way storage is done and accessed.
2.5.2. Safety Requirements

Application should be responsive to the user Input or to any external interrupt which is of
highest priority and return back to same state. When the game application gets interrupted
by call , then app should able to save pause and return to same pause state which was there
before it got interrupted.

2.5.3. Security Requirements

The game application should be reliable i.e. when user perform some important action it
should be acknowledged with confirmation. All the app data should be secured and be
encrypted with minimum needs so that it’s protected from outside environment also from
internal attack. All authentication token should be saved on local device for comparison and
need user permission to gain access.
2.5.4. Business Rules

Business rules are a set of instructions that determine how a process is performed. They
guide decision-making by establishing rules that everyone must follow when carrying out
certain activities. Companies frequently apply business rules to approvals. As a mobile
focused game, our buisness rules are centered around the Google Play Developer Policy.For
more information head to Google Play Developer Policy.[4]
2.6. Other Requirements

2.6.1. Cloud Ready
As C# was designed for the web and cloud is the metaphor for the Internet needless to say
C# is a client server-based Cloud Language. Many big Cloud Service Providers provide C#
hosting in their environment.
2.6.2. Loosely Typed

Learning C# is very easy unlike the complex languages and it doesn’t mean without
complexity you cannot make large applications. In fact, the basics of software engineering
lie in presenting simplicity. When learning C#, you don’t need to take care of it’s or float’s, it
is handled by C# dynamic typing.
2.6.3. Open Source

C# itself is open source, no organization can claim C# is theirs. The complete code of C# is
open and anyone can use it free of cost thus. Many beginners ask me if Security would be a
problem then, to them this is the same thing as you or any developer doing your work alone
in a room and in an open environment watched by thousand others.

2.6.4. Platform Independent

C# is truly platform independent where developers can write their programs on a windows
machine and run it on a Linux machine. The power of Platform independence also does not
come at a cost of performance.

Chapter 3
Use Case Analysis

Chapter 3: System Analysis

3.1. Use Case Model
Display Menu
Select Level
Play Game
Pause Level
Restart Level
Player
Resume Level
Drive Car
Game Over
Exit Game

3.2. Use Case Descriptions

Use Case 1
Use Case-ID UC_01
Use Case Name Menu
Primary Actor Player
Stakeholders and Player:
Interests
Player View the Menu
Pre-Condition Game Must be Launched
Post Condition Options Display
Main Success Scenario  Player Launch the Game
 View Menu
 Menu Display successfully.
Special Requirements  User friendly UI and game should be
played easily in landscape mode.
 Language should be international (English).
Open Issues  Low Phone memory can Crashed the Game.

Technology and Data  Game should be played on Android phones
Variations List
Use Case 2
Use Case-ID UC_02
Use Case Name Select level

Interests Player can Select the Specific Level
Pre-Condition Game must be in running Mode.
Post Condition Specific Level Selected

Main Success Scenario  Select the Play option
 Player Select the Level
 Player Selected the Level successfully
Special Requirements  User friendly UI and game should be played easily

in landscape mode.

Variations List
Use Case 3
Use Case-ID UC_03
Use Case Name Play

Interests Press the play option.
Pre-Condition Game should be running in condition
Post Condition Level selection menu open
Main Success Scenario  Player select the play option.

 Level selection
 Game ready to play
in landscape mode.

Variations List

Use Case 4
Use Case-ID UC_04
Use Case Name Paused Game.

Interests Player paused the game.
Pre-Condition Game must be in running form.
Post Condition Player paused the game successfully.
Main Success Scenario  Player play the game.

 Select the level
 Play the Game.
 Press the Pause option.
 Player paused the game successfully
in landscape mode.

Variations List
Use Case 5
Use Case-ID UC_05
Use Case Name Restart

Interests Player restart the game.
Pre-Condition Player Must consumed one live
Post Condition Player restart the game successfully.

 Select the level

 Play the Game.
 Select the restart option
 Player restart the game successfully.

in landscape mode.

Variations List
Use Case 6
Use Case-ID UC_06
Use Case Name Drive Car

Interests Player can drive the car.
Post Condition Player is able to drive successfully

 Left button will move the car to the left.
 Right button will move the car to the right.
 Brake will stop the car.
 Player changes the Acceleration successfully.
in landscape mode.

Use Case 7
Use Case-ID UC_07
Use Case Name Game Over.

Interests Player reaches the Final Destination
Pre-Condition Player Should be in the Game play Scene.
Post Condition Player reaches the Final Destination

 Select the level.
 Play the Game.
 Player reaches the Final Destination
in landscape mode.

Variations List
Use Case 8
Use Case-ID UC_08
Use Case Name Resume Game.

Interests Player Resume the game.
Pre-Condition Game Must be in Pause Mode.
Post Condition Player Resume the game successfully.

 Press the Pause button.

 Press the Resume option .
 Player resume the game Successfully
in landscape mode.

Variations List
Use Case 9
Use Case-ID UC_09
Use Case Name Exit.

Interests Player Exit the game.
Post Condition Player Exit the game successfully.

 Select the Location
 Play the Game.
 Player exit the game successfully.

in landscape mode.

Variations List

Chapter 4
System Design

Chapter 4: System Design

Design is the first step in the development phase for any techniques and principles for the
purpose of defining a device, a process or system in sufficient detail to permit its physical
realization. The system design involves four technical activities - design, coding,
implementation and testing that are required to build and verify the software. The design
activities are of main importance in this phase, because in this activity, decisions ultimately
affecting the success of the software implementation and its ease of maintenance are
made. These decisions have the final bearing upon reliability and maintainability of the
system. Design is the only way to accurately translate the customer's requirements into
finished software or a system. Design is the place where quality is fostered in development.
System design is a process through which requirements are translated into a representation
of software.

4.1. Architecture Diagram

An architecture diagram is a graphical representation of a set of concepts that are part of
architecture, including their principles, elements and components.
GUI
GAME ENGINE
Input Graphics Sound

Renderer
Subsystems Subsystems Subsystems
I/O Devices
STATE
Display
Game State
Speaker
Car/Player
Model
Touch Inputs
ASSET MANAGER
Instructional Cultural
Game Asset
Asset Asset
Asset Metadata

4.2. Domain Model

A domain model is a graphical representation of real-world ideas or flow, and not software
or databases. Domain models show entities or things, and how they are related.
<User>
Opens ITS(Game)
Player
Loads
Start Screen
Buttons
Level Select Settings Exit
Selected Level Completion

Opens Opens
Level Select
Loads Settings Menu
Menu
Returns to
Back Button

4.3. Class Diagram

A class diagram shows the existence of classes and their relationships in the logical view
of a system.
Start Game
Load Main Menu
Main Buttons
Scroller
Camera Open Level Menu
Continuous Moving Background Open Settings
Render Perspective Quit
void update()
Follow Player
Load PlayerPrefs on click()
AudioSource.Play()
void update() GameObject.SetActive()
void start()
Level Menu Settings Menu

Load Level
Player/Car Music Control
Select Level
Load Camera SFX Control
Back to Main Menu
Accelerate Load Player Back to Main Menu
Steer Load Road
Brake Load Canvas and UI on click() on click()
Load relevant scripts LevelClick.ClickLevel() MusicSwitch.On_Off()
void update() GameObject.SetActive()
void start() SFXSwitch.On_Off()
GoForward() GameObject.SetActive()
GoReverse()
TurnLeft()
TurnRight()
Brake()
Pause Menu
UI Canvas Back to Game

Restart Level
Timer Open Settings Menu
Pause Menu Button Back to Level Select
Car Input on click()
on click() GameObject.SetActive()
Pause() Reload.Restart()
ButtonUp()
ButtonDown()

4.4. Sequence / Collaboration Diagram

Collaboration diagrams and sequence diagrams are alternate representations of an
interaction. A collaboration diagram is an interaction diagram that shows the sequence of
messages that implement an operation or a transaction. Collaboration diagrams show
objects, their links, and their messages.

4.5. Component Diagram

The purpose of a component diagram is to show the relationship between different
components in a system.

4.6. Activity Diagram

Activity diagrams are graphical representations of workflows of stepwise activities and
actions with support for choice, iteration and concurrency.
Player Game
Start
Introduce
Start Screen
Show level
selection
Show the game

scenario in the level
Take input from user Show action of the input

to control car given by the user
Take input for

further action
Finish Level
Show Score

4.7. State Transition Diagram

State Transition Diagram are also known as Dynamic models. As the name suggests, it is a
type of diagram that is used to represent different transition (changing) states of a System.
Start Game
Select Level
Move Car
Pause
Forward
Menu
Right Button Left Button
Exit
Right Movement Left Movement
Reach Finish Line
Restart Next Level Exit

4.8. Deployment Diagram

Deployment diagrams show the relationships between the software and hardware
components in the system and the physical distribution of the processing.
Android Device Game Application

Display
Save
Game Render Data
Input Control Level Selection
Car Control
Audio Manager
Speaker
Sound/Music
Output

Chapter 5
Implementation

Chapter 5: Implementation
It is the most necessary chapter. In this, we discuss how our project will implement. As we
all know satisfactory tools and techniques are more important for a software engineer. So
this chapter defines how our project will be executed by using satisfactory tools and
techniques.
5.1. Components, Libraries, Web Services and stubs

The components and libraries are web services.
Components:
 A Camera Component.
 A GUI Layer.
 A Game Manager.
 Graphics Renderer.
 An Audio Listener.
Libraries:
 C#.
 OOP.
 SOLID.
5.2. Deployment Environment

Usually Deployment Environments are well built PCs and systems but as students our
Deployment Environment is our android smartphones.
5.3. Tools and Techniques

 Unity (Game Development Engine):
Unity is a game development ecosystem of a powerful rendering engine, intuitive
tools, rapid workflows for 2D and 3D games, all-in-one deployment support, and
thousands of already created free and paid assets with a helpful developer’s
community.
 C# (Scripting):

C# scripts are the code files that store behaviors in Unity, powering everything the
engine does. While there are a lot of new tools that will allow a developer to make a
game without them, scripts are still the best way to create custom actions and
interactions within a game space.
 Zbrush (3D Assets):
Zbrush can be used to produce 3D models for games. It is a popular choice in the
industry and is widely used in a game 3D modeling pipeline. It has the ability to export
to OBJ or FBX formats which is the standard format used in game engines for 3D
models.
 Photoshop (2D Assets, Textures, and Sprites):
Even in the most advanced 3D game studios, working with 2D images is still a huge part
of the development process. The weapon of choice is Adobe's venerable imaging tool.
5.4. Best Practices / Coding Standards

SOLID is a mnemonic acronym for five core fundamentals of software design. You can think
of them as five basic rules to keep in mind while coding, to ensure that object-oriented
designs remain flexible and maintainable.
 Single responsibility states that each module, class, or function is responsible for
one thing and encapsulates only that part of the logic.
 Open-closed states that classes must be open for extension but closed for
modification; that means structuring your classes to create new behavior without
modifying the original code.
 Liskov substitution states that derived classes must be substitutable for their base
class when using inheritance.
 Interface segregation states that no client should be forced to depend on methods it
does not use. Clients should only implement what they need.
 Dependency inversion states that high-level modules should not import anything
directly from low-level modules. Both should depend on abstractions.

5.5. Version Control

Git is a distributed version control system that tracks changes in any set of computer files,
usually used for coordinating work among programmers collaboratively developing source
code during software development. Its has a code hosting platform for version control and
collaboration called GitHub that lets you and others work together on projects from
anywhere.

Chapter 6
Testing and Evaluation

Chapter 6: Testing and Evaluation

After the implementation phase the testing part begins. Testing of the application
determines the correctness, completeness and the quality of the application. Being a
developer, the main objectives of us is to detect the bug as well as the other errors in an
application. Error prevents to produce the correct output/ desired output.
6.1. Use Case Testing

A use case is a description of a particular use of the system by an actor (a user of the
system). Each use case describes the interactions the actor has with the system in order to
achieve a specific task (or, at least, produce something of value to the user). The default use
case of the game is to teach about the various traffic signs which the game performs.
6.2. Data flow testing

Data flow testing is a family of test strategies based on selecting paths through the
program's control flow in order to explore sequences of events related to the status of
variables or data objects. Dataflow Testing focuses on the points at which variables receive
values and the points at which these values are used. This was used on the score system of
the game and though it had some bugs, they were eventually cleared.
6.3. Equivalence partitioning

The Game Application relies on the touchsreen mechanics of an android smartphone, hence
the inputs the game will accept are touch, swipe left, swipe right and slide. Any other input
such as shaking or tilting the smarphone will have no effect or it would not provide any sort
of output to the user.
6.4. Boundary value analysis

The gear switch is used to control the speed of the player vehicle. On maximum speed the
car goes at the speed of 120 kmh(in-game), at a little lower speed it is 100 kmh(in-game),
the normal value is at 60 kmh(in-game) and lowest speed is 20 kmh(in-game) and then at 0
kmh(in-game) it stops.

6.5. Unit testing

It is a level of software testing where individual units/ components of software are tested.
The purpose is to validate that each unit of the software performs as designed. A unit is the
smallest testable part of any software. The team tested each of the components/units to
make sure they perform their tasks as required.
6.6. Integration testing

Integration testing (sometimes called integration and testing, abbreviated I&T) is the phase
software testing in which individual software modules are combined and tested as a group.
It occurs after unit testing and before validation testing. Integration testing takes as its input
modules that have been unit tested, groups them in larger aggregates, applies tests defined
in an integration test plan to those aggregates, and delivers as its output the integrated
system ready for system testing. The game was built and tested multiple times as a whole to
test and make sure that all the components work together seamlessly.
6.7. Performance testing

Performance testing is the process of determining the speed, responsiveness and stability of
a computer, network, software program or device under a workload. Performance testing
can involve quantitative tests done in a lab, or occur in the production environment in
limited scenarios. Performance testing of our project was also done and after testing we
found some unneccessary bits of code that made the script unefficent. It was fixed in the
later revision.
6.8. Stress Testing

Stress test determines if the system is able to handle everything, how it handles with data
when the game infrastructure is overstressed, and how far can stress testing go before the
game stops responding and how are errors shown to users. Since this is an android based
game the stress that a Smartphone can handle is pretty low but we are glad that our game
was able to run despite a few apps running in the background.

Chapter 7
Summary, Conclusion and
Future Enhancements

Chapter 7: Summary, Conclusion & Future

Enhancements
7.1. Project Summary

Overall the project was a success as the game is up and running. The low poly simple design
helps to run the game easily on any android phone tested so far and it is pleasing to look.
The simple design also helps attract a lot of users to try the game and learn about the
various Traffic Signs in a fun and interactive way yet still challanging enough to be enjoyable
as a Video Game.
7.2. Achievements and Improvements

Generally, these exercises have been bolstered by pen and paper. The
users/players/aspiring drivers will be able to play the game and learn about all the Traffic
Signs easily and in an enjoyable manner.
7.3. Critical Review

Currently the game application is only available in English language which means it is a
major setback for people who only know/learn to speak Urdu. We also cannot reach people
that are on IOS or do not play android games.
7.4. Lessons Learnt

We learned many important lessons through the development of this project. We learned to
use ProBuilder(a 3D modeling tool), we also learned to develop android based games and
got very good in C# and OOP based programming.
7.5. Future Enhancements/Recommendations

Amoung the changes or enhancements that can be performed on the project some of them
are given below:
 Develop the UI in Urdu language to provide an option to choose.

 Develop support for Ios.

 Develop a web-based version.
 Make the script more efficient.
 Create new levels.

Reference and
Bibliography

Reference and Bibliography
[1] https://unity.com/
[2] https://pixologic.com/
[3] https://www.adobe.com/products/photoshop.html
[4] https://play.google.com/about/developer-content-policy
[5] https://unity.com/features/probuilder
[6] https://play.google.com/store/apps/details?id=ao.com.osvaldovipgmail.estradaango
lasadc&hl=en&gl=US

Index

Index
[A]
Accidents 2,3
Ads 11
Asset 3,4,35,36
[D]
Developers 8,11,14
[G]
GUI 10,35
Guidebook 2
[I]
IDE 8
[L]
Low-poly 10
[P]
Policy 14
[S]
Simulation 3,4
SOLID 35,36
[T]
TCP/IP 11
Tracks 3
[V]
Volume 10

Zahid Ali

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Zahid Ali

Uploaded by

Copyright:

Available Formats

THE SUPERIOR UNIVERSITY, LAHORE

ASSOCIATE DEGREE PROGRAMS

Final Year Project

Interactive Traffic Signs

Project ID: FYP-ADP-F21-017

Muhammad Zahid 1.0 17/5/2023 This project is a 3D

Faculty of CS&IT, Superior University Lahore, Pakistan ii

HEAD OF THE DEPARTMENT

Faculty of CS&IT, Superior University Lahore, Pakistan iii

Faculty of CS&IT, Superior University Lahore, Pakistan iv

Faculty of CS&IT, Superior University Lahore, Pakistan v

Faculty of CS&IT, Superior University Lahore, Pakistan vi

Faculty of CS&IT, Superior University Lahore, Pakistan vii

2.4.2.1. Description and Priority........................................................................................133

Faculty of CS&IT, Superior University Lahore, Pakistan viii

7.1. Project Summary........................................................................................................... 43

Faculty of CS&IT, Superior University Lahore, Pakistan ix

1.1 Gantt Chart 5

Faculty of CS&IT, Superior University Lahore, Pakistan x

1.1 Roles & Responsibility Matrix 3

Faculty of CS&IT, Superior University Lahore, Pakistan xi

1.2. Motivations and Challenges

1.3. Goals and Objectives

1.4. Literature Review/Existing Solutions

Faculty of CS&IT, Superior University Lahore, Pakistan 2

1.5. Proposed Solution

1.6. Gap Analysis

Faculty of CS&IT, Superior University Lahore, Pakistan 3

knowledge and practical applications. This difference is heightened by the lack of

1.7. Project Plan

1.7.1. Work Breakdown Structure

Faculty of CS&IT, Superior University Lahore, Pakistan 4

1.7.2. Roles & Responsibility Matrix

2 Testing. 8 50 Rao Ahtasham

3 Simulation. 9 21 Rao Ahtasham

4 Asset Collection 3 5 Muhammad Zahid Ali

5 Sign Design 4 7 Muhammad Zahid Ali

6 Road Design 5 21 Rao Ahtasham

7 Levels 1 10 Muhammad Zahid Ali

8 Designing 2 20 Muhammad Zahid Ali

9 Quality Check 6,10 2 Muhammad Zahid Ali

Faculty of CS&IT, Superior University Lahore, Pakistan 5

1.7.3. Gantt Chart

Faculty of CS&IT, Superior University Lahore, Pakistan 6

1.8. Report Outline

Faculty of CS&IT, Superior University Lahore, Pakistan 7

Faculty of CS&IT, Superior University Lahore, Pakistan 8

Chapter 2: Software Requirement Specifications

2.1.2. Document Conventions

2.1.3. Intended Audience and Reading Suggestions

2.1.4. Product Scope

Faculty of CS&IT, Superior University Lahore, Pakistan 9

2.2. Overall Description

2.2.2. Product Functions

2.2.3. User Classes and Characteristics

2.2.4. Operating Environment

Faculty of CS&IT, Superior University Lahore, Pakistan 10

2.2.5. Design and Implementation Constraints

2.2.6. Assumptions and Dependencies

2.3. External Interface Requirements

Faculty of CS&IT, Superior University Lahore, Pakistan 11

2.3.2. Hardware Interfaces

2.3.3. Software Interfaces

Faculty of CS&IT, Superior University Lahore, Pakistan 12