Jimmy Chattin - I make better games.

Sunday, April 28, 2013

4.28.13 - A Fury Void Update

This is the last update before a postmortem next week.  The weeks leading to this point have gone by too quickly, but Team Fury is still forward-marching.  As the team Producer and Product Manager, I couldn’t be prouder of this team.


The schedule over the last 2 weeks has been a hectic one; bugs, small feature tweaks, and general polish of the Fury Void game have taken priority.  There is a plethora of items still to complete in the next week, but even more are loaded into the team’s list of items that will not be tackled in time for game completion.  The following is a brief on the features added and the bugs fixed in the recent weeks.

An issue already resolved was the inclusion of additional nebula skyboxes for the game.  This was done by the outside initiative of a Team Fury member; no story was written for this item, but it is well received.


Another visual change was the remodelling of some of the 3D ship assets.  High polygon counts (leading to long load times) and model clipping were corrected to give .

2 more colors have been made available to players for their weapons: magenta and neon-green.  Missiles now reflect the colors that are selected, while the laser beam is bigger and meaner.

Black holes are now stark-black.  The original issue was caused by allowing various texture effects to influence the black hole object; removing these, black holes are truly dark and terrifying.  Further, black holes will start pulling-in objects within 3 seconds of spawning instead of 5, leading to more frantic play after they are spawned.  However, due to an issue of black holes pulling every in-game object in before the player ship either left the level or was destroyed, the size of any system level has been reduced to accommodate for this (doing even more to concentrate play).


A previous issue with black holes was that they killed each other if 2 came into contact.  After multiple attempts to add black holes to a list of objects that the black hole will ignore destroying, it was finally accomplished; to ward off future issues with multiple black holes, however, code was added to check if a black hole already exists, so that only 1 black hole will be spawned in any given level.

To indicate to the player how many points they will gain at the end of a level and to encourage them to move on to a new level, the ‘Population Density Bar’ has been added.  This small object at the top of the screen shows how much the player has destroyed and how close they are to getting the highest score multiplier.

A completely new section to the menu system has been added.  Under the ‘Options’ page, there is a section for explaining what Fury Void is about, what the player is trying to do, and what is in the game.  The first page covers the brief context of the game (copied directly from the intro text-scroll seen at starting the game).  The next page describes the goals of Fury Void (destroy the galaxy to save it) and how that is indicated through gameplay via the ‘Population Density Bar’.  Later, planets, enemies, and powerups are described.

Numerous options have been repositioned in the menu system.  The player may no longer select their control scheme from the ‘Options’ menu and the settings for difficulty have been moved to the ship-selection screen.
As the player’s health is small and tucked into a corner, the screen will flash red when the player’s health goes below a certain limit.  This is an indicator that the player should be leaving the system to retain their score.  Further, a blue onscreen warning is given when black holes spawn.  It will display periodically as long as the player remains in a level with a black hole.

There was a vast amount of text pixelation throughout Fury Void’s menus and playspace.  This has been corrected fairly easily, though extra work was needed on some screens as the viewing camera is not in a standard location on all pages.  Additional work on having uniform fonts and font-sizes in the game is being done; the issue is likely to be included with Fury Void by the time of this update’s publish.

When loading levels, any object or text displayed through Unity’s OnGUI service would remain over the loading screen’s background.  To amend this, a simple check on every OnGUI item to see if the level is loading was added.

At times, when attempting to view Fury Void’s credits, they would not display.  On a gut feeling, Team Fury’s lead programmer double-checked the time scale of the credits screen.  He found that, after entering play, exiting, and then attempting to view the credits, time was stopped; it had not been restarted from the act of exiting the in-game play.  Fixing this, credits now scroll no-matter what the player does beforehand.

In the following days - the final days of student development on Fury Void - there are a number of features and issues that are aimed to be addressed: Individual ships will have unique names; Transitioning between system levels will be faster; Enemies will fire different weapons; More enemies will be spawned; and, if time allows, each save profile will have their own name to keep track of their save.

Please pay attention to Fury Void’s Facebook page for further updates on Team Fury’s progress to help players save the galaxy by fire.  More work will be done, many planets will be destroyed, and many explosions will be had!

The latest build of Fury Void can be found here; the next build is Fury Void's official v 1.0 release!

Monday, April 22, 2013

GDC-3.1-Kanban - How to Make Your Production Scream

by Clinton Keith ( President of CK Consulting )

Kanban is :
  • a tool for managing the flow of assets or information in a process.
  • translated from Scrum, where it is visualizing the flow of valuable stuff being built.
  • something that does not rely on a plan of 'should', since Reality > Planning.



3 Basic Rules
  • Visualize workflow so there are clear goals for delivery.
  • Limit work-in-progress to reduce multitasking/batching assets.
  • Measure and improve flow, seeking ways to introduce measurable improvements.

