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:
- 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.
- 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.
- 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.
- 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).
- 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.
- 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.