0% found this document useful (0 votes)
16 views49 pages

Aravind RTP

Uploaded by

vejelol840
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
16 views49 pages

Aravind RTP

Uploaded by

vejelol840
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 49

A Real Time Project Report on

“Game Development”

Submitted to the

JAWAHARLAL NEHRU TECHNOLOGICAL UNIVERSITY HYDERABAD

In partial fulfillment of the requirement for the award of the degree of

BACHELOR OFTECHNOLOGY IN

COMPUTER SCIENCE& ENGINEERING (ARTIFICAL

INTELLIGENCE&MACHINE LEARNING)

BY

MALLE ARAVIND:(22WJ8A66E0)

Under the esteemed guidance of

Mr. S. Parabrahma Chari (Assistant Professor)

DEPARTMENT OF EMERGING TECHNOLOGIES (SPECIAL BATCH) GURU

NANAK INSTITUTIONS TECHNICAL CAMPUS (Autonomous)

(Affiliated to JNTUH, Accredited by NBA)


Ibrahimpatnam, R. R. District, Telangana - 501506.
(2023-2024)

1
DEPARTMENT OF EMERGING TECHNOLOGIES (SPECIAL BATCH)

CERTIFICATE

This is to certify that this Real Time Project entitled “Game Development” being

submitted by MALLE ARAVIND bearing 22WJ8A66E0 in partial fulfillment for the award

of the Degree of Bachelor of Technology in Department of Computer science

&Engineering (Artificial Intelligence and Machine Learning) of the Guru Nanak

Institutions Technical Campus, Hyderabad during the academic year 2023-2024, is a

record of Bonafide work carried out under our guidance and supervision at Guru Nanak

Institutions Technical Campus (Autonomous).

----------------------- ---------------------------------- ---------------------


Mr. S . Parabrahma Mr. S . Parabrahma Chari Dr. Tariq
Chari Hussain
INTERNAL GUIDE CO-ORDINATOR HOD (AIML &
IT)

—------------------------------

EXTERNAL EXAMINER

2
ACKNOWLEDGEMENT

I wish to express my sincere thanks to Mr. Sardar Gagandeep Singh Kohli, Vice-Chairman, GNITC
for providing me with the conductive environment for carrying through my academic schedules and
real time project with ease.

I wish to express my sincere thanks to Dr. Harvinder Singh Saini, Managing Director, GNITC for
providing me with the conductive environment for carrying through my academic schedules and real
time project with ease.

I wish to express my sincere thanks to Dr. Sreenatha REDDY, Director, GNITC for providing me with
the conductive environment for carrying through my academic schedules and real time project with ease.

I wish to express my sincere thanks to Dr. Rishi Sayal, Associate Director, GNITC for providing me with
the conductive environment for carrying through my academic schedules and real time project with ease.

I have been truly blessed to have a wonderful adviser Dr. Tariq Hussain, Department of Information
Technology and Computer Science and Engineering Special batch Emerging Technologies for guiding me
to explore the ramification of my work and I express my sincere gratitude towards him for leading me
throughout the completion of the real time project.

I would like to say my sincere thanks to Mr. S. Parabrahma Chari, Department of Computer Science and
Engineering Special Batch Emerging Technologies, Real Time Project Coordinator, for providing seamless
support and right suggestions are given in the completion of the project.

I specially thank my internal guide Internal Guide information, GNITC for his suggestions and
constant guidance in every stage of the real time project.

Finally, I would like to thank my family members for their moral support and encouragement to achieve goals.

MALLI ARAVIND
(22WJ8A66E0)

3
DECLARATION

I, MALLE ARAVIND,22WJ8A67E0 declared that Real Time Project report


entitled “HUNGRY HUB” under the esteemed guidance of Mr. Sriram
Parabrahmachari, Assistant Professor, Department of Emerging
Technologies (Special Batch) submitted in partial fulfilment of the
requirements for the award of the degree of Bachelor of Technology in
Computer Science and Engineering (Artificial Intelligence and Machine
Learning). This is a record of Bonafide work carried out by us and the
results embodied in this project report have not been submitted to any
other University or Institute for the award of Degree or Diploma.

Date :
Place : GNITC

MALLE AVAVIND
22WJ8A66E0

4
ABSTRACT
Games can be a valuable tool for enriching computer science
education, since they can facilitate a number of conditions that
promote learning: student motivation, active learning, adaptivity,
collaboration, and simulation. Additionally, they provide the
instructor the ability to collect learning metrics with relative ease.
As part of 21st Annual Conference on Innovation and Technology
in Computer Science Education (ITiCSE 2016), the Game
Development for Computer Science Education working group
convened to examine the current role games play in computer
science (CS) education, including where and how they fit into CS
education. Based on reviews of literature, academic research,
professional practice, and a comprehensive list of games for
computing education, we present this working group report. This
report provides a summary of existing digital games designed to
enrich computing education, an index of where these games may
fit into a teaching paradigm using the ACM/IEEE Computer
Science Curricula 2013 [13], and a guide to developing digital
games designed to teach knowledge, skills, and attitudes related to
computer science.

5
INTRODUCTION
As part of ITiCSE 2016, the Game Development for Computer
Science Education working group convened to examine the
current role games play in computer science (CS) edu-

2016 Copyright held by the owner/author(s). Publication rights


licensed to ACM. This is the author’s version of the work. It is posted
here for your personal use. Not for redistribution. The definitive
Version of Record was published in Proceedings of the 21st Annual
ACM Conference on Innovation and Technology in Computer Science
Education, July 11-13, 2016, Areq uipa, Peru.
ITiCSE ’16 July 11–13, 2016, Arequipa, Peru
2017 ACM. ISBN 123-4567-24-567/08/06...$15.00
DOI: https://doi.org/10.1145/3024906.3024908
cation, including where and how they fit into CS education. To
guide our discussions and analysis, we began with the following
question: in what ways can games be a valuable tool for enriching
computer science education?
In our work performed prior to our first face-to-face meeting, we
reviewed over 120 games designed to teach computing concepts
(which is available for separate download [5]) and reviewed
several dozen papers related to game-based learning (GBL) for
computing. Hainey [57] found that there is “a dearth of empirical
evidence in the fields of computer science, software engineering
and information systems to support the use of GBL.” This is not
unique to CS, however. A review by Papastergiou [95] found
limited evidence to support games for learning, and a systematic
review by Graafland et al. [54] also found no empirically validated
games to support education in the medical field.
Though our reviews were not designed to be comprehensive, our
findings support these claims. This lack of evidence prevented us
6
from identifying which of these games are most effective in
meeting educational outcomes, because little evidence exists to
make such claims, and it further prevented us from stating which
game design frameworks for CS education might be most effective
across various demographics. This required us to rethink our
approach and to consider how we would analyze the games and
the relevant research in a way that would provide significant
value for the broader computer science educational research
community.
The purpose of this working group report, therefore, is:
1. to provide a summary of existing digital games designed to
enrich computing education and an index of where these
games may fit into a teaching paradigm using the ACM/IEEE
Computer Science Curricula 2013 (CS2013), and
2.to provide a guide to developing digital games designedto
teach knowledge, skills, and/or attitudes related to computer
science.
To narrow the broad scope of games, we have chosen to focus on
digital games; however, we note that analog games (board games,
card games, etc.) can also be an important tool in enriching student
learning. Games like those presented in CS Unplugged [22] provide
a meaningful way of implementing active learning within a
curriculum [23].
Though an initial goal for this report was to also include a guide
for evaluating the effectiveness of games for CS education, given
the expansiveness of such a task, we will focus on evaluation and
assessment in follow-up work.
Game developers, educational theorists, and others may find
value within this report. However, the primary target audience is
academic researchers interested in developing games for
enriching CS education. This perspective is reflected throughout
this report.
This working group is unconventional in that its work will span
two ITiCSE conferences. This first report is divided into several
sections, starting with a background that introduces important

