Thread: All of you employed developers, what are your jobs really like?

Originally posted by Shadow12345
This I am willing to do, I'm glad I kept my soul instead of selling it to the devil (yes, he came to my house and made some very interesting offers). It seems to be realistic and mature to have a backup plan in case game development isn't all the meat and potatoes promised on the coupon.

Yeah, there's the rub -- the time and the pay. Game programming eats away at your time/social life. You really have to love it and be willing to make sacrifices. The pay isn't low, but considering the amount of hours that you put in compared to other professions it's really not that much of a salary... Unless, of course, you pop out a million seller or two ...

Originally posted by Shadow12345
Poly man what is it with you, you know everything. I'm jealous

Yes, yes, that's because I actually did sell my soul to the devil.

Originally posted by terrance11
polymorph, have you done any internships for game programming??? I know you're a student at digipen.

Not yet, I'm only a freshman. Hopefully in a couple of years, though.

Originally posted by terrance11
I need a social life though I don't think I could live without some time for myself.

You still have somewhat of a social life -- just that most of it is just with fellow programmers, heh.

Originally posted by terrance11
Anyways, why is assembly important for game programming? My guess is just to help optimize code??? And is c or c++ more popular?

Yeah, for optimization mainly. C++ is generally more popular in game development than C, but it varies. Carmack is a big C programmer and that's one big exception, eh?

Originally posted by terrance11
And what type of knowledge do you need to know in physics?

Mostly you should have a very firm understanding of linear algebra (vectors, matrixes, etc.). Quaternions are a plus. Ray tracing as well. You need to understand simple things like gravity, etc. Collission detection is a bigee -- anything in real-life that you want to model you should understand fairly well, but it all depends on what type of development you're talking about. An AI programmer doesn't need to know the same stuff as someone working on graphics.

Anyways, I'm not the most experienced digipen student here, so someone might be able to tell you better. If you look around, you might find a sophmore in these boards, but I won't name names

The new engine carmack wrote (is writing) is in C++ (read in an interview with him). I've gotta admit I like C style coding (just throw everything into functions!) but object oriented design makes way more sense in games. The simplest projects go down the hole and become way too disorganized without it (in my opinion).

as poly said assembly's used when speed's an absolute necessity. The only example I can give is writing your own software renderers (making sure every pixel gets color, texture, correct intensities, etc, which no one does any more because of opengl and direct3d). Those routines need to be so incredibly fast because they are executed every frame on top of the high level code that makes up the actual application.

Lately I've had no motivation to even start on any projects. I've almost completed my first singly linked list project (yes, I know, been coding for a year now and only starting linked lists, I suck). I have also been looking in the .ms3d format (milkshape3d) which I will probably use for my models when my project gets underway. I'm just really afraid of hard work, but yet I desperately want to 'sign my soul away' and become absorbed in something.

EDIT:
Now that I'm on the subject poly, how do you read in your formats? Do you keep the file open for the duration of the routine linearly reading each piece of data, or do you read everything into a buffer and extract the data from there? I like the latter, I don't know why, they both seem to work fine, but being able to read everything into the buffer and close the damn file is more appealing.

I really hate formats, I really do. There's no official documentation on them anywhere, the only way to find out what's in them is to read code for loading them, and that is an awful way to find out what is in a particular format, poor shadow.

well i work part time (paid internship) at philips www.philips.com

my dad works there so he got me in
but its 9->5, i enjoy it since its really lax, i can talkt o people on aim and everything while doing work. they just give a project, and i can choose what lang to write it in (i combine vb and c++), and just get it to them by whatever time they want

Originally posted by Shadow12345
Now that I'm on the subject poly, how do you read in your formats? Do you keep the file open for the duration of the routine linearly reading each piece of data, or do you read everything into a buffer and extract the data from there? I like the latter, I don't know why, they both seem to work fine, but being able to read everything into the buffer and close the damn file is more appealing.

Yeah, you generally don't want to keep files open and you don't want to read from them as the program is running. Reading from the hard drive is ssslllloooowwww. You really have to load everything in once at the beginning and then close the file -- you want to put the data into objects anyways and that's kinda hard to do without loading it into memory.

14 hour days is stretching it. USA Today exagerated a lot in that article. Unless you're really entering with absolutely no programming experience it's NOT that bad. I just post in here all day for the most part and I'm doing pretty dam well to say the least

so basically its psudo-code written to find holes/flaws?

It's actual code, verifying something you promise in the concept. Example: You would like to have a listview where special lines are marked. First idea is make them red. I don't know if this is easily possible in MFC, and if I promise it in the concept and it doesn't work as easily as I thought it would and someone has to spent 2 days to write an adaption of the listview control just because I promised some lines will be red that would suck. So I create a sample project, and try to make every second line of the listview red. Assume coloring lines requires overloading the control, but making them bold is a build-in functionality. So I put the project in the bin and change the concept so the marked lines will be bold instead of red. No-one even saw the red-concept, no one can complain.
That's a fairly simple example. Maybe I have three algorithms and want to be sure that I chose the correct one for our proplem. Or I do a little speed test to verify my estimations for the program as a whole. Things like that. It's real code without the rest of the appliaction in the background. A snippet of the code to make sure a concept works.

Have any of you professional developers been required to read something along the lines of Code Complete? In my opinion that book should be a part of evey college course. There seems to be a huge difference between knowing the syntax of a language and being able to actually put those skills to use in a team of developers on a large scale project.

The only required reading is our coding and quality standards. As someone else mentioned, use the terms "coding standard" in Google and you will find a lot of examples.
Code Complete is great. So are "Algorithms in C++" and "The mythic man-month". Noone is required to read books, but you notice the difference between those who do and those who don't. Some things can be learned by experience, some things need a book or teacher to sink in.

With professionals, the syntax should never be a problem. If you use a tool ( compiler ) daily, the error messages are clear as normal spoken english, most of the time even better. Syntax is rarely something you spend time with conciously. It's like using a pen in a math test. Sure you need it, but writing itself is not what is difficult about a math test. The challenging part is program design, algorithms and logic.

There's always game development

Don't kid yourself. Game development is development with another target. Not more or less challenging than programming applications. There is a huge need of applications in the marketplace and only a small percentage of games. A game sells for 50$, a good application is sold in bundles for a couple of hundred $. The point is, you don't do the same thing every day in application development. If you did, your boss would fire you and hire someone who knows what "code reuse" and modularity mean. Likewise in game development. It's just another library to use. Development is always the same.