   Understanding Game Dev
  This is NOT a flame thread, I'm just VERY confused with game development in general.I have to question a bunch of things about games right now because the actual development and management side, I have no experience of, but I'm really lost in the dark on these specific things:1.) You build an entire game and engine from scratch. You have 20 programmers. It sells well and then you work on the sequel game. What are those 20 programmers doing during the sequel? You should already have the pipeline working for people to just make new guns and new art. I mean aside from a couple new features, and a couple new graphical features..? 2.) In the same scenerio as the above, I came across this post:  Job Post . In short its a company that has been around, but they need an animation engineer. 2 questions arise from this:a.) If you just released a game every 2 years for the past 10 years, then you already have animation in. There is nothing more you can do than have a bunch of bones and matrices, and some IK. I'm just confused on what they could want someone to do that they don't already have in.b.) How long does it really take to implement an animation system. Even with full IK, that should only take someone 2 weeks, give or take. And integrating it with physics maybe another 2 weeks.From personal experiences or guesses, I would like to hear.   
  1) Anything you program the first time is not programmed as well as it good be. In fact, in a deadline driven production environment, it's probably written like complete shit. There are lots of shortcuts people take to "get something out the door" and then realize "Wow, I don't ever want to deal with this again" when they go to make a sequel. Or, more innocently, it's "Wow, I can't believe I didn't think to do it [this much better way] back then".As for what your programmers are doing... they should be making a new game. Games are not engines, and no engine is perfectly tailored to every game. Technology is constantly changing and evolving. There are always things that need to be done. Sequels are generally more different than you give them credit for. If not, then you should be producing more games at once. (You should also feel ashamed at yourself for not doing anything new).2) a) So you're saying animation technology can never improve past some bones and IK? Animation is one of the most lacking areas in game development and possibly the biggest and most challenging area to tackle in terms of making believable, realistic characters. There's a hell of a lot one can do past bones and IK. Even if your game only needs bones and IK, you can still develop better tools for working with them that enable your artists to work more efficiently and to higher quality.b) That's genuinely hilarious. Oh man, you gotta come back and read your post again after you get some experience. You'll know what I mean.   ;Quote:Original post by dpadam450b.) How long does it really take to implement an animation system. Even with full IK, that should only take someone 2 weeks, give or take. And integrating it with physics maybe another 2 weeks.?!!An IK animation system combined with physics ? Make that 2 years instead for a single programmer. And that's probably not even enough.;  it's so easy a child thinks he can do it.   ;  Oh, and just to be a bit more productive here ;)Quote:Original post by dpadam450a.) If you just released a game every 2 years for the past 10 years, then you already have animation in. There is nothing more you can do than have a bunch of bones and matrices, and some IK. I'm just confused on what they could want someone to do that they don't already have in.Bones and matrices are just the very primitive basis of an animation system. That was state of the art many years ago. Things have advanced significantly since. Adaptive envelopes and muscles for more realistic deformations, simulation of skin sliding over muscles, deformable soft body physics, phoneme synchronized facial animation, procedural behaviour modeling, etc.Never heard of Euphoria ? That's a bit more advanced than some simple IK... For how long do you think they worked on this ?Technology in this domain advances at an astonishing rate.;  As other have pointed out, there is plenty to do for programmers:1) Refactoring old hacked code for better ease of use2) Performance optimization3) Adding new features4) Improving the pipeline (tools development)5) Writing new gameplay specific codeThose five things are all MASSIVE endeavors.   ;  Have you ever seen "The office"?There your answer.   ;  zer0wolf gives the best examples.  I'd like to add another one that is not that common, but is pretty damn hard and can take a long time to do properly:6) Converting a single player engine to a multiplayer engine.(This is what I've been doing at work for a few months now...)   ;  Yes I've heard of euphoria and seen the new Madden animation stuff. I can give all the credit to those guys. But looking at any FPS-like game or online MMO, it just seems like the same refactored animation, nothing really special."simulation of skin sliding over muscles"Is everybody doing that though? You play a game and a guy gets projected to a small area on the screen. Am I really going to notice skin sliding? I don't know, I haven't read up and investigated euphoria and all the new animation techniques. I can agree that you might look back and say that the code was written bad etc, but if you released an fps that runs on an internal engine, it's not like you need to write a model loader, a sound system, an entire new editor etc. I just don't see how the work doubles once you have your core engine done, instead of being cut in half.   ;Quote:Original post by dpadam450I just don't see how the work doubles once you have your core engine done, instead of being cut in half.Because now you're fixing the old engine (which contained hacks, bugs and workarounds) and authoring new features. This is true of all software development. Have you never completed a large project, particularly in a team environment? Then I guess you can't understand.I'd step out on a limb and say that the single most valuable document in software development of any kind is the specification. Unfortunately, it is often the single least defined document - in many cases it is wholly implicit, embodied in a series of emails between various people, diagrams strewn all over network drives (and a few post-it notes and/or napkins), and a smattering of bugs entered into the defect tracking system... if the non-developer staff even embrace defect tracking (seriously; don't get me started here). This means that the software ends up containing structural defects early that are worked around late to polish the turd that the software actually is enough to get it out the door.Sad, but depressingly true.   