1

ANNA UNIVERSITY CHENNAI

BONAFIDE CERTIFICATE

Certified that this report titled “INFORMATION OBTAINED FROM THE LOT OF TECHNOLOGY
USED TO CREATE SPACE INVADER GAME USING PYTHON LANGUAGE ” is the bonafide
work of SENTHIL.V (512217104026) who carried out the work under my supervision.

……………………………… .………………………………

Dr.N.PURUSHOTHAMAN, M.E. Ph.D, Dr.V.RAJI, M.E, Ph.D.

HEAD OF THE DEPARTMENT, ASSISTANT PROFESSOR

DEPARTMENT OF CSE, DEAPARTMENT OF CSE,SKP ENGINEERING

COLLEGE, SKP ENGINEERING COLLEGE,

THIRUVANNAMALAI. THIRUVANNAMALAI.

Submitted to the Viva Voice Examination held on ……………

Internal examiner External examiner

 2

TABLE OF CONTENTS

CHAPTER TITLE PAGE NO

NO.

ABSTRACT
ACKNOWLEDGEMENT
LIST OF FIGURE
LIST OFABBRIVATIONS
SYSTEM SOFTWARE REQUIREMENT
1 OUTLINE
2 DETAIL AND INFORMATION ABOUT THE
GAME
2.1 Introduction

2.2 Introduction about the software

2.2.1 Flowchart

3 SYSTEM SPECIFICATION
3.1 Existing system

3.2 Proposed system

4 PROBLEM STATEMENT
5 SYSTEM ARCHITECTURE DIAGRAM
6 MODULE

7 DIAGRAMS
7.1Entity Diagram

7.2 Class Diagram

7.2.1 Sequence Diagram

7.2.1.1 Activity Diagram

7.2.2 Object Diagram

 3

8 TEST CASE METHODS

8.1 Black Box Testing

8.2 White Box Testing

8.2.1Basis Path Teasting

9 OUTPUT SCREEN
10 LIMITATIONS
11 CONCLUSION
12 FEAUTER DEVELOPMENT
13 REFERENCES AND BIBLIOGRAPHY
14 SITE FOR USED

ABSTRACT:

The aim of this project is to build a 2D arcadelike game from scratch in Python, the goal being for the
project to be as lightweight open source resource wise as possible. The core of the game, is PyGame [1],
a set of Python modules designed for game development, which was used for tasks such blitting images
on the screen or moving the said images.
The end product is a two levels game, the goal of the player being to destroy all the enemy space ships,
picking up buffs or debuffs along the way, encountering intelligent enemies in the latter level of the
game.
The following report will provide an indepth understanding of the technicality of the project, as well as
the reasons this game was built in the first place. The report starts by creating a context for this work and
will continue guiding the reader through the journey of its implementation. The second part of the
document will familiarise the reader with the development of the game, as well as the alternatives that
could have been used and the approaches undertaken during the development, while the following part of
the report will present the evaluation that has been made during and after the implementation. Finally,
the report concludes with a reflection of the last few months of work and the outcome of the project.
FieldProgrammable GateArray (FPGA) technology is gaining popularity among ApplicationSpecific
 4

Integrated Circuit (ASIC) designers. Ease of development and maintenance makes FPGAs an attractive
solution to many speed and efficiencycritical applications. 
The purpose of this project is to explore theworld of FPGAs by implementing an arcade game on top of a 
VGA driver. The project was implemented on Xilinx Spartan-
3E development board using VHDL hardware description language.
The project was started by learning VHDL as well as familiarising with the Spartan3E development
board and Xilinx ISE WebPACK design software. 
A number of simple applications were developed inorder to comfortably proceed on to investigation of w
orking principles of a VGA driver. It turned out
that the synchronisation logic was rather trivial and that the custom implementation would not add
much value to the project.
VHDL implementation of the classic Pong game was the first major task of the project. Plong, as it was
named, is a twoplayer game, where each player tries to to hit a ball towards the opponent. A number
of basic features, such as acceleration of the ball, sound output and textual information display, have
been implemented. As this game was developed in the early stage of the project, complexity was
consciously avoided.
The objectives the second game, on the other hand, were focused on technical features and other
improvements. Still monochrome images were exchanged for colourful animations, sound output was
made more sophisticated by adding a tune player, Nintendo game pads replaced onboard switches as a
user input interface and  a number of other modules were developed.  The  theme was chosen to
resemble the Space Invaders game, but all graphic elements were designed from scratch.
To make the project more complete and self contained, the two games were combined into a single
application, with a menu screen to allow user to choose which game to play.
Lastly, an adaptor board, for connecting NES game pads to the development board, was designed and
built.
 It facilitates the communication between the controllers and the FPGA. The board also hosts a
piezoelectric buzzer for sound output and a reset switch.
The project was complete and fully functional before the deadline. While there is still a lot of room for
improvement, all set objectives, and more, were met.
5
 6

ACKNOWLEDGEMENT

I am very thankful to the management of SKP Engineering College, Thiruvannamalai for giving us

this wonderful opportunity to study in this college and utilize all the facilities to the fullest.

My sincere thanks to lord blessing on us for the successful completion of my mini project. I thank

proudly Mr. K. KARUNANITHI, B.E., MBA, Chairman of my college for providing the facility to do the

mini project. I am grateful for my Principal Dr. S.BASKARAN, M.E, Ph.D., for his constant support and

encouragement to our project.

I express my sincere thanks to DR.N.PURUSHOTHAMAN Head of the Department of Computer

science and Engineering for us for guidance, timely suggestions and word motivation.

It is a Great pleasure to express my gratitude and thanks towards my project guide Dr. V.RAJI,

M.E, Ph.D., for his uninterruptable suggestions and words of improvements regarding this mini project,

which played a major role in guiding me in my track.

I would like to thank all the faculty members and family members for their continuous support and kind

cooperation during our mini project work. SENTHIL.V

 7

LIST OF FIGURE:

FIGURE DESCRIPTION PAGE NO

NO:
1

Class Diagram

Sequence Diagram

Activity Diagram

Object Diagram

Collaboration Diagram

Background Output Screen

Player Output Screen

Enemy Output Screen

Output Screen
8
 9

LIST OF ABBREVATION:
SERIAL ABBREVATIO DESCRIPTION
NO N
1 HTTP Hyper Text Transfer Protocol
2 WWW World Wide Web
3 PDF Portable Document Format
4 PNG Portable Network Graphics
5 VAV Variable Air Volume
6 TTF True Type Font
7 XML Extendible Markup Language
8 JSON Java Script Object Notation
9 EGG Explosion Graphics Generator
10 IML Integrated Memory Logic
11 HTTPS Hypertext Transfer Protocol Secure
12 CFG Configuration File
13 PTH PyTorch
 10

SYSTEM SOFTWARE REQUIREMENTS:

Platform Used:

 Hardware Platform :
 System Model : LENOVO E41-15
 Processor : AMD PRO A4-3350B APU with Radeon R4 Graphics
