W_CG_PracticalGameDesign

8/6/2019 W_CG_PracticalGameDesign

1/6

84 May/June 2011 Publ ished by the IEEE Computer Society 0272-1716/11/$26.00 2011 IEEE

EducationEditors: Gitta Domik

and Scott Owen

Practical Game Design andDevelopment PedagogyPaul J. Diefenbach

Drexel University

U

nlike many game development programs,

Drexel Universitys program doesnt reside

in one department and so mirrors the true

nature o commercial game development.1 Drex-els Digital Media program oers a game art and

production major that instructs students on the

undamental skills o design, art, programming,

3D modeling, animation, audio, and video pro-

duction and on how to use industry tools such as

Maya. The Computer Science department oers a

game programming and development concentra-

tion ocusing on sotware development skills and

oers sotware courses or prototyping game con-

cepts. The gaming courses (www.games.drexel.edu/

classes.html) and RePlay Lab (www.replay.drexel.

edu) bring these two majors together, with addi-tional participation o students and aculty rom

other majors including music industry, screenwrit-

ing and playwriting, engineering, and business.

The prerequisite courses provide the technical

oundation or Game Development Workshops

I and II. Workshop I serves as a design and pre-

production phase in which teams o our to six

students create a game concept and write a one-

page sell document, an executive summary, a

game design document, and a game prototype in

11 weeks. Instructors select the best, most viable

games or ull production in Workshop II the ol-lowing term, and teams are merged and expanded.

The sequence mirrors the industry in structure and

development, using project- and asset-management

sotware, agile development with weekly Scrum

sprints, meeting minutes and communication logs,

and a milestone payment mechanism in virtual

dollars that translates into student grades, empha-

sizing sot skills.2

In presenting the workshops, weve made several

recurring observations about students tendencies

that have inuenced the workshops structure and

ocus. Here, we detail our observations and how

weve modifed the workshops in the areas o game

design and development.

Game DesignWe noticed that students oten have creative ideas

but miss actors that might at frst seem intuitive.

So, Workshop I now addresses vague game con-

cepts and pitches. It reintroduces strategy, game-

play, and story to ocus on designing games rom

the players perspective so that students can assess

how this aects code and assets.

Fun and StrategyStudents sell presentations oten discuss story,

characters, controls, and so on but dont mention

the word un. When asked how their game is un,they typically respond with a list o game eatures,

an intricate story, or exciting visuals. Yet eatures

and story alone dont make or a compelling game,

and students oten dont examine how their ideas

translate to the players perspective. Students must

learn to recognize that games must support players

with dierent playing styles, strategies, and rea-

sons or playing.

A recent castle-deense game illustrates provid-

ing strategic support (see Figure 1). In this game,

the player must set up catapults and other de-

enses during a layout stage, and then fght attack-ing enemies while the deenses automatically fre.

Although this concept appealed to fghter-style

players, the automatic weapon fring permitted

the player to assume only a fghter role during the

action gameplay.

Two simple changes expanded the player profle

to support more strategic fghters as opposed to

button mashers. The frst let players add de-

enses during attacks, but at a cost to their health

because theyre deenseless while making changes.

The second change let players make deenses that

must be triggered by the players proximity, which


2/6

IEEE Computer Graphics and Applications 85

orces players to chose between fghting or trigger-

ing deenses.

GameplayStudents oten design games rom an abstract

perspective, as i the characters in the game are

sel-governed and the designer is an all-knowing

god. For example, they might propose a game

about two aliens battling over a magic crystal.

The students will have decided the games lookand physical characteristics, the aliens abili-

ties, the conicts backstory, and bizarre power-

ups, yet disagree when we ask them whether the

game is played rom a frst- or third-person per-

spective or whether its played with a keyboard

or controller.

We teach teams to discuss gameplay rom the

players perspective. What does the player see?

What does the player do? How is inormation

conveyed?

A recent game pitch or ZapJak (see Figure 2)

illustrates a typical game description:

Players race uturistic cars around an Internet-

inspired electronic world similar to Tron and

can destroy or hijack AI bot vehicles.

This doesnt address what the player sees and does.

A refned concept that addressed the players per-

spective added this:

The player, using an analog controller stick

or speed and direction, controls rom abehind-the-vehicle view a uturist ic hover-

car propelled in a three-tiered city envi-

ronment o approximately 100 square city

blocks. Similar to Tron, the games city roads

represent the Internet, and each building

represents a website, with larger websites

such as Google having larger buildings in

the highest, exclusive gated tier. Players use

the second analog stick to aim a reticle at

enemy bot vehicles to hijack a vehicle and

transer driving control to the new vehicle.

With three vehicle types and varied roads

(a) (b)