7
vocabulary related to game design theory, provides a summary of
previous related computer science education research, and
provides a summary of relevant educational psychology. It also
provides a brief review of games created for computer science
education and how these map to CS2013.
This is followed with case studies of four games designed to teach
CS concepts. The games are analyzed in two ways: 1) for their
design elements using the Mechanics, Dynamics, and Aesthetics
(MDA) framework and 2) for how one might evaluate their
effectiveness. Using information from this analysis, our
background research, and our previous experience creating
games, we provide a set of best practices for creating meaningful
games for CS education

BACKGROUND
There is a unique relationship between digital games and
computer science, since computer science is the foundation of
such games. But more than that, the programming process itself
contains many of the same elements found in games. In 1980,
Thomas W. Malone [84] stated:
“In some senses, computer programming itself is one of the
best computer games of all. In the ‘computer programming
game,’ there are obvious goals and it is easy to generate
more. The ’player’ gets frequent performance feedback
(that is, in fact, often tantalizingly misleading about the
nearness of the goal). The game can be
played at many different difficulty levels, and there are many
levels of goals available, both in terms of the finished
product (whether it works, how fast it works, how much
space it requires, etc.) and in terms of the process of reaching
it (how long it takes to program, etc.). Self-esteem is crucially
involved in the game, and there is probably the occasional
emotional or fantasy aspects involved in controlling so
completely, yet often so ineffectively, the behaviour of this

8
responsive entity. Finally the process of debugging a
program is perhaps unmatched in its ability to raise
expectations about how the program will work, only to have
the expectations surprisingly disappointed in ways that
reveal the true underlying structure of the program.”
Though other areas of study may also contain elements of this
process, programming offers a unique parallel. Malone’s insight
into how self-esteem is intertwined into the process is worth
noting, as CS educational research supports the notion that
learner and instructor self-esteem and self-efficacy are important
to the learning process. We mention this here, as it is important to
note that although games for CS education may be designed to
teach disciplinary concepts, such as programming constructs or
computational thinking, they may have positive or negative
unintended outcomes that could affect behaviors and beliefs
about computing.
This section is designed to provide a contextual background to
readers and describe the important elements of research relevant
to the remainder of this report. We define the value of using games
to teach computer science education. We also provide a summary
of vocabulary for game design, as well as CS educational research
and the broader educational psychology that is relevant to game
design.

The Case for Educational Games


Games can facilitate learning across a variety of disciplines in
multiple ways. Even games designed specifically for
entertainment have been shown to have educational value.
Though much has been written previously over the last couple of
decades about games in education, we provide a brief synopsis for
the case of using educational games for teaching computing.
Educational outcomes and competencies of modern education
are changing, and the quickly changing nature of computing
makes it important for educators to keep pace. Learners are
growing up with laptops, tablets and cellphones. Today, people
continuously learn and interact daily with information and
9
communications technologies [27]. The modern workforce needs
relevant education focused more on solving problems individually
and in groups. Jobs are changing and are often characterized by
increased technology use, extensive problem solving, networking
and complex communication [79].
A recent ESA Essential Facts Report [45] finds that 65% of US
households own a device used to play video games. Games are
culturally relevant to today’s learners, and previous research
shows that learners may feel more engaged when culturally
relevant tools are be harnessed for education [72]. Previous
research demonstrates that digital games sustain engagement
and motivation across time [52, 104], and that this engagement is
strongly associated with student achievement [119]. In addition,
students are more intrinsically motivated [53] and their work can
focus on complex thinking and problem solving through games
[19].
Traditional instruction can be improved by games given that they
can foster collaboration, decision-making, problemsolving,
communication, innovation, production, and procedural thinking
[66, 115]. The game World of Warcraft, for instance, is an example
of a game that drives individual specialization within cross-
functional teams working collaboratively to meet goals [53].
Games have broad appeal and the evidence does not support
many of the stereotypes perpetuated in popular media that only
young males play digital games [129]. Approximately 41% of
players are female, suggesting that technology acceptance is not a
significant challenge for a wide demographic.
Like other media, they do not automatically do this just by virtue
of being games. Freeman et al. [50] make a strong case for why new
active-learning approaches, such as games, are needed in STEM
fields. Games can be a valuable tool for enriching computer science
education, since they encompass a combination of motivation
techniques, student engagement, adaptivity, simulation,
collaboration and collection of performance metrics [55]. While
traditional instruction is primarily focused on concepts and
procedures, game-based learning in computer science can
1
0
improve the ability for students to apply learning outside of the
context in which it is learned, or transversal competence.
Additionally, educational games are designed based on learning
outcomes and can provide immediate feedback to the learner

ssssssssFormal Elements and the MDA Model


Beyond defining games, a further complication is establishing
the vocabulary of game design brought about through the formal
study of games. Game studies has yet to mature, which is to be
expected, as 2001 marked the year when game scholars declared
game studies a self-contained field of study [12]. However, as
key terms varies and this complicates the communication of
design knowledge and how we describe game experiences. For
example, terms such as gameplay are used in ambiguous ways and,
in the absence of a shared understanding, lack practical utility.

“principles” and “key elements” of gameful design. A game overall


can be characterised by a system of interaction which possesses
abstract qualities like player intention, perceivable consequence,
and narrative [31]. Even such a simple notion, however, has
weaknesses. The term narrative could refer to the story embedded
in the game by the designer, but it is also commonly used in a way
that includes the emergent story created by players. So, to clarify
what these principles and key elements are, we extend Church’s
[31] notions and summarise them in Table 1.
These elements define the aspects of a game that designers need
to consider. However, it is not clear how they work together to
form a game. To aid in this endeavour, several models exist (e.g.,
[107, 65]). One such model, which has seen widespread adoption
by both game scholars and games industry professionals, is the
1
1
MDA Model [65]. This is the notion that a game experience can be
understood in terms of three interconnected and interrelated
concepts: mechanics; dynamics; and aesthetics.
The mechanics are the specific parts of a game design, comprised
of elements such as the rules of the game. These could be the
game’s possible states, transitions from one state to another, ways
in which players trigger these transitions, representation of state,
and so on. In other words, they are the parts of the game that limit
or restrict the player’s actions, control the flow of the game, and
encode some kind of meaning. The dynamics refer to the behaviors
of the player-game system as a game is being played. In

Figure 1: The interplay of mechanics, dynamics, aesthetics, and


culture that is used to inform a game’s design.

