What Makes A Good Game Programmer?
Author
The title really says it all; what skills, attributes, characteristics or traits do you think make a good game programmer?
The abilities to learn and think are key. It might sound silly, but those seem to be skills that most people in the world are missing. I don't mean that you have to memorize things (which is what schools generally consider 'learning' to be), but that you must be able to receive information, internalize it, generalize it if appropriate, and apply it to future problems you may encounter.
[edited by - extrarius on February 6, 2004 2:59:35 AM]
[edited by - extrarius on February 6, 2004 2:59:35 AM]
That all depends on what game you are writing. These days the skills are leading more to the design and new ideas because there are so many games of a certain type. Take a FPS for example, what do you want to see in the next FPS, obviously it has to have good graphics, good collision detection and all the normal basics. You are expecting that because that is what all the other games have. You play the game because you want to see what new ideas the game developers came up with.
Attributes:
you have to be motivated, you have to know where you''re going
Characteristics:
you should have a passion for it else it will become like a job and you will do it because you have to. Therefore you won''t stive to make it better or get the best possible ideas.
Traits:
Be yourself, if you try copy somebody it will be like running into a helicopter
Skills:
know your stuff, learn as much as possible, learn more because you want to make it better. You might also want to get a Degree in Computer Science if you''re plannig on working for a game company.
And most of all, just do it because you love it.
Attributes:
you have to be motivated, you have to know where you''re going
Characteristics:
you should have a passion for it else it will become like a job and you will do it because you have to. Therefore you won''t stive to make it better or get the best possible ideas.
Traits:
Be yourself, if you try copy somebody it will be like running into a helicopter
Skills:
know your stuff, learn as much as possible, learn more because you want to make it better. You might also want to get a Degree in Computer Science if you''re plannig on working for a game company.
And most of all, just do it because you love it.
i agree with the memorization thing....you dont have to memorize anything (well maybe some things) but generally you just need to be a problem solver.
i think it is also important to know what to use in certain situations, i dont think you must memorize how to do it though...that is what a reference book is for
example: i know that if I have a data structure representing a graph (ie a road map or something) in my program and i want to find the shortest path between any two locations on the graph then i need to run djikstra''s algorithm on the data. i dont remember how to code djikstra''s algorithm but i know that is what i should use and therefore can look it up in a reference book (or google it)
"A soldier is a part of the 1% of the population that keeps the other 99% free" - Lt. Colonel Todd, 1/38th Infantry, Ft. Benning, GA
i think it is also important to know what to use in certain situations, i dont think you must memorize how to do it though...that is what a reference book is for
example: i know that if I have a data structure representing a graph (ie a road map or something) in my program and i want to find the shortest path between any two locations on the graph then i need to run djikstra''s algorithm on the data. i dont remember how to code djikstra''s algorithm but i know that is what i should use and therefore can look it up in a reference book (or google it)
"A soldier is a part of the 1% of the population that keeps the other 99% free" - Lt. Colonel Todd, 1/38th Infantry, Ft. Benning, GA
I''ll buck the trend. Good people skills are what I look for (in addition to the obvious ability to program). You are going to living with the rest of your team for the next year or more. You better get along with them.
Most of the skills that make a good programmer in general are also needed for a game programmer. In addition, you need:
* Good communication skills - particularly with non-programmers. A game programmer will frequently be coordinating with artists, designers, and marketing / business types.
* The ability and desire to learn new things FAST and WELL. Once upon a time, I wrote my own 3D polygon rasterizer in assembly, and I was "pretty good" at graphics programming on the Sony Playstation. And I knew C++ fairly well... C++ circa 1991, which has changed significantly in the last 12 years. Now C++ is quite different - and I don''t know it nearly as well. And while my skills in writing a textured / shaded poly rasterizer and knowledge of the Playstation 1 graphics architecture certainly helped me move on to bigger and better things, those skills ain''t exactly in demand right now. You need to be constantly learning new things, and self-motivated to do so.
* An eye for optimization: Most of what they teach you in school --- and most of the demands of non-gaming jobs --- down-plays speed or memory optimization. Doing it "right" is about making it robust and easy to read / modify. In game programming, those are STILL requirements, but you may also need to add speed and memory requirements. Not for everything.... who cares about shaving 1 millisecond off of your loading time from a memory card? But this is a skill that you need in games, maybe in embedded systems, and very few other places.
* Self-Starting: This is important everywhere, but especially in games, you will often not receive a fully-spec''ed-out, step-by-step instructions on what you should do next. You will need to be able to take a general task (like "code the AI"), jump into research mode to learn what you can about the problem, decide upon a course of action, and often set your own goals or mini-milestones, and see it through TO COMPLETION. That''s the next part...
* Be a finisher: Many programmers are good at starting a project, but they often give up (or figure "good enough") before things reallyt are done or ready. You have to know what it takes to get the job done - be willing and able to wade deep into arcane bugs that may be somewhere in someone else''s code and only shows up on even-numbered tuesdays on machines with very particular hardware setups. A lot of people assume they are "almost finished" when they are really less than halfway there. You can''t be the guy that everyone else has to go back and clean up after, because you left a lot of unfinished business laying around.
* Love Games: You may not have TIME to play them as much as you like, but I do believe that a good game programmer is someone who loves games, who can enjoy working on his current project, and is as much his own audience as any of the customers out there. You will generate your own feedback, and provide some guidance for the game before the changes become too costly and dangerous to put in.
* Good communication skills - particularly with non-programmers. A game programmer will frequently be coordinating with artists, designers, and marketing / business types.
* The ability and desire to learn new things FAST and WELL. Once upon a time, I wrote my own 3D polygon rasterizer in assembly, and I was "pretty good" at graphics programming on the Sony Playstation. And I knew C++ fairly well... C++ circa 1991, which has changed significantly in the last 12 years. Now C++ is quite different - and I don''t know it nearly as well. And while my skills in writing a textured / shaded poly rasterizer and knowledge of the Playstation 1 graphics architecture certainly helped me move on to bigger and better things, those skills ain''t exactly in demand right now. You need to be constantly learning new things, and self-motivated to do so.
* An eye for optimization: Most of what they teach you in school --- and most of the demands of non-gaming jobs --- down-plays speed or memory optimization. Doing it "right" is about making it robust and easy to read / modify. In game programming, those are STILL requirements, but you may also need to add speed and memory requirements. Not for everything.... who cares about shaving 1 millisecond off of your loading time from a memory card? But this is a skill that you need in games, maybe in embedded systems, and very few other places.
* Self-Starting: This is important everywhere, but especially in games, you will often not receive a fully-spec''ed-out, step-by-step instructions on what you should do next. You will need to be able to take a general task (like "code the AI"), jump into research mode to learn what you can about the problem, decide upon a course of action, and often set your own goals or mini-milestones, and see it through TO COMPLETION. That''s the next part...
* Be a finisher: Many programmers are good at starting a project, but they often give up (or figure "good enough") before things reallyt are done or ready. You have to know what it takes to get the job done - be willing and able to wade deep into arcane bugs that may be somewhere in someone else''s code and only shows up on even-numbered tuesdays on machines with very particular hardware setups. A lot of people assume they are "almost finished" when they are really less than halfway there. You can''t be the guy that everyone else has to go back and clean up after, because you left a lot of unfinished business laying around.
* Love Games: You may not have TIME to play them as much as you like, but I do believe that a good game programmer is someone who loves games, who can enjoy working on his current project, and is as much his own audience as any of the customers out there. You will generate your own feedback, and provide some guidance for the game before the changes become too costly and dangerous to put in.
I've noticed one thing that distinguishes the really good programmers from the average programmers, is that the good ones will internalize their programming knowledge. They use the emotional and intuitive part of their brain to figure out problems. They "feel" their way through a problem. They get emotionally excited when they come up with an O(1) algorithm, and they get visibly angry when a bug occurs. They have strong opinions towards various programming practices. When something is a bad idea, they don't say "it's not good practice" or "it might cause such-and-such", they say "it's EVIL!".
Of course, it is really difficult to get to that point- I say that the good ones use the "intuitive" part of their brain, but most programming knowledge is absolutely not "intuitive" at all. And it is sometimes hard to stir up any emotions at all, for a subject that is just so relentlessly bland as CS. So these "internalizers" are pretty rare.
And of course, all the other things apply: having a thirst for knowledge, being patient, being clever, etc etc etc.
[edited by - pinacolada on February 6, 2004 9:23:41 PM]
Of course, it is really difficult to get to that point- I say that the good ones use the "intuitive" part of their brain, but most programming knowledge is absolutely not "intuitive" at all. And it is sometimes hard to stir up any emotions at all, for a subject that is just so relentlessly bland as CS. So these "internalizers" are pretty rare.
And of course, all the other things apply: having a thirst for knowledge, being patient, being clever, etc etc etc.
[edited by - pinacolada on February 6, 2004 9:23:41 PM]
quote:Original post by pinacolada
... And it is sometimes hard to stir up any emotions at all, for a subject that is just so relentlessly bland as CS...
You obviously havn''t stepped into any language flamewars on the forums here, eh?
-Mike
~ Your friendly neighborhood troll, taking things out of context since 1985 ~
On topic: I internalize, but that''s not enough. I yell at my compiler lots, and tell my px::ui::string class to go fuck itself. The other part is focus. My problem is I have brain damage similar to ADD. I allways think of a better way to implement something before I''m done implementing it the first way. Thus, I never finish implementing anything because I can''t stop improving it.
As for Jay''s note learning fast and well:
I spent time trying to figure out how to render 3d scenes using my very limited knowledge of C (back then), not having read anything about percpective theory, rasterization, or the like. I collapsed things onto a sphere, but couldn''t decide how to get from sphere to flat surface without distortion.
Then I realized I was on crack, and just needed to project to a plane.
My first 3d program drew a 3x3x3 array of cubes in percpetive, when I was around 13, using only moveto(x,y) and lineto(x,y) for rendering. Oh yeah, and color(i). I was stuck with a 16 color pallet
. Stupid turbo lite C compiler...I also before that made a program that drew the mandelbrot set... but that didn''t count, as I was just pounding code together from examples I read. I was using Borland C++ Builder, which creates the GUI code for you.
Anyhoo, this->Property.Cash.BankAccount[0]->Ballance -= 0.02;
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
