MSC DISSERTATION TRAVIS HANDFIELD - University of … · · 2014-10-29... a personal research into the ... and conducive environment for learning. Learners can benefit ... ICT is

MSC DISSERTATION TRAVIS HANDFIELD

The candidate confirms that the work submitted is their own and the appropriate credit has been given where reference has been made to the work of others. I understand that failure to attribute material which is obtained from another source may be considered as plagiarism.

(Signature of student) __________________________

Dissertation Topic: Supporting the Learning of Mathematics with an

Information and Communication Technology Based Multi-player Educational Game

Travis Handfield

Master’s of Science Degree: Computing and Management

Session 2009/10 University of Leeds, United Kingdom


i

ABSTRACT

This dissertation was a fulfilment of a Master’s of Science degree at the University of

Leeds. Within this dissertation, the main goal was to produce a prototype application of Wacky

Game, which is a multiplayer game – the brainchild of a group of teachers from St. Aidan’s High

School in Harrogate United Kingdom. The game, which was first developed in its paper-based

form, now in accordance with gathered user requirements from both teachers and students who

wished that that game they enjoyed immensely be designed and implemented on the computer.

This was the overarching aim of this dissertation.

Given the task to be completed, a literature review of aspects of the game that were not

included in the user requirements but are necessary to ensure that user requirements are fulfilled

was conducted. Included in the literature review were good game design principles, issues of

educational computer games in the classroom, an evaluation of existing games similar to Wacky

Game, and how the role of the teacher and student will change with a new implementation.

Furthermore, an appropriate development methodology was researched and an iterative

approach to development was chosen along with Python and PyGame as the programming tools.

The methodology was closely followed to ensure that the components highlighted were

developed independently and later merged as one functioning unit. Within the main sections of

the report, which are Chapters 6 and 7, it can be confirmed that the methodology was followed,

multiple iterations were implemented for various components of the game, and evaluated

against aims and objectives, minimum aims and requirements, and methodology. In Chapter 6,

future enhancements to the work done for this dissertation were discussed as time constraints

prohibited such enhancements from being designed, implemented and tested.

In Chapter 7, an overall evaluation provided substantiated evidence for claims made that

the objectives and aims of the project were successfully achieved in compliance with user

requirements and minimum deliverables specified. In addition, evaluators were incorporated to

provide feedback on the various iterations developed and later modified with evaluators’

feedback taken into consideration. The conclusion highlighted lessons learnt and what the

future holds for further development of Wacky Game.

KEYWORDS: Information and Communication Technology (ICT); Educational Games; Game Design

Principles; Multiplayer Games; Python; Client Server Architecture; Mathematics Teaching.


ii

ACKNOWLEDGEMENTS

At this time, I wish to thank all those persons and parties involved in helping me complete this

project.

- I forever reverence the presence of God for his blessings, strength and protection

- My family both here in the UK and back home in the Turks and Caicos Islands

- My supervisor, Dr. Mark Walkley and assessor, Dr. Matthew Hubbard

- Professor John Monaghan, University of Leeds

- The cooperating teachers from St. Aidan’s High School, UK

- My fellow MSc colleagues

- My corporate colleagues

- My church family at Leeds Wesleyan Holiness Church

DEDICATION

I sincerely wish to dedicate this project as part of my Master’s of Science degree to my

grandmother – my mother, Mrs. Maud Handfield. I express my deepest gratitude to her for

financing my master’s studies. Much love and thanks to her.

Your grandson,

Your son,

Travis Handfield


iii

TABLE OF CONTENTS

Abstract ……………………………………………………………………………………………….. i

Acknowledgements …………………………………………………………………………………...ii

Dedication …………………………………………………………………………….………………..ii

Table of Contents ……………………………………………………………………………………..iii

List of Figures ………………………………………………………………………………………....vi

Chapter 1: Introduction

Section 1.1: Purpose …………………………………………………………………………..1

Section 1.2: Overview & Introduction ………………………………………………………..1

Chapter 2: Literature Review

Section 2.1: Understanding Information and Communication Technology ………………...2

Section 2.2: Teaching Mathematics ………………………………………………………….3

Section 2.3: Educational Games in Classrooms ……………………………………………..4

o Mathematical Educational Games in the Classroom ………………………………..7

Section 2.4: Evaluation of Existing Educational Maths Games ……………………………..9

Chapter 3: Game Design Principles

Section 3.1: Good Game Design Principles ………………………………………………….14

Section 3.2: GamePlay & Role of Player …………………………………………………….16

Chapter 4: “Wacky Game” – The Game

Section 4.1: Game Description ………………………………………………………………18

Section 4.2: Game Objectives – Learning Objectives ………………………………………18

Section 4.3: Structure & Rules of Game …………………………………………………….19

Section 4.4: Functional Requirements ……………………………………………………...20

Section 4.5: Non-functional Requirements …………………………………………………21

Section 4.6: The Role of the Teacher ……………………………………………………….22

Section 4.7: Computer based vs. Board based implementation …………………………..23

Chapter 5: Methodology

Section 5.1: The Problem ……………………………………………………………………24

Section 5.2: Design Methodology ………………………………………………………….24

Section 5.3: Development Language & Tools ………………………………………………25

o OOP ………………………………………………………………………………….27

o Python & PyGame …………………………………………………………………..28

o GUI …………………………………………………………………………………..28


iv

Section 5.4: Game Architecture …………………………………………………………….29

Section 5.5: Project Management ………………………………………………………….31

o Overall Aims & Objectives ………………………………………………………….31

o Minimum Aims & Requirements …………………………………………………...31

o Deliverables ………………………………………………………………………….31

o Project Schedules:

Proposed …………………………………………………………………...32

Actual ……………………………………………………………………….33

Section 5.6: Evaluation Criteria ……………………………………………………………..33

Chapter 6: Design & Implementation

Section 6.1.1: Design Approach ……………………………………………………………..35

Section 6.1.2: Web-based Application ………………………………………………………35

Section 6.1.3: Virtual Learning Environment ………………………………………………..35

Section 6.1.4: Client-Server Architecture …………………………………………………...36

Section 6.2.1: Iteration 1.1 ……………………………………………………………………37

Section 6.2.2: Iteration 1.2 …………………………………………………………………..38

Section 6.2.3: Iteration 2 …………………………………………………………………….39



Section 6.3: Future Enhancements …………………………………………………………43

Chapter 7: Evaluation

Section 7.1: Evaluation Overview …………………………………………………………...45

Section 7.2: Evaluation Participants & Tools ………………………………………………45

Section 7.3: Evaluation against Aims & Objectives ………………………………………..46

Section 7.4: Evaluation against Minimum Aims & Requirements …………………………46

Section 7.5: Evaluation against Methodology ……………………………………………..47

Section 7.6: Other Evaluation Criteria ……………………………………………………..48

Chapter 8: Conclusion ...……………………………………………………………………………..49

Bibliography ………………………………………………………………………………………….51

Appendices

A: Project Reflection ………………………………………………………………………...53

B: Interim Report Feedback Form ………………………………………………………….56

C: Project Management

o Meeting Log ………………………………………………………………………...57


v

o Summary of Progress …………………………………………………………….…57

o Milestones …………………………………………………………………………..58

D: Evaluation Form Templates

o Existing Games ……………………………………………………………………...59

o Administrator & Database …………………………………………………………60

o Sample Game Logic ………………………………………………………………...61

E: MSc Research Project Proposal ………………………………………………………….62


vi

LIST OF FIGURES

Figure 1: Framework of Flow in Computer-Mediated Environments ………………………………14

Figure 2: Three Channel Model of Flow ……………………………………………………………...16

Figure 3: Sample Wacky Game Card ………………………………………………………………....19

Figure 4: An Illustration of Evolutionary Development …………………………………………….25

Figure 5: Game Setup & Configuration ……………………………………………………………...29

Figure 6: Project Schedule (Proposed) ……………………………………………………………...32

Figure 7: Project Schedule (Actual) ………………………………………………………………….33

Figure 8: Facebook Logo …………………………………………………………………………….35

Figure 9: Fronter Logo ……………………………………………………………………………….35

Figure 10: Client-Server Architecture ………………………………………………………………..36

Figure 11: Administrator Interface with ‘Add Question’ Popup Box ……………………………….37

Figure 12: Sample Game Logic ……………………………………………………………………….41

Figure 13: Administrator Adds Question to Database ………………………………………………42

Figure 14: GUI Presentation on Client Machine ……………………………………………………..42

Figure 15: Response from Database via Server ……………………………………………………..42

Figure 16: Game Setup & Configuration (With a New Feature) ……………………………………43


1

CHAPTER 1: OVERVIEW & INTRODUCTION

SECTION 1.1: PURPOSE

The purpose of this dissertation is to fulfil the requirements set forth by the University Of Leeds

School Of Computing for the degree of Master’s of Science in Computing and Management.

SECTION 1.2: OVERVIEW & INTRODUCTION

With this dissertation, a personal research into the application of information and communication

technology (ICT) to teaching mathematics will be discussed. To gain a better understanding of

the extent of the topic chosen, a literature review was conducted which seeks to answer the

following questions (among others):

1. What is information and communication technology?

2. Why choose mathematics as the subject for an ICT-based application?

3. What research supports the use of educational games in classrooms?

4. What are teachers’ and students’ perspective on educational games?

In subsequent chapters, the proposed game will be described, a design methodology will be

outlined, and each design and implementation stage of the game will be broken down and

evaluated against a set criteria composed of user requirements.


2

CHAPTER 2: LITERATURE REVIEW

SECTION 2.1: UNDERSTANDING INFORMATION AND COMMUNICATION TECHNOLOGY

Information and Communication Technology (ICT) has a very broad definition and

different implications depending on the industry in question. Generally speaking, ICT describes

the ability/capability of users to interact with the world around them. This interaction is in

response to a rapidly changing world that is being transformed by technological advances. The

inherent benefit of using ICT tools is that users are now able to “find, explore, analyse, exchange

and present information responsibly without discrimination” ("ICT", 2010). In the field of

education, ICT is used to familiarise students with the usage and workings of computers, and its

related social and ethical issues. Because of the improvements in technology, students are now

able to engage in learning activities that can provide stimuli for all their senses – active learning.

Ultimately, ICT can and has improved the quality of learning, teaching, and management of

schools as they strive to raise educational standards.

The capabilities that ICT can offer an educational system of any particular country are

immense. As a result, in their 2009 report, the Office for Standards in Education, Children's

Services and Skills (Ofsted) published some key findings about ICT and its implications in the

educational system here in the UK. They found that:

Pupils were being taught how to use particular software rather than essential skills

needed to acquire genuinely generic and transferable skills.

There was an overemphasis on the usage of Standard Office Productivity packages.

School administrators were making positive strides to ensure that their schools were

adequately equipped with resources to improve their ICT infrastructures.

Not only were students learning to use ICT tools, so were the teachers and other

support staffs.

ICT had significantly improved learning and raised standards across curriculum.

ICT was contributing positively to the personal development and future economic

well-being of students. ICT tools made teaching more interactive, engaging, and

provided a more streamline way to monitor, assess and provide feedback to

students.

Lastly, the use of ICT provided students with learning difficulties and disabilities the

opportunity to learn on a more levelled playing field.


3

(Ofsted, 2009)

Still some may question: why should a school invest its ‘limited’ resources to keep abreast

on developing technologies? What justification can be provided for integrating ICT into the

classroom? It should be noted that ICT is not a replacement of traditional direct teacher-student

interaction, but rather a support to “attain objectives that have not been attained efficiently

otherwise: expanding access, promoting equality, improving the internal efficiency of

educational systems, enchancing the quality of education and preparing new and old generations

