Site-wide links

Evolving Interdisciplinary Collaborative Groups in a Game Development Course

By Holliie Bourdreaux, Jim Etheridge and Ashok KumarComputer science departments at many universities are now beginning to offer video gaming courses in response to the growing need for skilled programmers in the video game development industry. This paper describes the evolution of a senior level game programming course over a four year period. The course described is the culmination of a curriculum which offers students a concentration in video game design and development as part of a rigorous computer science undergraduate degree program. In addition to the core computer science coursework, students are required to complete two video game programming courses and have the option of taking two more as electives. To satisfy the remainder of the concentration requirements students can choose from electives in visual arts, theater, and creative writing. The current incarnation of the senior level game programming course puts great emphasis on large interdisciplinary team development projects. The course also incorporates software engineering principles, open source software, and periodic group and individual status reporting. The addition of a final project presentation to an audience of peers, industry professionals, and the media has proven to be an effective incentive for the students.

2 INTRODUCTION

The Computer Science department at the University of Louisiana at Lafayette (ULL) added a new concentration area of video game design and development to its curriculum in 2004. A concentration is a set of classes, consisting of approximately 15% of the total coursework, that focuses on an area of specialization. ULL currently has five concentrations, one of which is video game design and development. The core of the video game design and development concentration is several semesters of game development classes for several different platforms. The course discussed in this paper is the final one in that sequence.

2.1 CURRICULUM OVERVIEW

In addition to university general education requirements, the computer science curriculum consists of several areas of coursework, beginning with introductory and data structures courses then branching off into the following categories:

  • Core Computer Science Courses -The courses expected in any accredited computer science curriculum that do not fall into another category below.
  • Gaming Relevant Courses -This group consists of courses that are especially relevant to video game design and development, such as Artificial Intelligence, Graphics, Networking, Human Computer Interaction, Software Engineering, and Physics.
    • Artificial Intelligence familiarizes students with the background and foundations of AI, intelligent agent-based representation, problem solving and search algorithms, game playing, introduction to LISP, knowledge representation and knowledge-based systems. It also includes an introduction to other subareas such as natural language processing, connectionist models, and evolutionary algorithms.
    • Physics prepares students with the classical and relativistic mechanics: heat and mechanical waves. The first level of calculus is a prerequisite for this course. The course helps game design students to understand concepts such as straight line and rotatory motion, force and impact, particle physics, and springs which they will use in their game designs.
    • Gaming Courses -The concentration courses fall under this category. Currently available courses include Introduction to Video Game Design and Development, Video Game Design and Development (the subject of this paper), Programming Handheld Devices, Java for Small Devices, and Game Algorithms and Game Engine Architecture.
    • Gaming Electives -Students are required to select from approved courses in gaming related areas including creative writing, Communications, and Visual Arts.

Visual Arts prepares students with an introduction to the use of a computer as a tool for artistic expression. The projects employ scanners, video digitizers, and printers, together with editing software for drawing, painting, image manipulation, and 2D animation.

In conjunction with the senior level game development course students get hands-on experience in motion capture and related simulation in the Computer Science department’s motion capture lab. More information about the concentration can be found at the computer science department’s website [1]. This paper will discuss the senior level game development course, which has been offered every spring semester starting in 2006, for a total of five offerings as of this writing.

3 CLASS ORGANIZATION

3.1 LEARNING OUTCOMES

The departmental accreditation process dictates that objectives be set for the program as a whole. In order to determine the department’s ability to achieve these goals, each course in the program has a set of learning outcomes that reflect the content of the course and relate to the overall program objectives. Periodic assessment of the learning outcomes for each course provides a means for the department to determine the extent to which it is achieving its goals. The learning outcomes for the senior level video design and development course are as follows:

  • Work in a large group to design and develop a non-trivial 3D video game
  • Develop and implement a leadership hierarchy within the group
  • Analyze and present to the class periodic individual and group status reports on the progress of the project
  • Work effectively in conjunction with group members from other disciplines (Visual Arts, Music, Creative Writing, etc.)
  • Develop and implement procedures necessary to integrate components of the project produced by disparate software tools (game engines, 3D modeling tools, sound editors, etc.)
  • Analyze the strengths and weaknesses of software tools relative to the requirements of the project
  • Evaluate honestly and fairly the commitment and productivity of all members of the group
  • Define and maintain a development timeline for the project
  • Coordinate the creation of a substantial presentation of the status and features of the final product to classmates and other interested individuals

