Gamasutra - Feature - "Analyze This: Will 'Casual' Games Dominate the Future of the Industry?"
It's free to join Gamasutra!|Have a question? Want to know who runs this site? Here you go.|Targeting the game development market with your product or service? Get info on advertising here.||For altering your contact information or changing email subscription preferences.
Registered members can log in here.Back to the home page.

Search articles, jobs, buyers guide, and more.

By David Jefferies
[Author's Bio]

Gamasutra

August 8, 2006

Postmortem: MotoGP '06

Introduction

WHAT WENT RIGHT
arrowPt. 1
arrowPt. 2
arrowPt. 3

WHAT WENT WRONG
arrowPt. 1
arrowPt. 2
arrowPt. 3

 



[Submit Letter]

[View All...]
  


Features

arrow PreviousNext arrowPostmortem: MotoGP '06
(Page 2/7) [Article Start]

What Went Right?

1. Tight Focus

Right from the beginning we knew the focus had to be kept tight. MotoGP had always received praise for its handling, game modes and Live implementation. It was decided, therefore, that these key areas would receive only a light reworking leaving us to concentrate all our resources on a complete overhaul of the graphics systems.

 

2. Tomcat

Our artists don’t model in Max or Maya but in a modelling package that we write for them, called Tomcat. Work had started 2 years earlier on the tool that was based on our SuperTools modelling and texture package 1

The original incentive for writing our modelling tool came because of the lack of curved surface capabilities in the other popular packages. All our tracks and bikes are modelled with curved surfaces and then, at export time, we tessellated the model into any number of polygons. The artists are happy and productive working this way and it has the added benefit that all our resources are totally scaleable in terms of number of polygons. The tool is also much faster than the other packages.

The Tomcat renderer is the renderer that we use in game on MotoGP’06, so the artists have a true what-you-see-is-what-you-get interface.

This was invaluable at the beginning of the project because it allowed the artists to hit the ground running. They didn’t have to hang around waiting for us to write the in game renderer – they could get on and model their assets safe in the knowledge that when the time came their assets would work in game. They also knew that we could scale the polygons and texture sizes of their assets according to the power of the target hardware.

They also got busy designing their own shaders. Tomcat has 50 or so small shader fragments that the artists can combine in whatever order they like. This allows them great freedom to experiment with different material types and because the game and tool share renderers, anything they do in Tomcat will look the same in game.

(Page 2/7)
arrow PreviousNext arrow
arrowarrow Article Start

 


join | contact us | advertise | write | my profile
news | features | companies | jobs | resumes | education | product guide | projects | store



Copyright © 2005 CMP Media LLC

privacy policy
| terms of service