other words, the actual flow of the game. This flow emerges from
the interaction of the mechanics with each other in response to
player action. The aesthetics, then, refer to the resulting
experience of playing the game. This is conceived from the
perspective of a player as they play. This is distinct from the theme
of the game and the “look and feel” of the user interface. It instead
refers to the player’s experience itself. It is sometimes framed as
the set of emotions that a game may evoke.
The mechanics drive the dynamics because they constrain the
actions the player may take. However, the player also has a highly
influential role in the formation of the game dynamics, since
games typically provide players with a choice of possible actions.
Further, the skills of some players may be insufficient to sustain
certain dynamics, while other players discover subversive ways to
exploit the available mechanics in ways that designers may not
have anticipated. These different dynamics can have a profound

1
2
effect on the resulting aesthetic of the game. Again, there is
variance. For example, solving a puzzle may evoke satisfaction and
pride. However, if the puzzles are too repetitive, they may evoke
boredom and annoyance. Players can also differ in the way they
perceive an experience. Figure 1 illustrates an adaptation of MDA,
where Scott [110] proposes culture as a moderating factor
alongside dynamics. On the one hand, culture may shape a
player’s behaviour, while on the other, culture may shape a
player’s values and thereby influence how they interpret signs
and symbols to construct meaning. Hunicke et al. [65] state:
“From the designer’s perspective, the mechanics give rise
to dynamic system behavior, which in turn leads to
particular aesthetic experiences. From the player’s
perspective, aesthetics set the tone, which is born out in
observable dynamics and eventually, operable mechanics.”
It is also important to highlight a game designers’ focus on
aesthetics. As computer science students and educators, it may be
tempting to focus primarily on the mechanics, since art, sound,
and user interface design are typically not components of
computer science education. However, the aesthetics are often
what makes a game fun and more engaging, and considering
aesthetics can be pivotal to a game’s success.

Players
As with teaching, the target audience of a game is of primary
consideration. Players moderate the aesthetics of the games they
play, as their value systems will shape their interpretations, and
different dynamics may be accessed by different demographics
[133, 110]. Several player models have been considered and used
in designing games for different target demographics. Each of the
following player models with various levels of complexity have
been used to identify player preferences, providing information to

1
3
the designers who can then integrate those preferences within
their game. Though not a comprehensive list, this provides some
insight into how to consider player preferences within gameplay.
When designing a game, designers can link gameplay features to
specific player preferences to achieve specific goals. For example,
a game designer’s target demographic may be achievers, who are
known to enjoy competition and the ability to achieve high scores
and earn rewards.
Bartle’s Taxonomy. The Bartle’s Test was developed by Andreasen
and Downey, who based it on Richard Bartle’s player type analysis
[21]. This test is a questionnaire that was originally designed for
players of virtual worlds to take to provide insight into their
preferred play style. Four play styles are provided: Killers,
Achievers, Socializers, Explorers [20]. Also referred to as Hearts,
Diamonds, Clubs, and Spades, Bartle attempted to classify player
preferences in an effort to predict players who may enjoy dungeon
crawlers. Socializers (hearts) enjoy forming relationships with
other players within a game. Achievers (diamonds) enjoy meeting
goals in games and being rewarded for their efforts. Killers (clubs)
enjoy dominating others in gameplay using in-game means.
Explorers (spades) enjoy games that provide them with an
opportunity to explore and enjoy free-play. These styles are not
mutually-exclusive, and in fact, players often enjoy combinations
of these styles.
BrainHex. The BrainHex [1] is a broader model that defines seven
player archetypes based in part on neurobiological research:
Seeker, Survivor, Daredevil, Mastermind, Conqueror, Socialiser,
and Achiever [90]. More closely aligned with genres than Bartle’s
Taxonomy, it can still be used as a tool within a target demographic
(e.g. girls aged 10–13 in a particular middle school setting) to help
in determining the types of games they may prefer, thereby
creating a game to meet the preferred player styles of that
demographic.
Unified Model. The Bartle’s Test has been further adapted to
include the Keirsey Temperaments and the Bateman DG1 Model in
a Unified Model, as well as the alignment of these models with 7
1
4
others [124]. This also maps to the MDA framework of game
design, which defines a game based on Mechanics, Dynamics, and
Aesthetics. Motivation between the different types of players as
well as their preferred method of solving problems to achieve
goals differs. Their overall goals (Do, Have, Know, or Become)
provide a single action word summary into their play styles.
Five Factor Personality Traits. More recently, the Five Factor
Personality Traits survey, a validated instrument used in
psychology, has been used to predict game play preferences and in
designing games. Game designers at Ubisoft employ the Five
Factor Personality Inventory (also called OCEAN or the Big Five)
to measure five opposing dimensions in an individual’s
personality, Openness (versus Closedness) to Experience,
Conscientiousness versus Lack of Conscientiousness, Extraversion
versus Introversion, Agreeableness versus Hostility, and
Neuroticism versus Emotional Stability [126]. The Inventory has
been used in one study to show to that “conscientiousness was
negatively correlated with perceived use of first-person shooter
games and extraversion was positively correlated with both liking
and perceived ease of dancing games. Agreeableness was
positively correlated with liking of dancing games” [37]. An
alternative to OCEAN is HEXACO, which assigns personal
characteristics through Humility (H), Emotionality (E),
Extraversion (X), Agreeableness (A), Conscientiousness (C), and
Openness to Experience (O) [75].
Other psychosocial models. Though there are several ways to
define player styles, other psychosocial models can be used. For
example, Hofstede’s cultural model has four dimensions: power
distance (weak or strong), uncertainty avoidance (weak or strong),
individualism (versus collectivism), and masculinity (versus
feminism) [60]. One could form the basis for analyzing player styles
and preferences using such models.
These models encourage examining player preferences often
based on personality, in a very similar way that culturally relevant
pedagogy theory is used to develop curriculum [72]. These
models move beyond personal biological identities, with gender,
1
5
race, and ethnicity, for example, not given consideration. In a
classroom with learners, however, additional considerations may
need to be made: environment, socioeconomic influences,
instructor abilities and motivation, and more [57]. If seen as a tool
or only one form of several medium used in the classroom, games
should also be contextualized by the instructors. That is, the
instructor is still in control of the the learning process and
interpreting the in-game learning externally provides a method of
instructors integrating this knowledge—which is also referred to
as pedagogical content knowledge [118].
2.3Effect on students
Educational games may produce a number of learning and
psychological effects. These effects may be intended or
unintended. We list the most relevant effects of educational
games, as well as representative measures of these effects:
• Cognitive development. This effect can be summarized by
saying that games may present an opportunity for students to
learn more deeply. For example, according to Bloom’s
taxonomy [14], there are six levels of increasing cognitive
development, or according to the SOLO taxonomy [24], a
student may give responses to a task in five levels. Cognitive
development can be measured by means of different variables,
such as:
– Assessment performance.
– Time necessary to accomplish a task.
– Accuracy in performing a task.
• Affective and motivational effects. This category clusters a
number of subjective phenomena:
– Acceptance. Technology acceptance is a relevant issue in the
area of work and training [36]. Some students (especially
adult learners) may refuse the use of games in education.
– Emotions experienced. There is no universally accepted
classification of emotions. Some authors have proposed a set
1
6
of basic emotions, other being composed of the basic ones.
Thus, Zinck and Newen argue that the four basic emotions
are joy, anger, fear and sadness [134].
– Motivation. According to the theory of self-determination,
there are four classes of motivation towards a subject matter
or activity: intrinsic, extrinsic via identified regulation,
extrinsic via external regulation, and amotivation.
• Transversal skills or competences. In recent years, concern
about these general skills has increased. Some examples are
self-efficacy, communication or leadership skills.
• Behavior change. Computing students may develop
undesirable behaviors, such as cheating or hacking.
Educational games can guide students to consider their
behaviors in their academic and professional development.
Other effects can also be achieved with games but are not directly
relevant to CSE: motor skills (e.g. motor coordination), perceptual
and cognitive effects (e.g. attention, or visual or spatial skills), and
physiological effects (e.g. heart rate).