2.00GHz
 RAM : 4GB
 Hard disk : 500GB

 Software Platform:
 Operating System : Windows 10 pro
 IDE : JetBrains PyCharm Community Edition 2018.3.5
 EDITING APP : Adobe Photoshop CS5
 11

OUTLINE:
12
 13

INTRODUCTION:

Space Invaders(SI) origins date back to 1978, where the videogames were quite simple and there wasn’t the variety
that exists nowadays in video games, and so almost every game used to had a huge success. SI was originally
manufactured and sold by Taito in Japan and it is an excelent retro arcade video game. The objective in the game
was to control a sort of space aircraft and defeat the aliens by shooting them with a laser and destroy as many as
possible and then that performance was converted to points which would be then in an high score table. In its first
versions Space Invaders was really simple in a two dimensional environment game where the player moves his
”spacecraft” to the left and right shooting the aliens. Space Invaders (1978) The reason for choosing the rebirth of
Space Invaders [1] relates to the fact that this was a great game on his era and deserves recognition. This recognition
process will be done by rethinking the core-ideology of the game and by adding some new features that will improve
the game dynamics. This work will consist in modelation and implementation of a new version of Space Invaders,
that will be similar to the original copy, but with several improvements, like a 3D interface, new sound effects,
different levels, new items to shoot on (bonus items), etc. The report will talk about the difficulties and some
interesting things that happened during the development of the application and will explain some methods that had
been taken. In that way it will be divided in three parts, the first one will, in his essence, be focusing on explaining
the code done, like the objects created, the building of the scene and the user interaction. The second part will
resume what was learned during the development of the game, will focus the good and bad things in the project and
what could be done to improve the project in the future. The third and last part of the report will list all the
references used

this project was to implement the arcade game Space Invaders from 1978 on a FPGA (Field-Programmable Gate
Array). The idea behind the game is very simple. Figure 1 is a screenshot of the original game. The player controls
the ship in the bottom of the picture. It is possible to move horizontally and the goal is to shoot all the aliens above.
The aliens can also shoot bullets, which the player has to dodge or take cover from behind the green walls. The
implementation was done by designing a system containing both software and hardware parts. Figure 2 displays an
overview of the system. Two custom hardware cores with AXI bus (Advanced eXtensible Interface) interfaces had
to be implemented. A GPU (Graphics Processing Unit) to display the game on a VGA (Video Graphic Array)
monitor and a audio core to play sounds. Two different system buses had to be used as well, AXI bus and PLB
(Processor Local Bus). The reason behind this is that the PS/2 controller could only be connected to the PLB.
Therefore a bridge between the buses had to be used to connect the devices on the AXI bus to 2 the keyboard. The
software implemented on the CPU (Central Processing Unit) was used to control the game functionalities. These
functionalities included moving all sprites and handling collisions between the bullets and the player or the aliens.
The differences between the implemented and the proposed systems are quite big. Originally it was assumed that the
keyboard could be connected directly to the AXI bus. There were also no plans to implement audio support. This
was added since the rest of the system was implemented quite fast. Text support on the GPU was also added, which
means that the software developer can print text wherever is needed.
 14

INTRODUCTION ABOUT THE SOFTWARE:

PyCharm is the most popular IDE used for Python scripting language. This chapter will give you an introduction to
PyCharm and explains its features. PyCharm offers some of the best features to its users and developers in the
following aspects:

 Code completion and inspection

 Advanced debugging

 Support for web programming and frameworks such as Django and Flask

Features of PyCharm:

Besides, a developer will find PyCharm comfortable to work with because of the features mentioned below:

Code Completion:

PyCharm enables smoother code completion whether it is for built in or for an external package.

SQLAlchemy as Debugger:

You can set a breakpoint, pause in the debugger and can see the SQL representation of the user expression for SQL
Language code.

Git Visualization in Editor :

When coding in Python, queries are normal for a developer. You can check the last commit easily in PyCharm as it
has the blue sections that can define the difference between the last commit and the current one.

Code Coverage in Editor:

You can run .py files outside PyCharm Editor as well marking it as code coverage details elsewhere in the project
tree, in the summary section etc.

Package Management:

All the installed packages are displayed with proper visual representation. This includes list of installed packages
and the ability to search and add new packages.

Local History:

Local History is always keeping track of the changes in a way that complements like Git. Local history in PyCharm
gives complete details of what is needed to rollback and what is to be added.
 15

Refactoring :

Refactoring is the process of renaming one or more files at a time and PyCharm includes various shortcuts for a
smooth refactoring process.

User Interface of PyCharm Editor:

The user interface of PyCharm editor is shown in the screenshot given below. Observe that the editor includes
various features to create a new project or import from an existing project

From the screenshot shown above, you can see the newly created project Demo and the site-packages folder for
package management along with various other folders. You can download the PyCharm Editor and read its official
documentation at this link: https://www.jetbrains.com/pycharm/

2. PyCharm – Installation

In this chapter, you will learn in detail about the installation process of PyCharm on your local computer.

Steps Involved :

You will have to follow the steps given below to install PyCharm on your system. These steps show the installation
procedure starting from downloading the PyCharm package from its official website to creating a new project.

Step 1 :

Download the required package or executable from the official website of PyCharm
https://www.jetbrains.com/pycharm/download/#section=windows. Here you will observe two versions of package
for Windows as shown in the screenshot given below
 16

Note that the professional package involves all the advanced features and comes with free trial for few days and the
user has to buy a licensed key for activation beyond the trial period. Community package is for free and can be
downloaded and installed as and when required. It includes all the basic features needed for installation. Note that
we will continue with community package throughout this tutorial.

Step 2:

Download the community package (executable file) onto your system and mention a destination folder as shown
below:
 17

Step 3:

Now, begin the installation procedure similar to any other software package.
 18

Step 4
Once the installation is successful, PyCharm asks you to import settings of the existing package if any
 19

This helps in creating a new project of Python where you can work from the scratch. Note that unlike
other IDEs, PyCharm only focusses on working with projects of Python scripting language.

Pycharm –understanding basics:

This chapter will discuss the basics of PyCharm and make you feel comfortable to begin working in
PyCharm editor.
 When you launch PyCharm for the first time, you can see a welcome screen with entry points
to IDE such as: Creating or opening the project
 20

 Checking out the project from version control

 Viewing the documentation
 Configuring the IDE

Recall that in the last chapter, we created a project named demo1 and we will be referring to the same
project throughout this tutorial. Now we will start creating new files in the same project to understand
the basics of PyCharm Editor.
 21

This code can be run within IDE environment. The basic demonstration of running a program is
discussed below:
 22

Note that we have included some errors within the specified code such that console can execute the
code and display output as the way it is intended to
23
 24

FLOW CHART:
 25