for a technology-driven market place” (Haddad and Jurich, 2002, p.47, found in (Jhurree, 2005).

The list below summarises some of the benefits of ICT integration in education:

1. ICT can provided a more engaging, interactive, and conducive environment for learning.

Learners can benefit pedagogically from technology in the classroom.

2. ICT is a powerful tool to assist teachers in their instruction – to motivate both teacher and

students.

3. ICT can provide modernise and streamline administrative tools.

4. ICT can provide an opportunity to make education more inclusive – integrating all

students regardless of their backgrounds and abilities.

5. ICT is a medium by which students and teachers can collaborate both within one school

environment or globally

6. Students will be better equiped to cope with the technological changes in the world

around them if they are introduced at an early age. Technology in education can prepare

students now to efficiently integrate into the world of work and competition tomorrow.

(Jhurree, 2005)

Recognising that there are benefits of ICT tools in an educational setting, exploring how

to tailor the softwares, tools and resources to subject specific activities – such as mathematics

will be discussed.

SECTION 2.2: TEACHING MATHEMATICS

Speaking from personal experience, learning and understanding mathematics can be very

difficult, especially if you are not mathematically inclined. Maths is a facts based subject that is

manipulated by procedures and processes. Far too often students throw their hands in the air in

exasperation saying that maths is too difficult. Students may consider maths to be difficult for


4

several reasons, such as: (a) it is difficult to learn, (b) it has no apparent relevance to their lives, or

(c) it is just plain boring. Sedighian & Sedighian (1996) suggested that to be able to teach

students the intricacies of maths, educators must first identify the needs of the student. To be

able to better understand maths, students must be placed in a situation where knowing maths

will help them succeed, or as Sedighian & Sedighian stated, where “[knowing maths] becomes a

tangible need” (1996).

To understand the complex ways in which students comprehend a subject that relies

heavily on sequential knowledge such as maths, researchers suggest that artefacts are needed to

extend students’ ability to perform tasks. These artefacts according to Norman (1993, found in

(Sedighian & Sedighian, 1996) will improve students’ cognitive capabilities. Because meta-

cognition is a by-product of motivation, it is considered another facet of learning. Norman

continues that with such advances in technology as computer games, teaching students with

such tools can provide an educational and conducive environment where students can learn

maths in a meaningful and useful way. In addition, at the same time, “provide researchers with a

rich medium from which to gain new insights into the psychology of learning mathematics in

children” (Norman, 1993, found in (Sedighian & Sedighian, 1996). Furthermore, Gee (2007)

suggests that “learning should be both frustrating and life enhancing”. In that regards, he is

stating that for a subject like maths, which some students may consider difficult, the key is to find

ways to make learning the difficult subject area life enhancing. This will then motivate students

to want to keep moving forward and not just rely on learning subjects that may be simple and

easy.

SECTION 2.3.1: EDUCATIONAL GAMES IN CLASSROOMS

When the concept was first introduced to the educational system more than 20 years

ago, educators were dumbfounded. They wondered: how in the world would students be able to

learn anything in school if they were allowed to play games in the classrooms? Students were

already preoccupied with gaming at home and now these technical geniuses wanted to bring

gaming into the classrooms – a foreign domain. To educators at the time, such technology was

viewed as evil and counterproductive to students’ education. It would have been intrusive; taking

the responsibility of teaching away from teachers and putting it into the hands of the students

themselves via gaming applications.


5

It is now common practise to focus on how best to get students involved in the activities

of the class and part of that focus is appealing to their entertainment factor. Gee (2003, found in

(Carbonaro, et al., 2008) suggests that educational computer game are an effective medium by

which students’ literacy can improve - not only their literacy, but also students’ problem solving

skills, motivation to learn and build student to student social networks that enhances and

supports cooperative and collaborative learning. Gee when went on to say that educators of

today are now transforming their classrooms from one of observational activities to one of

interactive/performance activities.

Now that those technical geniuses had the green light from educators to introduce

technology into the classroom, they needed a starting point to be able to focus their design for

these new breed of games. Developers now needed to look at what made non-educational

games appeal to the growing children gamers across the globe. What motivated students to

want to play non-educational games? Could those motivational factors be easily transferable to

educational games? Educators agreed with this approach to a new game design because

motivation plays a critical role in any learning activity – regardless of the age group. As human

beings we only engage in activities if we know that we would be getting something back in

return; be it tangible or intangible. Norman (1993, found in (Sedighian & Sedighian, 1996) pointed

out that although we know about motivation, there is “little scientific knowledge about the

factors that underlie motivation, enjoyment, and satisfaction.” Regardless, it can be proven that

educational games can enhance a student’s motivation to learn difficult subjects such as maths.

Educators have come a long way in the last 20 years or so. They have come to terms with

the fact that computer games are an integral part of their students’ lives, and it is only wise to

learn how to integrate ICT into the classroom as well – the place where children spend a great

deal of their day (Provenzo, 1991). So why use games in the classroom? Research can be provided

that supports the use of computer games in the classroom as an educational tool that motivates

students, helps them comprehend difficult concepts and theories, put some power of learning

into their own hands, and gives overlooked students an opportunity to be more involved in class

(Kaplan, 1970). Learning with the aid of technology via video games makes sense in this day in

age with a “modern high-tech global world”, which fits with students’ daily routine rather than

“the theories and practises of learning that they sometimes see in [their] schools” (Gee, 2007).


6

Although using computer games in the classroom has its benefits, its presence does not

make the teacher obsolete. The teacher’s responsibilities are even greater in that they have to

monitor how students interact with the piece of software. Teachers are to provide constructive

feedback to students, outline how the lessons maps with particular gaming scenarios (Reed,

Drijvers, & Kirschner, 2010; Mavrou, Lewis, & Graeme, 2010). As most games can only teach

processes and not facts, teachers must not rely solely on the games to do the teaching. The

playing of the game will only be considered an effective learning tool if it is coupled with

classroom activities such as worksheets, class discussions, etc. “Without these additional

supporting activities, despite enthusiastic game playing, the learning increase [would be]

modest” (Conati & Klawe, 2000).

As a standalone software, educational games provide no added advantage to students if

they are not able to connect what they are being taught in class with what they are playing in the

game. Students must be directed by their teachers who will be responsible for laying out

roadmaps and guides for progress monitoring, as the game itself cannot provide adequate

learning and instructional guidance. Conati & Klawe (2000) presented several reasons for this

inadequacy in games:

1. Some well-designed games do not have the necessary mechanism built into the software

to provide students with a means for reflective thinking on what they are learning from

the software or on their problem solving strategies.

2. Because of high levels of engagement, some students may consider the game as a

distraction from reflective thinking or that some of the activities in the game are non-

educational ones.

3. Categorised weak learners, who do not possess the necessary meta-cognitive skill sets

necessary for reflective thinking, might not be able to learn from the gaming activities.

These skill sets include: “self-monitoring, self-questioning, and self-explanation”

4. Depending on the nature of the game, it would take longer to achieve the same level of

success compared to other more guided and focused educational activities.

Let us now take a closer look at how mathematics education can be improved with the

integration of educational games in the classroom.


7

SECTION 2.3.2: MATHEMATICAL EDUCATIONAL GAMES IN THE CLASSROOM

Developing an educational maths game is a task in of itself. To be able to design a

computer based maths game, the focus of the entire process should be on ensuring that maths is

used as an integral part of the design and not an “incidental diversion from the main activity”

(Sedighian & Sedighian, 1996). This step is critical in that it forces students to learn and develop

their mathematical abilities to be able to learn from the game and at the same time enjoy playing

it. One of the most difficult task designers will have to overcome is finding ways to motivate

students to want to learn mathematical content embedded in computer games (Sedighian &

Sedighian, 1996).

To illustrate if there are any benefits to introducing educational maths games into the

classroom, Professors Kamran and Andishe Sedighian (1996) from the University of British

Columbia conducted a research. Over a period which spanned two years, the research was

conducted in four stages and involved 50 grades 6 and 7 students collectively. The stages were:

1. A commercial educational game was installed in the classroom. The class was

observed weekly, students kept journals and held class discussions.

2. After a few months, a specialised game was developed for the grade 6 students

based on the maths topic, geometry. It was important to note that the game

designers sought students’ requirements such as fun and engaging.

3. The specialised game was introduced to the class which was observed weekly.

Students were told to keep journals of their computer activities.

4. Lastly, after about 6 months, students were given a test on concepts covered by the

game.

At the end of the research, the following were invaluable outcomes:

(a) When computer games were brought into the learning environment and tied in with

subjects such as maths, it brought greater relevance to the subject for the children.

Students were able to understand why learning maths would be meaningful and useful to

them.

(b) The specialised game was designed in such a way that it provided students with a goal to

achieve then move on to a more challenging level. The achievement of goals motivated

students to work harder on more difficult questions.


8

(c) Students were able to monitor their success by their progression up the levels of

difficulty. What's more, the better performance on the paper test covering various maths

concepts at the end of the research proved that students did in fact learn more about

maths.

(d) Students love challenges, knowing that they got scores, better grades, and being

competitive with themselves were all positive aspects of using computer games.

(e) Cognitive Artefact – in a typical classroom, students had to sit at their desk and listen to

the teacher talk endlessly about concepts. The game provided more interactivity among

students. They were able to communicate and learn from each other with the aid of the

teacher. A more cooperative learning environment was created.

(f) Students were able to associate maths with some pleasant memory that would remain

with them even after the class. E.g. beating a previous high personal score is a very

memorable moment. If it was a maths score, it became an associated memory.

(g) Students who were classified as weak achievers in maths, similar to their counterparts,

were dedicated to working with the computer game. They played tirelessly. It was

observed that some students, who rarely showed initiative in learning maths before,

would take problems home and solve them before class the next day. The computer

game created an environment in which students were excited about learning the subject

and was willing to spend the extra time and effort to learn the concepts.

(h) It was discovered that the first game, had minimal sensory stimuli. The game did not

appeal to students at all. It was developed in black and white, the use of animations was

simple, and so were the sound effects. The other game that was developed with the

input of the students proved to be a hit. Students wanted sensory stimuli to make the

game more fun to play thereby learning maths and enjoying the experience at the same

time. It was a vital ingredient to the success of the research.

Although it is fun to make computer games appeal to students and engage them, it is

important not to forget that it is also the aim of the game to educate the students as well. The

point of making educational computer games is to make it educational. Fisch (2005) stated that

game developers must ensure that adequate time is invested in covering the educational content

that should be integrated into the structure of the game. Students must be educated by the

game and be able to give and get feedback from their gaming activities. Fisch (2005) presented

game requirements/goals for an educational game developer.

Goal 1: Match each educational topic and concept with their most appropriate media.


9

Goal 2: Design the animations, etc. around the educational content.

Goal 3: Integrate real life application into the educational content.

Goal 4: Build in feedback and hints to support and scaffold students into challenging

content.

To ensure that the game that is developed is effective in its purpose of supporting in class

activities, developers must build in mechanisms within the game that is able to monitor students’

activities. These monitoring mechanisms must be inconspicuous in that they do not obstruct the

students’ interaction with the game, or the fun element of playing the game, and the ownership

of learning. The delivery of the game must be “delivered within the spirit of the game” and to

better serve the teacher in their responsibilities to the student. However, Gee (2007) cautions

that “activities that are entertaining but that themselves do not involve [any] learning [benefits]

are just meaningless play”, this caution is also applicable to educational games. The game should

be able to provide feedback about the student’s emotions, progress and have measures in place

to combat negative emotional states and lack of significant progress (Conati & Klawe, 2000;

Reed, Drijvers, & Kirschner, 2010).

SECTION 2.4: EVALUATION OF EXISTING EDUCATIONAL MATHS GAMES

To understand what might be required of the proposed game for this MSc project, an

evaluation of other educational maths games was helpful in determining what teachers and

students might expect a computer based game to deliver. With the introduction of the internet

and the vast unlimited resources it contains, game developers are opting to develop games that

are suited for web-based implementation. It is considered much cheaper than software

development/production. Furthermore, the internet can provide students with access to more

information they may need to play the games. The internet has also enabled teachers to be able

to track students’ progress with embedded progress reports that can be sent electronically for

teachers’ access.

Overall Evaluation of Games:

The games evaluated below were all developed using a different technology than the one

used for developing Wacky Game – this project. The web-based games were developed using

Flash in conjunction with PhP, whereas Python and PyGame will be used for developing Wacky

Game. Python was selected as the technology for development because it is the language with

which I have experience using. There are Python based web games, however they are not as


10

complex and exciting (in terms of aesthetic appeal) as the games discussed below. These games

below were evaluated based on good design principles (discussed in Chapter 3) and with

reference to student specified functional and non-functional requirements for Wacky Game

(Chapter 4). In addition to personal evaluation, experiences were incorporated from two

students who were asked to play the games (1 primary, 1 secondary). These two students were

asked to play the game and to provide their first impressions of the game based on what they

believe classifies a game as good, educational and entertaining. A copy of the evaluation form

can be found in Appendix D.

Using the internet as a new communication technology tool will provide users with a

much richer experience when using interactive games and other educational resources that are

accessible to them. When internet based resources are properly designed with user’s

requirements in mind, it can be more responsive to the users’ needs and can monitor their

information use. For students who are now able to play games on the internet, they can create

and share information of their own with others, such as “participation in news groups or

chatroom, or sending post.…... [I]nternet email and chatroom functions allows users to act as

equal partners in the communication process, while the web facilitates access to texts, graphics,

animations and audios” which enables the users to enjoy a more richer internet experience

(Chou, 2003). Therefore, the games below are all internet-based and each contains a feature that

is required for the game that will be design for this MSc dissertation.

Game 1 – Airport Arithmetic from Primary Games.co.uk

http://www.primarygames.co.uk/pg6/airport/airport.swf

This game is separated into three distinct sections classified as terminals at the airport.

Each terminal has 10 flights due for departure. All flights are in a queue. The flight that is up for

departure has the problem displayed on its side (fuselage). The next flight in the queue has the

problem on the sidelines. When that plane is up, the problem moves unto the aircraft. This

feature gives the player an advantage of anticipating the answer by being able to do quick

calculations – the current one and the one to follow. The player has to select which of the

operations will solve the question presented on the aircraft. At the end, the player is given a

success rate. How long the planes were delayed depends on how long the user took to answer

the question, and the number of incorrect responses. This game was developed for a web-based

implementation using Adobe Flash technology, which is becoming a new norm for web-based

http://www.primarygames.co.uk/pg6/airport/airport.swf


11

animations. More information about flash technology will be discussed in Chapter 5 –

Methodology.

User Response & Wacky Game Consideration: Both students enjoyed playing the game. As they

completed more questions, they were able to take advantage of the strategy of answering the

current question and the next one to follow. The more questions they were able to answer gave

them a better score – evidence of improvement. Each student was able to select the terminal or

operation they needed help in, which was a good design strategy. They mentioned that if they

were weak on all operations, they would not like a mixed operations game. This will be a

consideration for Wacky Game as the administrator/teacher will be able to select the type of

questions for each game session. In addition, because users were able to see the next question

while completing the current one, they developed their speed in problem solving. In Wacky

Game, it would be a good addition to have the next category for the next round visible

somewhere on the screen. Displaying the overall performance for each round will give Wacky

Game players an idea of how they performed in comparison to other players.

Game 2 – Arcademic Skill Builders: Space Race (multiplayer game)

http://arcademicskillbuilders.com/games/space-race/space-race.html

This game was chosen because it was multiplayer, similar to what Wacky Game is

described to be. Other customised advantage of this game was that players could be creative

with the name they use while playing. The game starts when a player either joins an existing

game created by another player, or creates a game of their own and other players join. This was a

good feature. If used in a classrooms setting, students can share with each other what their

name is and other students could locate them. To be more customised, the user can select to

make their game private and only give their pass code for their game to other users. This feature

allows the user to control who can see their active game and who can join in. Another feature

that users are wanting in Wacky Game is the ability to customise their racers. In this game,

players can change the colour of their racers. It is important to note that this game has a

feedback component. If a question is missed, at the end of the game, the player is able to see the

question again and the corresponding answer. They will also be able to see how they ranked in

relation to the other players of the game. This game was developed for a web-based

implementation using Adobe Flash technology.

http://arcademicskillbuilders.com/games/space-race/space-race.html


12

User Response & Wacky Game Consideration: Wacky Game will be developed on a server that will

control the number of players to accept before a new game starts. In future, development of

Wacky Game, players will be able to customise their player’s name – at present they are given

generic names. The evaluating students commented that they did not like having to wait for

people to connect or join their game. However, they enjoyed the level of customisation, which

compensated for the waiting time. They were able to customise their racers while other players

joined the game. Both students enjoyed the fact that they were competing against live players

and not just a computer, and the possibility of reviewing missed questions at the end of a game.

This game was the most engaging of all the game discussed mainly because of its realistic sound

effects such as zooming through space and its animated/creative way of presenting the

questions for the players to answer – while in-flight.

Game 3 – Maths Mayhem (multiplayer game)

http://members.learningplanet.com/act/mayhem/mayhem.asp?type=add

This game also allowed the players some level of customisation. It was multiplayer.

Identified by their unique names, to begin a new game, a timer set at 60 seconds allowed other

users to be involved in the game. A great advantage of this game was that it promoted a big, live,

midday maths competition. At 12 p.m. every day, it was advertised as a worldwide competition.

All four operations are used in this game as well which gives students the ability to work on the

operations that they are weak in. The engagement factor for this game was the timed

competition. Students had to try to out-compete other live internet players in a 60-second game

– how many questions can you answer correctly in 1 minute? At the end of the 60 seconds, a

progress report was displayed. This game was developed for a web-based implementation using

Adobe Flash technology.

User Response & Wacky Game Consideration: For Wacky Game, the administrator/teacher will be

able to communicate with other teachers –either in the same school or across schools to set up

gaming sessions at a particular time and date. This will enable Wacky Game, which is a team

game, to function as an inter-high school or inter-primary school competition. The games will be

timed and explained fully in Chapter 4. The students who played the game were impressed by

how many questions their competitors were able to answer in 1 minute versus theirs’. A live

scorecard showed who had answered the most questions throughout the entire minute game

which was both motivating and intimidating to the evaluating players.

http://members.learningplanet.com/act/mayhem/mayhem.asp?type=add


13

Game 4: Maths Olympics

http://www.mathplayground.com/olympic_math1.html

What was good about this game was its simplicity. It was a single player game and the

only action that happened was when the player chose an answer. If the answer were correct, the

runner would clear the hurdle and if incorrect would kick over the hurdle. As the runner

animates, a new question appeared waiting for the player to solve it. The downside of the game

was that it lacked engagement. This game was developed for a web-based implementation using

Adobe Flash technology.

User Response & Wacky Game Consideration: The two students who were asked to play this game

commented that it was not very engaging, and not as colourful or complex as the previous

games that were also developed using the same technology. However, an aspect of this game

that will be useful in Wacky Game was the setup of the database that fed the questions unto the

screen. The database instantaneously validated the answer provided by the player and then the

runner performed an action. This game also did not have any sound effects beyond the player

running on the track. Maths Olympics, was not a very fun game to play according to the students.

http://www.mathplayground.com/olympic_math1.html


14

CHAPTER 3: GAME DESIGN PRINCIPLES

SECTION 3.1: GOOD GAME DESIGN PRINCIPLES

There exist no perfect game model that has successfully implemented educational theory

and good game design. Although many came close, there is still an imbalance in how much

educational content is needed while not boring the users. Although there is not a perfect model

to follow, researchers have developed an experimental model that integrates the importance of

feedback to the player, clearly outlined goals, learning objectives and challenges. The model is

wrapped around experiential learning theory, flow theory and game design theory. Figure 1

shows the model.

Figure 1: Framework of flow in computer-mediated environments (found in (Kiili, 2005) :

A challenge of designing a computer-mediated game is that of engaging the

student. With so many things they are now able to do via the internet/information technology,

turning their attention to educational content can prove to be rather difficult. That is why the

model is very useful to developers (such as me) in regards to how to make engaging the student

a priority in game design. Kiili (2005) stated, “games should provide the possibility for reflectively

exploring phenomena, testing hypotheses and constructing objects…. [not just for] practicing of

factual information”. Given this objective of games (either paper based or computer based), it is

a reason why Wacky Game, a mathematical based game, should be computerised, and focused

Flow Antecedents

Person Challenge

Challenge

Playfulness Clear goals Control Feedback Focused attention Skill

Skill Control Feedback Playfulness Usability

Task

Artefact

Flow Experience

Time distortion Loss of self

consciousness Merging of

actions and awareness

Concentration Telepresence Sense of control

Flow Consequences Increased

learning Changes of

attitudes Exploratory

behaviour Perceived

behavioural control


15

not only on drilling students with mathematical content, but also helping them grow in the

subject area.

The flow and game-based learning model presented above was developed by

Csikszentmihalyi (1991, found in (Kiili, 2005)).The flow refers to the player’s total emersion or

engagement in the activity of the game. During this state, the player’s attention is on the game

and nothing else around them. Because the flow state has positive effects on learning, it must be

critical in the game design of learning material. The flow experience is dependent on the player,

the activities of the game and the tools that the player is required to use to be able to complete

the activities of the game. As identify in the model above, the antecedents, experience and

consequences of the flow are defined as follows:

The activities that make up the antecedents must be achieved before the player is able to

experience flow. The experience of flow is achieved when the player is fully absorbed or engaged

in the activities of the game. Over a period of time, the consequences or benefits of experiencing

flow are obtainable, of which increased learning and exploratory behaviour is critical for this

particular game (Wacky Game). As part of the learning objectives of Wacky Game, the teachers

want students to be able to learn from their interactions with the PCs and their fellow

classmates. Being able to achieve the tasks of the game, the teachers hope that students’

confidence in maths will increase and they would develop the urge and desire to tackle more

challenging maths tasks, thus exhibiting exploratory behaviours.

Kiili (2005) went on to say that, “a user’s prior knowledge and experience affect how

they experience and perceive the game world. If the system can offer the learner such challenges

that are in correspondence with his or her skills, the possibility of experiencing flow is higher”.

Figure 2 below shows the relationship between skills and challenges.

Flow Antecedents

Flow Experience

Flow Consequences


16

As advised by the designers of the model above, in the development of Wacky Game, the

various challenges that the player encounters must be closely matched with their skill level. That

is why the administrator of the game will be able to select which questions are appropriate for

each of the three levels available. If this step is ignored, when a question is presented that is

much too difficult for the player, they may feel anxiety. Similarly, if the question presented is too

easy for the player, they will feel bored and uninterested in the game. Therefore, to keep the

flow experience at its optimum, developers and designers alike must ensure that challenges are

closely matched to the player’s ability, and increased incrementally as the player’s skill improved.

SECTION 3.2: GAMEPLAY & ROLE OF PLAYER

The final discussion on good game design explores the role of the player. Gameplay

refers to the linked challenges that the player has to meet in a gaming environment, which

should be designed in such a way that the player is kept motivated and engaged during each

challenge. These actions involved in gameplay must be incorporated into educational game

design along with the educational contents, and goals of the game as to create a relevant

balance to achieve, quantitative and qualitative progress for the player (Kiili, 2005; Reed, Drijvers,

& Kirschner, 2010; Mavrou, Lewis, & Graeme, 2010).

One of the educational objectives of Wacky Game is to teach students to think more

strategically – become problem solvers. Problem solving (2010) can be defined as a unique ability

to achieve a goal that is not immediately attainable. Students are expected to develop their

Figure 2: Three channel model of flow (Adopted from Csikszentmihalyi 1975, found in (Kiili, 2005))

High Low

Low

High

Boredom

Anxiety

“Flow”


17

analytical thinking, reasoning and logical skills when they engage themselves in this game. The

nature of the game requires students to work collaboratively, decide how they wish to proceed

for each round of questions while thinking about how their competitors might compete (Reed,

Drijvers, & Kirschner, 2010). Wacky Game will provide an adequate framework for offering

problem-solving tasks to students. In the capacity of problem solvers, teachers anticipate that

students will engage in discovery learning by which they develop new ways of solving maths

problems, instead of memorising what others have done. While engaged in the gaming world via

the computer, “students will be becoming active participants in the learning process and their

motivation may shift from extrinsic to intrinsic rewards” (Kiili, 2005; Mavrou, Lewis, & Graeme,

2010).

“If a game has good principles of learning built into its design – that is, if it facilitates learning in

good ways – then it gets played well. If it is otherwise a good game, other games can [be] built

on these principles and perhaps do them one step better” (Gee, 2007). Hopefully, by the end of

this project, if Wacky Game is not fully completed, it is hoped that the game can be further

developed following the plans discussed in subsequent chapters.


18

CHAPTER 4: ‘WACKY GAME’ – THE GAME

SECTION 4.1: GAME DESCRIPTION

Wacky Game is a multiplayer computer based game that is geared towards teaching and

assisting students in developing better strategic approaches to solving mathematical

computations. Initially, the maths content will be based on the four operations: addition,

subtraction, multiplication and division. As the game develops in its complexities, more content

will be added to include such topics as trigonometry, algebra and fractions. Regardless of the

type of questions asked, the general idea is similar. During each round of questions the player

must select a card (from a random pile) to play that might best beat their competitors’ – Top

Card wins.

SECTION 4.2: GAME OBJECTIVES – LEARNING OBJECTIVES

The teachers who originally came up with the idea for Wacky Game provided the

following learning objectives and expectations they have for the game.

Encourage students of mixed abilities to work together to solve maths problems.

Teach students to develop problem solving, strategic and analytical abilities.

Teach students that they can learn from a competitive and exciting classroom activity.

Help students put maths into a real life context.

Encourage students to engage in exploratory learning beyond the maths classroom.

Teach students to work in groups, share responsibilities, and develop interpersonal skills:

o Students should be able to work collaboratively and cooperatively

o Students will learn by interacting with others, and independently towards a goal

o Students will understand the importance of group and individual accountability

o Everyone succeeds when the group succeeds

Lastly, see students across age groups compete against each other (example: primary vs.

secondary students).


19

SECTION 4.3: STRUCTURE & RULES OF GAME

1. Teams are formed with 3 or 4 students; a maximum of 8 teams

2. A deck of 48 cards is presented each with 4 questions on it. The cards are temporarily

displayed with its details and then flip over for selection. See Figure 3 below for sample card:

Figure 3: Sample Wacky Game Card

3. Each team selects 6 cards. When a card is selected, it becomes unavailable to other players

4. The category for the round is announced (e.g. Highest Number wins round)

5. The teams have 1.5 minutes to answer the question associated with that particular round

6. Each team has to answer the question for that particular round on ALL 6 cards selected

7. Each team must select a card that they would like to play that is their ‘best’ choice for the

round.

a. If the highest number is the category for that round, then of the 6 cards, the card

with the highest number (answer) for that round of questions must be selected to

play

8. Each team will submit a card number and the answer they have for the question

9. The answer is validated by the game and scored

10. The scores for each round are represented by the cars going around a track. The ranking for

each team is a car.

a. All cars will blast from the starting line together; however, the team with the highest

number will finish first, followed by the team with the second highest, and so on.

b. Those teams with the wrong answer would crash on the speedway

11. New Round begins, with a new category, but each team will still have their initial 6 cards

12. After the fourth round, the final race and ultimate showdown will be based on the overall

scores for each team.

Lap 1 56 + 107

Lap 2 83 – 27

Lap 3 9 x 3

Lap 4 77 ÷ 7 Card Number

4


20

a. The team with the highest score will finish through the line first, then second, and so

forth.

b. Please note that for each round, a different team can win. The final race is the

accumulative score for all 4 rounds - stating who wins overall out of the 8 teams.

13. After 4 rounds, a new game begins. Each team can how select a new set of 6 cards

SECTION 4.4: FUNCTIONAL REQUIREMENTS

1. The game should be set up as a client-server architecture, so that it can be played in a

computer cluster where one machine acts as the main server for the clients to access within

the lab.

a. This is the best option for a school with network restrictions and other technical

issues (refer to Chapter 6: Design & Implementation).

2. A database is needed to store questions and answers. The database will provide the

questions to be displayed on each card, and used for answer validation against user input.

3. An administrator interface is needed to create and manage the database and its data. The

role of the administrator will be the supervising teacher of the class. The teacher should be

able to feed new questions into the database as he/she sees fit.

4. The question table in the database must be structured in such a way that questions can be

filtered out based the level desired by the player.

a. As new questions are added, the administrator can specify the level of each question

stored.

5. Once a particular team has selected a card, it becomes unavailable to the other teams

playing. Therefore, the choices of cards is first come first serve.

6. Based on the category for each round, the game must be able to determine which team has

the best result, second best result and so forth. For example (highest answer wins):

Team one – 19

Team two – 45

Team three – 50

Team four – 39

a. The game should give team 3 the best score for that round since 50 is the highest

number, and give team 2 the next best score for the answer of 45, and so forth.


21

i. The category for each round is randomised, so the code for determining

scoring should match the category.

ii. Examples of categories are: highest number, lowest number, closest to 100,

or 50, etc.

7. The administrator should be able to add more categories if necessary.

8. There should be an adjustable timer for answering the questions.

a. Example: 2 minutes for easy questions and 1.5 or 1 minute for harder questions or

flipped, 1 minute for easy questions and 2 minutes for harder questions.

9. The timer should be adjusted for the level of competitiveness.

10. Teams should be able to customise their names associated with their racers.

11. Each team should be allowed to submit one answer for each round

12. The program should keep track of the highest scores for each game (a game has 4 rounds).

13. The administrator should be able to clear the highest score ranking

14. Players should be able to:

a. Access the game or connect to a new game

b. Select the number of teams

c. Play game, quit game, resume/pause game

d. Turn sound on/off

SECTION 4.5: NON-FUNCTIONAL REQUIREMENTS

These non-functional requirements were gathered responses from students about the

paper-based implementation of the game in the classroom, which complies with considerations

outlined in the literature review (Chapter 2) and good game design principles (Chapter 3).

Students expect the game:

To be fun, exciting and engaging

Require strategic thinking, and teamwork

Fair in its scoring

Well organised

Challenging

Help them build their maths skills

Competitive

To have some level of chance and skills development

To be better in a computer mediated environment


22

To improve their confidence in their abilities

Have good team working to make new friends

Encourage teams to be heterogeneous

Colourful

Have realistic sounds – example for the car speeding around the track, or the clock

ticking

Have some interface resembling a formula one racing environment to add to the

excitement

Have a randomised bonus round

Should be easy to connect too

Provide historical records of team scores, etc.

Should be able to validate answers very quickly so that the race round is almost

instantaneous after each team has submitted their answer – maintain the HYPE.

SECTION 4.6: THE ROLE OF THE TEACHER

As suggested in Chapter 2, it is important that the teacher is not left out of the learning

activity. Not just because the game is going to be computerised is by no means an excuse for

teachers to distance themselves from the classroom. The teacher’s role in Wacky Game is rather

simple. The main duty they will have to perform is to coordinate gaming activities across

classrooms (or schools). Ensure that students organise themselves into heterogeneous groups –

of mixed abilities and outline the purpose of the game, the learning objectives, and highlight the

importance of teamwork (responsibility and accountability to the group). The teacher must

monitor how students interact with the new piece of software and be available to provide

feedback to struggling students (or teams) (Mavrou, Lewis, & Graeme, 2010). After each gaming

session, students should collectively discuss what their experiences were and be duly noted so

that improvements can be made for future gaming sessions. Gaming time must also be

accompanied by reflective thinking, in class non-computer based activities, and independent

studies.

Referring to the architecture of the game, the teacher will also be known as the

Administrator. The role of the administrator will be discussed in Chapter 5. To summarise, the

administrator is responsible for inputting questions into the database that stores all information

relating to the game. For each question, the teacher/administrator must specify which level the


23

question is (either primary or secondary), the relevant points for the question and the answer of

the question which the database will validate against when the game is being played. The

administrator will also be responsible for knowing on which machine the server is located so that

clients or players are able to connect without failure.

SECTION 4.7: COMPUTER BASED VS. BOARD BASED IMPLEMENTATION

There are not many aspects of the game that must be altered significantly so that it can

be implemented from a board based to a computer-based version. As explained in section 4.6,

the role of the teacher will changed from active involvement in the game to overseer/manager of

the game. In the previous version of the game, the teacher could only validate one answer at a

time from each team. Queuing up for this critical step took time away from playing the game. The

computer-based version with the aid of the server will be able to validate answers

instantaneously and simultaneously by the database from each team.

The role of the students will be modified. Wherein the paper based version each student

in a team was given the shared responsibility of answering the questions on their card for each

round, in the computer-based game, one student will be the designated ‘inputer’. This student

will have to key in the answers supplied by their team members into the game to play for each

round. This ‘inputer’ role can be rotated for each round, or established however the team

members deem appropriate. The teacher can supervise this team building process to encourage

each student to be accountable to the overall success of the team. It would be best practice to

have this role rotated so that each student can have an opportunity to learn from the activities

involved in the game – the computations.

The last major distinction between the two versions of Wacky Game is that the potential

now exist to have students from various schools compete. The teachers who came up with the

idea for the game thought it would be great if students from the primary school could compete

against students from secondary school – if a handicap feature is build into the game. With the

board version of the game, it could only be played by a single classroom of students. A handicap

feature that the teacher envisioned is one of the considerations for future development of the

game and not accounted for in the current design of the game.


24

CHAPTER 5: METHODOLOGY

SECTION 5.1: THE PROBLEM

The aim of this project is to take an existing educational board-played mathematical game

and implement a multi-player, networked, information and communication technology based

version for both primary and secondary students. The problem to be solved is: how can the game

be implemented so that its characteristics enjoyed when playing the board version be transferred

to a computer based version?

SECTION 5.2: DESIGN METHODOLOGY

The nature of this project is best suited for a form of evolutionary development whereby

the activities involved in the project (specification, development, testing and validation) are

rapidly developed from abstract user requirements. This is then further refined with more user

input which will ultimately result in a system that meets the user’s needs (Sommerville, 2004). As

the users themselves are not sure what the complete formal specification of the game is, it is

best to develop something agreed upon as a starting point. Upon completion of an initial design,

future iterations will include agreed upon modifications.

Both methods of evolutionary development will be utilised in this project. These methods

as outlined in Sommerville, 2004 are:

1. Exploratory development – whereby developers work closely with end users to gather

user requirements. Then development of the parts of the system that are understood by

both developer and users progresses until a final system is delivered. The system evolves

in complexity as new features are added upon request from the users.

2. Throwaway prototyping – this method also involves working with end users to

understand the requirements of the system, and then developing a better requirements

definition for the system. The prototyping step is mainly for experimenting on parts of

the system when user requirements are poorly understood.

Figure 4 incorporates both development methods discussed.


25

Figure 4: An illustration of evolutionary development:

http://www.pro-technix.com/services/software/images/evolvem.gif

There are three main criticisms of this approach to system development. However, these

criticisms are not enough to refute the need of such a development method for the purpose of

this project. The disadvantages are:

1. End users are uncomfortable with the level of uncertainty involved in the process as there

is no clear outline of the process to be undertaken. Deliverables for example, cannot have

a set delivery date because of the exploratory development of the system. In addition,

the level of documentation associated with the waterfall method, for example, is almost

non-existent with this approach. It is not cost effective to produce documentation for

each version of the system developed.

2. The system may be poorly structured. This can be due to the continuous changes made to

the software used in the system’s development. Sommerville states that ‘incorporating

software changes become increasingly difficult and costly” (2004).

3. Special tools and techniques may be required which can be due to the exploratory

approach to system development.

SECTION 5.3: DEVELOPMENT LANGUAGE & TOOLS

Development Approach:

To be able to design and implement the requirements of the game, the development approach

must:

a) Have the capability of creating graphical user interfaces

b) Support a client-server architecture

c) Allow a flexible and configurable game logic to be implemented

d) Be portable and platform independent


26

Having the requirements of the development method, possible candidates were investigated to

determine its suitability for this project. The candidates were classified with the form of

implementation being the heavily weighted criteria. There is a clear distinction that can be drawn

immediately between a standalone programmed application and a web-based implementation.

Either choice leads to a different set of possible candidate languages.

Selection and Justification:

The Python programming language was chosen as the method of development for the following

reasons:

1. Python is the programming language I am most familiar with

2. Python is relatively easy to use and understand

3. Python supports object oriented programming

4. Python supports the design of a networked client server system

5. Python supports the design of a graphical user interface

6. Python supports the development of games through its PyGame package

Object Oriented Implementation Candidates Web-based Implementation Candidates

Python (2010): Description: is a high-level programming language that is known for its ease of use. For novices to the world of programming, Python provides a very good foundation for its almost natural language (or syntax). Its library for modules is very comprehensive. Can be used? Python is used mainly for object-oriented programming because of its ease of use. As a scripting language – a language that allows control of one or more software applications, Python has the ability to be used for various applications and is an open source language.

Adobe Flash (2010): Description: is fast becoming the way in which information is displayed on web pages. Flash can be used for animation, video, and interactivity – giving the webpage more character, more entertaining to visit and prevent page clutter. Its most recent usages are for Rich Internet Applications (RIAs). Flash has the ability to capture raw input from users via any connected input device. Can be used? Flash supports web-based implementation although it does have some capabilities for working with object-oriented design with its built-in ActionScript technology.

Java (2010): Description: is an evolution of C and C++ programming languages – but is much simpler and easy to understand and work with. Java is considered a compiled, general purpose, class-based and object oriented language. Can be used? Java can be used because it is an object oriented programming language and is dominantly used for a variety of web and standalone applications.

Java Script (2010): Description: is a scripting language that is used when working with client-server architecture – mostly on the client side. The script provides an enhanced webpage presentation or any other user interface. Can be used? Although it can be used in a variety of context on WebPages, its capabilities outside that realm are very limited. It is a scripting language that has a prototyping based object oriented component.


27

SECTION 5.3.1: OBJECT ORIENTED PROGRAMMING

With reference to Bruegge & Dutoit 2000, Object Orientated Programming (OOP) is the

ideal design architecture for this project because of the way in which the components of the

game need to be developed. The various objects or user concepts that makes up the game will

have to be decomposed to understand how the pieces fit together to create the game. Each

component of Wacky Game (the database, administrator, server, clients and networking), can be

developed independently and later merged as one functioning unit. An object oriented

programming language has this capability to program each object independently of each other

and can be altered if needed without affecting other objects. Each object or component used in

Wacky Game will be analysed to determine the following:

1. Its functionalities – what is the purpose of the component in the game?

2. Its interactions – how will/should each component interact with another?

3. Its domain – what application or other parts of the game will each component

manipulate?

An advantage of OOP is that individual developers can work on different components and

not be aware of how each component was developed, but only concerned that each component

works with each other. The features of OOP that will be of importance for Wacky Game will be

data abstraction, encapsulation and inheritance. For example, the server needed for Wacky

Game will utilise features needed for the administrator interface. Each individual object or

component will inherit characteristics from each other as both components will have similar

functionalities. During the iteration of each component (as per the methodology selected), when

a new object is added to the program, elements of other existing objects can be inherited which

will make the program easier to modify.

Finally, using Python as the OOP language of choice will make constructing objects that

can be created and modified without affecting other aspects of the Wacky Game program, easier

to structure and organise. Ultimately, as Wacky Game develops into a more complex piece of

software, working with Python will make developing the game more manageable.


28

SECTION 5.3.2: PYTHON & PYGAME

PyGame (2010) is a builtin module in Python that is specifically designed for writing

games. With PyGame, multimedia programs can be developed that can be played on nearly every

platform and operating system. PyGame, like Python is a free software that is simple and easy to

use because it does not require any prior programming skills to be able to use the tools. PyGame

is becoming a very popular preference for game development because its programs are made up

of smaller amounts of code. As with other languages that require many lines of code for a simple

task, it is understandable why those languages are not intuitive when it comes to programming

for novices. PyGame is the tool that will be used to develop the game logic and other

requirements for Wacky Game.

SECTION 5.3.3: TKINTER GUI

Once again, Python has many capabilities that are ideal for the nature of this project. As a

non-functional requirement specified in Chapter 4, a Graphical User Interface (GUI) is needed for

various aspects of this project. A GUI is used to present codes in a way that allows the users to

point and click, and drag and drop – thus making the program more user friendly. Python and

Tkinter are the main tools used for building the GUIs for this project. Although Tkinter is not a

part of Python, both work together beautifully to create dynamic interfaces across operating

platforms. Tkinter (Telles, 2008) was the GUI tool chosen for this project because it is marketed

as a tool for novice programmers with its ease of use. Although Tkinter is not directly related to

Python, both tools are compatible. Tkinter functions, such as a button, when pressed will

execute a command defined in Python code.

Some of the functionalities of Tkinter that will be used are:

a) Layout Manager: This non-visual component arranges things in an input form.

b) Labels: which is any particular text displayed in a window.