In general, the learning outcomes address the issues involved in the design and implementation of large software systems by relatively large (by academic standards) interdisciplinary teams. The main factor that makes the team approach in this course unique is the fluidity of the project requirements. The development teams determine the game design based on a consensus among team members regarding the type of game they want to create. While the major components of the design are fixed, the details of the design can, and often do, change on a regular basis as a reaction to new ideas, software integration issues, art and audio asset development, and time constraints. The purpose of the learning outcomes is to provide a means of assessing the student’s ability to function in this type of development environment.

3.2 DECISIONS

Several decisions had to be made with regards to the structure of the course. Table 1 provides a brief description of these decisions and the section in which a more thorough explanation is provided.

2006 2007 2008 2009 2010
Programmers 2-3 2 6 9-10 5-6
Artists 0 0 3 per group 3 shares 4 shared
Musicians 0 0 0 2 shared 1 shared
Development Time 3-4 weeks

3-4 weeks

16 weeks 16 weeks 16 weeks
Rendering Engine Custom Custom Ogre Ogre Ogre
Version Control None None SVN SVN SVN

Table 1: Overview of Major Decisions

3.3 LARGER, INTERDISCIPLINARY GROUPS

As of this writing, the course has been offered five times with several varying parameters. These parameters are outlined in Table 2.

In the 2006 and 2007 offerings of the class, the students were all computer science majors divided into groups of two to three students. Although the class was open to artists, few chose to participate. Those who did felt overwhelmed by the workload and quickly dropped the course. In 2008 more artists were attracted with the promise that their workload would be manageable. Word of mouth led to the recruitment of more artists for 2009 and 2010.

Issue Relevance Section
Group Size What group size affords students with the best learning experience? 3.3
Artists How should artists be allocated to the groups? 3.3
Musicians How should musicians be allocated to the groups? 3.3
Rendering Engine What rendering engine procides the best combination of availability, power, and ease of use? 3.5
Version Control What is the best way to manage a large code base? 3.6
Demo How to evaluate the finished product? 5
Peer Evaluation How to evaluate each student's contribution to the project? 5
Motion Capture How best to integrate current animation technology into the course? 3.7
Project Size What is the best balance between complexity and manageability? 3.8
Software Tools How does software selection affect student productivity? 3.4

Table 2: Differences in Course Structure over the Five Offerings of the Course

In 2008, there were eighteen students enrolled. Of these, twelve were programmers and six were artists. Rather than break up the class into many smaller groups, it was decided that having only two groups of six programmers and three artists would allow for larger, more complete games to be developed. The groups met twice a week during class meetings and were also required to meet at least once a week outside of class. Using the success of this class as a basis, the 2009 class also used large groups, but pooled the three artists as a shared resource used by both teams of programmers. This was done because there was no way to easily split three artists between the two groups. This class also featured the introduction of musicians. Two musicians chose to participate and were also used as a shared resource. In 2010 there were 11 programmers divided into two groups of five or six, four shared artists and one musician. Creative writers will be integrated in future offerings of the course.

3.3.1 CHALLENGES FACED

Working in interdisciplinary groups provides students with a taste of real world development. In a survey conducted of all students that had taken the course, the computer science students were very satisfied with the abilities of artists and musicians when they were available and appreciated the chance to work with them.

For many, if not all, of the students, this was the first time they had worked on a large project with students from other disciplines, which presented some unique challenges. When the students first started working together, there was a lack of understanding between the members of different disciplines as to the challenges they faced. For example, programmers had no concept of how long it takes to make a model suitable for use in a game. However, to give the programmers a taste of the artist’s side of game development, all of them were required to make at least one model to be used in the game. These models were generally small things like bullets and crates, but it helped aid in understanding the artists’ challenges in the project.

The artists had to learn to make simpler character models with a much lower polygon count than they were accustomed to. In their art classes the focus is on making very highly detailed models but in games effcient use of resources is more important. Highly detailed models consume too many resources and impact the performance of a game. To resolve this issue the artists would make simpler models but use a detailed texture to give it a more visually appealing appearance.

The main problem faced by the musicians in 2009 was that the two teams did not give music requests until later in the semester and were largely ignored before that. In 2010 the teams were encouraged to decide what music will be required early on and communicate more with the musicians throughout the semester. This approach was more successful and will be used in future semesters.

3.4 SOFTWARE TOOLS

The course places an emphasis on free and open source tools so students can use these tools after graduation and continue to work on their created games. If the course used proprietary software the students would not have that freedom. The only exception is Maya [2], which the artists are required to use by their curriculum. The programmers are encouraged to use Blender [3] instead, since it is free and they do not require the power of Maya to make simple models.

