Upcoming Events
Southwest Gaming Expo
11/20 - 11/22 @ Dallas, TX

Workshop on Network and Systems Support for Games (NetGames 2009)
11/23 - 11/25 @ Paris, France

ICIDS 2009 Interactive Storytelling
12/9 - 12/11 @ Guimarães, Portugal

Global Game Jam
1/29 - 1/31  

More events...


Quick Stats
6569 people currently visiting GDNet.
2341 articles in the reference section.

Help us fight cancer!
Join SETI Team GDNet!



Link to us

Link to us

  Intel sponsors gamedev.net search:   

2008 Austin GDC Coverage Part 1


Game UI Development in Flash

Grant Skinner (CEO and Chief Architect, gskinner.com) & Graham Wihlidal (Senior Programmer, BioWare)

Most UI solutions are proprietary tools, developed in-house or as part of a larger engine. There's not a broad adoption of any particular tool. New versions are often complete rewrites, as there's no legacy support. Support is whatever you can make of it. There's difficulty in creating rapid prototypes of products. Import is limited to whatever you can write. Text and fonts and localization are a pain.

Flash solves a lot of these problems. It was designed from day-one for building rich UI's. It has a lot of backwards compatibility. It's easy to outsource, because Flash support is a common skillset.

Flash Lite is also a player. It's the Flash player built for mobile development. It supports emulation and easy device testing for a mobile device on a desktop machine.

The Flash toolset is designer focused and developer friendly. It features wysiwyg art, text, and animation. It integrates seamlessly with Adobe's other design tools, like Illustrator. It's extensible fairly easily (not as easy as Eclipse, but hey), It supports a robust OOP language based on ECMA-262. ActionScript fully groks streaming in assets and communication with external sources.

Flash also supports code in external files, which is important when you need to separate functionality from graphics. Designers can concentrate on the visuals without having to worry about the code.

Drawbacks – Good Flash developers are still rare. FLA files are binary and not-editable, so it's not easy to work it into a development workflow. There is some deviation from player to player, so it's important to check the end-result on various players. There's no existing component framework that's specific to games – the existing component framework is a bit heavy. Game engine integration is not as smooth as it should be.

Workflow overview via ScaleForm

Prior to ScaleForm, Bioware's UI design was heavily bitmap based. Now it's based on Flash using the ScaleForm Flash UI engine.

Conceptually, it's similar to a traditional UI workflow. Authoring in Flash is easy for designers. AS libraries (text files) can be imported without regard to what's in 'em.

Engine import – map the resource name to the handler/tag in an INI file. Them import the SWF into Unreal Engine as an object.

Engine integration is client-centric, host-centric or mixed. You can create a handler for the SWF in UnrealScript/C++. The UI should be event driven without constant polling in the ActionScript. Localization is global by default but can be overridden.

In-game testing – verify the quality of rendering, modality, configuration entry.

Looking Forwards

Project “Skin” - gskinner.com & scaleform. A UI toolkit specifically for game UI's. It's going to address some getting-started issues regarding Scaleform, as it'll have a lower point of entry for tool designers.

Adobe OpenScreen Initiative – Adobe program to “bless” third party players as well as working with alternative player-makers to help 'em with future plans for the player.

Coverage by John Hattan



Page 5


Contents
  Table of Contents
  Page 1
  Page 2
  Page 3
  Page 4
  Page 5
  Page 6
  Page 7

  Printable version
  Discuss this article

The Series
  Part One
  Part Two