Wednesday, September 30, 2009

The Rise of the Technical Artist and Tools Engineer

In this article, software engineer and project manager Casey O'Donnell discusses the role of technical artists and tools engineers.

Game development has seen a dramatic shift in the last five years. The amount of storage space available for developers to use has risen dramatically and the expectation on the part of players and publishers that this space be used has risen as well.

This has meant in many cases that more content must be placed into a game. More levels, more models, more textures, etc. All of this has required a shift in how developers approach game development. "The pipeline" has become much more important. The pipeline is at its simplest a process by which a particular game asset (sound, image, model, level) is placed into a game.

As the demand for content has increased, the pipeline has become much more important. Specifically the turnaround time for an artist or designer to see something in the game such that they can ensure that what they've constructed in 3D Studio Max or Maya indeed looks as it should inside the game. Or, in the case of designers, that a level moves as anticipated, or that indeed "out of bound" areas cannot be accessed.

The pipeline has become much more complex over this time period, and its two main laborers have become the "Technical Artist" and the "Tools Engineer." Each serves different purposes and many are the same person in smaller game studios. Technical artists, in my experiences, have often been artists who first started college as computer scientists hoping to make games, only to find that such is not the mission of most computer science programs. In the mean time however, many of them did learn something about scripting/programming languages and assorted computer and operating system nitty gritting elements before migrating towards more art friendly disciplines. Many technical artists simply emerge in small game companies, making scripts, toolbars, and other utilities that speed the process of getting their work into the engine so they can see it. They are the saviors of other artists when things don't go quite as anticipated. More recently this has become a specific sub-discipline of artist in many game studios.

The tools engineer, much like the technical artist, has been an accident of history, rather than a deliberate shift of the industry. That said, I must admit my predilection towards the tools engineer, having been one. Tools engineers were typically engineers that found themselves watching designers or engineers continually making the same mistakes over and over getting things into the game. Tools engineers' sole goal seems to be helping others manage the chaos of game development. This has lead to the construction of custom tools for generating all sorts of items in game, many of which may have been previously constructed with the editing of text, ini, or XML files.

Those editors that you see for games are the babies of tools engineers. Perhaps unfortunately for the tools engineers, they have also become the masters of build systems that must frequently perform numerous tasks and integrate the persnickety compilers and tools developed by console manufacturers with little regard to usability.

Ultimately, however, each one of these disciplines has made it their goal to create game development systems that respond rapidly to the work of the developer. Adjusting a slider and being able to see the change in particle system behavior is much more intuitive. Dropping a new texture onto a model or selecting it from a drop down menu is far more responsive. Clicking a single button to perform a model check, export, and load into the game engine takes less time than following a check list. These systems are actually extensions of what I previously wrote about with regard to debug menus and consoles within games.

Their objective is to provide flexibility and make the lives of developers easier. Except that in this case, gamers rarely come into contact with the proprietary tools and pipelines developed by technical artists and tools engineers.

In some cases, when a pipeline or tool chain is effective enough, it becomes a company asset, such as the Unreal Engine and its array of tools. Even XNA Game Studio shows its colors with its accompanying asset pipeline.

Casey O'Donnell has worked as a software engineer and project manager both in and out of the videogame industry. He is a faculty member of the Telecommunications department at the University of Georgia and is currently the Athens Chapter President of the Georgia Game Developers Association.

Tuesday, September 29, 2009

The Console, Debug Menu, and Gaming Development

In the first article of a series, software engineer and project manager Casey O'Donnell talks about interactive "game design" infused game development.

In its simplest form, game mechanics have been around game design and development for a long time. The "debug" menu or "console" found in many games seems to be one of the foundational means by which developers have attempted to make their tools more flexible. In many games, though the debug menu remains hidden, or actually stripped out of shipping games, sometimes it re-emerges providing players and game enthusiasts with new avenues to examine the roads not traveled in the design and development of a game.

The console, though perhaps the most powerful, is the least intuitive and least interactive. It is commonly used to issue specific commands to the underlying game system. Variables can be assigned new values, thus adjusting the underlying mechanics. Boolean variables can be turned off or on, indicating whether or not particular program paths or options will be executed. But ultimately it becomes a task that isn't easily played. Commands are issued, and the developer returns to the game to see if or how those changes affect the overall game system.

The debug menu, on the other hand, while quite similar, will often offer the player/developer a range of options. Exposed variables will be listed, with current values and the option to change them. In some cases, specific actions can be executed. Characters can be spawned or destroyed. Models, textures, sounds, and other options can be substituted. Levels can be loaded, missions launched, or specific cut scenes played. But, most importantly, the debug menu offers a range of options visually to the user. They need not necessarily know the commands that make a particular action occur. The menu provides the user with the information regarding what can be changed.