3.5 Ogre

The first two times the class was taught, students used a graphics engine written by the professor teaching the class. One of the main complaints about this custom engine was the lack of documentation and lack of features. The third offering of the course saw a new professor and therefore a new engine needed to be selected. The Object-oriented Graphics Rendering Engine (Ogre) was chosen [4]. Ogre is a free, open source graphics engine. It is not a game engine, although many people, including those in this class, have used it for that purpose. It is written and maintained by a small core group and contributed to by a growing online community which also maintains a thorough wiki [5].

The power of Ogre is that it can be combined with other libraries, such as sound and physics, to create a customized game engine. Ogre does not include these libraries, but it does provide an interface to include these libraries in an application. In order to promote maximum flexibility, Ogre does not force users to use specific libraries. This use of additional external libraries is good practice for real production situations because graphics or game engines will rarely have all the required functionality built in.

In the classes where Ogre was used, each group took advantage of several of these external libraries. Most of the libraries and tools used worked very well, but some proved to be more difficult to integrate with Ogre. Students took this as a challenge to overcome. In addition, there were issues that could not be easily solved with a convenient library. One student spent many weeks developing a practical solution to fog of war, the obscuring of areas of a game world that have not been explored yet with fog, then posted his findings on the Ogre forums to share with the online community [6].

Many tools for content creation developed by the online community are also available. The Ogre Particle Accelerator is an example of one such tool [7]. It is written using Ogre and allows a user to create custom particle systems and see the results of parameter changes in real time as shown in Figure 1(a). When the particle system is completed, the editor can export a file that can then be loaded into the user’s application. An application that uses a particle system created in the Particle Accelerator is shown in Figure 1(b).

Figure 1.1Figure 1.2

Figure 1: Using the Ogre Particle Accelerator. (a) Creating a particle system with the Particle Accelerator. (b) A student created application using a particle system created in the Particle Accelerator.

In a survey given to all students that have taken the course, the comments about Ogre were very positive as compared to the custom engine used in previous years. Table 3 lists general student feelings about both engines.

  Custom Engine Ogre
Documentation Almost None Extensive Wiki and full API reference
Ease of Use Very difficult to use Tutorials on the wiki make it easy to become familiar with the code
Understandability Lack of documentation makes it hard to follow the code Generally easy to follow after completing tutorials
Adding custom functionarlity Very difficult External libraries make adding physics, sound, user interfaces, etc, simple in most cases
Support Original creator Extensive online community forums

Table 3: Summary of Student Comments on Custom Engine and Ogre

3.6 Subversion and Trac

Due to the size of the projects being developed in this course, each team was required to use Subversion and Trac [8, 9]. Subversion (SVN) is a command line open source version control system. Since development was done on Windows the students used TortoiseSVN instead [10], which is a Subversion client that easily integrates into the Windows environment. Trac provides a wiki and ticket system to allow students to keep track of bugs, tasks, and more. It can also act as an interface to an SVN repository and allow browsing of the source code and track changes made over time.

Using SVN also emphasizes the team cooperation aspect of the course and fosters a collaborative environment. When students are not assigned tasks or given any direction on what part of the code to work on, check-in conflicts, where multiple programmers are attempting to change the same part of the code simultaneously, will occur often. Coordinating which student is working on what section of the code base, via the Trac ticket system, reduces these conflicts. SVN and Trac were also used as part of the evaluation process in order to track student involvement in the projects. Since SVN and Trac activity is tied to a student’s school ID, if the student’s ID does not show up in the activity logs the instructor knows it is likely the student is not pulling his or her weight.

3.7 Content Creation

Characters used in the student games were modeled using a variety of modeling programs including Maya, Blender, and Milkshape [11]. Several models from one of the student games are shown in Figure 2. Most models were animated by hand, but a few were animated using the computer science department’s motion capture lab. Plugins for all three programs are available on the Ogre website to enable exporting of the character models in a format readable by Ogre.

The motion capture lab, running Vicon software, features eight cameras. It is an undergraduate lab open to any student with a valid reason for using it. In the 2008 offering of the course the lab was just being set up so only one group took advantage of this resource and only animated two characters with it. In 2009, however, one group animated all of their characters using motion capture. Figure 3 shows a student using the motion capture lab to record his movements on the left and the character from the game using those movements on the right. The other group used insect characters in their game and chose to do the animations by hand.