3. SURVEY
We examined over 100 unique games that have been or are
currently available for use in teaching computing concepts. Each
review consisted of inspecting available documentation and
commentary and, when possible, playing the game. Using this
information, we categorized each game with respect to numerous
pedagogical and game characteristics [5]. These games were
published over the last several decades, ranging from 1982 to
2016. Of the games reviewed, 34 are available commercially, 51 are
freely available, and 15 no longer appear to be available. In this
section, we provide a general summary of the games and a
classification of the games in context of the ACM/IEEE Computer
Science Curricula 2013 [13].

1
7
1Summary of Games for CS Education
With respect to the general computing topics addressed by the
games, just over half (64) focus explicitly on some aspect of
programming. Not surprisingly, within this group, topics typical of
introductory programming classes are addressed by numerous
games: arrays, assignment, data types, debugging, encapsulation,
event handling, expressions, I/O, iteration, modularization, object
orientation, parameters, recursion, selection, sequence, testing,
and variables. There are also more specialized programming-
related games that address artificial intelligence, algorithms,
bottlenecks, ciphers, concurrency, critical thinking, fault tolerance,
instruction sets, interprocessor communication, messaging,
memory access, multiagent systems, problem recognition,
registers, sorting, synchronization, tree traversal, and other topics.
We found that 17 of the games focus primarily on computational
thinking, in the sense defined by Wing [130]. Of the games that
focus on neither programming nor computational thinking, the
topics addressed include artificial intelligence, architecture,
circuits, data types, security, sensors, and systems. As part of the
review process, we attempted to identify specific learning
outcomes addressed by each game through either literature or by
playing the game. Though these details are provided in the online
appendix [5], they could not be summarized in a meaningful way.
We characterized the games in terms of the e-Learning Goals they
claimed or that we inferred based on our experimentation. Using
Clark and Mayer’s cognitive task analysis [32], we identified
“Inform” level goals for almost half of the games (55), “Perform
Procedure Tasks” for more than half (73), and“Perform Strategic
Tasks”for almost half (55). A majority of the games reviewed
specify their targeted demographics in terms of either age group
or educational level. All age levels from 3 to adult and grade levels
from preK to post-graduate are covered. Classifying the games
using the five stages of experience levels, novice, advanced
beginner, competent, proficient, expert, a fair number of games

1
8
state that the target specific levels of prior aptitude, education,
familiarity, or interest in either computing or gaming [42]. 61
(59.8%) targeted novices, 59 (57.8%) targeted advanced
beginners, 23 (22.5%) targeted those competent in computing
concepts, and 2 (2.0%) targeted those proficient in computing
concepts. We found documentation indicating that two of the
games (1.9%) were created to specifically target females.
The games reviewed include representatives of a wide variety of
genres, including action, adventure, arcade, board, dance, MMO
(massively multiplayer online), puzzle, RPG (role playing game),
(turn-based/real-time) strategy. Likewise, the user interface
styles employed vary widely, including command line, drag-and-
drop, first/third person graphical (key-based, mouse-based,
controller-based), and pointand-click. Finally, there is substantial
variety in the game mechanics. For example, many games are
either single player or competitive multiplayer, but some are
cooperative multiplayer. Also, within those games that use drag-
and-drop interfaces, in some cases the objects being manipulated
represent machine instructions, while in others they are
gamespecific actions.
Many of the games reviewed are based on established game
engines, such as Bioware Aurora, Codea, LibGDX, Moai, OpenFL,
Pygame, RPGMaker, Spring engine, XP, Unity, and XNA. Others are
built using identified languages and libraries such as .NET, C, C++,
C#, CSS, Flash, Git SCM, HTML, iOS, Java, Javascript, Logo, Lua, Ruby,
Scratch.

3.2Games mapped to CS 2013 Categories


We analyzed the games in context of the ACM/IEEE Computer
Science Curricula 2013 to identify which of the 18 computing
knowledge areas that each game targeted [13].
For the games that we were able to classify, the majority (75.5%)
could be used in teaching Software Development Fundamentals
(SDF). Nearly one-third (28.4%) taught Algorithms and
Complexity (AL) concepts. Table 2 shows the breakdown of the
categories. Note that some games could be used to teach concepts
1
9
in two or even three categories. Additionally, it is worth noting
that none of the games reviewed target the following areas: IM
(Information Management), NC (Networking and
Communications), OS (Operating Systems), and PD (Parallel and
Distributed Computing).
We analyzed this further and drilled down to the concept areas.
The vast majority of the games target concepts in the SDF
category. Within the three concept areas targeted in SDF, the
concept areas of Fundamental Programming Concepts (46 or
45.1% of all games reviewed), Algorithms and Design (25 or
24.5% of all games reviewed), and Algorithmic Strategies (19 or
18.6% of all games reviewed) have the most games suitable for
teaching these concepts (Table 3).
Based on prior evidence that games are useful for inspiring
student interest, it is natural that most of the games are designed
for beginners, and thus SDF and AL, which
Knowledge Areas Count
SDF (Software 77
Development
Fundamentals)
AL (Algorithms and 29
Complexity)
CN (Computational 11
Science)
GV (Graphics and 10
Visualization)
AR (Architecture and 9
Organization)
IAS (Information 6
Assurance and Security)
SE (Software 5
Engineering)
HCI (Human-Computer 4
Interaction)

2
0
IS (Intelligent Systems) 4
SF (Systems 3
Fundamentals)
DS (Discrete Structures) 3
PBD (Platform-Based 2
Development)
SP (Social Issues and 1
Professional Practice)
PL (Programming 1
Languages)
Knowledge Area Concepts #
AR (Architecture and Digital Logic and Digital Systems 1
Organization)
Algorithmic Strategies 19
Fundamental Data Structures 10
AL (Algorithms and Complexity) and Algorithms
Advanced Data Structures, 1
Algorithms, and
Machine Level Representation of 2
AR (Architecture and Data
Organization) Assembly Level Machine 1
Organization
CN (Computational Science) Data, Information, and 11
Knowledge
DS (Discrete Structures) Basic Logic 3
GV (Graphics and Visualization) Fundamental Concepts 10
Programming Interactive 3
HCI (Human-Computer
Systems
Interaction)
Foundations 1
Security Policy and Governance 1
IAS (Information Assurance and
Network Security 2
Security)
Threats and Attacks 1

2
1
Cryptography 2
Basic Search Strategies 2
IS (Intelligent Systems)
Fundamental Issues 1
PBD (Platform-Based Game Platforms 1
Development) Web Platforms 1
PL (Programming Languages) Object-Oriented Programming 1
Fundamental Programming 46
SDF (Software Development Concepts
Fundamentals) Algorithms and Design 25
Fundamental Data Structures 3
Tools and Environments 1
Software Project Management 2
SE (Software Engineering) Software Verification and 1
Validation
Software Reliability 1
SF (Systems Fundamentals) Computational Paradigms 3
SP (Social Issues and Security Policies, Laws and 1
Professional Practice) Computer Crimes
Table 3: Games by Category and Area.
Table 2: Number of Games classified in CS knowledge areas.