c) Buttons: these will allow the user to press a mouse button and a corresponding

action will perform in response.

d) Entry Fields: Allows the user to enter information that is retrieved and stored.


29

SECTION 5.4: GAME ARCHITECTURE

The new game must be networked and multiplayer with components nonexistent in the

board version. The essential components needed for an effective implementation are:

A database where all the game logic will be stored (the questions, scoring, rankings,

graphics, etc.)

An administrator to create and configure the database

A client-server architecture whereby players can access the game to play

A networked link between the clients and server

The key components of the game are: administrator, database, server, and networked clients.

Each of these components will be formally specified, designed bearing in mind user

requirements, and tested and evaluated based on the requirements aforementioned. Each of the

sections identified in Figure 5 will be coded and tested in multiple iterations until it works

properly. Once section A is completed and working properly, only then will section B be focused

on.

Figure 5 below shows the architecture of the game. The iterative stages will be explained

subsequently.

With an iterative approach selected, an iteration of the game will be developed, tested using

the evaluation criteria (see Section 5.6) and delivered to the user to see and provide feedback on.

It should be noted that a single iteration will not have all the final functionalities, but should be

able to perform some of the basic operations that the user requires. The proposed stages of

iteration are as follows:

Figure 5: Game Setup & Configuration

Network

Database