Maya was used by some groups to create the game environments, but others used a program called Earth Sculptor [12]. Earth Sculptor is a user friendly terrain creation tool that can make terrains suitable for inclusion in games. It is available in two versions: free with limited features and a full version for a small fee. For the purposes of this class, the free version was sufficient. After sculpting the terrain, the user can paint the desired textures onto it before exporting the terrain as a set of files that can be imported into Ogre. Figure 4 shows a terrain being created in Earth Sculptor (a) and imported into an Ogre application (b). For groups using Maya, the Ogre website provides an plugin for most versions of Maya to export the created terrain in the proper format for Ogre. Neither Earth Sculptor nor Maya is better than the other. Earth Sculptor has a shallower learning curve and works well when creating simpler environments. Maya has a very steep learning curve but is able to create more complex environments that Earth Sculptor cannot.

Figure 2

Figure 2: Models from Internal Conflict (2008).

Figure 3

Figure 3: A student having his motion captured and a game character following the captured motion.

Figure 4

Figure 4: Earth Sculptor - (a) A level being created in Earth Sculptor. (b) The terrain rendered in Ogre.

Sound effects and music were created using Adobe Audition [13] and Audacity [14]. Some teams recorded custom sounds for their game. The server in the game lab contains over 40GB of royalty free content that includes audio files that can be used to create music and sound effects, in addition to textures and models. All content created for the course is saved on the game lab server and is made available to all students in the video game concentration.

3.8 Development Time

In the 2006 and 2007 offerings of the course, the students were only given a few weeks at the end of the semester to work on their games. The early part of the term was devoted to lectures and demonstrations of various aspects of video game creation. As a result, the games produced were very small. Starting in 2008 the groups were formed by the end of the first week of classes. The groups began planning and brainstorming right away, with implementation beginning by the third or fourth week. In place of regular lectures students took advantage of Ogre’s extensive and detailed tutorials to get up to speed on Ogre and become familiar with game development topics. Special lectures on selected topics are given as interest warrants and time permits. Weekly show-and-tell updates are required, in addition to examination of SVN and Trac logs, to ensure that everyone is making progress. As a result, the groups are able to get a great deal accomplished. Sixteen weeks is only a fraction of the time spent on development in the game industry, where games require years and hundreds of people to complete, so it is understandable that none of the teams have been able to fully implement their game design. However, every team has made significant progress in that short time. All the games have been playable even if some features are missing or incomplete.

In the survey, students were asked to give a percentage representing how much of their original plan was implemented at the end of the semester. From 2006-2008 students gave responses generally ranging from 50-75%. In the 2009 class, where students were encouraged to start with a small plan, the responses were higher, ranging from 60-90%. The plans devised by the 2009 teams started with a minimum core game design and included a wish list of other features that would be added if time permitted. As a result, the teams were able to focus on the most important aspects of their respective games instead of incomplete features that would end up being removed from the game due to time constraints. The 2010 groups followed this same design structure, with 72% believing that they completed 70% or more of their original plan.

3.9 Internal Group Dynamics

As the size of a group grows, proper management of that group becomes even more important. Below are several measures taken to assist the students with managing their groups.

3.9.1 Team Leader

Every team was required to decide on a team leader. This person was responsible for assigning tasks to team members, dealing with con?icts, and making sure implementation was going according to schedule. In the survey, 85% of respondents felt that their team leader was an effective or very effective leader, with the remaining 15% stating their leader was only somewhat effective or not effective. Many of the poor responses were from students working on the game Carny Roll, which was plagued with leadership issues (see section 4.1).

3.9.2 Task Assignment

Before 2010, where the teams were required to use Trac for task management, the teams did not keep detailed records of who was assigned to a task. As a result, some students were able to slip through the cracks and do very little work. In an effort to prevent this from occurring again, in 2010 Trac tickets were used to assign tasks and the instructor was able to quickly identify students that were falling behind in their duties.

3.9.3 Trac Leader

Starting in 2010, the Trac leader was appointed by the team leader to handle the creation and assigning of tickets, as well as the managing of the weekly milestones. This allowed the instructor to easily see which students were completing their assigned tasks on time.

3.9.4 Artist/Musician Liaison

One student per group was appointed to be the liaison with the artists and musicians, if present. This student was responsible for communicating what art or music assets are required for their group’s game and ensuring that the artists or musicians are creating the assets in a timely manner.

4 Student Games

This section will give a brief overview of the games developed by the student groups in the last two iterations of the course.

4.1 Carny Roll (2008)

One team of the 2008 class decided to make a first-person shooter (FPS) game. In an FPS, the user sees from the perspective of a character and wields some sort of weapon such as a knife, sword, or gun. In Carny Roll, the user’s character is trapped in a dream of an evil carnival with other characters. Defeating the characters in the area earns tickets which are used to escape when enough have been collected. Figure 5 shows a screenshot of Carny Roll being played.

In a departure from FPS tradition, defeated characters do not collapse to the floor in a pool of blood. Instead, they explode into rubber ducks and candy. The students did this because they wanted to try an alternative from the traditional rag doll physics and bloody violence commonly seen in this genre of game. Carny Roll also features networked play with support for multiple servers. The use of the physics library NxOgre [15] allowed environment features such as barrels and crates to behave realistically when disturbed. Raknet, a cross-platform C++ game networking engine [16] was used to allow multiple players to compete over a network.

Figure 5

Figure 5: Screenshot of Carny Roll gameplay.

Unfortunately, leadership issues plagued this team. The team mutinied against two leaders due to their ineffectiveness and poor organization before finally settling on a third team leader. The constant changing of the command structure and lack of organization caused the overall quality of the game to suffer. Nearly all students on this team rated the leaders as ineffective in the survey.

4.2 Internal Conflict (2008)

The other 2008 team elected to make an educational game based on the real time strategy (RTS) genre. The basic premise of an RTS is to build up an army to defend against and defeat one or more enemy armies. While most RTS games have the player commanding an army of humanoid characters, in Internal Conflict, the user directs an army of beings based on cells in the human immune system. Using these cells, the player must defeat various diseases infecting the body in which the game takes place. Figure 6 shows a screenshot of Internal Conflict.

The characters are, for the most part, not based upon how they look in the human body, but the functionality of the cells is very similar. Because of this, Internal Conflict can potentially be used to teach people about the human immune system. The game features cel-shaded graphics, a style that makes objects rendered on a computer appear to be hand drawn. This allowed for many simpler models to be created. The game also includes voice acting for the immune system characters, fog of war to obscure unexplored areas of the map, and a simple artificial intelligence controlling the enemy army. All units use a path-finding algorithm to navigate around obstacles.

Also included with Internal Conflict is a stand-alone level editor. It was developed alongside the main game during the first half of the semester and then used to create the levels used in the game. After selecting a terrain and placing the initial setup of all the characters and buildings, the user can choose to export the level as a file that can be loaded by the main game. The level editor uses CEGUI [17] for its user interface. CEGUI uses XML scripts to describe the user interface layout and objects. The functionality of these objects is determined by the application code.

Figure 6

Figure 6: Screenshot of Internal Conflict gameplay.

4.3 Arachnitopia (2009)

In Arachnitopia, the user plays as a spider leading a group of other spiders to defeat the other insects and take over the entire game world. Like Internal Conflict, this game fits into the real-time strategy genre. Here the player must build up their army of spiders in order to defeat various insect opponents such as hornets and beetles. A screenshot of Arachnitopia gameplay is shown in Figure 7.

This team included several programmers who also had experience with modeling and drawing. As a result, some of the characters and art were created by these very enthusiastic programmers instead of the dedicated artists. Maya was used to create the game environment and some of the characters, with Milkshape used for the rest. CEGUI was used for the user interface with a custom style created by one of the programmers with artistic talent.

4.4 Steam Bout (2009)

Unlike the other groups, this team did not come up with the graphical style first and then tell the artists what was required. Instead, they used the idea of “psychographic profiles” of players developed by Wizards of the Coast [18], which uses the personality and behavioral traits of a person to determine their motivation for playing. In this way, developers can design content to satisfy each type of player. The artists were asked to design the characters to conform to those profiles using the art style of their choice. The resulting art style was steampunk, a blending of a setting where steam power was still used, such as the Victorian era, with elements from science fiction or fantasy. The game itself is a networked third person fighting game. The networking was done via Raknet. Each character has a certain amount of “energy” with which to perform their fighting moves. A gameplay screenshot is shown in Figure 8.

Figure 7

Figure 7: Screenshot of Arachnitopia gameplay.

Figure 8

Figure 8: Screenshot of Steam Bout gameplay.

4.5 Path of Cleansing: the Dark Horde (2010)

Path of Cleansing: The Dark Horde is a real time role playing game set in a medieval fantasy world. The game starts with the protagonist helping her mother tend to their farm. At some point, a giant meteor crashes into the farm, destroying the family farm house and unleashing a terrible plague upon the kingdom. People and animals become infected with the plague and turn into zombies. The player is tasked with finding the source of the plague and discovering a way to stop it. The game features a very detailed underlying battle system, similar to the Advanced Dungeons and Dragons (AD&D) table-top role playing adventure gaming system. Everything from player attributes such as intelligence, strength, charisma, constitution, and dexterity, are all meticulously factored into the damage calculations. A screenshot of the game is shown in Figure 9.

Figure 9

Figure 9: Screenshot of Path of Cleansing: the Dark Horde

4.6 N-STAL (2010)

The team creating N-STAL decided to make a game that was styled and inspired by games that featured more exploration and less outright combat or enemy encounters. They wanted to focus on one or two large encounters that would be fantastic, rather than several enemies that would be less interesting or exciting to fight, feeling that the player would be more impressed or challenged by something that was physically imposing. Their main character was based not on a soldier, as is common in this genre, but on an explorer. Taking a hint from Steam Bout, the team created a psychological profile of their main character and passed that to the artists, who styled his appearance off of the class professor in a form of homage. The other character that was given the most focus by the artists was the boss, a large, quadruped robot, shown in Figure 10.

Figure 10

Figure 10: Screenshot of N-STAL gameplay. The boss character rises from a crater to attack the player.

5 Post Development/Project Assessment

5.1 Performance Evaluation

At the end of the semester, teams are required to present their games in a seminar open to faculty, peers, industry professionals, and the media. Since it would not make sense for computer scientists to judge artwork or music, assessment of those parts of the game was done by faculty members from the appropriate departments where possible. A student’s grade for the course was based on a combination of factors:

5.1.1 Critiques of the Game by Peers

Each student is required to play the other teams’s game and evaluate it on several criteria, as well as give an overall impression:

  • Originality of concept
  • User Interface
  • Artwork and animation
  • Sound
  • Game Design
  • Balance Other students that have previously taken the course also volunteer to play and critique the games.

5.1.2 Status Updates

Students are required to show proof of their progress in order to verify progress is being made towards completing their assigned tasks instead of procrastinating until the end of the semester. SVN and Trac logs are mainly used as proof of progress, although a student may sometimes be working on a task offline and will be required to provide an appropriate proof.

5.1.3 Individual Cooperativeness and Productivity

Real world development is rarely done solo. Students are encouraged to collaborate with their team members to complete tasks. At the end of the semester all members of a team critique their teammates in regards to their cooperativeness and productivity.

5.1.4 Instructor’s Assessment of the Final Product

This includes evaluation of several factors:

  • Code review and demo
  • Gameplay
  • Features implemented
  • User interface
  • Percentages of original design implemented
  • Peer evaluations

5.1.5 Performance at the Seminar

Each team member is required to participate in the presentation. Students are graded based on their enthusiasm, preparation, and presentation.

5.1.6 Review by Professional Developers

Professional game developers attend the seminar and offer their input as to the quality of the final product, while taking the short development time into account.

5.2 Evolving Documentation and Resources

All artwork and music created for the games is collected at the end of the semester and saved on the game lab server. These assets are made available to future groups of students that take any of the game concentration classes. In addition, students that find and use a new Ogre plugin library are required to write a handout, in a standardized format, and provide example source code, if applicable, about the library to assist students that may use it in the future. The document covers how to integrate the plugin into Ogre, any pitfalls to watch out for, an example of how to use the library, and other helpful tips. In this way, students can use their experience to teach future students and reduce development time in upcoming semesters.

6 Related Work

Bayliss and Bierre [19] describe a newly designed and in-place curriculum named Game Design and Development (GD&D) at Rochester Institute of Technology, whose entire focus is on game design and development. The curriculum does overlap with the traditional Computer Science (CS) and Information Technology (IT) curriculum; however, the common courses deal mainly with advanced programming. The idea in the GD&D curriculum is to appeal to a broader range of students, with possibly more female students than in traditional CS and IT curriculums. It is reported that a smaller percentage of incoming GD&D students are familiar with basic programming than in the CS and IT curriculums, when they enter. However, the GD&D curriculum provides 3 innovative initial programming courses for GD&D students via usage of Wii-controlled games and a supplied code base. It has been observed that GD&D students go on to take the regular course in C++ programming and do well in terms of performance as well as retention. Furthermore, upon completing the curriculum, the majority of GD&D students wished to become software developers in gaming industry (44%) or game designers (25%). In other words, the curriculum inspired most GD&D students to become software developers and designers.