include many basic and introductory topics to computer science,


would include the vast majority of the CS educational games.
However, we note that there are considerable areas with few or no
games that teach these concepts, leaving a wide variety of subjects
that researchers could target in future games.

4. CASE STUDIES
Of the games that were evaluated by the group, we selected and
performed a more rigorous analysis on four: The Foos, Human
Resource Machine, Lightbot, and PicoBot. These games were
chosen to represent well-designed games across a range of
demographics, their quality, and their usefulness in appearing to
meet their stated learning outcomes. We use these games as
2
2
lenses into the array of games for computer science education,
first describing each game using the MDA model and then
comparing and contrasting the four in an effort to gauge how
design elements affect the player’s experience. This review serves
as a backdrop for the next section in which we provide suggested
best practices for designing games for use in computing
education.
4.1 The Foos
The Foos, a commercial game developed by codeSpark [3],
teaches basic programming concepts to students 5-10 years old.
The game is available for iOS and Android. A simplified version
can be played online. This game is endorsed by Code.org as an
activity for the Hour of Code [2].
The Foos presents the player with a series of scenes featuring an
avatar, some obstacles, some bonus rewards, and a final prize. The
player constructs a series of moves her avatar can make in order
to capture the prize. For example, in Figure 2, the avatar must
jump on and off the wooden boxes in order to get the donut. The
green collectibles are bonus rewards the player can collect along
the way to the goal. For this level, the available instructions are
move and jump. After constructing an appropriate sequence of
steps, the player runs her program, which steps through the pro-

Figure 2: The tile-based programming editor that a player uses to


guide the avatar to the donut in early level in the The Foos.

2
3
Figure 3: The heads-up display that reports the player’s
achievements in The Foos.

grammed movements with playful sound effects and music.


If the avatar reaches the prize, the avatar dances a victory jig,
while points accumulate in the heads-up display shown in Figure
3. If the player constructs an erroneous sequence, the avatar still
follows the instructions but does not reach the final prize. The
player is allowed to modify the instruction sequence without
penalty until she meets the goal.
Since the game is aimed at young children, it does not require
reading skills. It provides visual hints to help the player
understand the drag and drop interface and how the available
instructions work. This also makes the game easily played by
students whose first language may not be English. As levels
progress different types of instructions are introduced that allow
the player to solve increasingly difficult puzzles. The game
incorporates 10 different scenarios, each with specific learning
objectives: sequences, commands, parameters, events, loops,
efficiency, endless loops, conditional statements, and debugging.
4.2Human Resource Machine
Human Resource Machine is a commercial game published in
2015 by Tomorrow Corporation [10], which is available for
Windows, Mac, Linux, iOS and Android platforms. It is targeted for
players age 9 and above.
The game opens outside the drab-colored office building,

2
4
Figure 4: The avatar executing an assembly program that outputs
the maximum of each input pair.

whereupon the player chooses an employee avatar with large


blinking eyes, dressed in a desaturated suit. Instead of choosing a
name, the player chooses an impersonal employee number.
Work begins at once for this employee, who appears in a room
with two conveyor belts. One belt is marked “In” and the other
“Out.” A manager sitting at a desk gives the employee her first
task: move all the boxes from In to Out. While the look and feel of
Human Resource Machine is very different than The Foos, the
game mechanics are quite similar. The player must construct a
sequence of moves the employee can follow to accomplish the
objective.
In the first level the available commands are ->inbox and outbox-
>. The former causes the employee to pick up a tile from the input
conveyor belt and the latter causes the employee to place the tile
she is holding on the output belt. The player drags and drops
instructions to create a sequence in the program editor panel on
the right. When the command sequence is executed, the employee
runs between the two belts, picking up and dropping off tiles as
directed. The interface is shown in Figure 4.
If the player fails to compose a sequence that outputs the
expected tiles, the manager reprimands the employee. The player
modifies the sequence without penalty until the expected and
actual results match, at which point, a year passes and the
employee is promoted to a more complex task. The player’s

2
5
progress is marked on the “corporate ladder,” a game screen
shown in Figure 5 that shows a verticallyoriented map of the
game’s levels.
In subsequent levels, new commands are gradually introduced
that allow the employee to accomplish increasingly difficult
operations on the input. Additional commands include jump,
conditional jump, store or retrieve tiles, add or subtract tile
values, increment and decrement tile values, and so on. The final
“boss” is a sort routine.
When a player beats a level, a report is generated by
management. The player’s program is scored using two metrics:
the number of instructions used in the program and the number
of runtime steps required to execute it. This dual scoring reflects
a tension commonly found in software development, in which one
often chooses between minimizing code size and minimizing
execution time. If the scores are below a certain threshold, the
player’s achievement is noted. The game informs the player that
optimizing one metric may produce a suboptimal score for the
other metric. Multiple

Figure 5: The corporate ladder that marks the player’s progress in


Human Resource Machine.

solutions will sometimes need to be written to earn both


achievements, and the player may accordingly save multiple
solutions.
By the time the employee has reached the top of the corporate
ladder, the player has gained fluency in an 11instruction assembly
language.

2
6
The players of Human Resource Machine are not expected to have
prior programming experience, as the developers state on the
game’s website: “Don’t worry if you’ve never programmed before
- programming is just puzzle solving. If you strip away all the 1’s
and 0’s and scary squiggly brackets, programming is actually
simple, logical, beautiful, and something that anyone can
understand and have fun with!”
They also identify the intended audience as “expert nerds.”
The developers do not discuss particular learning outcomes or
assessment. However, the comments from the game’s reviews on
Steam provide some informal but insightful responses from
players:
• “Due to the fact that there is ’optimization challenges,’ I do get
the feeling I would return to some of the earlier puzzles to
beat/match the best possible.”
• “Everyone will probably enjoy this game for a little while, if you
like solving abstract problems and basic programming you’ll
enjoy it more.”
• “After I finished this, I realised that I’d accidentally learned how
to write efficient assembly-code. Hooray!”
• “If you’re a CS student that hasn’t yet taken an assembly course,
this is a great intro. The assembly language is very conventional
(unlike TIS-100), so many of the skills and strategies you learn
will be directly applicable to, say, MIPS or x86.”
4.3 Lightbot
Lightbot is a game developed by Danny Yaroslavski [4], based on
a game he first built in high school. It is available as an online flash
game or for iOS and Android. The game comes in two versions, one
targeted for players aged 4–8 and one for players age 8 and above.
Lightbot is endorsed by Code.org as an Hour of Code [2] exercise.
The mechanics of this game are very similar to both The Foos and
Human Resource Machine. In this game the player is presented

2
7
with a grid of tiles and a robot, as shown in Figure 6. The player
constructs a sequence of moves to

Figure 6: The interface of Lightbot. The player uses a tilebased


program editor to navigate a robot across a world of blocks, some
of which need to be illuminated.

direct the robot to traverse the grid. Available instructions include