Administrator

Server

Client 1

Client 2

Client 3

A

B


30

1. Setting up the configuration of the game, Section A of Figure 5:

a. Database design using Python

b. Add data to the database pertinent to the functionalities of the game

c. Implement an interface via Python for an Administrator of the game

i. A graphical user interface will be designed so that the administrator can

manipulate the database without knowing underlying Python coding

d. Time frame: 3 weeks

2. Setting up ‘The Game’ , Section B of Figure 5:

This section will be implemented in two stages: first, the server will be coded followed by

the client.

a. Design a server architecture similar to that of the administrator to communicate

with the database (the heart of the game)

b. The game design will involve the use of PyGame – a package of Python Language

c. Test that the server is able to communicate with the database

d. Time frame: 3 weeks

It is assumed the administrator, database and server will be stored on one machine. The clients will run from multiple (n) machines communicating with the machine that stores the server and database.

3. Connecting the Clients, Section B of Figure 5:

a. Design and implement the server – client interface

i. Focused on how the client communicates with the server to play the

game

b. Further development ambitions – design and implement a suitable Graphical User

Interface appropriate for the users and the learning environment

c. Time frame: 5 weeks

4. Connecting Multiple Clients

a. Modify the server to accept a specified number of clients

b. Ensure that each client can communicate with each other

