advice to someone wanting to enter the games industry

(paraphrased from a talk i gave at the university of colorado, usa, in april 1997. it's just my opinion.)

  • you will live or die in the games industry on the business side of things, not the technology
  • for every hour you spend thinking about technology or game design, spend an hour thinking about how you can get paid for it
  • ideas are not scarce. talented teams are scarcer. signed deals with publishers are the most scarce.
  • become very competent in c++. become competent in at least 3 other languages. understand more than 1 operating system.
  • you are most valuable if you can design and/or produce and/or direct
  • for an example of what can be done on the pc by folks who don't know what the limits are, view lots of demos. a great gateway to demos is Hornet's web site. its title is "PC Demos Explained". you can download many of the classics from there: unreal or second reality by future crew, crystal dreams by triton, paper by statix (psychic link), 303 by statix (psychic link), daydream, rox, claudia by deathstar, machines of madness. make it a habit to view the top 3 place-getters in the major demo competitions each year. eg. Assembly, The Gathering, The Party.
  • most of the time, your profit is made when you sign the development contract, not when you finish the game
  • for a retail product, whatever you sell in the first 3 months will be half your total sales for the life of the product
  • the fundamentals of computer science apply - correctness, abstraction, data hiding, modularisation, maintainability, understandability
  • correctness is important first. speed is important last. if you have a correct, slow program, it is straightforward to make it a correct, fast program. if you have a buggy, fast program, it is very painful and expensive to turn it into a correct, fast program. love thy profiler. do not guess where the time is going. i'm wrong half the time, which is the same as a coin toss.
  • in the past you could build a game by yourself. now, to compete, you need a team. working and communicating in a team environment is crucial.
  • game-building will never become like movie-making but it's going in that direction.
  • read every article in rec.games.programmer and comp.graphics.algorithms for a year. repeat.
  • no one can predict the future. come to your own opinion on what's fun.
  • get in the habit of building and breaking a couple of prototypes for every new project you take on.
  • on the roads, keep right. (on australian roads, keep left)
  • the demand for an unknown game is precisely zero. get known.
  • player-connection technologies like the internet create opportunities for completely new types of games.
  • understanding how you program for networks is important. understanding how you synchronise a game across many linked computers is important.
  • voice and video interplayer communication are crucial technologies for multiplayer games. understand them. read comp.compression and comp.speech
  • example of development deal: you buy a game at the mall for $50. the store owner bought it from a publisher for $30. it cost the publisher $5 to press a cd, print a manual, put it in a box, and staff the technical support lines. the net sales for the publisher is (30-5=25). the developer (that would be you) gets 10% of 25 = $2.50. the developer may or may not have got $500,000 to develop the game. the $2.50 royalty per unit may or may not be applied to the $500,000 before you get any more money. if it is, you need to sell 500,000/2.5 = 200,000 units before you see any more money. "developer" here = team of 5-10 people.
  • a game which sells 100,000 units on the pc is very, very respectable. a game which sells 500,000 units on the pc is a mega-hit. double or triple these numbers for console games.
  • the audience for games is expanding but the technical level of the audience is decreasing. console games hardly ever crash. why? discuss. 
  • if you want to make a favourable impression when you're going for a job at a game company, build a demo of a game first and be prepared to talk about it and its source code. it absolutely doesn't matter what sort of game it is.
  • put your mind to solving many sorts of technical problems, game ones or not.
  • you can make money via shareware but be prepared for the long haul, like years.
  • one way to break in to the business is to get a game broker to publish your game like epic or apogee.
  • if you read one book on building software, read "Writing Solid Code" by Steve Maguire, published by Microsoft Press. 

owen pearn's home page