GDC-2.0-AAA Level Design in a Day (2/2)

Art + Design + Programming = Level

Modular Level Design for Skyrim 

by Joel Burgess and Nathan Purkeypile (Bethesda Game Studio)

Bethesda games are BIG.

Scope is an integral part of the experience (delays don’t lose weeks, but months).

“…always move forward to explore our new ideas.”

Bethesda has efficiency focused studio culture.

KITS – A contextual system snapped to grids that is more than a sum of its parts.

Pros (+) and Cons (-) of Modular Level Design

                + Reusable art mitigates scope.

                                Beliefs + Circumstances + Experience = Culture

- Art fatigue happens (breaking immersion from recognizing assets in-game).

Abolish copy-paste design!

Disassociate enemy types and gameplay with setting.

Encourage asset mix-n-match when laying-out a level.

Artists need to ‘let go’ of protecting assets from being warped and edited.

+ Low artist / designer ratio.

- High complexity exists (artists need to know a lot of left- and right-brain techniques to be useful).

                Modular design requires an art and technology understanding.

                Bug fixing can be delicate.

+ Instant, game-wide art deployment.

                Zero impact on the design workflow.

                Artwork is viewable in a ‘real’ context.

                There’s cosmetic control with art (the aesthetic process is not rushed).

+ Iteration speed is quick.

                High flexibility and agility when making levels.

                1:1 correlation with final layout (fastest workflow ever?).

- The process has a dependence on art.

                An art and design relationship is imperative.

                The process must use abstract units for scale.

                Set standards for doorframe sizes.

                Set a minimum standard for width of a space.

                Figure out inclined angles that are traversable and what is too steep.

KIT Building

Concept Phase (a week or so timeline)

                Art: What is the visual theme?  What is the visual goal?

                How widely is this KIT used?

                What sub-KITs are needed? (The Cave KIT has large hall, round hall, etc.)

Proof Phase (2-3 weeks)

                512x512x512 dimension sizes were used (these can change per project, however).

                All sub-KITs are multiples of the standard sizes.

                Keep grid snaps large!

                Don’t tile on all 6 axis.

                Don’t build outside of a ‘footprint’ space when designing.

Greybox Core Phase (1-4 weeks)

                Greybox the most used sub-KIT as a priority.

                Focus on function, not aesthetics.

                Naming conventions should be used and must be consistent (while avoiding abbreviation); decide on conventions early because they are difficult to change later.

                Use ‘01’ as a suffix for all assets.

                [KIT name]-[sub-KIT]-[object name]-[suffix] // An example of naming an asset.

                Pivot placement is decided on usage and design (there are exceptions).

                Test all greyboxing.*

Build-Out Phase (4-8 weeks)

                Create one ‘visually final’ piece before building the whole KIT.

                Avoid Hero pieces (a single-use statue worked-on for 2 months).

                Helper markers (placed on the roof of a piece) give a run-down of the info of a piece.

Polish Phase!

                Avoid the temptation to add every suggested piece.

Art / Design Compromises

Art: It looks better, but takes longer.

Design: It helps in gameplay and world-building, but it’s harder to work with.

Read: Modular Level and Component Design by Lee Perry.

* Don’t test in comfortable settings / ideal conditions.

                Common problem: Loopback issues.

                                Avoid ‘Patch’ pieces (no band aids!).

                                Find footprint issues.

                Common problem: Unable to stack (co-planar issues).

                                Define common ‘gaps’.

                Common problem : The ‘Hall Room’.

                                Somebody will try unsupported issues (does the system support it or no?).

// NEXT - The Future of Storytelling: How Medium Shapes Story by Jesse Schell

4.12.13 - A Fury Void Update

Fury Void is in the last stretch.  Team Fury has collected the last set of feature suggestions, has butchered the asset and issue archives, and is plowing through the last few weeks of Fury Void’s development.

Firstly, all items that are being fixed or added to Fury Void is logged on the Trello board, a free program that allows teams to collaborate on lists of cards - Trello is superb for Scrum or Kanban boards.  There are a plethora of items spread among a series of lists: Public Notices; Feature (tweaks) Left; Bugs for this Week; This Week’s Finished Bugs; Bugs for Next Week; Bugs for the Third Week; New Bug Reports; and, Not Going to Make It.

From every board sacrifices have been made and fed to the Not Going to Make It list.  Team Fury had to objectively handle the very few remaining weeks in development.  All items that were pre-prioritized as ‘low’ were taken to the NGtMI list along with a vast number of feature-tweak suggestions and ‘medium’ priority bug fixes.  Despite removing dozens of items from what is  going to be worked on, there is still plenty of work to do; if this was a truly professional operation, this time would be ‘crunch’ time.

