Creating a Game Development Course with
Limited Resources: An Evaluation Study
ALBERT D. RITZHAUPT
University of North Carolina, Wilmington
This article provides an overview of the challenges in implementing a game development course
with limited resources in computing curricula. An approach to a holistic game development course
is outlined in terms of its organization, software, and instructional methods. The course had 23
students enrolled in its first offering and was systematically evaluated in light of the approach
using multiple sources of data. Descriptive statistics and measures of internal consistency reliability are provided. Three important findings resulted from this research: 1) a game development course can be implemented with limited institutional monetary support for a reasonable
cost per student, 2) cooperation and competition can be effectively integrated into a game development course as instructional strategies, and 3) integrated lecture and computer lab sessions with
cooperative learning is an effective instructional method for a game development course. Finally,
insights and lessons learned are provided to assist educators in creating their own game development courses.
Categories and Subject Descriptors: K.3.2 [Computer Milieux]: Computers and Education—
Computer and Information Science Education, curriculum
General Terms: Human Factors
Additional Key Words and Phrases: Game development curriculum, game development tools,
computing education, educational evaluation
ACM Reference Format:
Ritzhaupt, A. D. 2009. Creating a game development course with limited resources: An evaluation
study. ACM Trans. Comput. Educ. 9, 1, Article 3 (March 2009), 16 pages.
DOI = 10.1145/1513593.1513596. http://doi.acm.org/10.1145/1513593.1513596.
1. INTRODUCTION
Computing programs have been integrating game development courses into
their curriculum in an effort to expose students to an industry now larger
than Hollywood [Weber 2007]. Though the industry has grown dramatically, many institutions of higher education have been slow to develop such
courses for a wide range of reasons; including the span of cross-curricular skills
Author’s address: A. D. Ritzhaupt, Univetsity of North Carolina Wilmington, Department of Instructional Technology, Foundations, and Secondary Education 601 S. College Rd., Wilmington,
NC 28403-5980; email: [email protected].
Permission to make digital/hard copy of all or part of this material without fee for personal or
classroom use provided that the copies are not made or distributed for profit or commercial advantage, the ACM copyright/server notice, the title of the publication, and its date appear, and notice
is given that copying is by permission of the ACM, Inc. To copy otherwise, to republish, to post
on servers, or to redistribute to lists requires prior specific permission and/or a fee. Permission
may be requested from Publications Dept., ACM, Inc., 2 Penn Plaza, Suite 701, New York, NY
10121-0701, USA, fax +1 (212) 869-0481, or [email protected].
c 2009 ACM 1531-4278/2009/03-ART3 $5.00 DOI: 10.1145/1513593.1513596.
http://doi.acm.org/10.1145/1513593.1513596.
ACM Transactions on Computing Education, Vol. 9, No. 1, Article 3, Pub. date: March 2009.
3: 2
·
A. D. Ritzhaupt
required to create games, the inherent time-constraints in implementing largescale games, the lack of interest or expertise of senior faculty in teaching game
courses, or the often questionable view that game development is not serious
academics [Becker and Parker 2007; Martin and Smith 2002]. This article
is an evaluation study about such a program in which the first experimental
game development course was implemented with less than three months of
preparation (an estimated 400 hours of development time). The motivation for
implementing the course was to add an elective course in game development
to reach interested gaming students. The instructor of this course had never
learned to develop games, nor had the instructor ever taught such a course.
Instead, the instructor was merely a game player enthusiast with limited
knowledge in each of the areas required to develop games (e.g., physics,
computer graphics, multimedia, etc.). In particular, the instructor’s background was in computing sciences and educational technology. Put simply,
this is a story about an instructor who had some of the basic skills necessary,
but required a lot of preparation if the course was to be a success. Thus, the
purpose of this article is to provide other educators an overview of the many
challenges in creating a technical game development course, an overview of
the course design and tools used in this instructor’s first attempt, and some
lessons learned for those educators interested in implementing game development courses in their departments and programs.
2. CHALLENGES AND SOLUTIONS
The first challenge in implementing a game development course was selecting the approach. The implementations of game development curricula range
from single courses [Jones 2000; Parberry et al. 2005; Sweedyk and Keller
2005] to course sequences [Parberry et al. 2006; Clark et al. 2007; Rocco and
Yoder 2007] to integrated topics across a traditional curriculum [Coleman
et al. 2005]. The individual courses range in focus from game engine programming [Shultz 2004] to technical artwork [Parberry et al. 2006] to holistic,
cross-curricular game development courses that span all aspects of game
development [Jones 2000; Martin and Smith 2002]. Selecting the scope, purpose, and direction of a game development initiative within an academic
program is a critical step, especially in light of limited resources.
Game development courses are most often housed within computer science
curricula. However, computing departments and programs are often composed
of multiple degree programs and majors that transcend the broad field of computing and information sciences, which might include information systems,
information sciences, information technology, and software engineering to
name a few. This creates a problem when designing curriculum in that one
cannot assume equal levels of prerequisite knowledge, especially in mathematics, programming, and sciences. Taking this into consideration, and in
consultation with other faculty members within the department under discussion, it was decided that the game development course should provide students
broad exposure to all areas of game development without focusing too heavily
in one area.
ACM Transactions on Computing Education, Vol. 9, No. 1, Article 3, Pub. date: March 2009.
Creating a Game Development Course with Limited Resources
·
3: 3
2.1 Tools and Resources
The next major challenge in developing this course was identifying a suite of
tools and educational resources in a relatively short timeline (three months).
Given that the course was experimental in nature, budget was also a major
concern. Put simply, there was not a course preparation budget available.
There was a clear need for low-cost, user-friendly tools that students could
download and/or purchase. The situation also demanded existing educational
resources for the instructor and students. After an investigation of similar
courses offered at institutions of higher education and identifying available
tools, a suite of six different tools that could be purchased by students for no
more than $135 were selected.
One clear benefit of having students purchase their own license to the
game engine is that students will retain the copyrights to their produced
games. These tools included the Torque Game Engine (version 1.4), Milkshape
3D, QuArk, Audacity, Gimp, and Nullsoft Scriptable Install System. Table I
combines the information about these various tools and their purpose in this
course. It should be noted that students did not have to purchase MilkShape
3D because it includes a 30-day evaluation and permits read-only access to files
afterwards. Not all of these tools receive equal attention within the course. The
most difficult tool to use is the Torque Game Engine (TGE) as it is the utility
used to combine all the assets and create entertaining games.
The next challenge was learning how to use the tools, and selecting and
creating educational materials that could be used in the course. One of the
factors used in selecting the game engine (TGE) was not only its quality and
price; the TGE community, managed by GarageGames.com, is very active and
posts a wealth of educational resources on how to use TGE for specific tasks
and game engine modifications. Additionally, there are many online tutorials
available for each of the software tools that can be easily referenced during an
academic semester.
Two textbooks were particularly useful in learning TGE, as well as
MilkShape 3D and QuArK. Both of these textbooks are shown in Figure 1.
The first textbook, The Game Programmer’s Guide to Torque: Under the Hood
of the Torque Game Engine, by Edward F. Maurina, provided an overview of the
architecture and scripting elements of TGE, and a step-by-step game implementation. It also includes a compact disc with many resources, including full
documentation for the engine, scripting examples, splash screens, and sample
games [Maurina 2006]. This textbook was required for the course. The second
textbook, 3D Game Programming: All in One by Kenneth C. Finney, provided
examples of how to use MilkShape 3D and QuArK for creating game art assets,
such as buildings, guns, nonhuman players, and any other resources [Finney
2004]. This was a recommended textbook for the course.
In addition to the technical aspects of this course, the instructor also had
to learn about the principles and models used for game development, and
review basic physics and the basics of game artificial intelligence. There are
many textbooks covering these broad topics. For instance, Adams and Rollings
[2006], Ahlquist and Novak [2007], and Saulter [2007] have helpful game
ACM Transactions on Computing Education, Vol. 9, No. 1, Article 3, Pub. date: March 2009.
3: 4
·
A. D. Ritzhaupt
Table I. Software Selection by Name, Location, Cost, License, Overview, and Purpose
Name, Difficulty
Location
Torque Game Engine (TGE)
www.garagegames.com
Cost and
Licensing
Downloadable.
$100 for old version
(v1.4); $150 for new
version (v1.5) for
Indie, single-user.
license
Overview and
Purpose
3D AAA game development
engine that includes support
for world editing, multiplayer,
*****
shape rendering, scripting
language, splash screens, and
more. It includes the source
code for modifications. This is
the primary tool in this course
as it pulls all the resources
together to create a robust.
game
Milkshape 3D
Downloadable. 30-day
MilkShape 3D is a low-polygon
chumbalum.swissquake.ch
free evaluation followed
modeler used to create world
by a $35 single-user
objects, avatars, animations,
***
license
and more. It supports
more than 70 file formats.
Quake Army Knife (QuArK)
Downloadable. Free for
QuArK is used to model
quark.planetquake.gamespy.com use. Donations accepted.
complex 3D shapes and maps,
including those things that
****
can be walked on (e.g., bridges)
or in (e.g., buildings).
Audacity
Downloadable. Free
Audacity is an open-source
audacity.sourceforge.net
for use. Open source.
sound editor. It can be used to
record and manipulate audio
**
files for incorporation into
a game.
GNU Image Manipulation
Downloadable. Free
GIMP is a versatile graphics
Program (GIMP)
for use. Open source.
manipulation package. This
www.gimp.org
tool is used to create and edit
textures and other graphics
**
for a game.
Nullsoft Scriptable Install
Downloadable. Free
NSIS is a tool for the
System (NSIS)
for use. Open source.
development of Windows
sourceforge.net/projects/nsis/
installers. This tool is used to
combine game resources for
*
distribution and installation.
*Represents instructor-designated difficulty on a five-point scale.
development textbooks providing coverage of these topics. The author would
like to note that it is not recommended that faculty members without some
exposure to physics, multimedia, computer graphics, and basic networking attempt to teach this type of course without more time for preparation in these
areas. These are requisite content areas to teach in the course.
3. COURSE DESIGN
3.1 Overview and Deliverables
After learning to use each of the tools and reading enough literature on game
development, the next step was to start designing the course. As previously
ACM Transactions on Computing Education, Vol. 9, No. 1, Article 3, Pub. date: March 2009.
Creating a Game Development Course with Limited Resources
·
3: 5
Fig. 1. Textbooks used to learn software tools.
noted, the undergraduate course was intended to be a holistic game development course spanning the entire game development process and culminating
in the implementation of a complete game. The prerequisite for the course
was a junior-level data structures course either in CS, IS, or IT programs. It
was decided early on that the complete game would be implemented in groups
of two or three since an objective across computing curriculum is teamwork
[ACM/IEE 2001; ACM, AIS, AITP 2002]. The students were allowed to form
their own groups based on interests. The course would be delivered in a faceto-face format, supported by online multimedia materials, during a traditional
16-week semester. The overarching goal of the course was to provide students
experience in multiple areas of game development using low-cost and userfriendly tools. The course description is:
This course is intended to provide students an overview of game
development. Topics include the game development life cycle, an
overview of the game industry, and an emphasis on game design and
programming which includes some of the mathematics, modeling,
animation, physics, and artificial intelligence used to create games.
Students practice these concepts in several assignments using Torque
Game Engine/Torque script. The course will culminate with the
implementation of a complete game.
To assure both group and individual accountability, individual assignments
were designed to help students acquire the basic skills necessary to implement
a game. Additionally, all students were required to complete a peer-evaluation
at the completion of the course to thwart the threat of “free-riders.” The final
grades were composed of three areas: activities (20%), individual assignments
(40%), and the game implementation (40%). Activities grades were based on
in-class participation, attendance at lab sessions, and small homework assignments related to conceptual materials in the course (e.g., game mathematics
worksheet). As the course was a project-based learning experience, no examinations were used in determining grades.
ACM Transactions on Computing Education, Vol. 9, No. 1, Article 3, Pub. date: March 2009.
3: 6
·
A. D. Ritzhaupt
3.2 Course Organization
The course materials were organized into five phases: game development
overview, game technical artwork, Torque Game Engine basics, game development labs, and game quality assurance.1 Table II provides an overview of
these five phases, in relation to the major deliverables. The first phase focused on the basics of game development and some background knowledge
that would be important for understanding concepts later in the course. This
phase was delivered primarily by face-to-face lectures, in-class activities, and
notes written by the instructor that were posted to Blackboard as PDF files for
later use. In the first assignment, students were required to evaluate their
favorite game in relation to 25 different characteristics (e.g., game rating,
genre, spatiality, etc.). Students were also required to turn in a mathematics worksheet for activity points.
The second phase of the course focused on the basics of 3D modeling,
creating textures, audio sound recording and manipulation, creating skeletons, rigging models to skeletons, and animating complex movements. Most
of the material was delivered via face-to-face lectures during software demonstrations. During this phase, students were exposed to Milkshape 3D, QuArK,
GIMP, and Audacity. Students demonstrated their mastery of the tools and
concepts in the second assignment with the implementation of a pictureperfect real-world object, an animated object, and an interior, such as a house
or generic building. Additionally, student groups were required to submit the
game design document outlining their group project.
The third phase of the course focused solely on providing students the basics
skills to use Torque Scripting Language and teaching the basics of the TGE,
which included the engine architecture, base classes, terrain editing, collision
detection, and engine modifications. Special emphasis during this phase was
placed on showing students how to find resources in the GarageGames.com
online community that could be incorporated into their games. This phase
included face-to-face lectures, software demonstrations, and supplementary
animated screen captures with narration that students could reference at a
latter time. Two deliverables were submitted during this phase: 1) the third
assignment required students to incorporate their shapes from Assignment
2 and to implement an action upon colliding with those shapes in the game
world, and 2) the fourth assignment required students to complete step-bystep tutorials in the implementation of a game found in the textbook, the incorporation of an element that would be used in their group project, and the
creation of a game installer. The game installer was implemented using NSIS,
and thus time was devoted to introducing this utility during this phase.
The fourth phase turned out to be one of the most effective aspects of the
course design: having students work in their groups in a computer lab. During these regularly scheduled sessions, the instructor would move around the
computer lab to each group trying to assist with questions. Often groups
would encounter problems for which neither the instructor nor students had
1 To
access resources, visit http://aritzhaupt.com/courses/cis4993/.
ACM Transactions on Computing Education, Vol. 9, No. 1, Article 3, Pub. date: March 2009.
Creating a Game Development Course with Limited Resources
·
3: 7
Table II. Game Development Course Phases, Course Materials, and Deliverables
Phase and Duration
Game Development Basics
(3 weeks)
Game Technical Artwork
(3 weeks)
Torque Game Engine Basics
(4 weeks)
Game Development Labs
(4 weeks)
Game Quality Assurance
(2 weeks)
Materials Covered
Game development life-cycle
Game terminology
Overview of game industry
Game mathematics
Game physics
Game artificial intelligence
Static art assets using
Milkshape 3D
Textures using GIMP
Animations using Milkshape
Interiors using QuArK
Recording/editing audio
using Audacity
TGE game architecture
Terrain and world editing
Torque Scripting Language
Mission objects, including
weather, sky, clouds, fog, etc.
Special effects, including
particle emitters
Engine modifications
Paths and cameras
Scheduling and projectiles
Game installers with NSIS
Game interfaces
Game publishing
Materials covered and
learned varied from group
to group.
Alpha, Beta and Gold testing
Game Distribution
Game Marketing
Deliverables
Assignment 1
(Evaluate favorite game,
define 25 different aspects)
Game Design Document
(Group design documents for
a 3D game)
Assignment 2
(3D modeling and animation)
Assignment 3
(Basic game implementation
with TGE using Assignment 2
models and collision detection)
Assignment 4
(Textbook game
implementation part 1, group
project element, installers)
Assignment 5
(Textbook game
implementation part 2, group
project element, installers)
Final Game Implementation
(The final game and
supporting documentation)
Peer Evaluations
(Group and Game Evaluation)
a solution. This type of problem resulted in creative discussions and troubleshooting among students and the instructor until solutions were discovered.
Time during this phase was also allotted to creating splash screens and interfaces for the final games, and the process surrounding publishing games (e.g.,
copyrights). Only one deliverable was required during this phase aside from
mandatory attendance. This assignment was very similar to Assignment 4
with the exception that the fifth and final assignment is the completion of a
step-by-step textbook game titled MazeRunner [Maurina 2006].
The fifth and final phase of the course was focused on game quality assurance. All groups presented their preliminary games at an open forum in which
students from the university played the games and asked questions. Face-toface lecture time was spent on game testing, including alpha, beta, and gold
testing; and game marketing models. Each team was required to showcase
their games at a workstation for a minimum duration of two hours. During
ACM Transactions on Computing Education, Vol. 9, No. 1, Article 3, Pub. date: March 2009.
3: 8
·
A. D. Ritzhaupt
this time, students were required to take notes while observing people playing
their games. The purpose of the activity was to emulate a usability and entertainment test. Groups were provided an opportunity to revise their games in
light of the feedback collected. Finally, students within the course evaluated
the games of all the other teams. This served as a summative evaluation and
as the mechanism to select the winning team in the course (see next section).
3.3 Integrating Competition and Cooperation
As cooperation and competition are frequently cited as motivational factors
for game play [Adams and Rollings 2006; Saulter 2007], the instructor set a
goal to integrate both competitive and cooperative elements into the course
design. To engender competition between the teams, a policy was adopted to
award the team with the overall best game, as defined by total scores on a
game evaluation rubric, an automatic A on the game project. Each game was
evaluated by every student in the class who did not participate in the game’s
development. To assure students were taking the activity seriously, activity
points were contingent upon submitting complete evaluations.
To create a community of cooperation, the instructor implemented a policy
to award extra credit (up to five points towards the final grade) to the students
(individually) who participated most in answering questions posted to the discussion board and/or assisted the most during computer lab sessions. All students had access to a discussion board organized by deliverable in Blackboard.
Both policies were stated on the syllabus and were thoroughly discussed in the
first class session.
3.4 Comparison to Other Approaches
Unlike other game development course implementations, this course was a
single course elective in game development as opposed to integrated curricula
in computer science that spans several courses or an entire degree program
[Parberry et al. 2006; Clark et al. 2007; Rocco and Yoder 2007; Coleman et al.
2005]. Additionally, this course was open to students in computer science, information systems, and information technology degree programs. The course
was intended not to focus on one singular topic in game development, but
rather span multiple aspects of game development. The course was similar
to the implementation by Jones [2000] in terms of content but did not incorporate Java 2 as the implementation language. The implementation differed
from Martin and Smith [2002] in that the student population was not truly
cross-curricular in nature.
4. METHOD OF EVALUATION
4.1 Students
Students enrolled in the undergraduate game development course offered in
a computing department at a southeastern, public, large, master’s university
(Carnegie classification). Twenty-three students enrolled in the course: two
graduate students and the remaining were undergraduates. All students were
ACM Transactions on Computing Education, Vol. 9, No. 1, Article 3, Pub. date: March 2009.
Creating a Game Development Course with Limited Resources
·
3: 9
Table III. Internal Consistency Reliability Across Measures
Survey Section
Gameplay preferences
Student satisfaction
Interest in game development career
Student gains from course
Helpful course elements
# of items
9
13
6
8
8
Cronbach’s α
0.72
0.87
0.81
0.80
0.85
male. One student withdrew early in the semester due to work complications
and the remaining students successfully completed the course. Of the 22 students within the course, 17 students completed a specialized survey, which is
a 77% completion rate.
The respondents represented three different computing majors, including
59% majoring in information science and systems, 29% majoring in information technology, and the remaining majoring in computer science. Fifty-three
percent of the respondents worked part-time jobs, 29% were working full-time,
and 18% were not currently employed. Eight-two percent of the respondents
were classified as full-time students. All respondents had prior programming
experience ranging from three to thirteen courses with an average of 5.59
(SD = 2.65).
4.2 Survey and Measures
The survey used in this analysis was developed to evaluate this complex course
and to collect useful information about students’ previous background, gameplay preferences, and career expectations. The survey was developed by the
instructor of the course and contains 48 items organized into six sections:
student background information, student gameplay preferences, student satisfaction, interest level in game development careers, student assessment of
gains, and helpful course elements. The survey was derived from three NSFsponsored instruments and previous research [Ritzhaupt and Gill 2008]. As
can be seen in Table III, the measures demonstrate strong internal consistency
reliability for these data [Nunnally 1978]. Additional sources of information include the discussion threads and comments, student performance, and student
peer-evaluations that were administered at the end of the semester.
4.3 Procedures and Data Analysis
The survey was administered to students at the end of the fifteenth week of
a 16-week semester, along with the university-wide course evaluations. The
instructor left the classroom as the survey was administered. Students were
invited to complete the survey, but it was not a requirement in the course.
Though the survey did not include the student’s name, it was not truly anonymous as the instructor was able to view the responses prior to the end of the
semester. The quantitative analyses of the data included descriptive analysis
of response frequencies and measures of variation and central tendency, and
internal consistency reliability. Because of the small sample size, no statistical
inferences were made about the larger population (computer game development students). Additional comments about the course were solicited from
students during one-on-one conversations.
ACM Transactions on Computing Education, Vol. 9, No. 1, Article 3, Pub. date: March 2009.
3: 10
·
A. D. Ritzhaupt
Table IV. Gameplay Percentages, Mean, and Standard Deviation by Game Genres
Game genres
M
SD
1
2
3
4
5
Skill-and-action games
3.35
1.06
6
6
53
18
18
Adventure games
3.00
1.17
12
24
24
35
6
Role playing games
2.88
1.22
18
18
29
29
6
Strategy/simulation games
2.59
1.12
12
47
18
18
6
Racing games
2.00
1.06
41
29
18
12
0
Fighting games
3.06
1.09
6
24
41
18
12
Puzzle games
2.12
0.99
35
24
35
6
0
Sports games
1.88
1.17
53
18
24
0
6
Other (e.g., educational)
1.53
0.80
65
18
18
0
0
1 = Never, 2 = Less than once a month, 3 = Between once a week and once a month,
4 = A few times a week, 5 = Almost every day.
5. EVALUATION RESULTS
5.1 Gameplay Frequency and Games Created
One factor anticipated to influence overall student motivation in the course
as well as the types of games students would implement was the frequency
of which they played various game genres. As can be gleaned in Table IV,
the most commonly played game genres were skill-and-action games (M = 3.5;
SD = 1.06) and fighting games (M = 3.06; SD = 1.09). The least common games
were other (e.g., educational) games (M = 1.53; SD = 0.8), and surprisingly,
sports games (M = 1.88; SD = 1.17). The gameplay frequency of the other
game genres ranged from a mean of two to three, indicating students played
the various game genres around once a month or more.
Eight groups were formed from the 22 students enrolled in the course. Of
the eight groups, four games were classified as skill-and-action games, two
were classified as adventure games, one was a racing game, and one was a
role-playing game. Though it is clear skill-and-action games were the most
common game implementations, it is important to note that TGE was originally implemented for skill-and-action-like games that might also be described
as first-person shooters. Of the eight games, only one team elected to implement a LAN-based multi-player game, which is a feature of TGE.
5.2 Game Industry Career Interest
Another important evaluation question was the degree to which certain game
industry careers were attractive to students as a result of completing the
course. While there are many specializations in the game industry, the survey
included six broad game industry related careers: producers, level designers, programmers, audio engineers, testers, and technical artists [Adams and
Rollings 2006]. These careers were discussed as part of the course curriculum.
As shown in Table V, the two career areas that were most interesting to
students upon completing the course were game level designers (M = 3.47;
SD = 1.12) and game programmers (M = 3.47; SD = 1.07). These results are
unsurprising in that all the students are studying programming-centric curricula and since much of their time was devoted to implementing a game level
(group project). The career with least interest from students was game audio
ACM Transactions on Computing Education, Vol. 9, No. 1, Article 3, Pub. date: March 2009.
Creating a Game Development Course with Limited Resources
·
3: 11
Table V. Game Career Interest Percentages, Mean, and Standard Deviation
Career
M
SD
1
2
3
4
5
Game producer
3.29
1.10
6
12
47
18
18
Game level designer
3.47
1.12
6
12
29
35
18
Game programmer
3.47
1.07
6
12
24
47
12
Game audio engineer
3.06
0.83
6
6
71
12
6
Game tester
3.41
1.12
6
6
53
12
24
Game technical artist
3.24
0.97
6
12
41
35
6
1 = Much less attractive, 2 = Less attractive, 3 = Unchanged, 4 = More attractive,
5 = Much more attractive.
engineers (M = 3.06; SD = 0.83) or those responsible for the narration, sound
effects, and music found in games.
5.3 Student Satisfaction and Helpfulness of Course Elements
A student’s level of satisfaction with the course was of particular interest since
this was the first time the course was offered. It was also the instructor’s first
time teaching game development, so the indicators from the student satisfaction scale could serve to improve the instruction the next time the course is
offered. As can be gleaned in Table VI, students were satisfied overall (> 4)
with the elements in the course with the exception of the textbook (M = 2.88;
SD = 1.17). In discussions with students, it was discovered that many students felt the required textbook (The Game Programmer’s Guide to Torque:
Under the Hood of the Torque Game Engine) was poorly written. This insight
will change the direction of the course the next time it is offered: selecting a
different textbook. In particular, the text 3D Game Programming: All in One
may serve as a better required text in subsequent offerings.
The use of multimedia files was also an important consideration for this
course. Many of the software demonstrations were recorded as animated
screen captures with narration. The purpose of these resources was to provide students a resource outside of the classroom to assist in executing various software tasks (e.g., configuring environmental effects in the game world).
Students were generally satisfied with these resources (M = 4.18; SD = 0.73).
Individual discussions with the students revealed that students would reuse
the resources many times over the duration of the semester. In the future,
more of the resources will be developed to assist students in completing their
assignments and the final project.
Another way to investigate the elements that were successful was to ask students to indicate which elements of the course were helpful for their learning
the materials. Table VII illustrates the information collected for this domain.
Two areas of particular interest were whether students felt the competitive
and cooperative elements within the course were helpful for their learning. As
can be seen, students found the teamwork in labs (M = 4.18; SD = 0.81), working with peers inside and outside of class (M = 3.94; SD = 0.83), and hands-on
lab activities to be the most helpful elements in the course (M = 4.18; SD =
0.81). These results demonstrate two things: 1) the computer lab sessions were
helpful to students, and 2) cooperative learning in a game development course
is helpful to students, even with embedded competition. Fifty-nine percent of
ACM Transactions on Computing Education, Vol. 9, No. 1, Article 3, Pub. date: March 2009.
3: 12
·
A. D. Ritzhaupt
Table VI. Student Satisfaction Percentages, Mean, and Standard Deviation
Satisfaction Area
M
SD
1
2
3
4
5
The textbook that was used in
2.88 1.17
12
29
24
29
6
the course
Materials that were distributed
4.29 0.47
0
0
0
71
29
via Blackboard
The number of assignments
4.24 0.66
0
0
12
53
35
The type of assignments
4.29 0.69
0
0
12
47
41
The instructor’s use of different
4.24 0.66
0
0
12
53
35
ways of teaching
The interaction between the
4.76 0.56
0
0
6
12
82
instructor and students
The group work (collaboration)
4.59 0.62
0
0
6
29
65
between students
The use of Blackboard and
4.18 0.53
0
0
6
71
24
the Internet
The use of multimedia files to
4.18 0.73
0
0
18
47
35
supplement lectures
The amount of material that
4.18 0.81
0
0
24
35
41
was covered
The content of the course
4.29 0.59
0
0
6
59
35
materials
The split lecture/lab format of
4.65 0.79
0
6
0
18
76
the course
The availability of the
4.82 0.39
0
0
0
18
82
instructor
1 = Very dissatisfied, 2 = Dissatisfied, 3 = Neutral, 4 = Satisfied, 5 = Very satisfied.
Table VII. Helpful Course Element Percentages, Mean, and Standard Deviation
Helpful Elements
M
SD
1
2
3
4
The way in which the material was approached
3.47
0.87
0
12
41 35
The pace at which we worked
3.41
0.87
0
12
47 29
The grading system for the class
3.59
1.06
6
12
12 59
Working with peers inside and outside of class
3.94
0.83
0
6
18 53
Blackboard discussion groups
3.76
0.83
0
6
29 47
Teamwork in labs
4.18
0.81
0
0
24 35
The competition of the final group project
3.59
0.87
0
12
29 47
The hands-on lab activities
4.18
0.81
0
0
24 35
1 = No help, 2 = A little help, 3 = Moderate help, 4 = Much help, 5 = Very much help.
5
12
12
12
24
18
41
12
41
the students indicated the competition of the final group project was helpful in
the learning materials (M = 3.59; SD = 0.87).
5.4 Student Assessment of Gains, Performance, and Response Productivity
Students were asked to assess their gains as a result of completing the course
in a number of areas related to game development, as shown in Table VIII. In
particular, students indicated their largest gains in understanding the types
of tools used in game development (M = 4.12; SD = 1.05), understanding the
game development process (M = 4.00; SD = 0.94), and their enthusiasm for
game development (M = 4.12; SD = 0.86) as a result of completing the course.
All other areas also showed gains greater than the central point (> 3). These
are promising outcomes given the relatively short period of preparation for the
course and wide variety of topics and tools covered in the course.
ACM Transactions on Computing Education, Vol. 9, No. 1, Article 3, Pub. date: March 2009.
Creating a Game Development Course with Limited Resources
·
3: 13
Table VIII. Student Learning Gains Percentages, Mean, and Standard Deviation
Student Gains from Course
M
SD
1
2
3
Understanding the main concepts in
3.94
0.90
0
6
24
game development
Understanding the game development
4.00
0.94
6
0
6
process
Understanding the types of tools used
4.12
1.05
6
0
12
in game development
Appreciating the field of game
3.94
0.83
0
0
35
development
Ability to think through a problems in
3.88
0.70
0
0
29
game development
Confidence in your ability to work in
3.82
0.95
0
12
18
game development
Feeling comfortable with complex game
3.82
0.73
0
0
35
development
Enthusiasm for game development
4.12
0.86
0
0
29
1 = Not at all, 2 = A little, 3 = Somewhat, 4 = A lot, 5 = A great deal.
4
41
5
29
65
24
41
41
35
29
53
18
47
24
47
18
29
41
The final grade distribution for the course included twelve students earning
an A, eight students earning a B, and two students earning a C. All students
who stayed enrolled in the course earned a passing grade. Though the grade
distribution appears positively biased, it is the author’s conviction that the
strong motivational factor of succeeding in the course, as illustrated in the
previous sections, resulted in such a high grade distribution. When splitting
the weighted final grades, the average score across assignments was 90.35
(SD = 21.95), for activities was 83.73 (SD = 14.43), and for final projects was
89.64 (SD = 4.88). Students performed best on the individual assignments,
followed by the final projects and then activities. One explanation for the lower
activity average is that some of the activities required mandatory attendance.
Another consideration was the number of questions and responses from
students. As previously noted, students who were particularly helpful in assisting their peers in the course with problems and questions received extra
credit points toward their final grades. Four students in the course were extremely helpful in answering questions on the discussion board, often before
the instructor even had an opportunity to respond. These four students earned
extra credit. Throughout the semester, a total of 27 unique questions were
posed to the discussion board. The questions ranged from clarification of specifications to instructions or resources on each of the software packages. In total,
16 students participated in the discussions, and a total of 69 responses to the
questions were provided. The discussion board not only assisted in streamlining similar questions and answers, but also resulted in fruitful dialog among
the students in the course.
5.5 Student Peer-Evaluation
The students evaluated their group members in summative fashion in that the
scores were used to assess the final project grades and make a final judgment
on the merit of a group member. In investigating the group member evaluations, 18 of the 22 students (82%) completed their peer-evaluations. The evaluation instrument contained quantitative 10-items (5-point scale; 1 = lowest
ACM Transactions on Computing Education, Vol. 9, No. 1, Article 3, Pub. date: March 2009.
3: 14
·
A. D. Ritzhaupt
Table IX. Group Member Evaluation Summary
Evaluation area
Regularly attends meetings
Is prepared at the meetings
Meets deadlines
Contributes good work to the project
Contributes ideas diplomatically
Submits high-quality work
Listens to other members
Shows respect for other members
Helps to reduce conflict
Your overall assessment of this person’s contribution
M
4.64
4.49
4.29
4.29
4.69
4.27
4.76
4.96
4.80
4.33
SD
0.61
0.84
1.20
1.47
0.87
1.29
0.57
0.21
0.59
1.26
to 5 = highest) and two free-form response areas about self-evaluation and
overall group evaluation. The quantitative items are summarized in Table IX
across student respondents and their peers. As illustrated, peers were favorable about their group members. As a result of the peer-evaluation, only two
students received point deductions on their final project grade for consistent
low scores assigned across their team members.
In reviewing the responses across the participants, students indicated
both effective and ineffective things that influenced group interactions. The
effective strategies included exhibiting a positive attitude for teamwork (44%),
establishing group roles and division of labor (28%), perseverance with the
game concept (22%), and keeping an open mind about their peers’ ideas (18%).
In terms of group challenges, scheduling and meeting group deadlines (33%)
and consistent communication (12%) were both areas identified as areas in
need of improvement.
6. LESSONS LEARNED AND RECOMMENDATIONS
The suite of software tools reviewed in this article is intended to provide computing educators a low-cost and user-friendly option for a game development
course. Though these tools would not be considered industrial strength (e.g.,
Maya versus Milkshape 3D), the goal of the course was to provide students
broad exposure to the wide-variety of tools used in game industry. This goal
was reached, as evidenced in the results. Furthermore, the licensing for tools
like Maya cost around $2,000 per license [Autodesk 2008] as opposed to the
$35 per license to Milkshape 3D, which is a serious financial commitment
from an educational institution and far outside the reach of what students can
afford. The tools provided have reasonable learning curves and can be used to
implement complex games.
Developing expertise in game development takes many years of the practice
and reflection and with the wide variety of game genres and complex topics
such as Pathfinding systems, it is not conceivable that an educator will be
able to develop expertise in every area. Instructors who have not taught game
development or developed games in industry must accept that they will not be
experts in every aspect. Perhaps the most important lesson learned from this
experience is that teaching game development requires a shift in perspective
from a teacher-centered (e.g., sage on stage) learning environment in which
ACM Transactions on Computing Education, Vol. 9, No. 1, Article 3, Pub. date: March 2009.
Creating a Game Development Course with Limited Resources
·
3: 15
the teacher dictates the learning experience to a student-centered (e.g., guide
on the side) learning environment in which students have more control over
what they are learning and teachers serve as facilitators of this process [King
1993].
An important outcome of this evaluation study is the effectiveness of
cooperative learning, particularly in computer lab environment. Parberry et al.
[2006] emphasize the importance of computer lab sessions in creating an effective learning environment for game development. This evaluation study contributes more evidence in support of teamwork within computer labs in which
the faculty member facilitates the learning experience. The current course
implemented computer lab sessions during the fourth phase (four-week timeframe). Perhaps it would have been better to schedule the course in a split lecture and lab format in which one class session is devoted to teaching concepts
and providing demonstrations and a second session is devoted to practicing
these concepts.
As pointed out by Jones [2000], a computer game development course
provides an ideal learning environment in which students can integrate
wide variety of computer skills and knowledge. This realization has shifted
game development courses from experimental electives to integrative capstone
experiences [Parberry et al. 2005; Sweedyk and Keller 2005] in which students
work in many different areas of computing sciences and software development.
The author strongly concurs with this rationale for computer game development courses serving as capstone experiences in computing programs. The
breadth of skills and knowledge required to develop quality games is widereaching.
A final consideration is the effectiveness of the competition as a motivational
factor to create the “best” team game in the course. The results demonstrated
that students perceived the activity as motivating and effective for their learning. Aside from earning an automatic A on the group project, the winning
team also benefited from the bragging-rights in the class and the opportunity
to showcase their complete projects to their friends and family. The evidence
supports the future incorporate of both cooperative and competitive elements
into the design of a game development course.
REFERENCES
ACM/IEE. 2001. Computing curricula 2001: Computer Science.
http://www.sigcse.org/cc2001/cc2001.pdf (June 28, 2008).
ACM, AIS, AITP. 2002. Model curriculum and guidelines for undergraduate degree programs in
information systems. http://www.acm.org/education/is2002.pdf (June 28, 2008).
A DAMS, E. AND R OLLINGS, A. 2006. Game Design and Development: Fundamentals of Game
Design. Pearson Prentice Hall, Upper Saddle River, NJ.
A HLQUIST, J. B. AND N OVAK , J. 2007. Game Development Essentials: Game Artificial Intelligence.
Thompson Learning, Boston, MA.
A UTODESK M AYA C OMPLETE. 2008. http://usa.autodesk.com. (June 28, 2008).
B ECKER , K. AND PARKER , J. R. 2007. Serious games + computer science = serious CS. J. Comput.
Sci. Coll. 23, 2, 40–46.
C LARK , B., R OSENBERG, J., S MITH , T., S TEINER , S., WALLACE , S. AND O RR , G. 2007. Game
development courses in the computer science curriculum. J. Comput. Sci. Coll. 23, 2, 65–66.
ACM Transactions on Computing Education, Vol. 9, No. 1, Article 3, Pub. date: March 2009.
3: 16
·
A. D. Ritzhaupt
C OLEMAN, R., K REMBS, M., L ABOUSEUR , A. AND W EIR , J. 2005. Game design and programming
concentration within the computer science curriculum. SIGCSE Bull. 37, 1, 545–550.
F INNEY, K. C. 2004. 3D Game Programming: All in One. Thompson Learning, Boston, MA.
J ONES, R. M. 2000. Design and implementation of computer games: A capstone course for
undergraduate computer science education. SIGCSE Bull. 32, 1, 260–264.
K ING, A. 1993. From the sage on the stage to the guide on the side. College Teach. 41, 30–35.
M ARTIN, J. AND S MITH , C. 2002. A cross-curricular team based approach to game development.
J. Comput. Sci. Coll. 23, 2, 65–66.
M AURINA , E. F. 2006. The Game Programmer’s Guide to Torque: e: Under the Hood of the Torque
Game Engine. Thomson Course Technology, Wellesley, MA.
N UNNALLY, J. C. 1978. Psychometric theory. McGraw-Hill, New York.
PARBERRY, I., R ODEN, T. AND K AZEMZADEH , M. B. 2005. Experience with an industry-driven
capstone course on game programming: Extended abstract. SIGCSE Bull. 37, 1, 91–95.
PARBERRY, I., K AZEMZADEH , M. B. AND R ODEN, T. 2006. The art and science of game programming. SIGCSE Bull. 38, 1, 510–514.
R ITZHAUPT, A. D. AND G ILL , T. G. 2008. A hybrid and novel approach to teaching computer programming in MIS curriculum. In Handbook of Distance Learning for Real-Time and Asynchronous Information Technology Education, S. Negash, M. Whitman, A. Woszczynski, K. Hoganson,
and H. Mattord Eds., Idea Group Reference, Hershey, PA. 259–281.
R OCCO, D. AND Y ODER , D. 2007. Design of a media and gaming sequence for graduates in applied
CS. J. Comput. Sci. Coll. 22, 5, 131–137.
S AULTER , J. 2007. Introduction to video game design and development. Boston: McGraw-Hill.
S HULTZ , G. A. 2004. The story engine concept in CS education. J. Comput. Sci. Coll. 20, 1,
241–247.
S WEEDYK , E. AND K ELLER , R. M. 2005. Fun and games: A new software engineering course.
SIGCSE Bull. 37, 3, 138–142.
W EBER , T. 2007. Games industry enters a new level. British Broadcasting Corporation News.
http://news.bbc.co.uk/2/hi/business/6523565.stm (June 28, 2008).
Received July 2008; revised January 2009, February 2009; accepted February 2009
ACM Transactions on Computing Education, Vol. 9, No. 1, Article 3, Pub. date: March 2009.