c. Time frame 4 weeks

5. Test sample game logic (communicating with game information from database)

a. Use of Python language

b. Utilisation of other components previously implemented

i. Design and implement the server – game logic

ii. Focused on how the game is to be played on the server

iii. Send messages to clients retrieved from database via server


31

iv. Clients must be able to send a response back to server

v. Database must be able to validate replies from clients

c. Time frame: 3 weeks

SECTION 5.5: PROJECT MANAGEMENT

The overall aim of the project:

The aim of this project is to take an existing educational board-played mathematical game and

implement a multi-player, networked, information and communication technology based version

for both primary and secondary students.

The overall objectives of the project:

Gather user requirements from the teachers who designed the board game

Design and implement a prototype of an ICT application that complies with user

requirements

Research and discuss learning theories and the teaching of mathematics

Research and discuss the implications of educational computer games

Research and discuss teachers’ and students’ perceptions of the use of computer games

in the classroom

Minimum aims and requirements:

1. A formal specification of the game in software engineering terms (and diagrams)

2. A prototype implementation of the game

3. Specification of a suitable user interface

4. Further Requirements/Enhancements: A networked implementation of the multi-player

game; implementation of the interface

Deliverables:

At the end of this dissertation, the following are to be classified as possible deliverables:

1. Interim Report

2. Final Report

3. Prototype application


32

Resources required:

There are no resources required beyond access to the teachers and students involved in the

project.

Project Schedules:

Below is the projected schedule for the successful completion of this dissertation. Meetings logs

with teachers involved in the project are listed below with corresponding meeting agenda can be

found in Appendix C. Please note that any discrepancies between the proposed (Figure 6) and

actual (Figure 7) schedules will be discussed in Chapter 6 – Design and Implementation.

Figure 6: Project Schedule (proposed)

1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4

Background Reading

Gathering User Requirements

Exam Period

Write up Draft Report

-->System Design

-->System Implementation

--> Testing & Feedback

--> System Requirements Evaluation

-->System Design


-->Testing & Feedback


-->System Design




Interim Report

Write up Final Report

Submission

Iterations 1.1 - 1.2

Iteration 2


Travis Handfield - MSc Dissertation Project Schedule (Proposed)

Jan. Aug. Sept.JulyJuneMayAprilMarchFeb.


33

Figure 7: Project Schedule (actual)

SECTION 5.6: EVALUATION CRITERIA

This project will be evaluated both quantitatively and qualitatively. Quantitative

evaluation will involve asking the following questions:

1. Were the project requirements met?

2. Were the formal requirements met?

3. Did the final game adhere to game design principles?

Qualitative requirements may be more difficult to measure than those for quantitative

evaluation, which is due in large part by users’ changing their expectations and requirements.

The following questions will be asked to gather qualitative feedback:

1. Were the users satisfied with the iterative products/software?

2. Did the user provide adequate and constructive feedback?

3. Did the game deliver some of the basic functionalities the users required?

1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4

Background Reading

Gathering User Requirements

Exam Period

Write up Draft Report

-->System Design


--> Testing & Feedback


-->System Design




-->System Design




Interim Report

Write up Final Report

Submission


Iteration 2


Travis Handfield - MSc Dissertation Project Schedule (Actual)

Jan. Feb. March April May June July Aug. Sept.


34

Please note that in Chapter 7: Evaluation, the overall aims and objectives of the project will be

evaluated. Evaluation for each iteration will follow as it is implemented in Chapter 6: Design &

Implementation. Now that the problem has been identified and broken down into manageable

objectives, how to go about solving the problem will begin with a discussion on various methods

that can be employed for developing the solution.


35

Figure 8: Facebook.com http://www.facebook.com

CHAPTER 6: DESIGN & IMPLEMENTATION

SECTION 6.1.1: DESIGN APPROACH

In Chapter 5, the methodology for this project was outlined stating that multiple

iterations were required to develop and implement the components needed. Knowing what

components were needed and how they were to interact with each other played a role in the

implementation option taken. Below are the three options that could have been undertaken for

implementation. Each option was analysed to determine its suitability, user constraints and

reasons for or against implementation.

SECTION 6.1.2: WEB-BASED APPLICATION

This is a possible solution for implementation because applications for social

networking sites are often free of charge, very customisable and widely

accessible. A web-based solution was problematic for three reasons. (1) One of

the schools involved in the game planning (idea) has a limited number of

machines for students to access the internet on. (2) If web based, due to the

two groups of students that the game is targeted for (secondary and

primary), depending on the web based platform used, some students would not have access or

any familiarity with it – for example a Facebook – type application (Figure 8). Students at the

secondary level might have had access to and be able to navigate around the application, but the

same cannot be said for the primary school students. (3) Lastly, some schools prohibit access to

social networking sites from their school terminals. It would have been an additional challenge to

get the website approved by the school’s administration – it might have been approved if tabled,

but it would have been another unnecessary lengthy process.

SECTION 6.1.3: VIRTUAL LEARNING ENVIRONMENT

This implementation is an option as a Virtual Learning Environment

(VLE) already existed as a possible platform for development. All

the schools involved in the initial project had a VLE. However,

as a possible implementation solution there would have been

complications. The VLE used (fronter, Figure 9) was licensed

