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
MSC DISSERTATION TRAVIS HANDFIELD
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.
MSC DISSERTATION TRAVIS HANDFIELD
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
MSC DISSERTATION 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
MSC DISSERTATION TRAVIS HANDFIELD
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.2.4: Iteration 3.1 …………………………………………………………………..40
Section 6.2.5: Iteration 3.2 …………………………………………………………………..41
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
MSC DISSERTATION TRAVIS HANDFIELD
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
MSC DISSERTATION TRAVIS HANDFIELD
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
MSC DISSERTATION TRAVIS HANDFIELD
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.
MSC DISSERTATION TRAVIS HANDFIELD
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.
MSC DISSERTATION TRAVIS HANDFIELD
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
MSC DISSERTATION TRAVIS HANDFIELD
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.
MSC DISSERTATION TRAVIS HANDFIELD
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).
MSC DISSERTATION TRAVIS HANDFIELD
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.
MSC DISSERTATION TRAVIS HANDFIELD
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.
MSC DISSERTATION TRAVIS HANDFIELD
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.
MSC DISSERTATION TRAVIS HANDFIELD
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
MSC DISSERTATION TRAVIS HANDFIELD
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
MSC DISSERTATION TRAVIS HANDFIELD
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.
MSC DISSERTATION TRAVIS HANDFIELD
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.
MSC DISSERTATION TRAVIS HANDFIELD
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.
MSC DISSERTATION TRAVIS HANDFIELD
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
MSC DISSERTATION TRAVIS HANDFIELD
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
MSC DISSERTATION TRAVIS HANDFIELD
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”
MSC DISSERTATION TRAVIS HANDFIELD
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.
MSC DISSERTATION TRAVIS HANDFIELD
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).
MSC DISSERTATION TRAVIS HANDFIELD
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
MSC DISSERTATION TRAVIS HANDFIELD
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.
MSC DISSERTATION TRAVIS HANDFIELD
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
MSC DISSERTATION TRAVIS HANDFIELD
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
MSC DISSERTATION TRAVIS HANDFIELD
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.
MSC DISSERTATION TRAVIS HANDFIELD
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.
MSC DISSERTATION TRAVIS HANDFIELD
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
MSC DISSERTATION TRAVIS HANDFIELD
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.
MSC DISSERTATION TRAVIS HANDFIELD
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.
MSC DISSERTATION TRAVIS HANDFIELD
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.
MSC DISSERTATION TRAVIS HANDFIELD
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
MSC DISSERTATION TRAVIS HANDFIELD
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
MSC DISSERTATION TRAVIS HANDFIELD
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
MSC DISSERTATION TRAVIS HANDFIELD
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
-->System Implementation
-->Testing & Feedback
--> System Requirements Evaluation
-->System Design
-->System Implementation
-->Testing & Feedback
--> System Requirements Evaluation
Interim Report
Write up Final Report
Submission
Iterations 1.1 - 1.2
Iteration 2
Iterations 3.1 - 3.2
Travis Handfield - MSc Dissertation Project Schedule (Proposed)
Jan. Aug. Sept.JulyJuneMayAprilMarchFeb.
MSC DISSERTATION TRAVIS HANDFIELD
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
-->System Implementation
--> Testing & Feedback
--> System Requirements Evaluation
-->System Design
-->System Implementation
-->Testing & Feedback
--> System Requirements Evaluation
-->System Design
-->System Implementation
-->Testing & Feedback
--> System Requirements Evaluation
Interim Report
Write up Final Report
Submission
Iterations 1.1 - 1.2
Iteration 2
Iterations 3.1 - 3.2
Travis Handfield - MSc Dissertation Project Schedule (Actual)
Jan. Feb. March April May June July Aug. Sept.
MSC DISSERTATION TRAVIS HANDFIELD
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.
MSC DISSERTATION TRAVIS HANDFIELD
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
MSC DISSERTATION TRAVIS HANDFIELD
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.
MSC DISSERTATION TRAVIS HANDFIELD
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
MSC DISSERTATION TRAVIS HANDFIELD
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.
SECTION 6.2.2: ITERATION 1.2
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
MSC DISSERTATION TRAVIS HANDFIELD
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
MSC DISSERTATION TRAVIS HANDFIELD
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.
SECTION 6.2.4: ITERATION 3.1
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
MSC DISSERTATION TRAVIS HANDFIELD
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.
SECTION 6.2.5: ITERATION 3.2
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
MSC DISSERTATION TRAVIS HANDFIELD
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
MSC DISSERTATION TRAVIS HANDFIELD
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
MSC DISSERTATION TRAVIS HANDFIELD
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.
MSC DISSERTATION TRAVIS HANDFIELD
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
MSC DISSERTATION TRAVIS HANDFIELD
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
MSC DISSERTATION TRAVIS HANDFIELD
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
MSC DISSERTATION TRAVIS HANDFIELD
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.
MSC DISSERTATION TRAVIS HANDFIELD
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).
MSC DISSERTATION TRAVIS HANDFIELD
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.
MSC DISSERTATION TRAVIS HANDFIELD
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.
MSC DISSERTATION TRAVIS HANDFIELD
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.
MSC DISSERTATION TRAVIS HANDFIELD
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.
MSC DISSERTATION TRAVIS HANDFIELD
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
MSC DISSERTATION TRAVIS HANDFIELD
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.
MSC DISSERTATION TRAVIS HANDFIELD
56
APPENDIX B: INTERIM REPORT FEEDBACK FORM
Interim Report
Attached (Hardcopy)
MSC DISSERTATION TRAVIS HANDFIELD
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
MSC DISSERTATION TRAVIS HANDFIELD
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
MSC DISSERTATION TRAVIS HANDFIELD
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
MSC DISSERTATION TRAVIS HANDFIELD
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:
Additional Comments:
Wacky Game
MSC DISSERTATION TRAVIS HANDFIELD
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:
Additional Comments:
Wacky Game
MSC DISSERTATION TRAVIS HANDFIELD
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"