move, turn, light, and jump. As in the previous games, the player
runs the program to step through the programmed sequence. The
objective of the game is to have the robot light up every dark blue
tile in the grid.
The space provided for the tile sequences is limited, forcing the
player to consider code size. As the game progresses, the size
constraint adds substantial complexity to the puzzles. Similar to
The Foos, if the player constructs an erroneous sequence of
moves, the robot will follow its directions but will not light up all
the dark blue tiles. The player can revise and rerun a sequence
without penalty. Later levels incorporate subroutines and
recursive calls.
4.4 Picobot
Picobot [9] is a Karel-like [96] JavaScript game created by Zach
Dodds and Wynn Vonnegut for their introductory computer
science course at Harvey Mudd College. In the game, players write
rules that instruct the green Picobot to navigate a two-
dimensional grid world. The world consists of white, open cells
that Picobot can traverse and blue wall cells that are

2
8
impenetrable, as shown in Figure 7. When Picobot visits a cell, it
turns gray. The goal of the game is to have the Picobot visit all of
the white cells, turning them all gray.
The game models a finite state machine. The user defines rules
that dictate the Picobot’s next move and new state based on the
current state and which cells are in the immediate neighborhood.
For example, the rule “0: Nxxx -> W 1” specifies that if Picobot is in
state 0 and only its northern neighbor is barred (blue) and its
other neighbors are free (white), Picobot should move west and
go to state 1. An asterisk can be used as a wildcard. For example,
the rule “1: *S** -> S 1” specifies that if Picobot is in state 1 and
the southern neighbor is open, Picobot should move there and
remain in state 1. This rule effectively moves the Picobot south as
long as south is open.
Like the previous games, Picobotintroduces the player to basic
programming concepts, but using a declarative programming
language. It also provides visual analogy for programming
problems that provides immediate, clear feedback of both success
and failure. The interface also has a textual

Figure 7: The interface for Picobot, whose 2D game world is


navigated much like a Turing Machine with a 2D tape. The goal of
each level is to visit all cells using only state machine rules based
on neighborhood information.

display of the current state of the program including buttons to


step through the execution that is helpful for debugging. Picobot

2
9
has multiple maps with various levels of difficulty that encourage
players to seek and solve additional challenges.
Picobot is not polished to the same degree as the previous games.
Players enter rules using the keyboard. Its error messages can
often be inscrutable to novice programmers. Picobotdoes not
provide hints or have a builtin tutorial. It is intended to be
introduced in class by the instructor.
4.5Compare and contrast
The four games we reviewed are similar in many ways, but
provide substantially different user experiences. These examples
help illustrate the relationship between mechanics, dynamics, and
aesthetics and how they work together to make a game unique.
4.5.1Aesthetics
From the player’s perspective, a game is an aesthetic experience.
Hunicke, LeBlanc, and Zubek [65] suggest the following taxonomy
for categorizing the user experience:
1. Sensation: Game as sense-pleasure
2. Fantasy: Game as make-believe
3. Narrative: Game as drama
4. Challenge: Game as obstacle course
5. Fellowship: Game as social framework
6. Discovery: Game as uncharted territory
7. Expression: Game as self-discovery
8. Submission: Game as pastime
This list is not meant to be exhaustive and for the purposes of
educational games we can add a ninth experience:
9.Learning: Game as learning tool
These experiences are not mutually exclusive, in fact, games
typically aim to deliver on many of these objectives.

3
0
All four of the games we reviewed provide challenge. In each
case the difficulty of the challenge is targeted to a specific age
group/audience.
The Foos and Human Resource Machine both have a narrative
structure. It is strongest in Human Resource Machine where the
player is likely to empathize with the hapless employee trapped
in the dreary corporate world. In contrast the narrative structure
of The Foos is simple and fun and clearly more appropriate for a
younger audience.
All games provide some sort of sensation. The Foos and Human
Resource Machine use high quality graphics and sound to create a
rich sensation in the player. One can hardly resist being drawn
into the joyous world of The Foos with its fun characters, bright
graphics, fanciful animations, and cheerful sounds. In contrast
Human Resource Machine uses desaturated colors, repetitive and
mechanistic sounds, and mournful characters to convey the
dreariness of the corporate world (and the advantages of
automation). While graphics and sound are often considered
superfluous in learning games, they can greatly enhance the
user’s experience [6]. Based on admittedly anecdotal evidence, all
of our games we reviewed are effective learning tools for their
specific learning objectives and the audiences they target. The
Foos and Human Resource Machine provide a richer user
experience than Lightbot and Picobot. But that is somewhat
essential since they are teaching children programming concepts.
The fun of Lightbot and Picobot is derived largely from solving
difficult puzzles, which is perfectly fine for an older and possibly
captive classroom audience. Who would play if the games weren’t
fun? But that richness is not always easy or inexpensive to achieve.

4.5.3Mechanics
Mechanics are the rules of the game and the actions and controls
available to the player. The first three games have very similar
mechanics; the player drags and drops instructions to creates a

3
1
sequence their avatar follows to achieve some goal. This provides
a good introduction to imperative programming.
Picobot is different than the other three games in that its rules
are defined using a declarative programming language, which
may not be appropriate for classrooms that focus on imperative
programming. But this difference can also be a strength,
particularly an introductory computer science course that aims to
expose students to multiple programming language paradigms.
Human Resource Machine has the most sophisticated scoring
system providing two separate metrics by which a solution can be
evaluated: code size and execution time. Lightbot only focuses on
the first of these metrics but does so with a very hard constraint;
limiting the space to describe a solution effectively limits the
player to efficient solutions. The Foos scoring system is the most
forgiving; even wrong solutions can garner points. This is
appropriate given its young target audience.
4.5.4Summary
We consider each of these games to be fun learning tools for their
intended audiences, and as such each has the potential to be
effective. Games developed by professional designers/developers
with access to considerable resources are going to have greater
polish. But simple games that are designed for specific use in a
classroom can be highly effective in their own right and, therefore,
should be considered as another tool for enhancing learning.

5. SUGGESTED PRACTICES FOR DESIGNING GAMES FOR USE IN CS


EDUCATION
Based on our review of games, our experience as computer
science educators, our understanding of educational research, and
our experience designing and developing games, we provide
considerations for designing games for use in computer science
education. We discuss useful and relevant aspects of educational
frameworks to consider when design-

3
2
Figure 8: Hainey’s evaluation framework for games-based learning
evaluation.

ing, basic game production practices to aid a researcher new to


game design, and methods for enhancing the player (student)
experience. This is followed by techniques for integrating games
into curriculum. Though not an exhaustive list, we propose that
these are useful starting points for creating games for use in CS
education.
5.1Infusing Educational Frameworks
Hainey’s dissertation [57] considers a set of seven factors that
influence learning in the context of games. These are shown in
Figure 8. Each of these categories of influencing variables are
further defined by Hainey to provide a reference for evaluation
methods, and each is important for instructors to consider the
impact of games as a learning tool. Like books, videos, and other
teaching tools, their impact is often heavily influenced by many
other factors.
However, although striving to evaluate a newer media is a
desirable goal, holding a formal evaluation of games as a litmus
test for whether or not they should be used for learning
contradicts what instructors do in classroom preparation each
day. Shulman [118] refers to this as the “wisdom of practice,” or
the practice of instructors to choose assignments, activities,
discussion questions, lecture topics and more based on their
knowledge and wisdom of the content and how their particular
set of students learn. In considering wisdom of practice, games
can be carefully selected by instructors to incorporate them into
their curriculum in meaningful and influential ways.