Some important issues were corrected in the past few weeks.  To start, music is played in all situations.  The problem was that any tune for saving the galaxy was not playing, either being completely absent in-game, or at a very reduced volume on all screens but the Main Menu.  Creating an object that was not destroyed on a Unity scene’s load and placing it in the same place within each scene corrected this issue.

Similar to the previous item was the issue of not having consistent sounds being played to give the player auditory feedback.  It required a slog of testing each interactive object and adding the applicable sound effect script, but all things that the player may work with playback sound cues.

Another issue was that the game was not considering a new player launching the game without save data.  On the New Game screen, if a player decided to select a save slot to start a new game, a warning would appear saying that save data may be overridden; this proved to be very confusing and unintuitive for new players during testing.  Fixing this item lies in creating a check to see if the selected save slot has any points; if it does, warnings about overwriting save data will appear, and otherwise takes the player to the ship customization menu.

During a group testing session, it was deduced that one of the weapons was too loud in firing.  Simply fixed, audio levels were brought down.  However, at this point, the levels may be too low, though this consideration needs further testing.

Next, a number of minor features and tweaks were done on the game.  Fury Void enemies now appear on the minimap, following the path of enemies spawned and being destroyed in-kind.  Enemy weapons now appear clearer on screen when fired, and will not take the player’s health into a negative range.

How much damage enemies, collisions, and explosions do to the player has also been augmented.  Difficulty options are no-longer placed under Options, but are located on the ship customization screen and saved to player profiles.

Control options have also been moved to the customization screen.  Speaking of which, an issue was occurring when paused in-game; the player could still animate the ship aiming when using the XBox controls.  Minor code changes were required, and the issue is now resolved.  Further control tweaks involve the access of any axis on the XBox control, as per playtester request.

All options selected when on a menu are highlighted if selected; they are darkened if not or not available.  The only location that this feature is not present in is the menu presented during a pause, but it is planned to be fixed shortly.

A major feature - not a tweak - was the addition of an ‘Optimal Salvation Bar’.  This item appears on screen, decreasing whenever a planet, sun, moon, or enemy is destroyed.  Based on this, a score modifier is applied, with decreasing results occurring when ‘Optimal’ levels have been reached.  The Bar is something that was brought-up during a recent test session; it gives a partial context to the game, while also providing an indicator of when the player should exit the play-space.

To exit the play-space, a minimap object has been added to indicate where the player may go to warp to another system.  Between systems, the player is shown their score from the previous system.  Further, the player can edit their controls, difficulty, weapons, and ship.

There are a number of other minor feature tweaks and bug features, but a point to be addressed would be the issue of team drive.  Team Fury is hitting the ‘point’ witnessed in other game project teams in the past, that being the time when even sports players want to just glide into the finish.  The trick is to sprint through the goalline, so motivation and drive are a major contention for the Scrum Master/Product Owner, and the Project Manager.  The biggest test Fury Void will be facing in the next few weeks would be keeping the pace that the 4-man team has had so far.

Team Fury has been doing stupendously.  Even if the game was to stop development now, it would be a presentable product.  If work is done, and the schedule kept even 80% accurately, Fury Void is well on its way to wrapping-up an explosive player experience.

GDC-2.0-AAA Level Design in a Day (1/2)

Level Design is applied Game Design.

Once upon a Time: Giving Players the Freedom to Create Their Own Story
by Jim Brown ( Lead Level Designer - Epic Games )

Save the Cat is a book that is good for story writing, but not a silver-bullet.

3 act / 5 act / x act story structures do no apply across all mediums.

A medium’s limitations define story structure.

Story can be defined as what happens in a game.

                Plot is how it happens!

A game’s plot of moment-to-moment action cannot be written.

Cut-scenes give characters a story; gameplay gives the story of the player.

3^rd person cameras force players to pay attention to avatar / character story.

1^st person lets players be themselves, but it is hard to relate to the game character.

Forcing story and gameplay together can break engagement in the game.

Narrative as a reward for exploration gets players invested and empowered.

Designers shouldn’t write ‘stories’ but places for stories to happen.

Mood and intent should come together for a story to arise.

Demon’s Souls is an example to leave the player alone so they can ‘get it’!

The Walking Dead’s story is always the same in the end.

                Plot (how a story happens) is the experience for the player.

                This game shows what other players did; it makes the player feel unique!

Better writing isn’t the whole answer.

                Designing the experience is how to tell a better story is a partial answer?

Valve did cinematics that didn’t restrict the player’s perspective of the game.