Game development facts and tips

Last month I had the pleasure of finding a new friend in the gamedev community: Ian Masters, a senior game programmer at Sidhe Interactive, creators of the Speed Racer game for Nintendo Wii and Sony PlayStation 2.

While he was in town I managed to compile a list of game development facts and tips. Here they are:

Programming:
Everybody creates their own internal technology to build games. They modify engines and create frameworks for internal use.
The technical director is the responsable of selecting technology like the game engine.
Developing a game engine from scratch could take years and it’s not recommended.
The most used languages in game development are : C++, Lua and Python.
It’s common to have a prototyping team.
Use source control (SVN, mercurial, etc.)
Have all your projects into a solution, prefer that to link against static libraries (including third party code).
Have your engine’s source code in your source control system so you can modify it and the changes will propagate.
QA:
Unit testing is very important (specially for math libraries and core functions).
Regression testing is important too.
QA team is different from playtesting. QA test QA, playtesters test fun.
No QA guys in multidisciplinary teams.
Art:
Conceptual art should be delivered as soon as possible before programming start (at least a month ahead).
Work on iterations.
Artists hate naming conventions.
It’s not easy to convince the artists to follow naming conventions (normally you need a producer to talk to them).
Having a lead artist who follows naming conventions is crucial.
Try to integrate audio as soon as possible. Audio is not a luxury.
Post effects are often decided between the post effects coder and the art director.
Camera effects are often decided between the camera scripters and the designers.
Have metrics with the export tools (poly counts, texture sizes, bone count, etc)
Should present a visual target.
Design:
They can’t account for everything.
Design document should be as detailed as possible.
Design document should be a live document.
They define tunable properties.
Normally use XML files for tunable properties (exported from spreadsheets for extra awesomeness).
There are co-designers (scripters).
Production:
Producer’s work is to assure work is being done and cycles are running smoothly.
Wikis are awesome.
You can manage a whole project documentation using exclusively a wiki.
Procedures, knowledge and project management all fit into a wiki.
Multidisciplinary teams are a great way to work.
Have a list of features that need to be tested on the prototype.
Recommendations:
Scrum is the way to go.
Use Scrum properly.
Scrum meetings in the mornings.
Put scrum plans on the wiki.
Create tickets on Trac or a similar tool.
Keep things visible and transparent.
Read a lot. Be proactive and an active learner and problem solver.
Try to work as close as possible with artists, programmers and designers.
You need a published title to get into the industry. To get that title you need to be in the industry. Indie titles are a good way to break into it.
Prototype as soon as possible.

Programming:

  • Everybody creates their own internal technology to build games. They modify engines and create frameworks for internal use.
  • The technical director is the responsable of selecting technology like the game engine.
  • Developing a game engine from scratch could take years and it’s not recommended.
  • The most used languages in game development are : C++, Lua and Python.
  • It’s common to have a prototyping team.
  • Use source control (SVN, mercurial, etc.)
  • Have all your projects into a solution, prefer that to link against static libraries (including third party code).
  • Have your engine’s source code in your source control system so you can modify it and the changes will propagate.

QA:

  • Unit testing is very important (specially for math libraries and core functions).
  • Regression testing is important too.
  • QA team is different from playtesting. QA test QA, playtesters test fun.
  • No QA guys in multidisciplinary teams.

Art:

  • Conceptual art should be delivered as soon as possible before programming start (at least a month ahead).
  • Work on iterations.
  • Artists hate naming conventions.
  • It’s not easy to convince the artists to follow naming conventions (normally you need a producer to talk to them).
  • Having a lead artist who follows naming conventions is crucial.
  • Try to integrate audio as soon as possible. Audio is not a luxury.
  • Post effects are often decided between the post effects coder and the art director.
  • Camera effects are often decided between the camera scripters and the designers.
  • Have metrics with the export tools (poly counts, texture sizes, bone count, etc)
  • Should present a visual target.

Design:

  • They can’t account for everything.
  • Design document should be as detailed as possible.
  • Design document should be a live document.
  • They define tunable properties.
  • Normally use XML files for tunable properties (exported from spreadsheets for extra awesomeness).
  • There are co-designers (scripters).

Production:

  • Producer’s work is to assure work is being done and cycles are running smoothly.
  • Wikis are awesome.
  • You can manage a whole project documentation using exclusively a wiki.
  • Procedures, knowledge and project management all fit into a wiki.
  • Multidisciplinary teams are a great way to work.
  • Have a list of features that need to be tested on the prototype.

Recommendations:

  • Scrum is the way to go.
  • Use Scrum properly.
  • Scrum meetings in the mornings.
  • Put scrum plans on the wiki.
  • Create tickets on Trac or a similar tool.
  • Keep things visible and transparent.
  • Read a lot. Be proactive and an active learner and problem solver.
  • Try to work as close as possible with artists, programmers and designers.
  • You need a published title to get into the industry. To get that title you need to be in the industry. Indie titles are a good way to break into it.
  • Prototype as soon as possible.

Hope that helps, and a big “Thank you” to Ian for his time with us. I learned a lot.

  • Alberto

    YA ESTAS GRANDE PENDEJO MADURA