Ultimately though, the console and the debug menu were simply a first step down a path of moving design data outside of the core source code of videogame systems. They are simply the most obvious form of a broader movement within game design and development. "Data driven" design is nothing new in the world of software developers, but for many game developers it can seem a relatively new concept. Given than many engineers in the game industry are self taught from books and sample code from others, the idea that design elements should be external to the games underlying code systems can seem foreign. Models need to be loaded, not based on hard-coded source, but based on design data from game designers. Artists need to be able to specify a range of textures applicable to a single model and the frames associated with animations.

In many cases "consoles" are merely the interface into the underlying scripting engines that have been created as interfaces by which designers manipulate the game worlds presented to players. Thus, my next post will focus more on technical artists and tools engineers, whose job it seems to push the envelope with respect to interactive "game design" infused game development.

Casey O'Donnell has worked as a software engineer and project manager both in and out of the videogame industry. He is a faculty member of the Telecommunications department at the University of Georgia and is currently the Athens Chapter President of the Georgia Game Developers Association.

Monday, September 28, 2009

October 2009: Pitching/Creating a High Concept

October 2009's topic, Pitching/Creating a High Concept, was submitted by game designer Tobias Heussner.

Tobias writes:

“It’s easily understood.”

Who doesn’t want to hear this, when he’s pitching an idea?

We as designers are usually faced with this problem of creating nice, colorful, easily understandable pitch docs every once a while. How to’s for creating these docs could fill entire books and it would still be comparable to the quest for the Holy Grail. Since it’s such a complex topic, I’d like to focus on a very small, but in my mind very important part of it within this month's Game Design Aspect of the Month.

The High Concept

The term, high concept or tagline, was developed in the early 1970’s in Hollywood for movie productions. In general it describes the idea of condensing your whole story, or in our case game, down to 1 or 2 sentences. This is usually very helpful; because it shows that you have a clear vision of your project and can serve as the core vision during the development phase. Also another benefit kicks in, which is that due to its shortness it’s easy to communicate.
  • How do you communicate your idea, if you only have 5 minutes?
  • Do you already use the benefits of a High concept?
  • How does a high concept fit in your normal design/pitching/development process?
  • What are your steps when creating an appealing high concept?
  • Do you have other, maybe better ways to communicate your ideas?
I’m looking forward to your answers, your comments and hope that it’ll help us all to create better games.

Tobias Heussner is a Game/Narrative Designer, currently working as an Associate Producer for Radon Labs GmbH in Berlin, Germany. He has been involved in professional game development for over 10 years, has worked in different design and management roles, and has worked on 15 different, published titles, including top-sellers like Paws&Claws: Pet Vet and the AAA-RPG The Dark Eye: Drakensang.

Monday, September 21, 2009

Gaming the Game Developers Podcast (Part I)

Unfortunately, due to a malfunction in GDAM-IT, the second half of the podcast is elsewhere.

In this podcast, producer Billy Cain, game designer Josh Sutphin, and game designer Grétar Hannesson discuss the topic of Gaming the Game Developers.



To download the podcast: go here.

Games Referenced: Auto Assault, EVE Online, World of Warcraft, Scribblenauts

Billy Cain’s game industry career began in 1992 at Origin Systems. Since then, he has designed, developed, produced, and contributed to many award-winning video games including Wing Commander: Prophecy and SpongeBob SquarePants: Revenge of the Flying Dutchman. As co-founder of Critical Mass Interactive, Mr. Cain has created a world-class game development and outsourcing company that has served Disney, Electronic Arts, Midway, NCsoft, Sega, Sony, THQ, Universal, and many other studios.

Grétar Hannesson is a game system designer and an enthusiastic student of human behavior and choice architecture. He cut his teeth on EVE-Online where he served many roles before that of a designer and is now working on an unannounced title for Ubisoft Montréal. He (sporadically) writes about game design and related workplace matters on his blog.

Josh Sutphin is the design lead at LightBox Interactive (formerly Incognito Entertainment). He also produces mods, indie games, and electronic music, and blogs on game design and politics, at http://www.third-helix.com.

Friday, September 11, 2009

October 2009 Poll

Please come and vote for the October 2009 topic!

You'll see the poll to the side. The choices are:

* Emotive Games
* Pitching/Creating a High Concept
* Mechanics That Artificially Lengthen Gameplay

Please vote by October 18, 2009!