Showing posts with label Design. Show all posts
Showing posts with label Design. Show all posts

Philosophy on Design Progression and Balance - Railgun



Image from Railgun Twitter page.
(This post was first drafted and published here.  Updated and reposted with permission.)

I'm working as the associate Game Designer on Railgun, an action shooter for Windows PC, built using Lua scripting and Blueprint-like Flow in Autodesk Stingray.  Levels and some of the gameplay systems are my forte.

Here's how I go about designing things:

Bottom-Up Balance

Image from Battle.Net.
Companies such as Blizzard typically start their design balancing from the bottom-up.  Starcraft was made by first balancing the starting worker and warrior characters: Terran Marines, Zerg Zerglings, and Protoss Zealots are fine-tuned with each other before other units hit development.

I apply similar principles to the evaluation of Railgun's systems in these ways:

  1. If the base weapon and unit are not fun, we have a problem.
  2. If a new weapon or ability isn't fun with the base unit, we have a problem.
  3. If a new unit isn't fun with the base weapon, we have a problem.
These tenets make it easy to develop scenarios for different aspects of the game.  Though there can be exceptions (after close analysis), generally removing ambiguity simplifies the testing process and the communication that needs to happen with other members of the team (i.e. explaining design philosophy).

100 of a unit, the weapon choice for the player, and leaving everything else the same further allows for standard algorithms to be generated in predicting the outcomes of play (more on this below).  Repeated tests can refine prediction variables, but they get designers working with something decently accurate to the final outcome quickly.

Copy-Pasta Templates

Railgun_Autodesk_Flow
Image from RailgunGame.com.
Dictating parameters in a way that can be quickly replicated is a (glorious) feature of Visual Scripting, something Stingray and the more well-known Unreal Engine 4 take to heart.  Each node exposes only the necessary variables needed for design - K.I.S.S. and YAGNI reduce option-overload for non-designers, designers, and even the original background-code developer of the node.

After overcoming the psychologically debilitating selection of choices in Flow, I increase the speed of level generation by copying-and-pasting more complex code structures that only require first-time setup.  Time is then only required to tweak parameters for a given level to fit my progression modeling.

Not Designing in the Dark


Artists and writers often face detriment when it comes to the blank space of a page.  The same happens to a designer facing an empty level: What goes where?  Is it too tough?  How many rewards is the player going to get?  Does a story fit here?  Should it?

That's where abstract prediction algorithms come in.

At the earliest opportunity, get a visual representation of the game over time/space.  Even a back-of-the-envelope sketch of how difficulty, progress, and other measurable aspects guides the design process without doubt as to if the designer is going beyond their means.  This will guide design throughout the product lifecycle, projecting expected outcomes once the game gets to players.

It's important to prototype what is going on in-game before diving into the editor to see how things look on a spreadsheet (stereotypical friend of the designer).  Paper prototyping (or putting in ready-made assets into a blank, digital level) delivers what the base game could feel like, thereby outlining a point about which to escalate in difficulty.

Railgun-SpeedVSPoints-Chart
Image from RailgunGame.com.

As for starting to put in units and objects into a level, a general rule-of-thumb is to keep the first few minutes of the game educational (AKA the tutorial).  I involve one, at most two opponent types (these can be puzzles or similar obstacles in other genres) with enough change in the space of the level to encourage using nearly all the controls available to the player.

In 8 short steps:
  1. Paper-prototype game timeline/progression.
  2. Develop prediction algorithm.
    1. Compile game telemetry data to determine trends.
    2. Play the base set (unit, weapon, etc.) of the game repeatedly, plugging in the aggregate data (deaths, points, play time, etc.) into a tool such as Google Sheets, and deriving a value from that.
  3. Create basic first level.
  4. Apply prediction algorithm.
  5. Repeat processes three and four (approximately) to game design completion.
    1. By "completion", this means that there's content in every level, every unit/weapon has been implemented in code.
  6. Play the game; refine the algorithm's parameters, unit stats, and level design based on the firsthand experience.
  7. Get others play the game; observe performance, ask what players don't like, and never blatantly implement a solution offered by an outside party.
    1. Solutions to problems is the role of the game makers; players also tend to be biased towards fixes that benefit their style of play.
  8. Repeat steps six and seven to and through launch.

Image from Railgun Twitter page.

Conclusion

With simple rules and graphical projections to guide development, putting together levels and gameplay systems can be significantly sped-up while also decreasing the tweaks needed to balance the experience.  Railgun is one case study where this is working to great effect.

Look for more news from Railgun soon.  Check in again when new programs, designs, and insights are released here on Make Better Games!

Multiplayer Learning with Banjo-Tooie