Scrum vs. Kanban
  • Scrum is based on a To Do-Ongoing-Done approach, making it better for slower or more definitive projects.
  • Kanban works with a To Do-Ongoing1(#)-Buffer(#)-Ongoing2(#)-Done setup, where # is how many tasks are in that process at max capacity, making it better for faster hand-off projects.

Setting-Up Kanban
  • Visualize the process, map it, add metrics, inspect it, and adapt everything for your situation.
    • The process is the 'as-is' of the situation.
    • Consider sticking a Process column to a Kanban board.
    • There is only 1 asset from beginning to end.
  • Set WIP limits as identified by numbers (#) next to each column title.
    • Pay attention to limits - if they are overshot or never reached, they may show that there needs to be more/less of something.
  • Create an Emergency Lane, where if any item is in the lane and in a specific column, all other things in the column are put on hold until the item leaves.

Edits/Mods to Kanban
  • Split columns and assets between specialized teams.
  • Add a marking for assets requiring special attention.

Sprint Planning from Scrum is not a feature of Kanban; it is replaced by 2 week cadences that reflect on what has happened when they end.  Planning lies mainly in Burn-Down charts, where the y-axis is how many tasks are being taken-on during a cadence, the x-axis being major time landmarks during the 2 weeks.



Summary:
  • Kanban can be started quickly, it improves workflow with its features, and it regularly leads to a +50% improvement.

// Up next from GDC: The Walking Dead: Crafting a Stylized World for the Mature Franchise.

Friday, April 19, 2013

GDC-3.0-The Design of New Enemies for Halo 4

by Scott Warner ( Lead Game Designer - 343 Industries )

There was a 'fatigue' from fighting the Covenant in every Halo game so far.
Where was the '30 seconds of Fun'?

  • Find this from everything from Halo to Halo Reach.
  • Apply it to the Prometheans in Halo 4!


Foundations:

  • Every alien race is unique in Gameplay, Visual Silhouette, and Personality.
  • Enemies support experimentation (Halo is an open sandbox game).
  • There's a Leader/Minion hierarchy.
    • Some are easy to dispatch, others are real conflicts when encountered.
    • There are 'minibosses' with a squad/squad leader.
  • The Halo Encounter must exist for Prometheans.
    • Classically, it's Plan, Take by Surprise, Beat Back, Break Them, Mop-up, and Repeat.
    • Enemy characters (Leaders) raise or lower Minion moral and action.
  • The Halo approach to difficulty is Smarter-Faster-Stronger.
  • Higher difficulty only speeds-up gameplay; it doesn't change it fundamentally.
  • PROMETHEANS MUST USE EXISTING CONTENT CREATION TOOLS!

The Gold Triangle: Shoot - Hit - Throw

Promethean Inspirations:
  • Voltron
    • Forerunners are involved beyond anything else in the galaxy.
    • Adaption of form to fit events and environments.
  • T1000
    • They can take any form, but stay relatively humanoid.
  • The Thing
  • Cranium Rats
    • Units are smarter the more there are.

Early Enemy Goals:
  • There should be a combination of 'familiar' and 'alien'.
  • They cooperate with each other to defeat threats.
  • They adapt their form and the environment.

The Knight is something easily understood and relate-able.
The Crawler (Pawn) started as a biped.
The Watcher (Bishop) was wanted to be something like a Necromancer from Diablo; a game changer.
Other enemies were Rooks, Queens, and Kings, all of which are likely to be included in future releases.

Watcher Prototyping:
  • Had the abilities of a shield, resurrection, deflection, spawning, focus fire, physics impulse, a 'junk attack', etc.
  • From focus fire on, players just didn't get what the abilities did.
Knight Prototyping:
  • They used squad tactics in a combination of alien and human strategy.
  • Use cover like a human, but use a bound move like a Metroid ball.
  • Enter and exit battle through the environment.
  • Dismemberment is shown when damaged, answering 'am I damaging this thing or not?'
  • Have a deadly melee attack!


Problem: Pipeline.
  • Pipeling rewriting for Maya was a pain.
Solutions:
  • Bring in more engineering staff.
  • Reduce the scope, cutting the Rook, Queen, and King enemy types.

Problem: Who are they, the Prometheans?
  • They were not fleshed-out with gameplay features seeming to be random.
Solution:
  • Center everything around the Knight.
  • Finally say 'this is it' and drop some features.

Problem: Pawn
  • The team didn't like the biped design because it felt like the Covenant.
Solution:
  • Walk on walls as a quadruped!


Post Mortem Wrongs:
  • Early team communication
  • Long absence of high-level vision
  • Watcher encourages one-dimensional solutions
  • Prometheans are devoid of emotion
  • Forerunners are like bullet-sponges
Post Mortem Rights:
  • Early gameplay contraints and a foundation
  • Enemies players enjoy
  • Creating different enemies from either the Covenant or Flood
  • Team orientation

// Next: Kanban-How To Make Your Production Scream.


Wednesday, April 17, 2013

GDC-2.1-The Future of Storytelling: How Medium Shapes Story



 by Jesse Schell ( CEO - Schell Games )

Weaknesses of current games:
                Verbs
                                Right-now verbs of running, shooting, yelling, etc.
                                ‘Below the neck’
                No use of tragedy
                There is a lot of lost unification
                                All great stories tell the ending by foretelling it at the beginning.

 

Elemental Tetrad of aesthetic, mechanics, story, and technology.
                Either mechanics or technology changes will likely lead to better stories.
Prophecy of Chris Swain:
                Film was taken seriously when film learned to talk.
                Games are waiting to learn to ‘listen’.
                                This will allow for a conversation between the game and the player.
Games must: sense emotion, understand spoken word, and remember what a specific player has done.
Who will we talk to?  Our avatars (virtual companion!) is the answer.
Don’t think ‘platform’, think ‘venue’.
                The Hearth – OK for story games.
                Anywhere – Great for mobile games, but terrible for story games.
                Reading Nook – A good venue for story games played on things such as tablets.
                Workbench – The home of PC gaming and a good home for story games (future tech would include the Oculus).

 













We need: Above the neck verbs, irreversible tragedy, and everything coming together in connection and reference.
What happens to avatars when the player dies?
                Inheritance: Virtual companions can be sought to teach about the player that was alive.

// Visit jesseschell.com to find the slides!

// Next: The Design of New Enemies for Halo 4.

Sunday, April 14, 2013

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.

http://level-design.org/wp-content/uploads/2012/02/creationkit_1322839910.jpg

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.

http://worldofleveldesign.com/categories/level_design_tutorials/images/010-reverse-engineering-level-design-00.jpg

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

Friday, April 12, 2013

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.