Hey guys, I have a few quick questions about game programmers.
1. Firstly, do game programmers have any input in the creative side of game development? Like the story of the game, or how characters might look, anything like that?
2. Secondly, what makes a game programmers job different than your average software programmer? Is there anything specific?
3. Thirdly, if possible, can you explain what the average day of a game programmer is like? What are all the things a programmer does during an average work day?
Thanks.
Game Programming Questions
These questions belong in Breaking In. Vern, please check the forum FAQs.
Sorry for brief reply, I'm on the run.
Sorry for brief reply, I'm on the run.
-- Tom Sloper -- sloperama.com
These questions belong in Breaking In. Vern, please check the forum FAQs.
Sorry for brief reply, I'm on the run.
Okay, thanks.
1) Yes and no. Excluding very small studios, it's not in your job description, so "no" would be the answer. However, many studios do encourage the whole team to put forward their ideas regardless of their role, so the answer is also "yes", you will have a chance to help guide the direction of the game. There will be other people who's job is to design and concept though, and it's up to these people whether your ideas are heard or not.
2) You're working with artists and other creative people. You might interact with the "business" side of the business less than at other programming jobs. You're making a product with a shipping date -- other jobs don't always have the same concept of "milestones" that game projects will.
Technically, there's a broad range of skills involved, from low-latency networking, to database technology, to real-time global illumination. It's common to have the "sound guy" and the "graphics guy", etc within your programming team.
Even within the programming department, the staff can be quite multi-disciplinary. For example technical artists may in fact write code and also be highly proficient at using DCC software.
3) Team meeting (e.g. scrum). Make coffee. Read emails. Update from version control. Run content build system. Write code. Make coffee. Write code. Test code. Hang out in lunch room. Play Mashed/SF4/Starcraft. Update from version control. Fix merge conflicts. Check code in to version control. Send emails and write in the wiki. Make coffee. Write code. Update project tracker. Studio meeting. Drink beer. (last two are Fridays only )
2) You're working with artists and other creative people. You might interact with the "business" side of the business less than at other programming jobs. You're making a product with a shipping date -- other jobs don't always have the same concept of "milestones" that game projects will.
Technically, there's a broad range of skills involved, from low-latency networking, to database technology, to real-time global illumination. It's common to have the "sound guy" and the "graphics guy", etc within your programming team.
Even within the programming department, the staff can be quite multi-disciplinary. For example technical artists may in fact write code and also be highly proficient at using DCC software.
3) Team meeting (e.g. scrum). Make coffee. Read emails. Update from version control. Run content build system. Write code. Make coffee. Write code. Test code. Hang out in lunch room. Play Mashed/SF4/Starcraft. Update from version control. Fix merge conflicts. Check code in to version control. Send emails and write in the wiki. Make coffee. Write code. Update project tracker. Studio meeting. Drink beer. (last two are Fridays only )
. 22 Racing Series .
1. Firstly, do game programmers have any input in the creative side of game development? Like the story of the game, or how characters might look, anything like that?
To a limited degree yes. At least in the early stages many teams allow everyone to attend design meetings and give feedback. However, once development starts a programmers job is to write code. You will need to read and understand the design and contribute to the technical aspects of it (it is up to the programming team to decide how to implement a particular idea) but you wouldn't be writing the story or drawing concept art. That is what Designers and Artists are for.
Obviously they above is a general answer and there are exceptions. In small or single man studios there is a greater chance to work across disciplines but in the bulk of the industry roles are specialised.
Dan Marchant - Business Development Consultant
www.obscure.co.uk
www.obscure.co.uk
1) Yes and no...
2) You're working with artists and other creative people...
3) Team meeting (e.g. scrum)...
I shortened that for the purpose of this reply. Just wanted to say: Hodgman, very nice answer!
-- Tom Sloper -- sloperama.com
Hey guys, I have a few quick questions about game programmers.
1. Firstly, do game programmers have any input in the creative side of game development? Like the story of the game, or how characters might look, anything like that?
2. Secondly, what makes a game programmers job different than your average software programmer? Is there anything specific?
3. Thirdly, if possible, can you explain what the average day of a game programmer is like? What are all the things a programmer does during an average work day?
Thanks.
1. if you are a game programmer... NO, a game programmer only programs the game like the coding
2. yes there is anything specific. you are making a game thats one also you need to give a game acces to ram and last but not least you are freaking important, because you make movement and anumations
3. you go out of bed you take some food, go to work, programming a part of the game or telling others what to program (only if you are head programmer) and last you go to home and sleep till next day
beasides that you go to conferences, meetings and so on
regards,
As another detail...
Programmers implement the concepts as far as they are designed.
There is generally a lot of leeway in the design. Implementation details are generally vague. It's often a good thing because over-specification means they might add requirements that are unnecessary but add significant complexity.
Even when a design calls for something specific you can make a very persuasive argument by saying "You want feature X, but I want to implement feature Y instead." Good justifications include it is faster/easier to implement, or it will be less buggy/risky.
Programmers implement the concepts as far as they are designed.
There is generally a lot of leeway in the design. Implementation details are generally vague. It's often a good thing because over-specification means they might add requirements that are unnecessary but add significant complexity.
Even when a design calls for something specific you can make a very persuasive argument by saying "You want feature X, but I want to implement feature Y instead." Good justifications include it is faster/easier to implement, or it will be less buggy/risky.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement