Developing Criteria for the Supervision of Computer game development Projects A Case Study at the School of ICT, NMMU J.F. van Niekerk
∗
L.A. Futcher
Institute for ICT Advancement Nelson Mandela Metropolitan University Port Elizabeth, South Africa
Institute for ICT Advancement Nelson Mandela Metropolitan University Port Elizabeth, South Africa
[email protected]
[email protected]
ABSTRACT
development should thus become a viable career option for almost any software development student. At the Nelson Mandela Metropolitan University (NMMU) School of Information and Communication Technology (ICT), students are actively encouraged to pursue game development as an option for the ”capstone” third year software development project. These third year game development projects are in many respects similar to more business oriented software development projects. However, despite the similarities, game development projects do pose some unique challenges. Certain software documentation requirements, for example entity-relationship diagrams, are not always applicable in a game development context. As such, the effective supervision of game development projects requires different criteria for student ”hand-ins” and assessments. Despite this, the School of ICT at the NMMU has been very successful in the supervision of such game development projects. Since the inception of Microsoft’s Imagine Cup competition, the School of ICT’s students have completely dominated the game programming division of the South African leg of this competition. In both 2009 and 2010, for example, students from the School of ICT were awarded the top three placings in the game development division of this competition. However, until recently, lecturers involved in the supervision of such game development projects have been using the same criteria as developed for the more typical business oriented systems for game development project ”hand-ins” and assessments. These criteria were typically modified on an ad hoc and informal basis to suit the requirements for specific game development projects. Such an ad hoc approach to the supervision of these projects relied heavily on the experience of the specific lecturers involved and was thus not a desirable situation. This paper outlines how a set of criteria and guidelines specific for the supervision of computer game development projects has been developed by the lecturers previously involved in the supervision of these projects over the past five years. The paper briefly outlines how ”typical” third year projects are managed at the School of ICT, and then critically evaluates these guidelines in terms of their suitability for game development projects. Finally, a set of criteria and guidelines specific to game development projects is presented.
The computer gaming industry has shown tremendous growth over recent years. Developing computer games has become a viable career option for software development students. However, very few formal qualifications offered by South African universities are preparing students specifically for careers in this industry. At the NMMU in the School of ICT this problem is partially addressed by allowing students to develop computer games as their third year software development projects. This paper presents the lessons learned during the supervision of such projects over the past seven years in the form of a case study.
Categories and Subject Descriptors H.4 [Information Systems Applications]: Miscellaneous; D.2.8 [Software Engineering]: Metrics—complexity measures, performance measures
General Terms Keywords Capstone projects, Software development, Game development
1.
†
INTRODUCTION
The computer gaming industry is currently worth more money per year than any other sector within the entertainment industry. Unfortunately, very few formal qualifications offered by South African universities are preparing students specifically for careers in this industry. However, it could be argued that a student studying towards a typical software development qualification should in fact gain most of the skills needed to enable him/her to pursue a career in the game development industry. Computer game ∗No note †No Note
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SACLA 2011, October 11-13, Bela Bela, South Africa Copyright 2010 ACM 978-1-60558-950-3/10/10 ...$10.00.
2.
METHODOLOGY
The work in this paper is based primarily on the experience of the authors. The game development guidelines 1
were in part developed according to an action research like approach. The lessons learned during this process over the past seven years will be presented in this paper. The paper is written according to case study guidelines from Creswell [2] which suggests the following structure for the presentation of case studies:
guidelines for ”traditional” third year software development projects.
4.
Third year software development projects focussing on developing business oriented systems are supervised according to a set of guidelines which have evolved over several years. These guidelines are continuously adapted and presents the students, and supervising lecturers, with a clear outline of prescribed deliverables and time frames for these deliverables. The following is a brief overview of the primary deliverables and relative time frames.
• Entry vignette • Introduction • Description of the case and its context • Development of issues • Detail about the selected issues
4.1
• Assertions
Overview
As mentioned earlier, the third year software development projects fill the role of a capstone experience as described in ACM/IEEE-CS [4]. As such the students have to work in groups of typically 2 to 4 students, usually addressing a ”real” problem, and spanning a period of approximately 29 weeks. The students are required to integrate knowledge from all prior subjects and often have to use tools and/or technologies they have not been formally taught. The third year projects follow an agile-like approach. This approach cannot be strictly agile, due to the need to fit the project activities into an existing curriculum. The projects thus try to espouse the principles of agile development without enforcing strict adherence to a specific agile methodology. The project consists of four major iterations, each ending at a major milestone in the project’s lifecycle.
• Closing vignette
3.
DESCRIPTION OF THE CASE AND ITS CONTEXT
INTRODUCTION
At the NMMU’s School of ICT, third year software development projects have always been viewed as a major capstone experience. Such a capstone experience commonly serves to integrate the knowledge acquired in all other subjects leading up to the experience. According to the ACM/IEEE-CS IT curriculum guidelines [4, p. 35] such capstone experiences generally have three common elements; 1) students are required to work in teams, 2) they have to address ”real world” problems, and 3) the projects generally span many weeks. The ACM/IEEE-CS IT curriculum guidelines also states that such projects aim to ”address the aspects of the Information Technology discipline that cannot be presented adequately in the formal classroom setting”, and that ”these skills can be learned only in the framework of an independent capstone experience” [4, p. 58]. The School of ICT has always seen the third year software development projects, and the role(s) they play in its curricula, in a similar light as that described in the Information Technology 2008 Curriculum Guidelines for Undergraduate Degree Programs in Information Technology [4]. Traditionally these projects have been limited to ”real world” problems focussing on business oriented solutions or on issues of a more technical nature. The deliverables students have had to submit through the course of such projects have thus been in line with the needs of such business oriented problems. This focus on business oriented problems is in line with the School of ICT’s focus on vocational education. This means that the School actively tries to align its educational approach with current industry needs. Due to this alignment with business needs, the approach towards third year software development projects are continuously adapted in order to stay in line with IT industry trends. As such, there has been a move away from the more ”traditional” structured systems analysis and design methodologies towards an agile/scrum based approach, as described in Ambler [1]. Similarly, the enormous growth in the computer game development industry, as well as the advent of more ”mainstream” game development environments such as XNA, has prompted the School to start encouraging game development oriented third year software development projects in addition to the more business oriented projects. Initially, these game development projects were supervised according to the same guidelines that were used for the business oriented projects. The next section of this case study will briefly discuss the School’s current
Iteration 0 This iteration starts with the initial scoping and definition of the project and ends with the delivery of a detailed requirements specification. Iteration 1 This iteration starts with a ”contract” based on the requirements analysis from the previous iteration. The primary activity during this iteration is the analysis and design of the core components of the intended system. A working prototype of the core components must be presented at the end of this iteration. Iteration 2 Similarly to iteration 1, this iteration starts with a ”contract” outlining extended functionality that will be added to the core system developed during the previous iteration. This iteration ends with a system that meets all the major requirements of the final system. Iteration 3 The final iteration focuses on final acceptance testing, ”packaging”, and deployment of the final system. This iteration ends in a final judging session where the projects are assessed by a panel of 4 to 5 ”judges” as well as an external moderator. Each of the above iterations requires the submission of specific elements of the project documentation at predefined weekly intervals. Submission of these deliverables contributes towards an overall project management mark which impacts the final summative assessment. Each iteration is also subjected to a formative assessment by a panel of ”judges”. These formative assessments result in extensive feedback and play a major role in determining the contents of the ”contract” for the next iteration. The following subsection provides a more detailed outline of the weekly deadlines. 2
4.2
Detailed outline of project deliverables per week
Week 16 Iteration 1 Presentation - Focus on Business Understanding, Process Flow, User Interface Design, Reporting , Online Help - Core Functionality (must be fully tested and implemented)
As stated previously, the third year software development projects span a period of 29 weeks. At the start of this period, students are provided with a detailed outline of the prescribed deliverables for each week of the project. These deliverables are further elaborated on in weekly project lectures. Each project group is assigned to a lecturer who acts as a project supervisor, and groups are required to find a willing ”user” to advise them on the business specific needs for the project. These ”users” can be actual clients from industry, a knowledgeable lecturer, or even a post-graduate student who is willing act as a user. The students compile requirements specifications with the aid of both users and supervisors. These are then submitted to the project coordinator and assessed, on a continuous basis, by various ”judges”. The following is a detailed list of the weekly deliverables expected from project students:
Week 16 Iteration 2 contract (signed by all stakeholders) Week 17-23 Ongoing meetings with project stakeholders Week 24-25 Project Seminar (Iteration 2 Presentation) - focus on selling system to ”potential buyers Week 25 Iteration 2 documentation Hand-In (Contract, Introduction, Updates since Iteration 1, Minutes of Meetings, Timesheets). Week 26 Hand-in Lessons Learned (individually) Week 26 Create Install/Setup CD and test.
Week 1 - 2 Project Group Name and Logo. Project Group Members (2-4 per group)
Week 27 Hand-in Final CD (Containing all source code, database, install/setup files, project documentation)
Week 3 1-3 Potential project ideas (1 paragraph per idea) Week 4 Project Overview (Project Title, Group Name, Group Members and contact details, Stakeholders and contact details, Brief Project Description, Proposed Solution)
Week 27 Iteration 3 documentation Hand-in (Intro, Hardware and Software Requirements, Install procedure, lessons learned, marketing material, etc.)
Week 5 Project Proposal (Problem Statement Matrix, PIECES Framework, Project Scope, MoSCoW, HighLevel Use Case Diagram)
Week 27 Return complete set of documentation (Iteration 0,1,2,3)
Week 6 Detailed Requirements Specification (Functional, Non-functional, User Interface Requirements, Database Requirements, Security Requirements, Project Constraints) Week 7 - 9 Iteration 0 - PowerPoint Presentations (Include Introduction, Overview Diagram, Problem Statement, Detailed Requirements Specification, High-level Use Case Diagrams)
Week 28 Final Judging (Complete system, fully tested and implemented, no errors) Week 29 Innovation Day and Awards. The above schedule of deliverables is used ”as is” by software development project students doing business oriented projects. Initially, the same approach was used with game development projects. However, almost right from the start it became necessary to make exceptions to the ”rules” to deal with the different requirements specific to game development projects. The following section discusses some of the issues encountered with game development projects.
Week 10 Iteration 0 Documentation Hand-In (Project Overview, Project Proposal, Detailed Requirements Specification, PowerPoint Slides, Minutes of Meetings, Timesheets). Week 11 Iteration 1 Contract (signed by all stakeholders), Entity Relationship Diagram, Class Diagrams (if relevant), Detailed Use Case Narratives
5.
Week 12 Data Flow, Sequence and State Transition Diagrams, Test Cases (linked to detailed use case narratives)
5.1
DEVELOPMENT OF ISSUES Game development projects usually do not have a user and/or business problem
In business oriented software development projects the students have to find a person to act as a user for the project. The project team members have to meet with this user on a regular basis and essentially develop a system in response to some business problem the user has identified. Game development projects differ in the sense that most games do not aim to address a specific business problem. Instead, games are developed with the primary aim of being ”fun”. Often the students involved in such a project have no clear idea of the intended end product and simply want to ”write a game”. In a business oriented project the problem and/or user to a certain extent dictates the end product.
Week 13 Story Board Designs Week 14 Sample Reports (3 to 5) Week 15 Discuss Project Judging and Iteration 1 handin Week 16 Iteration 1 Final Documentation Hand-In (Contract, Introduction, ERDs, Class Diagrams, Use Case Narratives, Data Flow Diagrams, Sequence Diagrams, State Transition Diagrams, Test Cases, Sample Reports, Story Board Designs, Minutes of Meetings, Timesheets). 3
5.2
Game development technologies are not taught as part of the formal curriculum
map and to shoot at enemies who can shoot back. Typical genres include strategy games, first person shooter, role playing games, space combat games, simulations like racing and flight simulators, platform games, etc. The choice of a genre is very important since, to a certain extent, it dictates features the game should be supporting.
Students studying towards a software development qualification gain most of the skills needed to develop games as part of their formal curricula. From a programming perspective, there is very little difference between developing a game and developing a business oriented application. For example, game development requires very strong basic programming skills as well as good logic and problem solving skills. It could also be argued that strong object oriented programming skills are essential to game development. However, there are certain game development specific skills and technologies that do not form part of most formal software development curricula. The XNA framework is one such technology. XNA is a managed game development framework which encapsulates Microsoft’s DirectX application programmers interface. This framework makes it possible for students to develop games based on DirectX technologies without needing low-level knowledge of DirectX. However, despite making it easier to learn how to develop games, mastering the XNA framework still requires students to spend a significant amount of extracurricular time learning how to use it. This brings several additional risks to such a project. Firstly, there is a risk that students may not be able to learn the needed technologies in time to meet the project requirements. Secondly, students may not have the ability and/or motivation to teach themselves. Finally, it is also possible that students may try to deliver sub-standard work using the fact that they had to ”teach themselves” as an excuse.
5.3
• Perspective: The second important choice that needs to be made is whether the game graphics will be in 2 or 3 dimensions. There is large difference in the handling of both artistic and technical aspects of a game that depends on this choice. A 3 dimensional game also usually dictates a steeper learning curve for the students involved. • Theme: A game’s theme determines its ”storyline” and to a large extent dictates many of the other elements. A game with a ”detective” theme would thus revolve around the gathering of evidence and the solving of puzzles, whilst a space exploration theme would dictate a ”science fiction” kind of setting. Clearly a change in game ”theme” would have major implications for the overall development of the game. It is thus essential to determine, and describe, the theme of a game early in the development/design process. • Mechanics: Game mechanics are closely linked to the genre, perspective and theme. Game mechanics basically governs how elements in the game will be manipulated by either players or some form of artificial intelligence. Both the ”physics” governing movement and behavior of elements in the game world, as well as player interaction with elements in the game world, are implemented through the development of ”mechanics”. Game developers need to decide which mechanics will form a part of the game from the outset since changes to such decisions at a later stage could have a far-reaching impact on the other game elements.
Supervisors might lack game development skills and/or knowledge
Another potential problem, which is closely related to the one discussed in the previous subsection, is that the supervising lecturer might also lack game development skills and/or knowledge. The supervisor plays an important role in third year projects and needs sufficient knowledge to be able to advise students regarding design choices, etc. If the supervisor him/herself lacks the underlying knowledge and/or skills it would not be possible to advise students appropriately. Students developing games also often choose to use ”starter kits” and/or third party ”game engines”. The supervising lecturing staff, as well as the assessors for the projects would need sufficient knowledge of such available tools in order to judge how much of the delivered end product is the students’ own work.
5.4
• Single player vs multi-player: Another major choice that needs to be made by players early on is the number of players the game is intended for. Depending on the genre and/or theme a single player game would often require the development of some form of artificial intelligence to provide a challenge to the player. A multi-player game, on the other hand, would require a strategy for dealing with multiple inputs and/or displays. Often a multi-player game would necessitate the development of networked game play.
Game development projects require different choices
Game development projects also require very different choices from the students at the start of the project. Students have to decide on issues like the genre of the game they want to develop, whether the game will be 2 dimensional or 3 dimensional, the basic theme of the game, the game mechanics, whether it will be a single player or a multi-player game, etc. Many of these choices have to made before the students have a clear understanding of the implications of such a choice on the overall scope of the project and their own learning curve. Each of these choices will be briefly discussed:
• Networked or stand-alone: Many multi-player games requires networked capabilities. This requires the design/development of a communication strategy for the game. Many such games are completely reliant on fast and ”smooth” graphics and game play in order to be enjoyable. This means that game developers need to think about issues relating to the amount of data they pass between players, network prediction algorithms, ways of dealing with latency and/or packet loss, etc.
• Genre: Games come in several genres. Each of these have certain features that a player of such a game would typically expect from the game. In a first person shoot, for example, the player would expect to be able to move around some form of a
5.5
Data Storage
Business oriented software development projects almost invariably are supported by a relational database system. 4
The design and implementation of such a database system are also seen as core to these systems. For most, but not all, games such a database system adds unnecessary overhead. Firstly, there is a need for very fast and consistent response times in a computer game. The primary execution cycle of a game repeatedly calls an update method to update the state of game elements based on game ”rules”, mechanics, player inputs, etc. This update method call is followed by a draw method call which renders the graphical representations of the game elements on the screen. In order for a game to run ”smoothly”, this cycle should repeat about 60 times per second. It is thus considered impractical to constantly read, from and/or write to, a database during these cycles. Instead, most games hold all necessary information for a specific level (or game phase) in memory. The application programmer’s interfaces (APIs) for game development platforms like the XBOX also do not support the frameworks needed to interact with a relational database. Lastly, games do not usually generate a large amount of ”important” data. It is only considered important to store data in a non-volatile way for functions like saving the game state, or keeping a top score list. This is generally accomplished through writing to a ”simple” text file, or through the serialization of all objects in memory to an XML stream.
5.6
section is based on lessons learned (sometimes the hard way) over the last 7 years.
6.1
As mentioned earlier, the ”user” and/or business problem in a business oriented software development project, to a large extent, dictates the actual end product the project has to deliver. This is dealt with by requiring game development students to submit a very detailed high level game project overview as described by [3, pp. 101-110]. This overview is outlined in section 6.7 and forms part of the deliverables for weeks 4, 5 and 6.
6.2
Game development technologies are not taught as part of the formal curriculum
This issue is dealt with through two major ”interventions”. Firstly, due to the fact that game development technologies are not taught as part of the formal software development curriculum, most technology related choices in the initial game development projects allowed at the School of ICT were left to the students’ discretion. Students thus had the option of using frameworks like DirectX or OpenGL at their own discretion. These frameworks, especially DirectX, also had very steep learning curves. This resulted in a very large risk that students might fail to deliver their intended ”products” on time. The advent of Microsoft’s XNA framework changed this. Due to its managed nature, and the availability of textbooks and other learning material, the XNA framework has significantly reduced the learning curve towards creating a first game. At the School of ICT, students wishing to develop a game as a third year project are now required to use the XNA framework for all game development. Secondly, a special interest group for game development was started at the School of ICT. Membership of this special interest group is free to all students but compulsory for students wishing to develop games as their third year project. The group meets once a week, during the designated lunch hour, in a programming laboratory. At each meeting some game development topics are discussed and brief examples of implementation specific issues are presented. The sessions at these meetings are lead/presented by either staff members interested in game development, or senior students who have developed games as their own third year projects. Currently one of the students who has previously completed a successful game development project is employed by the School of ICT as a student assistant for game development. This student is partly responsible for ensuring the running of this special interest group. This ”game development assistant” also plays a significant role in addressing the lack of supervisors with game development skills.
Graphics
The ”quality” of computer games are usually very closely tied to the quality of non-programming related elements such a graphics and/or sounds used in the game. The graphics used differ substantially depending on the perspective of the game. For a 2 dimensional (2D) game a large amount of 2D drawings is used. For example: to have a representation of a wizard that walks the developers would need several images representing such a wizard in various stages of walking. These images are then moved across the visible screen, whilst simultaneously being swapped through the stages of walking, during the game’s update and draw cycles [5, pp. 15-45]. This creates the visual impression of a wizard walking across the screen. In 3 dimensional (3D) games the same wizard would be modeled onto a 3 dimensional wire-frame model. The model is then ”colored in” by applying carious texture to the outer surface of the wire-frame model. The 3D model is then manipulated to move across the screen and to be in various stages of walking during the update and draw cycles of the game [5, pp. 201-211]. It is important to note that the creation of these graphics, though extremely important to the overall success of a game, can not be considered to be ”development” from a programming curriculum perspective. All of the above issues contribute, in varying degrees, towards the differences in supervising game development projects. The next section will discuss the lessons learned about dealing with these issues, and how they are currently dealt with, at the School of ICT.
6.
Game development projects usually do not have a user and/or business problem
6.3
Supervisors might lack game development skills and/or knowledge
At the School of ICT, the success of third year projects is largely due to the fact that most staff members form part of the projects in some or other capacity. It is expected of every lecturer to be involved in a supervisory capacity for at least one project team. Unfortunately, the lack of game development related knowledge amongst lecturing staff also means that lecturers who do have the technical background to supervise game development projects tend to be involved with more projects than average. Every project supervisor is expected to meet with every project
DETAIL ABOUT THE SELECTED ISSUES
The issues discussed in the previous section impacts on the supervision of game development projects. This section discusses how the School of ICT deals with these issues. The section firstly provides brief detail on each of the individual issues and then presents a detailed guideline to weekly project deliverables currently being used specifically for game development projects. The work in this 5
team they are supervising at least once per week. Currently only one lecturer is actively supervising the game development projects. Due to the large number of project groups developing games, this has resulted in various time management issues. This problem is addressed through three mechanisms. Firstly, the guidelines presented in this paper are continually being improved and formalized. It is hoped that these guidelines will reach a maturity level which will eventually enable any lecturer in the school to act as supervisor for game development projects. Secondly, in conjunction with the activities of the special interest group mentioned in the previous sub-section, an e-learning portal for game development topics is being developed. Finally, the student assistant appointed for the game development activities is also utilized as a cosupervisor for many of the game development projects. This reduces the ”load” on the lecturer involved.
6.4
to ”outsource” the creation of the graphics for their games to art students. Over the last few years an informal, but mutually beneficial relationship between students from the game programming special interest group and graphic design/fine art students has developed. Unfortunately this also brings additional risk to the project. If the art student(s), who have no formal requirement to ”deliver”, loses interest in the project, or simply do not deliver, this can have a very negative impact on the IT students’ project. • Secondly, there is a risk that the IT students want to wait for the final graphics before writing the code to manipulate the graphics on the screen. A lot of the code in a game project relates directly to the underlying graphical representations. For instance, there is code that loads the content, manipulates it, draws it, compares it for collisions to other graphical elements, and swaps between images to animate game objects. If there is a significant change in the underlying graphics it sometimes requires a lot of additional changes in the rest of the code. Often students embarking on a game development project have little or no previous experience in dealing with computer graphics and thus do not know how to deal with such changes.
Game development projects require different choices
All of the choices that game development students have to make are addressed in the form of different deliverables in the adapted guidelines presented in section 6.7. These choices are also discussed in depth with the students during special interest group sessions. For some of the possible choices the guidelines are very prescriptive. For example: if students wish to develop a networked multi-player game they have to develop it based on the existing XBOX live tools. Finally, students are not allowed to develop 3D games as third year projects unless they can demonstrate that they have previously developed successful 2D games.
6.5
• Both of the above issues are largely addressed via the same mechanism, namely, the use of placeholder graphics. Placeholder graphics are simplified graphics which takes the place of the final more ”rich” graphics during the earlier stages of a game’s development. It is vital to develop placeholder graphics according to the exact same specifications as the final graphics that will be used. For example: if the intended final graphics require the creation of a sprite sheet (a single graphics file containing a ”sheet” with multiple images of the same in-game element, i.e. a wizard in various stages of walking), the placeholder graphics would contain an exact duplicate sprite sheet, in all aspects except for the level of sophistication of the actual content. Thus, for a sheet containing nine images of a wizard walking, there will be a placeholder graphic sheet containing nine images of a ”stickman” wizard walking. The location of the individual images, i.e. from pixel coordinates (100,100) to pixel coordinates (200,300) and the placement of the element within those images, i.e. the wizard’s feet must be exactly 10 pixels above the bottom of the image and his head must be exactly 25 pixels below the top, etc. must be an exact match for the intended final sprite sheet. A well planned set of placeholder graphics enables students to develop and test an entire game without needing access to a final version of the graphics. Should the artist deliver the final graphics according to the same specification, the entire game can be updated with the final graphics by simply replacing the underlying content files and re-compiling the game. The development of an extensive set of placeholder graphics is seen as essential to the success of a third year game development project and is the primary deliverable for week 13 of the project life-cycle outlined in section 6.7.
Data Storage
In business oriented software development projects the design of the underlying database system plays a major role in both the project’s life-cycle and the assessment of the final project. In game development projects the design focus is more object oriented. There is thus a large focus on the design of the games underlying class hierarchy and on the interactions between classes. This is reflected in the emphasis on class diagrams, sequence diagrams, activity diagrams and state transition diagrams instead of focussing on entity-relationship diagrams. A focus on data storage is thus mostly replaced by the in-memory management of data in various states. The actual data storage structures used is thus evaluated in terms of the applicability of these structures for the given object hierarchies.
6.6
Graphics
Graphics can be seen as one of the biggest risk areas in a student game development project. Poor graphics can have a major detrimental effect on the overall impression made by a game. However, good graphics can not be seen as a substitute for good development skills. The following lessons were learned over the last few years: • The first area that needs to be addressed very clearly is thus the expectations of the software development students themselves. Students need to realize that the development of the actual graphics will not get them credit for software development. They can thus not assign this as a task to a single team member and then divide the rest of the development responsibilities amongst the rest of the team. Each project team member must make a software development contribution towards the overall project. At the School of ICT, students are strongly encouraged
Proper management of issues relating to graphics, and to the communication of graphics requirements between game designers and graphical artists, is one of the most 6
essential parts to delivering a successful student game project. Finally, all of the previously discussed issues need to be incorporated into the detailed outline of project deliverables.
6.7
Week 24-25 Project Seminar (Iteration 2 presentation) - focus on selling system to ”potential buyers Week 25 Iteration 2 documentation Hand-In (Contract, Introduction, Updates since Iteration 1, Minutes of Meetings, Timesheets).
Detailed outline of game project deliverables per week
Week 26 Hand-in lessons learned (individually)
This subsection presents the current weekly outline for deliverables specific to game development projects at the School of ICT.
Week 26 Create Install/Setup CD and test. Week 27 Hand-in Final CD (containing all source code, database, install/setup files, project documentation)
Week 1 - 2 Project Group Name and Logo. Project Group Members (2-4 per group)
Week 27 Iteration 3 documentation Hand-in (Intro, Hardware and Software Requirements, Install procedure, lessons learned, marketing material, etc.)
Week 3 1-3 Potential project ideas (1 paragraph per idea) Week 4 Project Overview (Project Title, Group Name, Group Members and contact details, Stakeholders and contact details, Brief Description of Game, Basic Storyboard)
Week 27 Return complete set of documentation (Iteration 0,1,2,3) Week 28 Final Judging (Complete system, fully tested and implemented, no errors)
Week 5 Project Proposal (Identify the Game Genre, Theme and Perspective; Describe Player Interaction; Determine the Game Development Platform)
Week 29 Innovation day and awards.
7.
ASSERTIONS
The previous sections outlined the various issues encountered during the supervision of game development projects at the School of ICT over the past seven years, and also discussed how these issues were handled. Based on the lessons learned whilst dealing with these issues the authors wish to make the following recommendations to other departments/schools wishing to actively support game development third year projects:
Week 6 Detailed Requirements Specification (Describe Game Mechanics; Extended Storyboards; include Data Structures and some Class Diagrams; specify Textures/File Formats and why you chose them) Week 7 - 9 Iteration 0 - PowerPoint Presentations (include introduction, Game Genre, Theme, Perspective, Mechanics and show Detailed Storyboards)
• Firstly, the difference in deliverables between game projects and business oriented projects should be ”spelled out” very clearly to the students from the start of the project.
Week 10 Iteration 0 documentation Hand-In (Project Overview, Project Proposal, Detailed Specification, PowerPoint Slides, Minutes of Meetings, Timesheets).
• Secondly, a clear distinction between the work of the game developers and the supporting artist(s) needs to be made. Students should be encouraged to get ”real” artists to do the artwork and should themselves focus on the IT aspects of the project.
Week 11 Iteration 1 Contract (signed), Class Diagrams, Game State Management, Leveling Week 12 State Transition Diagrams, Sequence and Activity Diagrams (showing Mechanics), Test cases (if applicable)
• Thirdly, students must use placeholder graphics and must have a clear graphics strategy from the very start. The success of the project should never depend completely on the delivery/non-delivery of content by an external stakeholder (artist).
Week 13 Placeholder graphics Week 14 Detailed Story Board Designs
• Fourthly, additional support in the form of a special interest group and/or dedicated student assistant is essential to the success of such projects. The school/department should commit to and support such projects by providing funding if necessary.
Week 15 Discuss Project Judging and Iteration 1 handin Week 16 Iteration 1 final documentation Hand-In (Contract, Introduction, Game State Management, Levelling, Class Diagrams, Sequence Diagrams, Activity diagrams, State Transition Diagrams, Test Cases, Placeholder Graphics, Story Board Designs, Minutes of Meetings, Timesheets).
• Finally, continued success in the delivery of game development projects depends on committed support from an academic staff member. Once established, special interest groups and/or student assistantships can make a big difference in the ongoing success of such projects. However, to establish it the first time will require ”buy-in” from a staff member. There is also a risk that one may be unable to find a suitable game development student assistant for a specific year. Without a motivated and committed academic ”sponsor” long term success in game development projects will be very difficult.
Week 16 Iteration 1 Presentation - Skeleton game with placeholder graphics and examples of major mechanical elements. Week 16 Iteration 2 contract (signed) Week 17-23 Ongoing meetings with project stakeholders 7
8.
CONCLUSION
The School of ICT at the Nelson Mandela Metropolitan University has had tremendous success in the delivery of game development projects as capstone third year software development projects. This success has not been accidental, but the result of careful planning, experimentation, and commitment from both individual staff members and the School’s management. It is the authors’ opinion that most software development departments at universities in South Africa can duplicate this success. It is hoped that the lessons learned described in this paper will assist other departments in the establishment of a ”game development culture” to meet the changing needs of the software development industry.
9.
REFERENCES
[1] S. W. Ambler. The Object Primer: Agile Model-Driven Development with UML 2.0. Cambridge University Press, 3 edition, 2004. [2] J. W. Creswell. Qualitative Inquiry and Research Design: Choosing among Five Approaches. SAGE Publications, 2nd edition, 2007. [3] F. Dille and J. Z. Platten. The ultimate guide to video game writing and design. Skip Press, 2007. [4] B. Lunt, J. Ekstrom, S. Gorka, G. Hislop, R. Kamali, E. Lawson, R. LeBlanc, J. Miller, and H. Reichgelt. Information Technology 2008: Curriculum Guidelines for Undergraduate Degree Programs in Information Technology. Retrieved July, 7:2009, 2008. [5] A. Reed. Learning XNA 4.0. O’Reilly, 2011.
8