The work by Bidarra, et al. in [20] describes a particular course on game projects, taught in the second year, at Delfts University of Technology with a focus on game development in large teams consisting of students from different disciplines. The proposed courses learning outcomes include demonstrating proficiency in the following:

  1. Applying media and programming techniques within the context of computer games, and in relating them to particular game effects;
  2. Striving for the balance between the effectiveness of a programming technique and the desired quality of a game effect;
  3. Describing the main modules of a game engine and purposefully using their functionality;
  4. Deepening object-oriented programming skills while building a complex and large software system; and
  5. Developing and contrasting teamwork skills within the context of a realistic interdisciplinary team.

The deliverables for the proposed project-based course include working source code, game design document, and technical document. The survey results, reported in the paper, indicate that the students were highly motivated upon completing the course and were largely happy with the projects.

Brown, Lee, and Alejandre [21] report introducing a game design project in the department of computer science at Drexel University with an emphasis on developing team development skills as well as other soft-skills in students. The goals of the course were to:

  • Provide students with an opportunity to develop math games for middle school students that can be immediately available for use;
  • Enable students to receive and respond to feedback from multiple sources;
  • Teach educational game design and development concepts to Drexel University students by providing them with a real world application for the knowledge gained,
  • Provide students with an opportunity to express their ideas using multiple media such as online-only discussion board exchanges, storyboards and class presentations, and
  • Provide students with an opportunity to work in teams of students from technical and non-technical disciplines.

A team consisted of students from computer science, education, and digital media. The end users for the product (game) were K-12 students and teachers. The course entailed not only planning, design, and development, but also demonstrating the product to the end user and taking their feedback into account for further improving the product.

Kessler, van Langeveld, and Altizer [22] describe a new interdisciplinary program at the University of Utah, entitled Entertainment Arts and Engineering (EAE), which brings together students from the School of Computing and the Division of Film Studies in an effort to teach both video game development and computer animation. The key characteristic of the program is the shared classes where students from both Computer Science and Fine Arts study together and cooperate on game and animation projects. The program is highlighted by a yearlong capstone course in which the students work together to make a video game or animated short from scratch. The interdisciplinary program is reported to attract students and better equip them for careers in video games and animation.

The report from a forum in [23] states that gaming is an interdisciplinary field with a wide range of topics encompassed by the acts of game creation, analysis and criticism. It states that game development students must be exposed to analytical, practical and contextual materials, and it points to the International Game Developer Associations (IGDAs) curriculum framework.

One common factor in most of these programs is the focus on getting the task done (i.e., a game designed and developed) in mid to large size teams, mostly interdisciplinary. This is a significant departure from the traditional computer science curriculum, which was mostly devoid of such experience.

7 Conclusions and Future Work

Developing a game curriculum is a challenging task that requires cooperation and expertise from several diverse areas of knowledge, as articulated in [24]. Further, there could be many ways of designing a curriculum depending on the emphasis of the curriculum. The video game design and development curriculum was established as a concentration within the framework of an existing, fifty year old nationally accredited program that awards the Bachelor of Science degree in Computer Science. It meets or exceeds the minimum guidelines set forth in [24] for starting a game curriculum.

A criticism of many college courses is that they do not represent a “real world” experience. Within the constraints of time and personnel, the current format of the course described here attempts to provide students with as realistic a game development environment as possible. Under the current format, 90% of students felt that the course was either “useful” or “very useful” in preparing them for a career in video game development. The professors have noticed that students taking this course have gained broader knowledge that can be taken to other courses and the workforce. This includes but is not limited to:

  • Code efficiency – In the offerings of the course where artists were not present, the graphics used in the game were very simplistic and did not tax the hardware. The assets provided by the artists in later offerings were complicated enough to cause slowdown in the games unless the students optimized their code.
  • Modular design – Due to interfacing with Ogre’s prebuilt libraries, the students had to use a more modular design and work around what was already written. This also gave them experience working with other people’s code that will be useful for all future development projects.
  • Interdisciplinary cooperation – The students now have experience working with people from other disciplines. This will be beneficial when they graduate and work on real development projects.
  • Self sufficiency – Students quickly discovered that for many tasks, such as physics or networking, one or more Ogre libraries existed. However, there were also many features planned for the games where no such library existed and the students wrote their own application or code. One of the programmers for Internal Conflict created a custom level editor in order to design the levels for the game with a convenient click and drag interface. On the same game, another student created a custom implementation of fog of war.