Figure 9: fronter logo http://fronter.info/uk/news/UK_Magazine_1

_2009.html


36

Figure 10: Client-Server Architecture http://www.roseindia.net

software and it was unknown as to what the capabilities were for external additions. If there was

a feature for external additions, as it is a licensed software, it would have been a lengthy process

to get around with developers to find out if the game would be compatible with the VLE. Free

open source learning environments exists. However, a change over in VLE would need council

approval. Furthermore, a new VLE would be beyond the scope of this project as it was only

intended to affect a group of students (those doing maths). With a new VLE, it would have to be

a school wide implementation and not a segregated classroom.

SECTION 6.1.4: CLIENT-SERVER ARCHITECTURE

As discussed in Chapter 5: Methodology, a client-

server architecture was the best implementation for

this project (as shown in Figure 10). This solution

was the best, as it requires everything involved in

the game to run locally within one school without

the added challenges of getting things approved.

The teacher will have control of the game and its

setup, and be assisted by the IT department. As it

stands, this option would be easy to set up and manage.

It would be accessible by students – whether or not they

know how the client-server actually works – all they would have to do is, click ‘connect’ and the

client would connect to the server and start a new game.

SECTION 6.2: DESIGN ITERATIONS

Adhering to the methodology specified in Chapter 5, the overall architecture presented in

the aforementioned chapter was broken down into small manageable iterations and

implemented accordingly. Below, each stage will be discussed and evaluated highlighting the

various components implemented.


37

SECTION 6.2.1: ITERATION 1.1

Iteration 1.1: Administrator and Database Interface

The administrator interface was developed first because it must have the

capabilities to create and manipulate the database. The initial time frame for

implementing both the administrator and database interfaces was 2 weeks.

However, because the tools and background knowledge needed for such interfaces

were not covered in programming modules, it had to be self-taught. The final time frame for

developing both interfaces was 3 weeks. Testing to ensure that each component worked within

its capacity of Wacky Game took 2 weeks. Testing was done three weeks after exams. The overall

time frame for these iterations (1.1 - 1.2) was 7 weeks. Below are the functionalities of each of the

component developed. Please note that not all the functionalities were implemented – just the

most important ones necessary for grasping a general idea about how the game should work

with these particular components. The functionalities that were developed are marked with an

asterisk.

Administrator Functionalities:

Create database*

Configure database structure*

Create tables within database*

Add/delete questions to/from tables*

Create log charts

Create database security measures

Store images needed for game (players, tracks, etc.)

Database Functionalities:

Create tables within database*

Add/retrieve/delete information from within database*

Communicate with administrator and server*

Store information pertinent to the game*

Store images for game

Log player’s scores

The database was created using the administrator

interface. After the database was created, a table called

‘Questions’ was created once the first question was added to the

Database

Administrator

Figure 11: Administrator Interface with ‘Add Question’ popup box


38

Database

Server

database using the popup box (as depicted in figure 11). By default, in the Python coding that

underlies the database, in the Questions table, the primary key for each record added to the

database was the level of the question that was specified by the administrator as they entered

each question. A completed dialog box is recorded as one record within the ‘Questions’ table. In

the playing of Wacky Game, once the game is about to start, the player has to select their

competitiveness level. By prompting the player to select their level before a game starts, allows

the database to filter the ‘Questions’ table to extract only those questions with the particular

level that the player selected to be used in that game. For example, if the player selected level ‘2’

as their competitiveness level, then only questions entered as level 2 in the popup box by the

administrator will be used in that gaming session. That is why the primary key is important in the

database. The database schema is: Questions (question, answer, level, points) – the underlined

text is the primary key. The field types are as follows (with reference to MS Access):

Question – Text

Answer – Number/Long Integer

Level – Number/Integer (primary key)

Points – Number/Integer

Testing:

To confirm that the database and administrator interfaces communicated correctly, a sequence

of tests were performed. Sample questions were entered into the popup box as depicted in

Figure 11. Each question was entered with its corresponding answer, level and points. The ‘View

All Questions’ button on the administrator interface was selected to confirm that each question

keyed was successfully added into the questions table within the Wacky Game database. To

confirm that the administrator was able to filter questions by level, the view all questions button

was modified to extract only those questions with a specified level. If the questions were filtered

by the level selected, the feature worked perfectly. Reference texts used were Hetland, 2008 and

McGugan, 2007 for Python Programming.


Iteration 1.2: Server Component and its interaction with the Database

It was very important to get this implementation accurate, as it is the

critical connection between the configuration and the playing of the

game. The server manages the game by communicating with the

database and relaying information to the clients – which will be developed in the next stage of

Name of Table in database


39

implementation. The time frame for this implementation was 2 weeks. The server and the

administrator are very similar in functionalities. That is why some of the code used for the

administrator was copied for the server. This feature was outlined as one of the benefits of

Object Oriented Programming, the ability of objects to inherit characteristics of other objects.

The functionalities that were developed are marked with an asterisk.

Server Functionalities:

Connect with database*

Retrieve information from the database*

Communicate and send messages to client(s)*

Control number clients connecting to game*

Adds player to new game

Testing:

Testing for this iteration involved opening an active connection with the database and sending

prompts to: call the questions table from within the database, and close the connection to the

database when the server is closed.

SECTION 6.2.3: ITERATION 2

Iteration 2: Client component and its interaction with the Server

The clients are the players in this architecture who are able to play

the game via the server which was developed in iteration 1.2. The

client has no direct communication with the database or the

administrator (the configuration of the game). All communication that the client may have is

controlled by the server which connects the game logic and the game configuration. This stage

took 6 weeks to complete. The main reason behind the lengthy time frame was that the machine

used to run the program through each of its iterations had just one core processor which froze

each time the server started and prevented the client from connecting. Only after this technical

problem was rectified, was the client able to communicate with the server which now ran on a

dual processor machine. In addition to the technical difficulties, more literature research was

done to understand the implementation of a client - server pair. In this iteration, the focus was on

ensuring one client was able to communicate with the server. Multiple clients will be the focus of

iteration 3.1.

Client Functionalities:

Server Client


40

Network

Server

Client 1

Client 2

Client 3

Connect to server*

Disconnect from server*

Send and receive messages from server*

Present an interface for player to interact with

Start/end/pause new game

Testing:

Using a host computer with a dual processor (without any networking), both the client and

server programs were executed. A simple ‘Hello’ message was sent from the server terminal

prompt. If the same message appeared in the client terminal window, it was confirmation that

the communication channel was established. To end a session, as specified within the coding, the

client just sent the message ‘Quit’. After the message was sent, the client would close and the

server would receive the message stating the client had closed the session.


Iteration 3.1: Server interaction with multiple clients via

networking

This stage was greatly dependent on the successful

implementation of the previous iteration. The server and client

components were already developed. However it was now

important to ensure that the two components are able to

communicate, not only with each other, but with multiple clients simultaneously. As the game

requires that the server is able to manage multiple clients or players of the game, all the clients

must be able to communicate with the server, and the server must be able to track how many

clients are connected at any particular time. In the previous iteration, the server was

implemented to communicate with one client both running on one machine. At this stage, the

client was designed to be able to connect to the server running on another machine. As the final

game requires each client to be on a separate machine, each must be able to locate the server

that connects the game. These iterations (3.1-3.2) were completed in 5 weeks.

The tool used to implement multiple clients into the design was multithreading

(“Asyncore”, 2010). Python is able to work with multiple threads which enables the server to

simultaneously communicate with multiple clients. This feature allowed the game to run on both


41

one processor and dual processor machines. When a client connected to the server, the server

created a new thread to deal with that client. Multithreading also uses better memory allocation

on the CPU, which means that resources are not all used by the game processes.

Testing:

Similar to testing in iteration 2, the server was started and the client program was executed on

multiple machines within one computer lab. From each machine, a message was sent from the

client. On the server machine, if a message was displayed in a command prompt window, it

confirmed that a message was successfully received. Similarly, if an identical message send from

the server was received in the command terminal on the client machine, it confirmed that the

communication was successfully established. A different message was sent from each client so

that it was uniquely identified on the server machine.


Iteration 3.2: Sample Game logic

During this iteration, a sample communication, which forms part of the game logic for Wacky

Game, was tested. It was critical that each of the components involved were developed correctly

so that this iteration operated as intended. It was assumed that the administrator, database and

server were stored on one machine, while the client was on another machine. Desired

functionalities (Figure: 12):

The administrator can add a question with its corresponding answer into the database*

The server can extract the question*

The server can relay the question to the client over the network*

The player situated at the client machine can respond to the question and send a

response back to the server*

Network

Client

Figure 12: Sample Game Logic

Database

Administrator

Server

1 2=

3-=

5

4


42

The server validates the client’s response against the answer stored in the database and

sends a reply back to the client*

Please refer to Figures 13 -15 for snapshots of relevant GUIs of this process. This iteration took

2 weeks (part of the overall 5 weeks) to complete as all the components involved were

developed in previous iterations. As discussed in the methodology, Python enabled independent

versions of each component to be developed, and made combining them much easier. This

process took 2 weeks because of that aforementioned explanation.

Testing:

User feedback was involved for this iteration as it was a simplified version of how the final

game would operate. Users noted that although the activity was not stimulating or highly

animated, it served its purpose of demonstrating that the client and database can communicate

over the server with relevant game data. User feedback was a part of the testing process to

confirm that not only was the developer (me) able to interact with the various components, but

also potential administrators and players. A question was added by the administrator (me) and

sent via the server to a client (an evaluating participant). Upon receipt of the question, the

participant was asked to answer the question and send their response for validation by the

server. If their answer was correct, the server sent a reply back with a ‘Correct’ message (Figure

15).

What is 70 ÷ 7?

10

Enter

Correct!! You have earned 5 points

Figure 13: Administrator adds question to database

Figure 14: GUI Presentation on client machine

Figure 15: Response from database via server


43

SECTION 6.3: FUTURE ENHANCEMENTS

For a future development in Wacky Game, the administrator will have the option of

manipulating the server directly, for example changing the number of clients that must be

connected before a new game starts. During this present development, the default value is 8 as

specified in the rules and structure of the game section (4.3). This new relationship can be

identified by the line marked C on Figure 16 below.

Another future enhancement: the questions and database responses should be

displayed in a GUI and not in Python terminal as was done in this phase of testing. A temporary

GUI was presented to evaluating participants as they were unfamiliar with terminal command

prompts. During testing, users suggested that it would be brilliant if the server could send

different questions to multiple clients simultaneously. After which the database should be able to

validate each client’s response independently.

Now that the foundation of Wacky Game has been implemented, it is now possible to

move ahead with future enhancements of the game mentioned previously in addition to other

features. What is left to be implemented will make Wacky Game as it was described, to become

more engaging, educational, interactive, and further fulfil user requirements.

A more developed game logic. This will build up on the implementation testing that was

conducted in iteration 3.2, and will incorporate suggestions made by evaluators so that

the logic complies with good game design principles.

o These additions will include animation of the cards, cars, tracks, etc.

o Appropriate usage of colours, sounds, graphics.

Figure 16: Game Setup & Configuration (with a new feature)

B

C

Network

Database

Administrator

Server

Client 1

Client 2

Client 3

A


44

The database is a key component of this game. Therefore, more features need to be

implemented to secure the data that will be stored in the database.

o As mentioned in iteration 1.1, the database should include security features which

are controlled by the administrator. The use of user names and passwords should

be a fundamental approach.

Data that will be used in the playing of the game should be uploaded and stored in the

database by the administrator. Images for the track, racers, and the template for the

cards, should be uploaded. Also additional tables in the database to store logs and history

charts should be added, similar to the ‘Questions’ table implemented in iteration 1.1.

By adding more information to the database, the administrator’s capabilities are

increased. Therefore, the administrator interface should be updated as such (refer to

figure 11, pg. 37 for current functionalities of the administrator). The GUI should include

more buttons with underlying Python coding to execute appropriate functions.


45

CHAPTER 7: EVALUATION

SECTION 7.1: EVALUATION OVERVIEW

This section of the report is critical in determining whether or not the aims and objectives

of the project were achieved, and if not fully achieved, how closely were they satisfied. Please

note that at each stage of iteration for the development of a prototype of Wacky Game,