Figure 1. EpicDeense. (a) The hack-and-slash strategy. (b) The triggered-deense strategy. Workshop students

modifed gameplay to support dierent player styles by permitting hack-and-slash play or strategic armament

placement and management.

(a) (b)

Figure 2. ZapJak. (a) An early concept sketch. (b) The players view o the game. The original pitch or this game ailed to considerthe players perspective. The students revised their pitch to remedy this problem.


3/6

86 May/June 2011

Education

having dierent characteristics, hijacking

vehicles is integral to player strategy in

both timed races and last-player-standing

modes.

Conveying the Story and BackstoryStudents oten also ail to consider the players

inherent knowledge, or lack thereo, o the game.

As I previously mentioned, students usually cre-

ate an intricately detailed story yet ail to consider

how to convey the story to the player. Students

must be asked, Does the player see this story as

images, video, or machinama? [Machinama em-

ploys the game engine to create an animation.]

Or must they read text? Or must the game have

a voice-over or character dialogue? Additionally,

conveying the story can be resource-intensive or

both digital-media artists and computer sciencesotware developers, so students must learn to ex-

amine the alternatives that work or their game

(see Figure 3).

Moach Rotel, a game about a cockroach whose

amily was killed by the houses owner, was story-

intensive, with a 60-plus-page script, in-game dia-

logue, and machinima segments. Because the

characters were cockroaches, the game used click-

ing sounds or cockroach-speak (obviating the

need or voice talent). It presented the dialogue

as scrolling text, which was conveyed by a cus-

tom dialogue-parsing logic the sotware develop-ers wrote to translate the scriptwriters annotated

dialogue into in-game events, text, and sounds.

Engine Divine and CityScape used an alter-

native strategy: conveying the story by cutscenes

(video or animation clips between parts o a

game). Both used animatics (an animated story-

board), but each generated the images dierently

because o their team skill sets and resource al-

locations. Engine Divine had a strong lead art-

ist and decided that hand-drawn artwork would

best convey the complex backstory. The CityScape

team had no strong artist and wanted to convey

a comic-book eel or its superhero game. So, the

team used Photoshop flters to translate staged

photos into a comics-style sequence.

Game DevelopmentOnce the students have vetted their game concepton the basis o the concerns we just detailed, they

ollow an iterative Scrum development cycle that

permits continual refnement. This has introduced

problems due to students having little experience

in incremental development, milestone planning,

and resource management. We now structure

the milestones to guide inexperienced students

in long-term project planning. Development now

involves three distinct phases: establishing the as-

set pipeline, refning and balancing gameplay, and

dressing up the game.

Prove the Asset Pipeline EarlyIterative development has become increasingly

popular or games, and Drexel has been teaching

Scrum methodology since frst oering its game

development program. In previous years, teams

ran into difculties because o development issues

such as choosing a game engine on the basis o

its capabilities instead o the teams comort with

it. Another issue has been the tendency to ocus

on fnal models and animations beore establish-

ing frm asset pipeline practices or understanding

engine requirements, such as scale, polygon andperormance limitations, rigging requirements,

and bounding geometries.

To minimize potential late-term problems,

teams now must make incremental advancements

addressing these issues, starting early in the term.

Students must produce an in-engine, core game-

play demo by week three and in-game models and

animations by weeks fve and six, respectively. We

dont permit any mods (modifcations o a game

that require the original release) using game tem-

plate assets because this can hide asset pipeline

issues, such as

(a) (b) (c)

Figure 3. Three approaches to conveying a story. (a) Moach Rotel combined inline dialogue and machinima segments. (b) Engine

Divine used cutscenes with hand-drawn artwork. (c) CityScape also used cutscenes but used Photoshop flters to translate staged

photos into a comic-book-style sequence. (Machinama employs the game engine to create an animation; cutscenes are video or

animation clips between parts o a game.)


4/6

IEEE Computer Graphics and Applications 87

how the bounding geometrys defnition can in-

uence collision detection or

whether animations are exported as bones (which

connect joints and control how vertex mesh

skins deorm) or baked into vertex animations.

Workshop II employs a similar approach. Stu-

dents must demonstrate early proo o competency

in creating more complex layered and blended ani-

mations and using the motion-capture studio.

Gameplay BalanceProving the asset pipeline early doesnt guarantee

a successul game; students oten dont realize that

signifcant gameplay testing is required. They must

test and tweak gameplay actors such as character

speed, gravity, the number o shots, and health

parameters. However, this tweaking could present

a potential bottleneck or the computer sciencestudents who adjust these parameters. Because

o gameplay balancings importance, by week fve

the students must expose all relevant gameplay

parameters in the orm o an option screen (see

Figure 4) that players can modiy.

