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.
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.
Which profiler do you suggest?
You don't usually need to profile each routine just certain areas so make a table of 20 or 30 areas and each time PunchIn is called increment the call count for that area and record the time in. PunchOut would subtract the current time to the time in and add to the total time. Then when you exit your program print the results.
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:
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
void PunchIn (int routineID);
void PunchOut (int routineID);