evaluation was provided where appropriate in Chapter 6. Therefore, this section of the report will

focus on the overall evaluation of the project and not just specific stages.

SECTION 7.2: EVALUATION PARTICIPANTS & TOOLS

There were two types of participants involved in this project:

2 students – 1 primary, 1 secondary. These students who are the potential end users of

Wacky Game were brought into the project to evaluate existing educational maths game.

Their feedback was use in Chapter 2, section 2.5. They were given questionnaires (see

Appendix D) to judge the games suggested based on its compliance with good game

design principles.

MSc Colleagues: these individuals who can all be possible administrators of Wacky Game,

provided information about the usability of the administrator interface, and tested the

sample game logic. A copy of the administrator evaluation form can be found in Appendix

D. To summarise their comments:

o They thought that the sample logic lack a few of the game design principles

outlined in Chapter 3. However, as they understood, what they were evaluating

was just a prototype with the bare minimum functionalities of the overall game.

Therefore to that end, they stated that Wacky Game sample game logic had

achieved its purpose.

o They all confirmed that sufficient groundwork has been done for future

enhancement of the game to add more of its complexities and functionalities. At

this stage, it was not important to embellish the prototype with images, colours

and sound effects. The core educational content is needed first, and how it

should be animated must be the next step for future development.

Disclaimer: the teachers involved in the project were supposed to be the main evaluators

of the prototypes. However due to conflicts with their school calendar and Wacky Game


46

development schedule they were away on holidays when the prototypes were

completed. They will be available in September 2010. Unfortunately that is the deadline

for the submission of this report.

SECTION 7.3: EVALUATION AGAINST AIMS AND OBJECTIVES

Wacky Game and all the processes involved will be evaluated to state whether or not the

overall objectives of the project was achieved. As stated in Chapter 5, the objectives of the

project were to:

1. Research and discuss learning theories and the teaching of mathematics

2. Research and discuss the implications of educational computer games

3. Research and discuss teachers’ and students’ perceptions of the use of computer

games in the classroom

4. Gather user requirements from the teachers who designed the board game

5. Design and implement a prototype of an ICT application that complies with user

requirements

It can be confirmed with complete assurance that all of the objectives of this project

were achieved. Points 1 – 3 were extensively covered in the literature review which can be found

in Chapters 2 and 3. These chapters presented relevant information that was useful in

determining a developmental approach for Wacky Game, such as an appropriate methodology,

what are some characteristics of good game designs and the importance of user involvement in a

project of this nature. The literature review provided guidance for decisions made in the

development of Wacky Game. This lead into the fulfilment of point 4, gather user requirements.

These requirements are outlined in full detail in Chapter 4. In this chapter both functional and

non-functional requirements of Wacky Game were discussed, both from the perspective of the

end users (students) and the administrators (teachers). The evaluation tool used to gather

information for those sections was face-to-face interviews.

SECTION 7.4: EVALUATION AGAINST MINIMUM AIMS AND REQUIREMENTS

The minimum aims and requirements were signposts for this project. It was used as a

basis for developing Wacky Game based on user requirement and software engineering

principles. Briefly, those aims and requirements specified in Chapter 5 were:

1. Provide a formal specification of the game


47

2. Develop prototypes of various components of the game

3. Specify a suitable user interface

4. Suggest further enhancement to the work done

It can be presented with evidence that the minimum aims and requirements were met

and surpassed throughout this report. Points 1 – 3 can be substantiated with information

provided in the methodology of this report. By being able to complete points 1 – 3, it was then

possible to suggest and then develop further enhancements to the work done. Of significance

was the development of multiple clients that were able to connect to the server, which was

initially developed to accommodate and communicate with one client. Time constraints

prohibited the development of every aspect of the game that the users had envisioned.

However, a prototype was developed that successfully performed the operations that were

essential to the playing of the game. This operation was the multiple clients – server link. The

server was able to retrieve relevant game information stored within a database and send it over

the network to clients (on other machines).

Upon achieving the minimum aims and requirements, the deliverables for this project

were attained. These deliverables were an interim report, this final report, and snapshots of

various prototype applications – or components of the game.

SECTION 7.5: EVALUATION AGAINST METHODOLOGY

It was vitally important the methodology of the project was closely followed. The

development of a prototype of Wacky Game has adhered to the methodology outlined in

Chapter 5. Due to the nature of the project, and the external deadlines users had, an iterative

approach was selected as the best way forward. Firstly, all the relevant components of the game

were identified, their links were established and an agreed upon first prototype was developed.

With an iterative approach, components were developed independently with high user

involvement. After each iteration, evaluation was conducted to determine future modifications,

which again were agreed upon by all parties involved in the project. It was evident during each

iteration that the methodology was closely followed. Evaluation for iterations 1.2 and 3.2 were

conducted with the use of questionnaires and formative feedback from fellow MSc colleagues.

Iteration 2 was self-evaluated because there was no user interface developed to show a


48

successful client – server connection. This essential iteration was the underlying infrastructure in

the success of iterations 3.

In regards to scheduling, the only major difference between the proposed and actual

schedule is the extra time taken to undertake additional literature research. Additional research

was needed to progress through each iteration – such as the client-server pair in iteration 2, and

in connecting multiple clients via multithreading in iteration 3.1. After sufficient research was

completed, more time was spent on ensuring that each iteration worked properly.

SECTION 7.6: OTHER EVALUATION CRITERIA

The following evaluation criteria were use to judge the prototype developed and the

tools used in its development.

Portability: Python was used as the tool for its development because programs

developed in that language are platform independent. Therefore, when packaged as one

complete unit, Wacky Game can be executed once a portable Python shell is available, or

a command terminal, which is a becoming standard feature in new operating systems.

Usability: The administrators who evaluated the prototype did not have any

complications using the program, as everything in their opinion was straightforward. For

example, the administrator interface asks which option the individual wish to perform. If

he/she selected “add questions” to database, a pop up window appeared with the

relevant fields to be filled in. After which, the user just select “Add” and the question is

added to the database. A screenshot of this procedure can be found in Chapter 6, section

6.4.

Efficiency: Evaluators stated that the program work very quickly in that it did not require

much memory to complete its tasks. The Wacky Game program does not affect other

program being run on the same machine in any way. In addition, the clients were able to

communicate with the server without difficulty or delay.

Functionality: Once again, as the sample game logic was developed and tested for its

ability to undertake the essential communication link between the client, server and

database, its functionality within the game was a success.


49

CHAPTER 8: CONCLUSION

Wacky Game was the culmination of a yearlong Master’s of Science degree in Computing

and Management at the University of Leeds’ School of Computing. Clearly detailed throughout

this report, evidence suggests that it involved planning, selecting appropriate tools, background

literature, implementation, evaluation and conclusion. As technology becomes a very important

asset in the educational system, it is no surprise that game developers are now seeking out ways

of incorporating gaming into the classroom. Wacky Game, the brainchild of a group of six

teachers from three primary and secondary school, was developed to help the schools which the

teachers represented, keep in pace with educational technology that is accessible to students

(Mumtaz, 2001).

A literature review provided evidence that many existing software available in the field of

education for mathematics was designed as drill and practise packages that required little

teacher intervention (Mumtaz, 2001). Wacky Game was described as a step in a new direction for

maths computer games. Wacky Game encourages students to develop skill sets such as strategic

thinking, problem solving, and collaborative/cooperative team working. The teacher will not be

just a bystander. They will be integral in helping students understand what is required of them in

playing the game. In addition, the teacher must be able to provide feedback for students, and

accompany gaming sessions with relevant classroom based activities (worksheets, debriefing

sessions, quizzes). Because Wacky Game was first played in its board form, user requirements for

a computer version of the game were gathered from both teachers and students. This key step in

game development will assist with making Wacky Game computer version engaging and exciting

for the players.

As the literature review suggests, there are many students who may find learning maths

an insurmountable challenge. However as Watson (2006) stated, and I personally concurred that

“all school learners are able to learning significant mathematics given appropriate teaching”. This

is a powerful statement, but it is true. By incorporating tools or technologies, that students are

familiar with, teachers will be able to identify gaps to use such technologies to enhance their

classroom activities. Showing students ways in which they can enjoy learning maths can be both

“psychologically and intellectually empowering” (Watson, 2006).


50

The students involved in the project provided valid information about what they

expected a good computer maths game to be. Following good design principles outline in

Chapter 4, elements of non-educational games were considered for its transferability to

educational ones. Research suggested that as more students now have a personal computer at

home, when they are in a school environment they are more inclined to undertake activities on

the computer with confidence (Mumtaz, 2001).

As with many MSc project, elements of this game could not be developed because of time

constraints. As mentioned in Chapter 8 – evaluation, many of the areas developed required

extensive self-taught material, which also meant time spent on coding was minimal. However, it

is still possible for future developers to continue making Wacky Game the game it is described to

be, as the database – the storehouse for all the game information is completed, and the server

with multiple clients is functioning. All that is needed is more work on the game logic to connect

the various components together as a functioning unit.

What was developed can be considered a personal success as it was a first attempt at

game development on any scale. Introduction to programming languages, various programming

tools, object properties and actions were all key personal successes. It is believed that Wacky

Game is a different game than ones that students are accustomed to because of its uniqueness.

The various interfaces designed involved gathered specific user requirements, has the potential

to be across grade levels or schools. The players are in full control of the game and a successful

session depends on the player’s action and their ability to think strategically – mathematically. As

user requirements were integral in Wacky Game development, it is hoped that this good design

principles will motivate players to engage in the game. The students wanted a game that is fun,

engaging, requiring them to think, working as a team and promoting their learning of maths.

The groundwork has been laid for someone else to continue the work started on Wacky

Game. They will be able to follow the methodology, incorporate user requirements, and build up

on coding already done. This project has detailed information for future students interested in

designing a computer based educational game from the idea stage, through multiple iterations

and final product.


51

BIBLIOGRAPHY

"Adobe flash". (2010). Retrieved June 17, 2010, from Wikipedia: The free encyclopaedia:

http://en.wikipedia.org/wiki/Adobe_Flash

"Asycore". (2010). Asyncore - Asynchronous socket handler. Python Software Foundation. Retrieved

on 21 August, 2010 from: http://docs.Python.org/library/asyncore.html

"ICT". (2010). Retrieved June 10, 2010, from Wikipedia: The free encyclopaedia:

http://en.wikipedia.org/wiki/Information_and_communication_technologies

"Java (programming language)". (2010). Retrieved June 17, 2010, from Wikipedia: The free

encyclopaedia: http://en.wikipedia.org/wiki/Java_%28programming_language%29

"JavaScript". (2010). Retrieved June 17, 2010, from Wikipedia: The free encyclopaedia:

http://en.wikipedia.org/wiki/JavaScript

"Problem Solving". (2010). Retrieved July 16, 2010, from Education Counts:

www.educationcounts.govt.nz/publications/series/ALL/29946/7

"PyGame". (n.d.). Retrieved July 22, 2010, from About PyGame: http://www.PyGame.org/wiki/about

"Python (programming language)". (2010). Retrieved June 17, 2010, from Wikipedia: The free

encyclopaedia: http://en.wikipedia.org/wiki/Python_%28programming_language%29

Bruegge, B., & Dutoit, A. H. (2000). Object-oriented software engineering: Conquering complex and

changing systems (International ed.). Upper Saddle River, New Jersey: Prentice Hall, Inc.

Carbonaro, M., Cutusmisu, M., Duff, H., Gillis, S., Onuczko, C., Siegel, J., et al. (2008). Interactive story

authoring: A viable form of creative expression for the classroom. Computers & Education ,

687-707.

Chou, C. (2003). Interactivity and interactive functions in web-based learning systems: A technical

framework for designers. British Journal of Education Technology , 34 (3), 265-279.

Conati, C., & Klawe, M. (2000). Socially intelligent agents to improve the effectiveness of educational

games. Vancouver, British Columbia, Canada: University of British Columbia.

Fisch, S. M. (2005). Making educational computer games "educational". MediaKidz Research &

Consulting .

Gee, J. P. (2007). What video games have to teach us about learning and literacy. New York: Palgrave

Macmillan.