EXISTING SYSTEM:

 Cannot Upload and Download the latest updates.

 Risk of mismanagement and of data when the project is under development.

 Less Security.

 No proper coordination between dissimilar Applications and Users.

 Fewer Users – Friendly.

 Manual system need man power a lot.

 Communication between customer and owner is not directly.

 The complete hierarchy is doesn’t implemented in manually.

 In big organization it is time consuming process.

SOLUTION OF THESE PROBLEMS:

The developments of the new system surround the following activities, which try to automate the entire process
keeping in view of the database integration approach.

 User responsiveness is offered in the request with various organizes.

 The coordination makes the by and large project organization much easier and supple.

 Readily upload the latest updates, allows user to download the alerts by clicking the URL.

 There is no risk of data misconduct at any level while the project progress is under procedure.

PROPOSED SYSTEM:
To debug the existing system, remove procedures those cause data redundancy, make navigational sequence proper.
To offer data about audits on dissimilar level and also to reflect the current work status depending on
organization/auditor or date. To build strong password mechanism.

NEED FOR COMPUTERIZATION:

We all know the importance of computerization. The world is touching ahead at lighten momentum and each one is
organization short of time. One forever needs to get the in order and perform a commission he/she/they wish(s)
inside a short phase of time and too with amount of efficiency and accuracy. The application areas for the
computerization have been selected on the basis of following factors:

 Minimizing the manual records kept at dissimilar locations.

 There will be more data honesty.

 26

 Facilitating desired data display, very quickly, by retrieving data from users.

 Facilitating various statistical data which helps in decision-making?

 To decrease labor-intensive labors in behavior that occupied boring work.

 Update and removal of such a huge quantity of data will turn out to be easier.

FUNCTIONAL FEATURES OF THE MODEL:

As far as the project is developed the functionality is simple, the objective of the proposal is to strengthen the
functioning of Audit Status Monitoring and make them effective and better. The entire scope has been classified into
five streams knows as Coordinator Level, management Level, Auditor Level, User Level and State Web Coordinator
Level. The proposed software will cover the data needs with respect to each request of the user group viz. accepting
the request, providing vulnerability document report and the current status of the audit.

PROBLEM STATEMENT:

Space Invaders is one of the early arcade games (1978) and one of the first to make into the home PC market (in
1980 by Atari). In this game you (the "ranger-guy") can fly back and forth (left or right) along the bottom of the
screen while rows of aliens march across the screen. They can shoot at you and you can shoot at them. Once the
aliens have made it all the way across the screen, they "drop down" a level (i.e. get closer to you), change directions,
and begin their march again. If any of the aliens manage to land (i.e. get down to your level), you loose. If any of
them hit you when they shoot, you loose. Your job is to shoot them all before that can happen. In most versions of
the game the aliens start to move faster as they get closer. Sometimes they also get faster as soon as you get rid of an
entire row. In most versions there are also a certain number of "shields" between you and the aliens. You can hide
behind them but no-one can shoot through them and they can be destroyed just like any other object on the screen.