3
3
Many games for learning may be used as stand-alone games for
independent learning by the learners; however, providing context
for the learner’s in-game experiences is certainly part of the game-
based learning environment [92]. The manner in which the
instructor integrates the learning experience from games into the
classroom is very important to its effectiveness.
Based on this, integrating the learning into the classroom is an
important aspect of the curriculum design process, and
instructors can liken themselves to the Dungeon Master (DM) in
Dungeon and Dragons. The DM sets up the context for the
dungeon or game. They provide assistance during the game to
clarify any questions and can debrief after the game.
Important Caveats
Though this set of guidelines is not comprehensive, it has the
potential of being overwhelming for someone who has not yet
created games for learning. We recommend researchers new to
this field find one or two areas on which to focus, then expand
those areas as more work is considered.
As previously mentioned, though our initial goal was to provide a
guide for assessing games for efficacy, scope and time prevented
us from engaging in that activity. This should by no means be
taken to imply that this goal is not as worthy. We recognize its
importance and intend to pursue that activity in whole or in part
during the 2017 ITiCSE Working Group.
We note here that beyond knowledge and skills, attitudes and
dispositions are valid reasons for providing games as a learning
tool in CS. Motivation, engagement, happiness, satisfaction, and
perceptions of the field among students across a wide range of
demographics are important aspects of games for CS education. As
educators, the “wisdom of practice” may not be enough for this
new medium, and we may be interested in various levels of proof
that games are effective. A wide range of tools for understanding
effectiveness can and should be used. For example, test scores,
students surveys, quantitative or qualitative research methods,
and/or rigorous evidence (replicated, longitudinal) are all forms

3
4
of data that can be used to determine whether a game may be
effective for a particular group of students.
The next two sections on game development processes and game
design for games for use in CS education are presented in the
context of games for CS education where possible. These two
sections are also enhanced by Section 5.5, which discusses best
practices integrating games into the CS curriculum or a CS
classroom.

Basic Game Development Processes


Game design is the process of designing the game. Game
production is the process of taking the design and implementing
it. There are many books and articles on game production, and in
this section we highlight a few important aspects of development
that a researcher newer to creating game for CS education might
find useful.
Agile processes. Agile processes [7] are often used in managing a
game project. A project is broken into tasks or sprints. In a
classroom setting, the first sprint, for example, may last two weeks
and during that time students may be responsible for creating a
game proposal. One of the values of agile development is the
reflection at the end of each sprint of what is going well with the
project, what needs to be improved, and what might be standing
in a team member’s way.
Moodboards, Storyboards, Ripomatics. Moodboards provide a
visual representation of the art style, typography, and early visual
design and themes of the game to convey its look and feel. An
example is shown in Figure 9. Storyboards provide a visual
representation of gameplay and narrative. An example is shown in
Figure 10. Ripomatics are scenes that are“ripped from”existing
media such as film, TV, or games to provide a concept of the look
and feel of the proposed game. All of these can be used to create a
consistent look and feel across the game and are particularly
useful when multiple people are working on the game.
Paper prototyping and testing. Paper prototyping is the process
of presenting a game idea through storyboards or mockups of a
3
5
game’s scenes (or a combination) to present your game in a paper
format to potential players. This form of test has been proven to be
very effective to gauge how fun is one’s game, to determine
whether the flow of the game is effective, and to determine if
players are learning. This process enables the developers to get
feedback very early in the design process, before actual production
of the game

Figure 9: Sample moodboard for the game Wake Up, Koala!, a


game developed by undergraduate students to raise awareness
about Sjogren’s Syndrome.¨

begins. It is much easier to correct major issues with flow and


game mechanics before starting to program rather than after time
and effort has been spent on programming the early prototype of
the game.
Quality Assurance and User Testing. Testing is a necessary and
important process and is critical for enhancing the user
experience. No one likes to have flow broken when learning due
to problems with their learning aides! We have used two types of

3
6
testing, one with users to gain critical feedback on concept builds,
early prototypes, alpha, and beta builds. In this type of test, users
are solicited for feedback on how to improve any part of the
system. The other, quality assurance, is the development team’s
responsibility. This type of test includes the painstaking process
of testing each element within the game (buttons, scene
transitions, scoring, general functionality, and more) as well as
art, animation, and sound.

Designing for the User Experience


Within this section we provide a set of design principles for game
development. Though not meant to be comprehensive, we
carefully selected elements that are important to consider when
designing a game for use in CS education. The intent is to provide
a best practice cheat sheet for creating games for CS education to
those newer to game design and development. This toolset
considers best practices in each area and is designed to suggest
methods for improving the impactfulness of the games.

Figure 10: Sample storyboard for the game Wake Up, Koala!

Define the Learning Outcomes


Games have been shown to improve learning in some computer
science education domains, such as computer memory [95].
Embedding sound instructional design into games for learning is
3
7
needed if we want the games to be effective. O’Neill, Wainess, and
Baker [92] note that many games for learning have historically
missed the mark on this. They make the case that CRESST and
Kirkpatrick’s models for learning can be evaluated and applied
within a game’s design.
The Understanding by Design model [128] is also relevant to
game design for education. The three major stages of this
backward design model is to 1) identify the desired results, 2)
determine the acceptable evidence, and 3) plan the learning
experiences and instruction. These stages can be tailored for the
development of games for computing education as follows:
• Stage 1:
– Establishing learning goals for the player
– Defining the set of essential questions for achieving these
goals
– Identify the understandings that are desired
– Specifying what key knowledge and skills students will
acquire as a result of playing the game
• Stage 2:
– Identify the tasks that will be performed in the game to
provide the evidence needed to ascertain the player’s
understanding of the learning material
– Identify any other evidence that should be collected to
determine if the desired results in Stage 1 have been met.
Include time playing, time spent in each level, incorrect and
correct moves, etc.
– Provide a manner for the players to reflect on their learning
experiences
• Stage 3:
– Once Stages 1 and 2 have been drafted, design the sequence

of experiences that the players will need to engage with in


the game, develop by playing the game, and
3
8
SOURCE CODE:
my_game_project/

# Initialize Pygame

pygame.init()

# Set up the game window

screen_width = 800

screen_height = 600

screen = pygame.display.set_mode((screen_width,
screen_height))

pygame.display.set_caption("Simple 2D Platformer")

# Colors

WHITE = (255, 255, 255)

BLACK = (0, 0, 0)

# Create clock for controlling the frame rate

clock = pygame.time.Clock()

# Create Player and Platform instances