Hetland, M. L. (2008). Beginning Python: From novice to professional (2nd ed.). Berkley, Calafornia,

USA: Apress.

Jhurree, V. (2005). Technology integration in education in developing countries: Guidelines to policy

makers. International Education Journal , 6 (4), 467-483.


52

Kaplan, A. G. (1970). Games for growth: Educational games in the classroom. Science Research

Association, Inc, College Divisoin .

Kiili, K. (2005). Digital game-based learning: Towards an experiential gaming model. The Internet and

Higher Education 8 , 13-24.

Mavrou, K., Lewis, A., & Graeme, D. (2010). Researching computer-based collaborative learning in

inclusive classrooms in Cyprus: The role of the computer in pupils' interaction. British Journal

of Educational Technology, 41 (3), 486-501.

McGugan, W. (2007). Beginning game development with Python and PyGame: From novice to

professional. Berkeley, CA: Apress.

Mumtaz, S. (2001). Children's enjoyment and perception of computer use in the home and the

school. Computers & Education (36), 347-362.

Provenzo, E. F. (1991). Video kids: Making sense of Nintendo. Cambridge, MA: Harvard University

Press.

Reed, H. C., Drijvers, P., & Kirschner, P. A. (2010). Effects of attitudes and behaviours on learning

mathematics with computer tools. Computer & Education (55), 1-15.

Sedighian, K., & Sedighian, A. (1996). Can educational games help educators learn about the

psychology of learning mathematics in children? Vancouver, British Columbia: University of

British Columbia.

Sommerville, I. (2004). Software Engineering (7th ed.). Essex, England: Pearson Education Limited.

Telles, M. (2008). Python power! The comprehensive guide. Boston MA: Thomson Course

Technology.

The Office for Standards in Education, Children's Services and Skills (Ofsted). (2009). The importance

of ICT: Information and communication technology in primary and secondary schools.

London.

Watson, A. (2006). Raising achievement in secondary mathematics. Maidenhead, Berkshire: Open

University Press, McGraw-Hill Education.


53

APPENDICES

APPENDIX A: PERSONAL REFLECTION

I can honestly say that I am utterly relieved that this project has ended. Not just because I

do not have to attend meetings anymore, but mainly because I will have more time for myself. A

major challenge I had to overcome and be able to deal with on a level as I never had to before

was time management. Coming to university miles away from home with just personal finances

from the start was a challenge, and on top of that, I wanted to be successful in my educational

endeavours.

Working and attending university full time is a predicament that most international

students often find themselves. Therefore I would encourage future students to negotiate with

employers about suitable working hours. Yes the lingering thought about would my corporate

life affect my academic life was always on my mind, but I had to bear the burden of personal

financing. During semester 1, my focus was on passing my modules. However when semester 2

came around, I had to readjust my focus to include semester 2 modules, work and beginning my

MSc project. Although the MSc project is scheduled for the summer months, I would admonish

other students not to rely on that. I was caught up with my MSc project from in late February,

early March. It was during these months that I was able to gather pertinent user requirements

and establish contacts that have enabled me to complete my project.

The greatest hurdle of this project was my programming. I told my supervisor that I was a

novice programmer. I had no programming experience; I was neither familiar with Linux

machines, nor familiar with Python and other tools used - PyGame, Sqlite, MySql, or Tkinter. I am

competent with Web Design software (Adobe’s Dreamweaver, HTML, etc.). However, I was not

able to use any of this knowledge. I began my project as a newborn to the world of computer

programming. I guess that was the reason I was at university studying for a master’s degree in

computing and management. One would think that the modules would have prepared me for

my project (the programming bits), but I was not. All the tools I needed to learn for getting my

project off the ground was self-taught. I would say due to the failure of the School of Computing

module to prepare me for programming in Python resulted in delayed programmed deliverables.


54

My charge to future students: if you know what you will be required to deliver for your

project early on (around March/April), have a look at your module syllabus (past and current). If

you will not be taught essential skills to assist you in your programming, I strongly ask that you

begin researching and self-teaching the languages, tools, etc. you will need. Do not depend on

the course modules to prepare you for every aspect of your project. I would have like to deliver

all that I was envisioning for my project, but my technical skills were lacking and I believe it may

be a downfall in my project grading. I am relying on my write-up to explain what I wanted to do,

what I was able to do, and why I was not able to do all that I wanted to do.

Choose a topic that has personal appeal to you. I really enjoyed working on my project

because I have an education background. I love teaching. I had a really good connection with

teachers in the field who were very supportive throughout the entire project, so was my

supervisor who had relevant experiences. I believe these were key ingredients in making my

project run smoothly and it motivated me to work hard at its completion. Students should know

that every day was not a bed of roses. I did get depressed when my programming did not work

and I had no idea where the bugs were. Nevertheless, once I was able to move over a stumbling

block, I was excited about moving on. Students should take time out and relax during the project

– yes, the time frame is tight, but stressing and burning oneself out would not make it any

easier or enjoyable. That is why I am grateful to my fellow classmates who were just a breath of

fresh air in the MSc study room. We would chill out, relax, and just have a laugh throughout the

summer months – just to catch up (since we were out of classes) and go out for a drink. This

rejuvenated each of us and gave us that extra boost to work on our projects.

I came to the realisation early on in my project that I would have a very tight schedule. As

my fellow classmate were working on their project following the standard: gather user

requirements, design & implement, code, etc. I had to work in reverse. I would once again

encourage future students to think clearly about the nature of project they wish to pursue.

Because I was working along with a group of teachers and their respective students, the project

required me to work in reverse. July is the month during which schools go out of session.

Therefore, I theoretically should have whatever tangible outcome of my project completed for

the teachers and students to evaluate. I had to begin coding at the beginning of my project –

knowing that I am not a programmer it was an extra challenge for me. It should be made known

that any project that is related to education and students are needed for evaluation, the time

frame for deliverable are different from other projects. Lacking the necessary programming skill


55

to have something prepared for July resulted in me not being able to have students’ input for my

project, which may have an impact on my evaluation section grade.

Lastly, my faith had kept me through it all. I am the keyboardist at my church, and each

and every Sunday, I am blessed by the Holy Spirit. I knew I had so much on my plate and always

had since I was young. God has plans for my life and I intend on following his will and I know

having to complete this project was critical in me getting my masters. I was the first in my family

to attain a bachelor’s and will soon be the first master’s degree holder. God is good. He will

reward me for sacrificing my Saturdays for worship practise; leaving a 12-hr work shift at 7 am on

Sunday morning to go to church for 10 am and then back to work at 7 pm for another 12-hr shift.

Not many people would have the willpower and stamina to do it all. However, I have, with the

strength of God. My family has been very supportive throughout my university career and I am

forever in their debts and prayers. An extracurricular activity was a much-needed break during

the project months as a distraction.

Overall, although I was not able to produce the greatest game ever or any resemblance

of one, I have learnt that the goal of the project was for me to go through the process. I was

able to balance coding and other related project tasks (I tend to shy away from the programming

bit quite often), learn new programming languages and tools, and once again undertake another

lengthy dissertation of high academic calibre.


56

APPENDIX B: INTERIM REPORT FEEDBACK FORM

Interim Report

Attached (Hardcopy)


57

APPENDIX C: PROJECT MANAGEMENT Meeting Logs: Weekly - Meeting with project supervisor, Doctor Mark Walkley Agenda: To discuss progression of dissertation 01 Feb. 2010 - Meeting with Professor John Monaghan Agenda: Discussion of the item proposed as an MSc project and how I would go about

doing it 24 Feb. 2010 - Meeting with teachers from both Primary and Secondary schools who were

initially involved in the project. Agenda: To discuss their understanding of the project, what their visions are, where I can

help, and get notes from them about how they have played the game in its paper version.

09 Feb. 2010 - Meeting with Professor John Monaghan Agenda: Debrief about meeting with other teachers. How to make the project something I

can work with to meet the needs of my MSc degree. 24 March, 2010 - Meeting with All Teachers Agenda: More specific user requirements, technical challenges, user expectations,

deadlines, feedback, rules of the game, etc. 14th June, 2010 - Meeting with All Teachers Agenda: Progress report, how is the project going and what deliverables can be delivered

or not. Summary of Progress as of 18th June, 2010 (Interim report): To date I have made the following progress:

Acquired a more accurate understanding of the game to be implemented Gathered sufficient user requirements to determine a suitable implementation of the

application Proposed a schedule for various tasks involved over the deadline given Completed a draft interim report with background reading and other research Completed sufficient literature review to understand topics such as:

o Game design o Human computer interface/interaction factors o Factors that makes a game educational, while entertaining

Research other maths computer game and critique them on the bases of: o Educational content o Usability by students and teachers o Design implementation

Met with teachers and other invested bodies to discuss the progress of the project Research and determined the best implementation platform considering the locale of the

clients involved Determine the best methodology – with justification, for development and

implementation – an iterative approach is best suited for the project intended


58

Begun writing Python coding for the configuration portion of the game (database and administrator) which will be followed by a similar process for the server architecture.

o Completed programming for database Begun reading and coding for a graphical user interface for the administrator to

manipulate the database Mile Stones: 14th June, 2010 – gathered sufficient user requirements 18th June, 2010 – completion of interim report 10th June, 2010 – completion of iteration 1 9th July, 2010 – completion of iteration 2 24th August, 2010 – completion of iteration 3 28th August, 2010 – completion of final report 2nd September, 2010 – submission of final report


59

APPENDIX D: EVALUATION FORM TEMPLATE

User Evaluation (Existing Games)

General Information

Candidate: ____________________________________ Date: ___________________________

Age: ___________________________________

Gender: ___________________________________

Overall Usability

Straight Forward Complicated

Candidate Evaluation

Name of Game: Poor Fair Satisfactory Good Excellent

Appropriate Sound Effects

User customisability

Content Appropriate

Fun factor

Directions clear and concise

Feedback provided?

Would play again or recommend to others? (Y/N)

__________

Strengths:

Weaknesses:

Additional Comments:

Wacky Game


60

User Evaluation (Administrator & Database)

General Information

Candidate: ____________________________________ Date: ___________________________

Age: ___________________________________

Gender: ___________________________________

Overall Usability

Complicated Straight Forward

Component Evaluation

Poor Fair Satisfactory Good Excellent

Layout appropriate?

Directions clear and concise?

Input field size appropriate?

Feedback provided (successful add)?

Database retrieval understandable?

Delete option understandable?

Interface presentation?

Did the current design serve its purpose intended? (Yes/No) __________

Strengths:

Weaknesses:


Wacky Game


61

User Evaluation (Sample Game Logic)

General Information

Candidate: ____________________________________ Date: ___________________________

Age: ___________________________________

Gender: ___________________________________

Overall Usability

Complicated Straight Forward

Component Evaluation

Poor Fair Satisfactory Good Excellent Client aware of connection to server?

Question visible?

Response prompts appropriate?

Feedback provided (right or wrong)?

Interface presentation?

Strengths:

Weaknesses:


Wacky Game


62

APPENDIX E: MSC PROJECT RESEARCH PROPOSAL

Title of project: ICT in Education research project Probable supervisor: any Computing staff could supervise; Prof Monaghan co-supervisor Area of interest: ICT in Secondary school education Professor John Monaghan of the School of Education has passed on this project suggestion: "I have, with my colleague John Threlfall and three teachers in Harrogate, Pete Hallam, Tony Staneff and Richard Street, got an educational project going between one secondary and two primary schools - basically aimed at getting primary and secondary pupils working together and competing in maths activities. The project is a follow up to a funded project with the same team of people but this current project is not funded - but is a fun experiment in seeing how ICT can be used to connect pupils/schools/teachers in maths activities. Tony Staneff is our main programmer who has the written the first draft of the ICT tool for this in Php linked to a Mysql database - but we are not tied to any particular system. I have a lot of other information I could provide but I feel it would be better leaving this to a later date. I am very happy to have a meeting with anyone who might find this an interesting thing to be involved in. Best wishes, John Monaghan Prof of Maths Education"

Documents

MSC DISSERTATION TRAVIS HANDFIELD - University of … · · 2014-10-29... a personal research into the ... and conducive environment for learning. Learners can benefit ... ICT is