As of this writing, the senior level game development class has been taught five times, three times in its current version. Student response to the last three iterations has been overwhelmingly positive. Many students from the first two semesters of the course have expressed a desire to take the class again. The survey asked students how satisfied they were with the course overall, and the results indicated much higher satisfaction levels for all aspects of the course under the new format. Students that had taken the course under both formats were very pleased with the new format and felt it provided for a much better learning experience.

In the future the class will be expanded to include students from performing arts and creative writing. Also, the department will begin encouraging students to consider more educational themed games like Internal Conflict in all the gaming courses.

8 Acknowledgments

The authors would like to thank the anonymous reviewers for their constructive comments.

References

[1] Bachelor of science degree program with a concentration in video game design and development. http: //www.louisiana.edu/Academic/Sciences/CMPS/, 2009.

[2] Autodesk. Maya. http://usa.autodesk.com/adsk/, 2009.

[3] Blender Foundation. Blender. http://www.blender.org/, 2009.

[4] Ogre Website. http://ogre3d.org/, 2010.

[5] Ogre Wiki. http://www.ogre3d.org/tikiwiki/tiki-index.php, 2010.

[6] Todd Fontenot. Fog of War topic on Ogre Forums. http://www.ogre3d.org/phpBB2/viewtopic.php? t=41829&sid=f7734e153a689165f34ba42e51fc470a, 2009.

[7] Ogre Particle Accelerator. http://www.ogre3d.org/tikiwiki/tiki-index.php?page=Particle% 20Accelerator, 2010.

[8] Subversion. http://subversion.tigris.org/, 2009.

[9] Edgewall Software. Trac. http://trac.edgewall.org/, 2009.

[10] TortoiseSVN. http://tortoisesvn.tigris.org/, 2009.

[11] Milkshape. http://chumbalum.swissquake.ch/, 2009.

[12] Ernest Szoka. Earth Sculptor. http://www.earthsculptor.com/, 2009.

[13] Adobe. Adobe Audition. http://www.adobe.com/products/audition/, 2009.

[14] Audacity. http://audacity.sourceforge.net/, 2009.

[15] NxOgre. http://www.nxogre.org/, 2009.

[16] Jenkins Software. Raknet. http://www.jenkinssoftware.com/, 2009.

[17] Paul Turner. CEGUI. http://www.cegui.org.uk/wiki/index.php/Main_Page, 2009.

[18] Mark Rosewater. Timmy, Johnny, and Spike. http://www.wizards.com/Magic/Magazine/Article. aspx?x=mtgcom/daily/mr11b, 2009.

[19] Jessica D. Bayliss and Kevin Bierre. Game design and development students: who are they? In GDCSE ’08: Proceedings of the 3rd international conference on Game development in computer science education, pages 6–10, New York, NY, USA, 2008. ACM.

[20] Rafael Bidarra, Jerke Boers, Jeroen Dobbe, and Remco Huijser. Bringing a pioneer games project to the next level. In GDCSE ’08: Proceedings of the 3rd international conference on Game development in computer science education, pages 11–15, New York, NY, USA, 2008. ACM.

[21] Quincy Brown, Frank Lee, and Suzanne Alejandre. Emphasizing soft skills and team development in an educational digital game design course. In FDG ’09: Proceedings of the 4th International Conference on Foundations of Digital Games, pages 240–247, New York, NY, USA, 2009. ACM.

[22] Robert Kessler, Mark van Langeveld, and Roger Altizer. Entertainment arts and engineering(or how to fast track a new interdisciplinary program). In SIGCSE ’09: Proceedings of the 40th ACM technical symposium on Computer science education, pages 539–543, New York, NY, USA, 2009. ACM.

[23] Jason Della Rocca, Robin Hunike, Warren Spector, and Eric Zimmerman. Game development, design and analysis curriculum. In SIGGRAPH ’02: ACM SIGGRAPH 2002 conference abstracts and applications, page 16, New York, NY, USA, 2002. ACM.

[24] International Game Developers Association. International Game Developers Association (IGDA) Curriculum Framework, version 3.2 beta edition, February 2008.

About Us

The JGDDE is a peer-reviewed journal, that covers all aspects of teaching the art, craft and science of game design and development to students in and out of a higher education setting.

Read More


Submit an Article

Do you have some original research, book reviews or survey articles you'd like to share with us? See if your article can be hosted on the Journal of Game Design & Development Education

Read more


Distribution

  • Download our entire 2011 Journal as a PDF
  • Purchase a copy at Lulu.com