Also, a spreadsheet keeping track o the param-

eter settings and corresponding gameplay ratings

lets developers track optimal settings. This permits

every team member to be a tester and acilitates

beta testing. An additional beneft is that this player

experimentation sometimes results in unexpected

play modes, such as when testing ound that lower-ing gravity in CityScape resulted in a un explor-

atory mode, jumping rom rootop to rootop.

The 80/20 RuleWe also direct teams to ocus on eorts that pro-

vide the most bang or the buck, as exemplifed

by the 80/20 rule, also called the Pareto principle

or the vital ew and trivial many. This rule states

that approximately 20 percent o the vital tasks

produce 80 percent o the results. In the work-

shops, we apply this principle at week eight, when

the fnal 20 percent o the development eort can

make or break the game and outweigh the other

80 percent to bring the game to beta unctionality.Besides the obvious addition o visual eects such

as shaders and particle systems, students learn to

ocus on adding game modes and reusing assets.

Visual eects can provide signifcant enhance-

ments with relatively little eort; likewise, game

modes can enhance gameplay with minimal code

changes. For example, in the castle deense game,

testing revealed that players enjoyed acing attacks

by unlimited numbers o trolls until the players

character is killed, in contrast to the normal game

mode, in which each level had a set number o

attackers. Additional variations include adding atimer to regulate gameplay time or adding deenses

that are triggered automatically or by the player.

Simple repurposing o assets can also enhance

games. Animated characters can be integrated

with menu screens (see Figure 5) or visually aug-

ment intralevel story elements. A spherical camera

path around a victorious character can enhance a

Figure 4. The Proteus games parameter screen lets play testers tweak

gameplay.

(a) (b)

Figure 5. The Project Bolt menu. (a) The main character, Bolt, repurposed on the main menu screen. (b) Bolt

outftted with props or the instruction menu screen.


5/6

88 May/June 2011

Education

win condition. Such asset reuse requires minimal

eort but can make the game look much more

proessional.

Balancing Structure and FreedomWithout an imposed structure, students design

and development eorts can be misguided owing

to their lack o real-world experience. A course

cant teach strategy, sot skills, and agile develop-

ment without imposing the structure to support

that teaching. With this additional structure, the

quality and complexity o our students games

have increased.

One drawback o this approach is that some stu-

dents complain about a lack o individual reedom.

Although this problem is common in large corpo-

rate projects, academic settings require a balance.

Requiring ormalism can sometimes stie creativity

and enthusiasm, but when we simply recommenda structure, teams tend to ignore it. For example,

one team produced a proo-o-concept mod in week

three instead o a true new game build; this resulted

in late-term integration problems.

Similarly, the agile development methodology

and sot-skills training alone cant ully simulate

industry conditions because team leaders dont

have the true authority that might exist in a cor-

porate environment. This sometimes leads to con-

icts, but employment contracts or both team

leaders and members can help clariy their roles,

tasks, and expectations.

Overall, the workshops have successully pre-pared our students or industry, as evidencedby Drexels number-three national ranking in game

design (www.games.drexel.edu) and a pairing with

EA Games in a CBS Evening News segment on pre-

paring students or the industry. Over the past

ew years, weve made numerous changes to the

workshops structure and the curriculum as a whole.

However, the workshops still need continual refne-

ment to balance industry requirements with the ex-

ploratory nature o the academic setting.

References1. M. Sakey, Fundamental Learning GDC 2006 Cur-

riculum Workshop, Intl Game Developers Assoc., Apr.

2006; www.igda.org/articles/msakey_gdc-curriculum.

2. P. Dieenbach, Teaching Sot-Skills: Digital Game

Development in a Multi-discipline Environment,

Eurographics 2008 Annex to the Conf. Proc., Euro-

graphics Assoc., 2008, pp. 135139.

Paul J. Diefenbach is an associate professor in Drexel Uni-

versitys Digital Media program. Contact him at pjdief@

drexel.edu.

Contact department editors Gitta Domik at domik@

uni-paderborn.de and Scott Owen at [email protected].

Selected CS articles and columns are also available

for free at http://ComputingNow.computer.org.

IEEE Pervasive Computingexplores the many facets of pervasive and ubiquitouscomputing with research articles, case studies, product reviews, conference reports,

departments covering wearable and mobile technologies, and much more.

Keep abreast of rapid technology change by subscribing today!

www.computer.org/pervasive/SUBSCRIBE


6/6

For access to more content from the IEEE Computer Society,see computingnow.computer.org.

This article was featured in

Top articles, podcasts, and more.

computingnow.computer.org

W_CG_PracticalGameDesign

Documents

Transcript of W_CG_PracticalGameDesign