(Games of Taste - Comments from late '12 after varied game competition.)



Banjo-Tooie Multiplayer

Image from Banjo-Kazooi Wiki.

  • + Unique library of weapons to use.
  • + Distinct character features to fit multiple play styles.
  • - Useless melee ability.
    • A fix: Decrease cool-down times in attacking while increasing the effective range of the attack.
  • - Unintuitive effects from weapons.
    • A fix: Define all the effects of an attack in the first pull of the trigger.
  • - Clumsy controls in aiming and movement.
    • A fix: Keep sensitivity of aiming at a moderate scale, while only keeping movement on one control (not both the directional pad and analog stick); don’t use inverse controls by default.
  • - Level design is absent - like a cake missing something sweet.
    • A fix: Make levels have high and low areas, while also placing weapons in locations that naturally draw players together.


This past weekend was another Olympic LAN party.  A few games were played, but I felt Banjo-Tooie’s multiplayer needed special mention.  As you can see by the list above, it was… unimpressive.

The game provides a unique library of weapons to use.  Mines, bombs, rockets, and machine gun rounds are all in the form of eggs shot out of a bird.  Special, right?  It is, but all for the wrong reasons.  Mines explode when placed anywhere near another mine, machine guns do zilch, and the difference between higher-damage rounds can’t be told just looking at them.

Speaking of weapons, the melee would be better if it didn’t exist.  When the melee button is hit, the in-game character goes into a dreadfully long animation to do essentially nothing.  That time makes the player a sitting-duck, readying them for cheap-shots in multiplayer matches.  Attacking hand-to-hand is a death wish.

Image from Wikipedia.
There is a fun set of familiar Banjo game characters.  Each one is either fast, average, or slow in movement.  However, the controls make every character feel like they are either antique tanks or sliding on a greased floor.  Turning to aim at an opponent is nigh futile; the prevailing strategy is to shoot like a madman in the general direction of foes.  Maybe then a hit will be landed, but it won’t make up for very touchy controls.

Finally, multiplayer levels lack a lot of what modern games take for granted.  Modern games have elevation levels, ‘safe’ and ‘prospect’ places, and flow to direct players into confrontation.  Banjo-Tooie misses these things by a mile.  To summarize, encounters are random, and players can easily get lost in the cramped depths of the multiplayer arena.

In essence, Banjo-Tooie is a game to learn from.  Being a spearhead of 3D gaming, there are both good things, and terrible things, in the game’s multiplayer design.  Good differences are present in character traits and weapons, but poor weapon instruction, excruciating controls, and no level design leave the game lacking.  May we all learn from Banjo-Tooie’s multiplayer to help make better games in the future!

IGDA Nanocon '12 Notes - The Lens of Truth

(Games of Taste - Notes from Nanocon '12.)


The Lens of Truth: Real World Adaptive Level Design


Speakers: Chris Totten (Art Director E4 Software) and Josh Lynsen (Creator of StreetPass Network)

How did we get here?


                How Chris got here:
    • Architecture Masters.
    • Self education in Blender.
    • Teaching on game development.
    • Writing on game development.
    • Doing game development.
    • Advice: Be self-motivated.  Put the time in.  It will work for you if you keep your head down and hit the grind-stone.

                How Josh got here:

    • Took the skill in his day job and applied it to what he wanted to do in game making.
    • Does things that apply to a part of game making.

Discussion


Use virtual clues for real-life treasure.
How to deal with structures that already exist
                Use Urbanism
                                - Large spaces can keep people away from each-other
                                - Paths, districts, nodes, landmarks allow for meeting
                Connectivity
                                - Cell phones/internet create a damaging interaction issue

Adaptive Game Reuse - take a game and re-center it around a place
                1. Games that enhance
                                - Simple mechanics to real-world situation
                                - Ex: item finding to explore locations
                                - Ex: virtual art/characters in real locations
                2. Games that pervade
                                - Events can only be executed in specific locations
                                - Going from point A to B affects the virtual world
                                - Ex: passing someone in life gives virtual goods/action
                3. Games that rehabilitate
                                - Jane Megonigle
                                                - Works on games that makes the world better
                                                - Gamify basic actions in a positive way
                                                - Ex: Tombstone Hold'emCruel to be Kind
                                - Gamifying a common feature/location

Chris and Josh: Creating a ‘Hometown social game’



  1. Goals
    • Revisit hometown and bring welcome visitors
    • Support local business and institutions
    • Inject new life into smaller/shrinking cities
    • Maintain links to - and value - your past
  2. Platform
    • Facebook, Google Plus or other social network
    • Any communal posting area that supports photos/discussion/moderation
  3. Guiding principles
    • Large amount of local control
    • Encourage tourism as much as revisiting
    • Especially support volunteerism
    • Especially support local festivals and city events
  4. Example point system for pictures taken:
    • 2 - you in town
    • 5 - you and local landmark
    • 10 - you supporting local business
    • 50 - you volunteering at local charity
    • 50 - you at local festival
  5. Rewards
    • Game enjoyment and community support
    • Gold, Silver, Bronze involvement rankings
    • No specific leader-boards
    • Less about competition, more about involvement
  6. Notes
    • No specific hometown?  You are a nomad player.
    • National chains ineligible for business photos.
    • Chambers of Commerce could be local bases.