(see also: http://spaceinvaders.retrogames.com/html/history.htm) An exerpt from this link:

Space Invaders was designed and programmed by Toshihiro Nishikado for Taito, Japan in 1978 and remains one of
the most popular arcade games ever made. The game was licensed from Taito by Midway for production in the US.
In 1980, the game was licensed by Atari for the 2600 game system and was the first arcade game ever adapted for
Atari's home system. The Space Invaders franchise has flourished for more than 20 years and according to Taito, the
game has generated more than $500 million in revenues over multiple platforms including coin-op, the Atari 2600
and the Nintendo.
It was based on a 8080 CPU, had muffled analog audio, and simulated color by putting a transparent overlay on top
of a monochrome display.
Space Invaders was the first arcade game to work it's way out of seedy arcades and into pizza parlors and ice cream
shops.
The Space Invaders phenomenon stuned conservative adults who were certain the games soured the minds of their
youngsters. Residents of Mesquite, Texas pushed the issue all the way to the Supreme Court in their efforts to ban
the illicit machines from their Bible-belt community.

The game was so amazingly popular in Japan that it caused a coin shortage until the country's Yen supply was
quadrupled. Entire arcades were opened in Japan specifically for this game.
 27

Description of Our Version:

 with sound
 ASCII graphics

our game will consist of a WINDOW defined using "easycurses" and marks displayed in the window will be
standard ASCII characters (suggested size:800,600)

 graphics done using easycurses

 our "universe" is two dimensional

Since we do not yet have the experience to create a full-blown event-driven system our game will run as "snapshots
in time". This is similar to the approach used in MINESWEEPER last term.

 we will create an initial configuration at the start of the game consisting of a number of different spaceships.
When we have destroyed them all, we win. If we get destroyed first, we loose.
 just as in MINESWEEPER each object will respond to the conditions as they were at the end of the
previous time interval. 

At each time interval:

 each object will make a move based on the screen as it was last
 spaceships continue to move
 we retrieve input from the user to tell us what the "Ranger" (that's the player) should do (which could be null
meaning don't move the Ranger)

Running the Game:

 ( optional ) can have command line arguments for game "parameters":

 level of difficulty (affects # of "shields", spaceships, shooting range, etc.)
 or could allow user to specify range, etc.
 with no arguments, it would be run like:

./play

 can have a restart option or can simply require the user to quit and start again

(suggested) user input: (everyone but ranger moves EACH "turn")

 ESC = Quit
 SPACE = Shoot
 SPACE,↑ = mOve and shoot
 SPACE,-> = move right and shoot
 28

 SPACE,-<= move left and shoot 

The "names" of these commands need not be as specified - can use others (single-character Highly Recommended).
Check the keyboard for conveniently located keys. I would suggest implementing them in the above order (roughly).
Do <blank> and 'q' first with just the shields to make sure they move as they are supposed to. Do this before your
ranger even exists.

Minimal Solution:

Get some graph paper so you can draw your window and objects. Calculating x,y coordinates is easier if you
have a picture of what your are doing.

The minimal passable solution will have only a ranger that moves correctly on the screen and a few shields. This
solution is worth a maximum mark of C+

The midrange solution will have the shields and a working ranger who can move and shoot stuff.

This solution is worth a maximum mark of B+

The best solution will have shields, the ranger, AND sereval kinds of spaceship all working correctly. It is worth up
to an A

Testing and Marking:

Needs external documentation that user can refer to while playing the game.

Notes on Marking:

We will be looking for the usual good, clean design; documentation, etc. as always.

In order to pass it must work. (Some marks will be given to all *reasonable* attempts, working or not)

Specifics we will be looking for when marking:

 Ranger

 initial position correct?

 can the player move him?

 can the player make him shoot?

 SpaceShips
 29

 do they consistently get closer to the ranger

 do they change direction at the right time

 do they shoot when in the proper range

 do they ever win?

How to submit your assignment:

This assignment SHOULD be 'demo'ed for your TA. Be sure to arrange a time IN LAB (or when your TA is
scheduled in CT) with your TA.

This assignment can be submitted electronically using submit.

Include:

- all .PY files

SYSTEM ARCHITECTURE DIAGRAM:

The above figure shows the overall architecture of the game. As it can be seen from the diagram, there
 30

are four major units that form Space Defenders: Audio, Graphics, Assets and Game State components.
Having followed a loose coupling and high cohesion approach in building the underlying structure of the
system, components can easily be changed without affecting the others, making the application more
flexible and easier to maintain.

MODULE:

SPACE INVADER

There’s no need to convince anyone that video games and virtual simulations are really popular among kids and teens, the
groups which forms a large faction of students. Through e-games, this demographic can learn a thing or two about how
organizations and companies based on space exploration, work. ‘Space Company Simulator’, as the name suggests, would
simulate an aerospace research company. The player will take the role of CEO and Chief Scientist. The aim is to expand and
successfully conduct scientific research. As the chief, the player has to take all the decisions including:

(a) Accepting and Developing mission to the space

· Finishing the mission provides you with ‘Gold’, the in-game currency which helps you to buy stuff within the game and level
up easily.

Completing each mission will grant you with experience points which help you to level up.

· Leveling up helps you to accept more complex missions.

(b) After leveling up to a certain point, a side-story quest would start where you have to build a colony on a new planet.
As the chief, your job would be to learn as much as possible about the assigned planet I order to make sure the colony
survives.

· This will give the students an insight on how a space colony can be planned.

· Before setting up the colony, the player has to analyze the planet’s environment which will be helpful in understanding how
scientists examine the planet’s environmental conditions.

· In order to build colonies and set machines, the players would need to build some and buy some machinery, from the in-game
store, in-exchange for Gold.

· The students would be able to understand the phenomena that occur out there in space and they’d need to learn about them in
order to tackle hurdles and move forward in the game.
 31

© The game would also allow the players to train astronauts for the missions. They’ll need to take care and make sure
that these virtual spacemen stay alive and healthy.

· The training progress would be displayed in a bar in the astronaut’s profile.

· This would allow the students to understand the way astronauts are trained in order to survive and work optimally in the outer
space.

· Astronauts would be precious commodities in the game and the player has to take proper care of them as without a certain
number of astronauts, they won’t be able to go for in-game missions.

(d) The players would learn about the space weather as in some instances, the space and colony missions mustn’t take
place due to the risk of astronauts getting killed. This would lead the player to take in-game decisions based on scientific
facts and data.

(e) A monthly event shall take place which would allow the players to mine on cosmic bodies like moon, asteroid etc. in
order to get rare in-game elements.

The game has to be kept grounded in order to make it as scientific as possible. Thus, it will influence the players to take a
realistic approach towards the game. An in-game assistant would provide all the scientific details, mission briefing, and
information regarding the status. Everything would be relevant to the game in order to make the player progress as well to make
them learn while playing.

Apart from the ones suggested above, there are many well-established games and apps through which, people are learning about
the cosmos in more than one way. From sparking people’s imagination to unleashing their creativity and bringing them together,
these games won’t disappoint anyone who wants to learn:

2D GRAPHICS:
Various techniques to display graphics have been used throughout the video game history and these
techniques have evolved due to hardware improvements as well as the gamers’ demands.
Earliest games had textbased graphics [11], where players could read or view text rooms, items, players
or even actions performed in the game’s world. Requiring less to none graphical processing, systems that
could run these games did not require a video display at all. The next ‘big hit’ in the video game industry
was the vector graphics [12], which used geometrical primitives such as points and lines, instead of
bitmap graphics.
Fast forwarding to current day graphics, in which the 3D first or third person perspective dominates the
industry, I have chosen a 2D top down perspective [Fig. 5] for Space Defenders. Also referred to as
bird’s eye view, the top down perspective is described as a camera point of view that shows the player
 32

(and the rest of the scene) from above [13]. Reason behind this choice is strongly related to the detail this
approach offers in displaying and manipulating entities, as well as aiding the mask based collision
algorithm (more on this later in the report). Currently, there seems to be a trend of remaking classic
games and fortunately, as we live in the HD remastering era, we have already witnessed Age of Empires
HD [14] and with Blizzard being rumoured to release HD remakes of Warcraft III and Diablo II [15], I
decided to follow the same principle so my game has a classical feeling to it.

The game itself has a number of graphical items, such as the player spaceship, the enemy space ships,
bullets or powerups, that interact with each other maximising the gameplay experience. All these entities
are loaded as PNGs and converted to PyGame Sprite objects for easier manipulation.
 33
0 0 0 0
SOUND:
The task of the audio module is 0 1 1 0 to select and play sounds when
certain events happen, such as a powerup being picked up or the
player spaceship has been hit by an enemy bullet. Before the game
0 1 1 0
starts, sounds are loaded into a mixer (a module used for loading
Sound objects and controlling playback), which acts as driver for
the Audio module.
0 0 0 0

With a custom buffer and a careful choice of audio channels, the game is
able continuously play a background sound throughout the entire gameplay without interfering with sounds that are played
periodically

Collision:

Collision detection represents the problem of signaling the overlapping between two or more objects, the
topic being mainly associated with video games as well as physical simulations. Therefore, since

collision between entities is one of the factors that make any game seem as close to a real world scenario
as possible, Space Defenders’ collision detection algorithm aims to achieve this.
In order to understand the collision detection algorithm used in Space Defenders, we need to understand
what are the two approaches that can be undertaken when checking for collisions: discrete and
continuous
Mask Based Collision Detection Algorithm:
 34

A mask of an image is a bitwise matrix representation of the said image [20], where transparent pixels
are represented as 0s and non transparent pixels as 1s. Let’s consider the following example image:For
demonstration purposes, let’s imagine the black ‘frame’ of the light blue square is in fact the background
of the image and is transparent. Also, let’s assume that the size of the image is 4 pixels x 4 pixels and the
“frame” is exactly 1 pixel wide. The bitwise mask of the image above looks like this:

Despite mentioning above that all my graphical assets were converted to Sprite objects for easier
manipulation, PyGame still loads them as PNGs before this casting occurs, therefore, I can create masks
for every graphical object.

The main idea behind a Mask Based Collision Algorithm is straightforward: if, at any time, at least two
1s from different masks overlap, a collision occurred. Such algorithm follows an a posteriori
approach, since the collision is signaled only after it happened

Why a Mask Based Collision Algorithm?

WITHOUT MASKS WITH MASKS

 35

The diagram above depicts the difference between using mask based and non mask based collision detection
algorithms. An alternative approach to the mask based collision algorithm, an approach I have implemented before
switching to masks, is to have all the Sprite objects inside rectangles. Collision would then be signaled if two of
these rectangles would intersect, as it can be seen on the left hand side of the diagram above. Despite this is a
possible approach to tackle collisions, it is not quite accurate, especially if the shape of the objects within the
rectangles are irregular.
Using a mask based approach, the algorithm would signal the same scenario as before as no collision.
This would be the case because even though the bitwise matrixes of the two PNGs would intersect, no 1s
would overlap.

FSM BASED AI ALGORITHM:

 36

A finite state machine, or FSM for short, is an abstract model of a system made of a number (finite) of
states. At any given time, the system can find itself in one and only one state, thus, for the system to
perform various actions, the machine has to transition to another state. [23] FSMs are primarily used to
organise the execution flow of a system, therefore being appropriate to implement AI in video games.
Any FSM can be defined as a graph: the nodes are states and the edges are transitions. Thus, the brain of
an enemy can be modeled as a FSM with states representing actions the NPC can perform, such as
Move, Fire, Dodge or being Dead. All transitions are labeled with events that, if happened, the system
changes from one state to another.
My game follows this approach and the enemy space ships perform actions based on certain events:
player’s actions or position at any given point in time.
Enemy AI:

In the gaming world, artificial intelligence (AI) is used to simulate humanlike intelligence in non playing
character. The reason behind this is for the NPCs to behave accordingly within the environment
constraints. From the early 1970s, when a number of games that featured enemies were released,
including Pong, and later Space Invaders, people realised gaming needs to move forward from the
competition between two players, thus, the idea of AI opponents was starting to become more and more
popular. [21]

From simple AI move patterns, game developers introduced, in the early 1990s, the idea of using a finite
state machine (FSM) that simulates the behaviour of an NPC [22]. I have chosen to implement a similar
 37

AI architecture in my game as well.

Enemy AI Shooting:

Space Defenders has two types of enemies: enemies that shoot straight regardless the position of the
player and enemies that sense the position of the player spaceship and shoot in its direction. This
subchapter will cover the latter.
PyGame treats movement as continuously blitting on the screen the same object at different coordinates
at every CPU clock tick, thus, the bullets make no exception. For PyGame to redraw PNGs at every
clock tick, it needs to know each new pair of coordinates and, compared to bullets being shot straight,
shooting diagonally requires advanced mathematical computations.
Enemy AI Moving :
Following an a posteriori approach to handle collisions, it would have been impossible for the enemy
space ships to avoid collision with the player’s bullets. Therefore, to implement an algorithm that would
signal the NPCs when to dodge, I am using an a priori approach.

At every CPU clock tick, the NPCs analyse the environment for player’s bullets and the enemy space ships will
dodge bullets if one of the following two scenarios: the distance between the player’s bullet and an enemy spaceship
is less or equal to d or, considering the trajectory of the both player’s bullet and the enemy spaceship, they will
intersect in the near future. In either of the two scenarios, the enemy spaceship, taking into account its position, will
dodge the bullet by moving either up or down without leaving the screen
 38

As mentioned before, PyGame needs a set of pair of coordinates to know where to draw the bullet that
has been shot diagonally. In order for the enemy bullet to go exactly where the

player is, it has to follow an imaginary line that connects both the player and the enemy spaceships,
therefore, a set of points that reside on this line has to be generated.
In order to retrieve such set, we first need to create this line. It is a well known fact that two points in
space create a line and since we have two such points, point A(x1, y1) and B(x2, y2), where x1, x2, y1,
y2 are coordinates, as seen in the diagram above, these points being the rightmost point of the player
spaceship and the leftmost point of the enemy spaceship, respectively. Once we have established we
have two points in space, the equation of line d is:

Y −Y 1 X −X 1
=
Y 2−Y 1 X 2− X 1

The equation of line d reads as follows: a new point P(x, y), where x and y verify the equation above, reside on line
d. Having known that the bullet is shot by the enemy spaceship, we already know that point B(x2, y2) resides on line
d and the question remains on how to generate a large enough set of points that reside d so the bullet would give the
feeling of moving smoothly. To achieve that, I am incrementing x2 by 1 pixel, which, let’s assume, results in x3, at
every CPU clock tick and using the following equation to find the corresponding y3:

( Y 2−Y 1 ) . ( X 3−X 1 )
Y 3= +Y 1
X 2− X 1

I keep generating these (xn, yn) pairs until either the bullet leaves the screen or hits the player spaceship. Having
computed a set of points that reside on line d, the bullet goes diagonally, but still needs to be tilted by an angle T, so
shooting into the player’s direction would look more naturally. In order to do this, we need to find the radians value
of the angle T.
Keeping in mind the diagram above, we need to find the following: the distance between the player and
the NPC, which is the length d as well as the length of d’.

d′ = y2 − y1
 39

2 2
d=√ ( x 2−x 1 ) + ( y 2− y 1 )

With d and d’ calculated, we can compute the sin of T, which can further be used to find the value of T in degrees
(let’s call this value valT). With this value, we can calculate the number of radians of T (let’s call this value radT),
which can be used to tilt the bullet into the direction of the player.

valT = arcsin(sin(T ))

It is well known that 180 degrees is 2π radians. So, if we know valT, we can easily calculate radT as
follows.

2 π . valT
radT= radT
360

Doing these graphical transformations, shooting diagonally looks like the right hand side of the diagram below.
 40

FLOW CHART FOR ENEMY:

KEY BOARD FUNCTIONS:

The main objective in our implementation of the Space Invaders game is to eliminate all aliens in each level. This
Implementation of Space Invaders has four levels of an ever increasing amount of aliens. The last level is then
looped when completed so the player may compete for the high score. The player has to fire his gun in order to kill
the aliens as they move ever closer to the player, simultaneously as the player has to evade their incoming shots. As
the number of aliens begins to dwindle, they increase in speed and thus the difficulty. To the players assistance there
are a couple of covers that can absorb the incoming shots. But as the covers are hit, they systematically get damaged
and ultimately destroyed. At the start of the game the player is given two lives, which means that the player can get
hit twice before losing the game. For each alien the player manages to kill, he will receive score. Sometimes, at
random, a special boss alien will appear in the top of the screen and if the player manages to hit it the player will be
awarded additional score. Before the FPGA is configured with the game, a PS/2 style keyboard should be connected
 41

to the USB port and a PModAmp1 expansion module should be connected to the JA(0-3) ports on the FPGA. After
the FPGA is configured with the game, the player can control it.using the keyboard controls as seen in Table 2. The
player may also utilize the hardware reset on the FPGA

ACTION KEY
MOVE LEFT LEFT
ARROW

MOVE RIGHT
RIGHT ARROW

MOVEFRO UP ARROW
NT

MOVE DOWN
BACK ARROW
PLAYER SIDE FUNCTION:
SHOOT SPACE
The first object designed was the EXIT ESC Player, which will be controlled by the
user inside the game.
 42

Assets:
The following component is more or less self explanatory, assets of the game being in one of the two
categories: audio or graphical assets. Regardless the category, all the assets that have been used in this
project are open source. Examples of graphical assets are the image used for the player spaceship or the
background image of the game, while an example of audio asset is the sound that is played when the
player spaceships shoots or when an enemy is destroyed.

Game State

Probably the most critical feature of the game, the game state is considered to be a variable between 0 and 50, 0
signaling the game just started, while 50 representing the death of the player spaceship. The said variable is what
drives the algorithm that decides whether or not and what powerup to throw to the player (more on powerups later in
the report) when an enemy spaceship is destroyed. The state of the game is strongly related to how many lives left a
player has (from a maximum of three) and what the current score of the player is. An algorithm will take the two as
inputs and will constantly compute, at every CPU clock tick, the variable that represents the state of the game. One
can argue this constantly calculated variable represents the heart/core of the game engine.
 43

DIAGRAM:

ENTITY DIAGRAM:
 44

CLASS DIAGRAM:
45
 46

SEQUENCE DIAGRAM:
 47

ACTIVITY DIAGRAM:
 48

OBJECT DIAGRAM:
 49

TEST CASE METHOD:

Apart from correctness, for a piece of software to truly behaves the way it should, testing is required as
well. Since testing is designed to provide an objective view of the quality of software, I strongly believe
the job of testing should be out of the hands of the developers. Representing the third year project, I
believe that the best way to test Space Defenders was a variation of User Acceptance Testing (UAT)
[33]. Despite UAT being the last phase of testing before a release, I consider no developer wants to see
their code fail under Unit or Integration Testing, UAT is the solely way of actually testing such project.
In order to achieve this, I needed users to play the game and log the bugs they find so I asked my
girlfriend to play this role. As the game progressed she would play and try break it so I would be aware
of existing bugs that needed immediate fixing. Also, after every release of the game, she would make
sure the new feature don’t affect the old ones, taking the exact steps she did to break it before. Having
another person, another developer, test my code for bugs made me aware of many issues with the game,
some of which, perhaps, would have still be there as we speak.

Apart from UAT, I did other types of testing on my own, one of them being Integration Testing [34].
Following an iterative integration approach, after each component was implemented separately, it would
be tested against other interacting components to make sure there are no new defects. Progressively
throughout the project, if new components caused others to break, they would have been reviewed and
tested again until there were no failures.
If during the course of the project I did Integration and User Acceptance Testing, I have allocated a
couple of weeks before the deadline purely for endtoend testing. Having finished the game and noted
down every bug I encountered in the past few months, I tried to recreate the same scenarios that led me
to those bugs to check if any system is still failing. Without

much surprise I managed to find failures that I could fix within the time frame allocated for the project.

Testing has been ongoing

throughout development and a
 50

number of important observations

have been made.
In particular users initially found it
difficult to distinguish between
different sounds and from where
they
were coming. However, with a little
practice they soon became able to
locate and shoot the enemy ships.
The
graphical interface proved a useful
training mechanism even for non-
sighted users since with the help of
a
sighted friend they were able to gain
an understanding of where the
sounds were coming from and what
they
represented.
 51

Other results were also gleaned

about the type of sounds and
general game play that were most
effective,
for example:
• Sounds with a smooth varying
pitch were very difficult to locate. It
gave the impression that these
sounds were moving when they were
in fact not.
• Sounds that changed could be
located as long as the change was
quite harsh. A helicopter’s propellers
or some other sort of machine were
easy to locate whereas a sound like
siren was not.
• With more than two sounds the
quieter or less distinguishable
 52

sounds became masked and were

not
easy to hear until objects making the
louder sounds were destroyed.
• Two or more sounds which were
the same or very similar were also
difficult to locate, although not
impossible.
• Too many sources of sound were
found to be detrimental to the game.
Originally every time a players
score increased or their life-span
decreased the information was
communicated audibly to the player.
This proved to mask out the ship
sounds and disadvantage the player.
This feature was therefore
 53

subsequently changed to the score

being read out on demand via a
control key and only automatically
when a players life was becoming
dangerously low.
• There was a very steep initial
learning curve particular for sighted
people trying the play the game on
audio alone, as the task is quite
peculiar to a lot of sighted people
who rely mainly on images to locate
items.
• The game became rapidly more
challenging as ships flew with
circular motions in addition to
straight
lines. Further challenges were
provided, by having ships flying in
both directions over the user and
 54

approaching from both sides

simultaneously.
• The game is playable using only
two speakers although it is obviously
better with four speakers. If
only two speakers are available it is
best to use headphones instead.
• Changing the height of the object
has proved very difficult to use with
a 4-speaker set-up. The
difference in sound is very small and
so is currently not used. Further
testing is required, possibly
within a CAVE environment, to make
full use of this feature.
• The positioning of the speakers
was found to be essential for
maximum efficiency and enjoyment
of
 55

the game. The speakers should be

positioned at approximately head
height with the player an equal
distance from each speaker.
The initial version of the game has
been completed, is comparatively
portable across a wide range of PC
specifications and is very robust.
Preliminary feedback has been
exceedingly encouraging.
Unfortunately, the
more extensive and formal
evaluations with blind/visually
impaired teenagers originally
scheduled for
March/April 2000 have had to
delayed slightly due to the logistics
of term-times and exam timetables.
 56

However, these will shortly be

underway and all feedback obtained
will impact on the continued
development of the game.

Testing has been ongoing

throughout development and a
number of important observations
have been made.
In particular users initially found it
difficult to distinguish between
different sounds and from where
they
were coming. However, with a little
practice they soon became able to
locate and shoot the enemy ships.
The
graphical interface proved a useful
training mechanism even for non-
 57

sighted users since with the help of

a
sighted friend they were able to gain
an understanding of where the
sounds were coming from and what
they
represented.
Other results were also gleaned
about the type of sounds and
general game play that were most
effective,
for example:
• Sounds with a smooth varying
pitch were very difficult to locate. It
gave the impression that these
sounds were moving when they were
in fact not.
 58

• Sounds that changed could be

located as long as the change was
quite harsh. A helicopter’s propellers
or some other sort of machine were
easy to locate whereas a sound like
siren was not.
• With more than two sounds the
quieter or less distinguishable
sounds became masked and were
not
easy to hear until objects making the
louder sounds were destroyed.
• Two or more sounds which were
the same or very similar were also
difficult to locate, although not
impossible.
• Too many sources of sound were
found to be detrimental to the game.
Originally every time a players
 59

score increased or their life-span

decreased the information was
communicated audibly to the player.
This proved to mask out the ship
sounds and disadvantage the player.
This feature was therefore
subsequently changed to the score
being read out on demand via a
control key and only automatically
when a players life was becoming
dangerously low.
• There was a very steep initial
learning curve particular for sighted
people trying the play the game on
audio alone, as the task is quite
peculiar to a lot of sighted people
who rely mainly on images to locate
items.
 60

• The game became rapidly more

challenging as ships flew with
circular motions in addition to
straight
lines. Further challenges were
provided, by having ships flying in
both directions over the user and
approaching from both sides
simultaneously.
• The game is playable using only
two speakers although it is obviously
better with four speakers. If
only two speakers are available it is
best to use headphones instead.
• Changing the height of the object
has proved very difficult to use with
a 4-speaker set-up. The
 61

difference in sound is very small and

so is currently not used. Further
testing is required, possibly
within a CAVE environment, to make
full use of this feature.
• The positioning of the speakers
was found to be essential for
maximum efficiency and enjoyment
of
the game. The speakers should be
positioned at approximately head
height with the player an equal
distance from each speaker.
The initial version of the game has
been completed, is comparatively
portable across a wide range of PC
specifications and is very robust.
Preliminary feedback has been
 62

exceedingly encouraging.
Unfortunately, the
more extensive and formal
evaluations with blind/visually
impaired teenagers originally
scheduled for
March/April 2000 have had to
delayed slightly due to the logistics
of term-times and exam timetables.
However, these will shortly be
underway and all feedback obtained
will impact on the continued
development of the game
 63

WHITE BOX TESTING:

White-box testing is a verification technique software engineers can use to examine if their
code works as expected. In this chapter, we will explain the following:
 a method for writing a set of white-box test cases that exercise the paths in the code
 the use of equivalence partitioning and boundary value analysis to manage the
Number oftest cases that need to be written and to examine error-prone/extreme “corner” test cases
 how to measure how thoroughly the test cases exercise the code

White-box testing is testing that takes into account the internal mechanism of a system or
component (IEEE, 1990). White-box testing is also known as structural testing, clear box
testing, and glass box testing (Beizer, 1995). The connotations of “clear box” and “glass
box” appropriately indicate that you have full visibility of the internal workings of the
software product, specifically, the logic and the structure of the code.
Using the white-box testing techniques outlined in this chapter, a software engineer can
design test cases that
 exercise independent paths within a module or unit;
 exercise logical decisions on both their true and false side;
 execute loops at their boundaries and within their operational bounds;
 exercise internal data structures to ensure their validity .
BASIS PATH TESTING:

Basis path testing (McCabe, 1976) is a means for ensuring that all independent paths through
a code module have been tested. An independent path is any path through the code that
introduces at least one new set of processing statements or a new condition. (Pressman, 2001)
Basis path testing provides a minimum, lower-bound on the number of test cases that need to
be written.
To introduce the basis path method, we will draw a flowgraph of a code segment. Once you
understand basis path testing, it may not be necessary to draw the flowgraph – though you
may always find a quick sketch helpful. If you test incrementally and the modules you test
are small enough, you can consider having a mental picture of the flow graph. As you will
see, the main objective is to identify the number of decision points in the module and you
may be able to identify them without a written representation.
 64

OUTPUT SCREEN:
65
66
 67

LIMITATION:

While VR provides the ability to immerse a player's senses like never before, it also creates some new, unique
problems that must be addressed by responsible VR developers.

Locomotion sickness:

VR headsets are meant to make you feel like you're somewhere else, and it only makes sense that you'd want to be
able to explore that somewhere. Unfortunately, common game mechanics such as traditional joystick locomotion
are problematic for VR. Our inner ears are accustomed to sensing inertia while we move from place to place, so if
you were to push a joystick forward to walk in VR, your body would get confused when it sensed that you're still
stationary.

Typically when there's a mismatch between what we're seeing and what we're feeling, our bodies assume that a
nefarious poison or illness is at work, and they prepare to rid the body of the culprit; that's the motion sickness
you feel when reading in a car, standing on a boat, and yes, moving in VR. This doesn't mean that we have to
prevent users from moving in VR, we just might want to be more clever about it---more on that later.

Common limitations of VR games:

While VR provides the ability to immerse a player's senses like never before, it also creates some new, unique
problems that must be addressed by responsible VR developers.

Locomotion sickness:

VR headsets are meant to make you feel like you're somewhere else, and it only makes sense that you'd want to be
able to explore that somewhere. Unfortunately, common game mechanics such as traditional joystick locomotion
are problematic for VR. Our inner ears are accustomed to sensing inertia while we move from place to place, so if
you were to push a joystick forward to walk in VR, your body would get confused when it sensed that you're still
stationary.

Typically when there's a mismatch between what we're seeing and what we're feeling, our bodies assume that a
nefarious poison or illness is at work, and they prepare to rid the body of the culprit; that's the motion sickness
 68

you feel when reading in a car, standing on a boat, and yes, moving in VR. This doesn't mean that we have to
prevent users from moving in VR, we just might want to be more clever about it---more on that later .

Lack of real-world vision:

One of the potentially clumsiest aspects of VR is getting your hands where they need to be without being able to see them.

Whether you're using a gamepad, keyboard, or motion controller, you'll probably need to use your hands to interact with VR,

which you can't see with an HMD sitting over your eyes. It's good practice to centralize input around resting positions (that is, the

buttons naturally closest to your thumbs on a gamepad or the home row of a computer keyboard), but shy away from anything that

requires complex precise input, such as writing sentences on a keyboard or hitting button combos on a controller.

Some VR headsets, such as the HTC Vive, have a forward-facing camera (sometimes called a passthrough camera) that users can

choose to view in VR, enabling basic interaction with the real world without taking the headset off. The Oculus Rift doesn't

feature a built-in camera, but you could still display the feed from an external camera on any surface in (we'll play with that idea

later in the book).

Unnatural head movements:

You may not have thought about it before, but looking around in a traditional  first-person shooter (FPS) is quite
different than looking around using your head. The right analog stick is typically used to direct the camera and
make adjustments as necessary, but in VR, players actually move their head instead of using their thumb to move
their virtual head. Don't expect players in VR to be able to make the same snappy pivots and 180-degree turns on
a dime that are simple in a regular console game .

Vergence-accommodation conflict:

Another limitation to consider when designing your VR game is what's called a vergence-accommodation
conflict. This is basically what happens when the distance to the point of your focus, or vergence (that is, an
object in VR), is notably different than your focal distance, or where your eyes are actually focusing on the screen
in front of you.
 69

This image from a research article in the Journal of Vision demonstrates the conflicting difference:

Forcing the user to focus on objects that are too close or too far away for extended periods of time can cause
symptoms of eye fatigue, including sore eyes or headaches. Therefore, it's important to consider placement of the
pieces of your game that will draw a lot of attention.

CONCLUSION :

The main objective of this project was to design and develop a 2D shoot ’em up video-game and learn the maximum
amount of things possible while doing it. For this purpose, the different graphic elements of the video-game were
designed, allowing me to learn how to efficiently use the Inkscape software in order to achieve the desired results. In
this manner, each design has been done faster and better than the previous one. Similarly, I have learned how to
design simple albeit necessary sound effects for the game by combining audio software, more specifically Audacity
and Bfxr. Regarding the video-game itself, all of the game logic and the objects were designed and subsequently
implemented using Unity and its 2D toolset. As a result, the video-game is composed of one single perfectly
playable level which includes many different objects and obstacles to overcome. This is the part that I have most
enjoyed, because I really like programming and designing game logic. Additionally, coming up with different
Enemies and Boss logic provided me a fun challenge, and gave me the opportunity to learn many different issues
about game design and development. Furthermore, I discovered many interesting things about developing a game
for people with colorblindness disability, and found out a way for them to thoughtfully enjoy the game. On the other
hand, the obtained video-game can be played at different operating systems and it has a very good performance even
on dated computers. Moreover, it can be easily ported to any of the current generation game consoles. Finally, I
would like to highlight that most of the things done throughout this project were learned while developing it, as I
had very little experience in the whole process of video-game development. I had made very simple video games
without using full fledged game engines, and never before had I designed any sound effect or graphic material for
them.

FEAUTER DEVELOPMENT:

If Space Defender was not a third year project and if the development was not constrained by a tight
deadline, the player would have benefited from a number of extra features such as local and remote
multiplayer, boss fights and a mobile version. Even though Local Multiplayer was part of initial plan, it
was not delivered due to the meticulousity other tasks were undertaken.
 70

To implement a Local Multiplayer functionality, I would have used the Xbox 360 Controllers API so
two non NPC spaceships could be controlled by two players in the same time, on the same screen. Such
functionality would also require two different score as well as lives systems and an altered powerup
module that would compute the game state based not on one but two different gameplays. While a local
multiplayer feature would not require much more than a Python implementation of the Xbox API and a
couple of controllers, a remote multiplayer functionality would involve a server to which clients are able
to connect in order to send and get data from. Apart from local and remote multiplayer, if Space
Defender were to be a real life project, the players would have enjoyed from a variety of level styles as
well as boss fights to pass certain levels. To take the game one step further, it could have even be
deployed on mobile. Despite Python is not the first programming language that comes to
mind when one thinks of writing applications for either Android or iOS devices, tools such as Kivy can
convert the Python code and create applications from its logic, following a Write Once, this project, I
have done all the necessary to achieve the main targets by designing and developing my own video-
game. However, I already have a few ideas to extend this work and improve the video-game:
• Create a complete projectile system with many types of projectiles and ways to shoot them,
using different approaches.
• Create more levels with different game-play options, each of them with new enemies and
bosses.
• Create a power-up system that allows players to get new powers, such as super-speed.
• Make a different kind of reward logic, like including a multiplier to calculate the final
score.
• Make different types of ships that can be used as the Player.
• Create a module for Unity to accept graphics in SVG format.
• Create a similar video-game but using other game engines, such as Unreal Engine in 3D

Challenges:

The past few months spent working on Space Defenders proved to be more challenging than
expected. From tackling graphics in project for the first time to detecting and handling
collision, the third year project carried me on a journey that strengthen my knowledge both as
a student as well as a future developer. During the course of developing this project, the first
 71

and probably the most critical task that challenged me was my knowledge of Python.
Regardless the modules I took in the first and second year of university, Distributed Systems
and Distributed Computing, respectively, the level of Python required for this project was
way above what I was asked to use Python for in the previous years. Therefore, only after I
intensively taught Python myself I could actually make visible progress on Space Defenders.
While working on my third year project, I encountered other two big challenges: the
mathematical graphical manipulations and developing a sensible powerup module.

Firstly, let’s consider the powerup module. The overall challenge with this was how and
when to generate powerups and for this I have altered and used various algorithms, from
continuously computing the game state to implementing my version of a probability
distribution algorithm. Looking back to the past few months, I can argue that the challenge
regarding the powerup module was not as much a technical one as it was a logical one on
how to design this module to be as sensible as possible. Thus, designing and building on top
of an average proved to be both a solid technical as well as thinking exercise.

Secondly, a number of mathematical transformations were required for the enemy spaceships
to be able to shoot diagonally. These were covered in detail in Chapter 2, however, the
 72

challenge in achieving these came from the fact that the last time I have used such equations
was when I was in high school, over 4 years ago.

REFERENCES AND BIBLIOGRAPHY

 BOOKS USED:
 Python programming version 3.7.4(Dr.A.Kannan,Dr.L.Sai Ramesh)
 Software Engineering (Shalini Puri)
 Software Engineering (Pressman)

 SITES USED :
 www.scribd.com
 www.wikipedia.org
 https://www.flaticon.com/search?word=space+invaders
 https://www.freepik.com/search?dates=any&format=search&page=1&query=space
%20background&sort=popular
 https://www.rapidtables.com/convert/color/hex-to-rgb.html
 https://github.com/
 https://www.mathplanet.com/education/algebra-2/conic-sections/distance-between-two-points-
and-the-midpoint

 Pygame. URL: http://www.pygame.org/hifi.html. Last accessed: 04/04/2016

 The ESA 2015 Report. URL: http://www.theesa.com/wp-
content/uploads/2015/04/ESAEssentialFacts2015.pdf. Last accessed:
05/04/2016
 Video Games Industry sales. URL: http://vgsales.wikia.com/wiki/Video_game_industry.
Last accessed: 05/04/2016
 73

 Video Game Industry sales in Japan. URL:

http://vgsales.wikia.com/wiki/Video_games_in_Japan. Last
accessed: 05/04/2016

 Unity3D. URL: http://blogs.unity3d.com/2014/09/03/documentationunity-

scriptinglanguagesandyou/. Last accessed: 28/04/2016
 Quora. URL: https://www.quora.com/Whatprogramminglanguageisthemost-
usedtomakevideogame sWhichisthebest. Last accessed: 28/04/2016
 EvE Online. URL: http://evesearch.com/thread/1262481/page/all. Last
accessed: 28/04/2016
 Pyglet. URL: https://bitbucket.org/pyglet/pyglet/wiki/Documentation. Last
accessed: 28/04/2016
 Pyganim. URL: http://inventwithpython.com/pyganim/. Last accessed: 28/04/2016
 Street Directory. URL:
http://www.streetdirectory.com/travel_guide/141178/gaming/the_very_first_vi
deo_game_eve r_released_and_its_not_pong.html. Last accessed: 28/04/2016
 Juul, J. The Open and the Closed: Games of Emerges and Games of
Progression. Copenhagen. p328.
 Arie Kaufman (1993). Rendering, Visualization and Rasterization Hardware.
Springer Science & Business Media. pp. 86–87.
 Gaming Wikia. URL: http://gaming.wikia.com/wiki/Topdown_view. Last
accessed: 28/04/2016
 Now Gamer. URL: http://www.nowgamer.com/ageofempires2-
remasteredinhdedition/. Last accessed: 28/04/2016
 Softpedia. URL: http://news.softpedia.com/news/blizzardismakinghdremakes-
forstarcraftwarcraftiiiand diabloii495743.shtml. Last accessed: 28/04/2016
 Ausretrogamer. URL:http://www.ausretrogamer.com/thehistoryofmariospowerups.
Last accessed: 28/04/2016
 What is a Probability Distribution?. URL: http://stattrek.com/probability-
distributions/probabilitydistribution.aspx. Last accessed: 28/04/2016
74