3
9
player = Player(screen_width // 2, screen_height - 100)

platforms = [

Platform(0, screen_height - 50, screen_width, 50), # Ground


platform

Platform(150, 400, 200, 20),

Platform(400, 300, 200, 20),

Platform(650, 200, 200, 20)

# Game loop

while True:

screen.fill(WHITE)

# Event handling

for event in pygame.event.get():

if event.type == pygame.QUIT:

pygame.quit()

sys.exit()

# Update the player and platforms

player.update(platforms)
4
0
player.draw(screen)

# Draw platforms

for platform in platforms:

platform.draw(screen)

# Update the display

pygame.display.flip()

# Set frame rate to 60 FPS

clock.tick(60)

2. player.py – Player class

python

Copy code

import pygame

# Player Class

class Player(pygame.sprite.Sprite):

def __init__(self, x, y):

super().__init__()

4
1
self.image = pygame.Surface((50, 50)) # Create player as a
50x50 block

self.image.fill((0, 128, 255)) # Blue player color

self.rect = self.image.get_rect()

self.rect.x = x

self.rect.y = y

# Movement variables

self.vel_x = 0

self.vel_y = 0

self.speed = 5

self.gravity = 0.8

self.jump_power = -15

self.on_ground = False

def update(self, platforms):

# Get keys pressed

keys = pygame.key.get_pressed()

# Horizontal movement

if keys[pygame.K_LEFT]:
4
2
self.vel_x = -self.speed

elif keys[pygame.K_RIGHT]:

self.vel_x = self.speed

else:

self.vel_x = 0

# Jump

if keys[pygame.K_SPACE] and self.on_ground:

self.vel_y = self.jump_power

self.on_ground = False

# Apply gravity

self.vel_y += self.gravity

# Update position

self.rect.x += self.vel_x

self.rect.y += self.vel_y

# Check collisions with platforms

self.check_collisions(platforms)

4
3
def check_collisions(self, platforms):

self.on_ground = False

for platform in platforms:

if self.rect.colliderect(platform.rect):

if self.vel_y > 0: # falling down

self.rect.bottom = platform.rect.top

self.vel_y = 0

self.on_ground = True

elif self.vel_y < 0: # jumping up

self.rect.top = platform.rect.bottom

self.vel_y = 0

# Prevent the player from moving off the screen

if self.rect.left < 0:

self.rect.left = 0

if self.rect.right > 800:

self.rect.right = 800

if self.rect.top < 0:

self.rect.top = 0

4
4
if self.rect.bottom > 600:

self.rect.bottom = 600

self.vel_y = 0

self.on_ground = True

def draw(self, screen):

screen.blit(self.image, self.rect)

3. platform.py – Platform class

python

Copy code

import pygame

# Platform Class

class Platform(pygame.sprite.Sprite):

def __init__(self, x, y, width, height):

super().__init__()

self.image = pygame.Surface((width, height))

self.image.fill((0, 255, 0)) # Green platform color

self.rect = self.image.get_rect()

self.rect.x = x

4
5
self.rect.y = y

def draw(self, screen):

screen.blit(self.image, self.rect)

How It Works:

1. Main Game Loop (main.py):

o The game window is initialized, and the screen is


updated every frame.

o Player controls are handled through key presses for


left/right movement and jumping (spacebar).

o Platforms are drawn, and collisions are handled.

2. Player Class (player.py):

o The player has a position, velocity, and speed.

o The player moves horizontally with arrow keys and can


jump with the spacebar.

o Gravity is applied to simulate falling.

o The player can collide with platforms, and jumps are


prevented unless the player is on a platform.

3. Platform Class (platform.py):

o Represents static platforms in the game world.

o The player can stand on and jump from these platforms.

Assets Folder:

4
6
 player.png and background.jpg can be used to replace the
blocky player and background. You can import these images
using pygame.image.load("assets/player.png").

Extensions/Improvements:

 Add Enemies: Introduce enemies that move around and can


be avoided or defeated by the player.

 Add Collectibles: Place items that the player can collect for
points or power-ups.

 Sound Effects: Add jump and background music using


pygame.mixer.Sound and pygame.mixer.music.

 Level Design: Expand the level with multiple platforms and


scrolling effects.

This structure is a starting point for a game project and can be


expanded with additional features like scoring, levels, and game-
over conditions.

CONCLUSION
The Operating System 4 Computer Science (OS4CS) [30] initiative
lists five key challenges for computing education. One of these key
challenges identifies the need for more comprehensive, quality
instructional resources with a call to the community to create
these resources. Games can serve as an important, engaging
instructional resource for many of the reasons defined throughout
this study. However, the community fails to provide
comprehensive and high-quality games. It has also failed in
measuring the effectiveness of games in achieving their stated
educational goals.

4
7
This workgroup study provides a resource for the reader
interested in designing and developing games for computing
education. The high-level summary provides a starting point for
examining important underlying theories about digital game-
based learning, best practices to consider when designing and
developing a game, and relevant educational psychology, all in the
context of computing education. In addition, it defines a set of
games that can be used in computing education, and it identifies
gaps where future games can be developed to enable the creation
of a comprehensive set of resources for the education community.
The second part of this working group study will focus on the
evaluation of games to identify their efficacy. As part of that
process, several new games are currently being created using the
design guidelines provided in this report. These games will add to
the list of games for teaching computing education and provide
analysis of players’ learning.
We encourage the community to consider games that could be
created to make the available games more comprehensive.
We also encourage the community to keep in mind the need for
contextualizing learning and providing the necessary
interpretation of games in the context of computing. Just as we
interpret assignments, required readings, and other subsidiary
materials, our active incorporation of games into our educational
environments is key to achieving the learning that external media
can provide.

7. REFERENCES
[1] BrainHex. http://survey.ihobo.com/BrainHex/. [Online; accessed
29-August-2016].
[2] Code.org. https://code.org/learn. [Online; accessed 29-August-
2016].
[3] codeSpark. http://codespark.org. [Online; accessed 29-August-
2016].

4
8
[4] Developer spotlight: Danny Yaroslavski.
http://www.openfl.org/blog/2014/11/07/ developer-spotlight-
danny-yaroslavski. [Online; accessed 29-August-2016].
[5] Game survey. http://www.twodee.org/forothers/ game survey
iticse2016.csv. [Online; accessed 15-September-2016].
[6] Juice it or lose it. https://youtu.be/Fy0aCDmgnxg. [Online;
accessed 29-August-2016].
[7] Manifesto for agile software development.
http://agilemanifesto.org. [Online; accessed 29-August-2016].
[8] Molleindustria. http://www.gamedefinitions.com/. Accessed:
2016-07-13.
[9] Picobot. https://www.cs.hmc.edu/picobot/. [Online; accessed 29-
August-2016].
[10] Tomorrow corporation. http://tomorrowcorporation.com/.
[Online; accessed 29-August-2016].
[11] Unity3d. https://unity3d.com/. [Online; accessed 29-August-
2016].
[12] E. Aarseth. Computer game studies, year one. Game studies, 1(1):1–
15, 2001.
[13] ACM/IEEE. CS Joint Task Force on Computing
Curricula. 2013. Computer Science Curricula ACM Press and
IEEE Computer Society Press, 2013.
[14] L. W. Anderson, D. R. Krathwohl, P. W. Airasian,
K. A. Cruikshank, R. E. Mayer, P. R. Pintrich,
R. Raths, and M. C. Wittrock, M. C Wittrock. A Taxonomy for

Learning, Teaching and Assessing. Addison Wesley


Longman, 2001.
[15] J. Arjoranta. Game definitions: a wittgensteinian approach.
GamStudies, 14(1), 2014.
K. Ash. Digital gaming goes academic. Education Week, 30(25):24–
28, 2011.
T. Bailey and J. Forbes. Just-in-time teaching for cs0. ACM
SIGCSE Bulletin, 37(1):366–370, 2005.

4
9

You might also like