Which is better in your opinion, working in-house
for a big game company or working for a small development group?
Between a big house and small house I think most likely it's
better to work at a big house for security. Ie, your job will be around and also for your
resume, it's better to say I worked at Westwood, or Origin then Joe Blow's Software Guys.
Unless JBSG happens to be the next Id but more likely JBSG will turn out to go under. Most
small developers do.
On your "Making games" page, you state that a development system for $30000
is needed. What is a development system? Do you mean the computer itself or is it
software? It seems to me like a programmer could just use a $3000 PC for development.
Most console systems, Playstation, Nintendo 64, Dreamcast, etc.
require a development system. For example the Playstation development system is a
board or set of boards that plugs into your PC and basically has a programmable
playstation on the board. Many tools are supplied for example a TSR that lets your
PSX programs read files from your PC's hard drive so you don't have to burn a new CD every
time you want to try some new data in your game. There is also a C and C++ compiler
and several routine libraries, tools, docs and a source level debugger. There are
extras you can buy too like another card that is supposed to simulate the CD. For
example you can't easily simulate video from the PC hard drive because the playstation uses
special format CD sectors and timing info and there is no way to supply that info through
software easily. For example the sound data during video is never read into ram. It
goes straight from the CD to the audio hardware. Simulating the timing perfectly is
especially important so you know it's not going to skip or studder when you burn a disc.
You can also get a performance analyzer that will tell you things like where you are
thrashing the different caches and where you are re-loading data redundantly.
All that hardware costs lots of bucks partly because there are so
few customers and it takes lots of people to support and develop tools for it and to write
documentation etc.
Sony, for example, also requires that if you are going to submit
a CD to them it has to be burnt on THEIR burner and on THEIR CDs. They will not accept a
CD that is burnt on some $500 burner you bought at CompUSA or on a $.50 cheapo disc.
Nintendo 64 development, at least in the beginning required an
SGI. I'm not sure it still requires that.
Dreamcast is similar to a PC with a PowerVR2 card in it but if
you really want to make a Dreamcast game (instead of a PC port) you need to program the
Dreamcast directly. For example the Dreamcast has a matrix multiply in the processor. The
PC does not. The PowerVR2 has hardware support for shadow volumes and light volumes. The
PC PowerVR2 card probably has those features too but you can't access them through DirectX
or OpenGL. Also, going directly to the hardware instead of programming through an API
like OpenGL or DirectX you can easily double your polygon count.
Therefore you really need a Dreamcast development system if you
want to make a game that is competitive with other Dreamcast games.
For PC development you only need a PC although it's often nice to
have 2 so you can remote debug. It's hard to debug a full screen game since you will not
be able to see the debugger unless you have 2 machines. Or you could just decide debuggers
are for whimps 
What are you working on now?
Currently I'm working on a game for the arcade at Sega's AM1
division in Japan. It was called Blood Bullet and there is some small amount of press out
there because it was shown early at the JAMMA show in Japan in September. I think they are
going to change the name before it ships though.
How do you choose your projects (or are they assigned to you)?
I don't usually get to pick the game. If you think about it
unless you do your own game it's unlikely you'll get to pick. For example take a
medium sized developer like Crystal Dynamics. They have had up to 100 people but those 100 people
are only working internally on 3 or 4 projects. Most likely 2 or 3 people picked
those 3 or 4 projects. The other 98 people just do what they are told. Of course at many
companies alot of discussion happens before the decision is made so people who want have a
little influence.
Even at your own company you might not get to pick. See my
"starting your own company" page 
Have you considered writing for Game Developer Magazine?
I've considered writing for GameDev mag but I haven't thought of
anything I really want to write about that would make a good article. The only thing I
kind of want to write but I haven't found the time is some pages about 3D (not for Gamedev
though). I've looked all over the net for various topics that I needed to implement with
little or no luck. Many people claim to have articles but then they either say
"coming soon" or they give some brief explanation but no real code or they give
the wrong info etc.
Maybe someday.
Which profiler do you suggest?
I've never really used a profiler much. I did use the one that
comes with Microsoft VC++ a couple of times. I've heard some great things about VTune from
Intel. I have yet to see anything nearly as useful as the Sony Playstation performance
analyzer on the PC.
Usually it's pretty clear where your bottleneck is in a game
without a profiler. Often on the consoles since we try to run the games at 60hz
(Playstation more like 30h usually) we will do things like at the top of the main loop,
set the border color of the screen to black, then between calculating each character we
set it to a different color and then before drawing a different one and at the end black
again. Then we wait for the next vertical blank. This ends up showing sliding bands of
color on the side of the screen representing the time each part of the code takes as a
percentage of one 60hz frame.
For slower titles you can write a few timing routines that you
stick in your code with a conditional compile and then check the timing manually. I
haven't done that in a long time but it's not that hard. You just need a routine to update
a table of routine counts and times. For example something like this:
typedef struct
{
int acccessCount; // inc when PunchIn is called
int timeIn; // set to microsecs
when PunchIn is called
int totalTime; // add (currentTime - timeIn) when
PunchOut is called
char* areaName; // so you can print the results easily
}
AreaInfo
void PunchIn (int routineID);
void PunchOut (int routineID);
