Making games is hard k?

[Typhon]

Splitting this off because it's a plenty big enough topic to be a thread in its own right, and the SWG megathread doesn't really need any more bloat. - Samwise

Programming takes EFFORT, but is not hard.  There is a huge difference.  Digging ditches requires a lot of effort, but anyone can do it.  Programming is the same way, it's not hard, but it does require effort.

Have you ever led a team of programmers?  In my experience the difference in quantity, quality, and most importantly, maintainability of code between an average coder and a good coder is large.  Additionally, good coders will help find design flaws, bad coders will cause them to become infuriatingly hard to find.

if you give me shit for design, you'll get a shit product in return

If you worked in my team, and didn't open your mouth when you got a shit deisgn, I'd find myself another coder.  Then I'd look at what the designer produced and figure out if he needed to improve his documentation skills, or whether I need another designer.  I never provided a design that was so complete that it required no thought from the programmers.  If I have progammers that require that, I fire them and get programmers that have some desire to grow into a designer role.

None of this is true of ditch diggers.

[cevik]

I just tend to lump 'software design' and 'programming' together, if by programming you mean 'I have a detailed spec here, I'm mostly just translating it to C/C++/Java/Whatever from English' of course that it easy.  I've never worked on a project where I was only involved at that level.  The design is the hard part.  Of everything.

There is Design, Architecture and Implementation.  As I keep repeating, Implementation requires effort, but is easy (i.e. Implementation translates directly into man hours, but has little to do with talent).  Design is HARD, and Architecture is can either be easy or hard, depending on several factors (like design goals that include maintainability,  which increases the difficulty of the architectural goals, or a really good design can cut down on the architecture time).

Typically, from what I understand, game studios have a Designer and a Software Team.  The Designer is the guy in charge of creating the concept of the game, and that doesn't mean "Well, it will be a game with dragons, ohhh ohhh ohh and LAZERS.  DRAGONS WITH LAZERS!! PEW PEW PEW!!" which is typically what you get from a weekend of "ideas".  Design means stuff like "This skill will do 15% more damage, but if we crunch the numbers you'll see that the 15% less damage mitigation that class gets on a whole means the numbers equal out", etc.  And that is for the ENTIRE system.  If your designer sucks, you end up with lots of shit like mind damage that only one class can damage and no one can heal, ohh and it also counts as your action pool from which you draw to perform specials, so when you fight that one class that does damage to that bar you're taking double damage.  This is THE hardest part of any software project, but games probably take more effort here than any other software engineering job.  This should be the first phase of your game, but it probably will also be the phase which requires the most effort (you better have a fuckton of documents when you are done, spreadsheets, word docs, you should be able to fill up a small building with the design on a MMOG) AND talent (you must have the vision required to make this system, to balance this system, and most importantly, to make the system FUN).

Past the design phase, you architect the solution ("okay, the designer wants to be able to make a skill that makes you do 15% more damage, how do we write software that does that?  Do we make the software configurable, so that later he can make it do 18% more damage?  What about if he wants to have someone do 15% LESS damage?  What about if he wants someone to TAKE 15% more damage?  Are we over architecting or are these real customer needs?").  It requires effort, but the talent required can either be minimal ("the design says make a system that allows us to increase and/or decrease the damage inflicted, and increase and/or decrease the damage taken", that gives you a specific set of goals that is easy to architect to because you don't have to anticipate much) or the talent required can be vast ("LAZER DRAGONS!!! PEW PEW PEW!!!", where the fuck do you start with that?).

Finally comes implementation, which is cake.  And it's the only phase that involves programming (or coding or whatever you call it).  Though, obviously, the phases overlap.  You're ALWAYS in design (from now until you flip off the power switch on the last server), once you reach the architecture phase you'll ALWAYS be architecting, and once you reach the implementation phase, you'll ALWAYS be implementing.

[cevik]

Have you ever led a team of programmers?  In my experience the difference in quantity, quality, and most importantly, maintainability of code between an average coder and a good coder is large.  Additionally, good coders will help find design flaws, bad coders will cause them to become infuriatingly hard to find.

I should be leading one right now in fact, but it's a holiday week and I have tommorrow off, so I've been kinda lazy today.

EDIT:  Anyone can make a hamburger at Burger King.  But when I worked there in high school there were shitty buger flippers and good burger flippers.  The difference between the two had a lot less to do with the persons innate talent to create hamburgers, and had a lot to do with the individuals work ethic, training, and a variety of other mitigating factors.  Anyone can program, but programming requires effort, thus there will be "good programmers" and "bad programmers", but the difference between the two is not some innate talent, but the effort they put forth, their training, and their experience.

if you give me shit for design, you'll get a shit product in return

If you worked in my team, and didn't open your mouth when you got a shit deisgn, I'd find myself another coder.  Then I'd look at what the designer produced and figure out if he needed to improve his documentation skills, or whether I need another designer.  I never provided a design that was so complete that it required no thought from the programmers.  If I have progammers that require that, I fire them and get programmers that have some desire to grow into a designer role.

I can tell you why your orginization has systemic issues that seem almost unsolvable and make your life a living hell to the point that you hate waking up and going to work in the morning, if you like.

None of this is true of ditch diggers.

So you'd keep the ditch digger, who followed the instructions to the letter, but dug the ditch through your living room employed?  Would it be the designers fault for shitty ditch design, or would you also lay blame on the ditch digger for being pendantic and not questioning the obviously flawed orders?  Is it simple bias that you expect more out of your coders than out of your ditch diggers?  Are you saying that your coders are also the designers (this is true many places, I'm not arguing that the tasks have to be seperate people, I'm arguing that the tasks are seperate TASKs) thus they are responsible for the code AND the design?  In that case coding is still easy, but design is still hard, just because the person doing the design is the same person it doesn't mean that the individual tasks grow in complexity.

[Alkiera]

... Design, Architecture, and Implementation stuff ...

Yah, I tend to roll architecture and implementation together, they are often done by the same people, depending on the scale of the project.

I'd also argue that most MMOs have more than one designer.  Raph would know best, of course, but I believe he was the 'lead designer' on both UO and SWG, which would imply he lead someone, probably someones.  As you said, you need a TON of stuff don, it makes sense to divide the work somehow; with the lead designer in the position of making sure designs from all these people work together and are relatively balanced against one another.

I believe that what you call architecture can be art.  Implementation is just turning architecture into a language a compiler understands.  A good architecture can be a thing of beauty and elegance, a bad one is, well, yuck.

Is it bad that when you starting talking about DRAGONS WITH LAZERS!! PEW PEW PEW!! I immediately thought of that thread about Mourning?

Alkiera

[cevik]

... Design, Architecture, and Implementation stuff ...

Yah, I tend to roll architecture and implementation together, they are often done by the same people, depending on the scale of the project.

Most people do, I think it's very symbolic of the problems in the software engineering world today.  Once we realize that the tasks are seperate and need to be considered seperate (and thus need to be SCHEDULED seperately, even if the same person is doing it), then we'll see much better software in the world.  The places that put out really really really good software have already realized this fact.

I'd make the case that the Architect and the Programmer should NOT be the same person, but the world is not ready for that.. :(

[Typhon]

Are you saying that your coders are also the designers

I wouldn't say it that way.  I'd say that the coders need to take the high/mid level design, understand it, and complete the low level design while coding.

I'm not arguing that the tasks have to be separate people, I'm arguing that the tasks are separate TASKs

I'm arguing that separating the tasks of low-level design and coding is counter productive because there is an iterative loop that occurs within the coders head that includes low level design and coding.  You must have worked with coders that come back to you for every little decision that needs to be made within a module they are coding, that is counter productive.  What is important is that they meet the requirement of the module (api, interface, inputs/outputs, performance, etc).  If it was all just building blocks that needed to be put together, GUI tools + designers would be all that any software project needed.

Further, I'm arguing that discussing the two as if they are separate is counter productive because it leads people to believe that talented developers (coding + low level design) are not worth any more then average developers.

Unlike the task of digging a ditch, and deciding where the ditch needs to be dug, which can be separated with little additional overhead, and do not require complementary skill sets.  Civil engineers don't need to come up through the ranks as ditch diggers to know where to dig a ditch.  An Architect or Technical Lead who hasn't worked with the technology is useless.

[Merusk]

Having watched ditches, holes, pits, and tunnels being dug as part of my profession let me say this:  There's more to ditch digging than just getting a shovel and going at it, even if you have a plan to show you where to dig.

[Typhon]

I'd make the case that the Architect and the Programmer should NOT be the same person, but the world is not ready for that.. :(

I don't know about all industries, but in banking it's fairly common to have architecture and development as separate people, even separate groups (where I currently work uses this model).  I know that consulting services also tend to this model (IBM, Accenture).

It can generate a different problems - architects that are hands off tend to drift from technologies over time, and are less accountable for the failures (they are there to celebrated the successes, of course).  I guess that's why I'm a little nervous about my current job, over time I can see the same thing happening to me.

[Typhon]

There's more to ditch digging than just getting a shovel and going at it, even if you have a plan to show you where to dig.

No disrespect intended, I (perhaps incorrectly) was just trying to point out that in the case of ditch digging knowledge of how to dig a ditch is not necessarily intertwined with knowledge of where to place the ditch

[naum]

Most people do, I think it's very symbolic of the problems in the software engineering world today.  Once we realize that the tasks are seperate and need to be considered seperate (and thus need to be SCHEDULED seperately, even if the same person is doing it), then we'll see much better software in the world.  The places that put out really really really good software have already realized this fact.

I'd make the case that the Architect and the Programmer should NOT be the same person, but the world is not ready for that.. :(

No. We've already seen the results of this in the world of large systems programming, and it's been an abject failure.

Just look at the biggest success stories in the history of computer programming — invariably, it's a small passionate team, less than a dozen members, that outshine any other arrangement , be it the traditional waterfall approach where each stage of software development is compartmentalized, or some newfangled automatic managerial neverland dreamscape utopia that some code generation engine will instantly morph a system into a holy behemoth that satisfies the requirements of all. And a small dedicated team means the team members must be adept in many facets — from system administration to server management, from automated builds to automated testing.

And I do take offense at the crack that programming is just math. That's so superficial, programming is an art, a craft, just like writing, playing an instrument, your golf game, your athletic skill, acting skill, etc.… …some are blessed with an innate advantage, but ALL are capable if they (a) possess a burning desire to become proficient  and (b) dedicate long blocks of time to expanding their expertise in said area. No, not everyone can be at the pinnacle. But there is a magnitude between proficient programmer and average programmer that dwarfs any scale you could apply to a burger flipper or ditch digger. Good programmers outperform average programmers by factors of 10-100X or greater. I, in my 20+ year career of programming computing machines, have witnessed this firsthand — a team of programmers struggling for nearly a week to pinpoint a bug, and I stroll in and solve it in less than a few hours. And in the design/architecture phase, such differences may even be exponentially greater.

On creativity, anyone can hone their imagination and expand their "creativity quotient" — problem is many get locked into what they do and what they are that they never exercise those mental muscles. But it can be done. It goes for art and music too — there is a lady named Betty Edwards that can teach anyone how to draw… …I met someone once through some radio work I did that could instruct anyone to sing decently, etc.…

[eldaec]

That's so superficial, programming is an art, a craft, just like writing, playing an instrument, your golf game, your athletic skill, acting skill, etc.…

True, though that still doesn't make it the same thing as design.

Just look at the biggest success stories in the history of computer programming

Ok, lets do that...

Hmmm...

Not sure this is really helping.

Like in every walk of life, clever technique and new ways of working are best developed by small teams. Actual usable product ready for mass consumption needs a different approach, proper control, and proper project management. The innovation is always needed as the seed, but (at least in my book) you don't get to consider yourself a success until you actually changed customer behaviour and made a tool they can use (and until you can build those tools repeatedly), because until you did that, you didn't actually achieve anything.

A few people can do both, good for them, but I seriously doubt they'll be able to do what they've done repeatedly and without having to build more control and structure into their growing organisation.

On creativity, anyone can hone their imagination and expand their "creativity quotient" — problem is many get locked into what they do and what they are that they never exercise those mental muscles. But it can be done. It goes for art and music too — there is a lady named Betty Edwards that can teach anyone how to draw… …I met someone once through some radio work I did that could instruct anyone to sing decently, etc.…

Agree here, people need to realise that whatever your special skill is, it can be taught. (and conversely whatever skill you don't have, all it takes is interest and effort on your part)

Art can be practised and taught.

Design can be practised and taught.

Programming can be practised and taught.


Some people require more effort to learn specific skills, but I never met a person who couldn't pick up a skill they were sufficiently (a) interested in and (b) ready to work for.

It really is all about the grind in the end.

[heck]

O Noes!  Not a debate about creativity itself!

From a quick google, remembering what I learned in college centuries ago:

The Seven Intelligences
Intelligence is not fixed, but instead is a set of abilities and skills. This is why someone may excel in one situation, while having great difficulty with another. Intelligence develops, and can be improved by learning to make the most of your natural abilities. Consciously making use of your full range of intelligences leads to well-balanced learning while promoting creativity and new ways of thinking.

Howard Gardner separated human ability into seven groups based on cognitive-contextual intelligence theory. The abilities are collectively referred to as the Seven Intelligences:

Physical: sports, car maintenance, do-it-yourself projects, woodworking, crafts, cooking.
Linguistic: verbal arguments, crossword puzzles, riddles, research, poetry, writing, giving instructions.
Mathematical/Logical: budgeting, planning, calculations, estimating quantities, time management, math, sciences.
Visual/Spatial: map reading/navigation, using diagrams/plans, driving, art, dressmaking, model layouts.
Musical: playing music, repeating songs, rhythm, recognizing tunes, moving in time to music, remembering slogans&verses.
Inter-Personal: listening, committee work, supervising others, parenting, teaching, consoling, training others.
Intra-Personal: keeping a diary/journal, time management, planning and organization, understanding your emotions, goal setting.

You can't teach an engineer to be creative.  Humans simply don't live that long.  And you can't teach an artist to make money.  There are always exceptions to the rule, but c'mon.

[Samwise]

I'd argue that an engineer without any creativity is a pretty goddamned shitty engineer.  Which of those seven intelligences is engineering?  Which is creativity?  And why are they mutually exclusive?

[Raph]

On SWG at peak, there was a creative director (me), a lead systems designer, a lead content designer, and 30 designers under them, split between two teams. A dozen of those were "apprentices" which means they were novices at content design.

Creative director is roughly analogous to the code architect you describe, but for the design. Specs for systems get written, not detailed designs. That gets split up across the system designers. (I did do a few detailed system designs, but not a ton). Content design is similar, though I did basically no architecting on that (save for the Warren).

This all varies significantly from team to team, but suffice to say that the projects are so big that it's hard for anyone to pay close attention to every aspect of the design, much less the project as a whole.

[Margalis]

There is Design, Architecture and Implementation.  As I keep repeating, Implementation requires effort, but is easy (i.e. Implementation translates directly into man hours, but has little to do with talent).  Design is HARD, and Architecture is can either be easy or hard, depending on several factors (like design goals that include maintainability,  which increases the difficulty of the architectural goals, or a really good design can cut down on the architecture time).

That's not true at all. Man hours are basically a myth - they aren't a measure of anything. One hour of some people's time is worth literally 100x someone else's time. If implementation is not hard, why do so many software projects have major implementation problems?

Nothing translates directly into man hours, because man hours are a figment of middle-manager imagination. Software imeplementation is pretty damn hard, especially in MMORPGs.

[Margalis]

Anyone can program, but programming requires effort, thus there will be "good programmers" and "bad programmers", but the difference between the two is not some innate talent, but the effort they put forth, their training, and their experience.

Again this is totally wrong. Effort and programming quality are virtually unrelated. Are you speaking from experience?

Obviously effort, training and experience matters, but there are very much good programmers and bad programmers. One study someone ran showed that if you give a bunch of students an assignment, there was ZERO correlation between time spent and quality. Some people can do twice the job in quarter the time, and that is very much innate talent.

It's well known in the computer industry that a programming "superstar" is worth nearly an entire team of average guys. In programming the difference between decent and extraordinary is humongous. Just adding more resources, more man hours or more bodies often is counter-productive.

[Margalis]

On SWG at peak, there was a creative director (me), a lead systems designer, a lead content designer, and 30 designers under them, split between two teams. A dozen of those were "apprentices" which means they were novices at content design.

Creative director is roughly analogous to the code architect you describe, but for the design. Specs for systems get written, not detailed designs. That gets split up across the system designers. (I did do a few detailed system designs, but not a ton). Content design is similar, though I did basically no architecting on that (save for the Warren).

This all varies significantly from team to team, but suffice to say that the projects are so big that it's hard for anyone to pay close attention to every aspect of the design, much less the project as a whole.

Content design and system design are quite different. It seems to me that a project should have many more content designers than system designers. What was the approximate split?

[Evangolis]

Perhaps I am misreading things here, but I think that there is a real disconnect between coding for modern games and other sorts of coding in other fields.  I have some experience coding small hard coded systems and data driven code drivers for small business, and the process is rather different from the process for making modern games as I understand it, based on discussions with game professionals, books by the same, and a very small amount of experience.

As I understand it, most code is segregated into the 'game engine', which is one focus of game programmers.  A second focus is 'design tools', which are what game designers use to format their content so that it is usable by the engine.  Thus programmers have little connection to game design, per se; programmers simply build an engine which ideally would have a maximally transparent interface for the data input by the game designer.  Ideally, this means that your programming tasks can be done by programming stars, and will be largely re-usable between projects; while your game design tasks can be done by skilled designers, who have a strong grasp of design skills like lighting, use of art assets, narrative, and so forth, and who are focused on a subset of the specific game they are working on.

The best analogy I can think of in the business world is web design, where people trained graphic artists and marketers can use software tools like DreamWeaver to create web pages with minimal real programming expertise.

But perhaps I'm wrong, or perhaps just not understanding the discussion.

[heck]

I'd argue that an engineer without any creativity is a pretty goddamned shitty engineer.  Which of those seven intelligences is engineering?  Which is creativity?  And why are they mutually exclusive?

Welp, my post was a reaction to the SWG thread as a whole.  Over a thousand posts, each figuratively ending in "case closed".  Like a judge is going to whack the gavel every time someone hits submit.  I thought the 7 intelligences idea might help steer away from that.  Heh.

The 7 intelligences aren't mutually exclusive, they're on a spectrum like everything else, and they aren't meant to be a definitive problem solver to all of life's mysteries.  Sometimes ya gotta keep the question going for as long as possible before even pretending to come to any conclusion.  Sandbox games might always fail, crafting might always suck, moisture farming and entertaining might be retarded...but maybe not.  It might be possible for every human to be a math genius, a fine artist, and a shrewd business person all in one, with the proper cultivation...hey who knows.  Maybe this whole artist/patron model is a millenia-old sham.

Engineers: bad example.  Engineering is creating.  Hasty post.  Carry on.

[StGabe]

Here's an opinion from a game programmer, albeit one who works on projects with much smaller teams.

There are lots of kinds of programming.  And lots important attributes which define "good" programs and good programming.  If you take experience from the world of web applications or other realms and try to apply it to game programming, I think you will make many errors.

There is a large field of programming problems which are well-known, well-understood, well-taught and for which programming is more an effort of knowledge and effort than an effort of creativity.  Most of game programming is not within that field.  Some game programming is standard client/server stuff, standard database stuff, etc., but then there's a lot of other stuff: creating the lighting model, creating the design tools that designers use to make a world, hacking code to be efficient, etc.  And a lot of that is stuff that takes a lot more than know-how, a good work ethic and time.  There is a lot of creativity in game programming and the results of that creativity will greatly expand or limit where the designers can take their game.

Programming well for games, products that have huge sets of use cases and are allowed very few, if any, bugs, also means that you must be extremely good at understanding what you are implementing and forecasting for future problems.  Not only that, but the amount of change that a project can go through means that good programming will create solutions that can adapt for solving problems other than those indicated in the original specification.  "Effort" programming just means getting from A to B in whatever manner possible.  Good game programming means creating robust, modular solutions that are easily modified, understood and maintained.  Ideally any code should be like that, in games it is just a lot more important.  Problems creating by "average" coders can snowball into huge wastes of time very easily.  More importantly, very good programmers can do a lot in very little time and you can run a much tighter and vastly more effective team if you have a very talented group, meaning that you remove many of the large-project nightmares that will otherwise creep in.

I've seen skilled programmers that could "effort" there way through a lot of standard projects and yet couldn't program games at all.  I've also noticed that there are a lot of programming projects that can be (relatively) easily out-sourced to teams in other countries.  Teams which offer lots of cheap man-hours but are lacking in skill/talent (those with skill and talent get better jobs). In my experience, out-sourced game programming is almost always completely awful and ends up creating not only poor products, but costing a lot more after requiring huge management overhead and extensive delays.  Which further corroborates to me that there is a lot more than effort that goes into game programming.  I also haven't any successful game programmers who weren't quite bright.  Not to toot my own horn or anything.

I'm sure that larger projects have room for *some* programmers that aren't terribly skilled.  But generally I think you'll find that, yes, programming games is definitely very hard.  As is designing good games and creating high-quality art for games.  It's nice to sit around and kibbitz about how it should be easy to fix problems in a given game, design a better game, etc., but this tends not to happen as often as we'd like because, among other things, it's just very, very difficult to do.

[Roac]

From someone who is an architect / lead dev:

Yes, design, architecture, and implementation are seperate, or at least had better be if you know what's good for you.  They also tend to be iterative, and by necessity overlap to some extent.  I don't mean with the same person (but can, depending on project size/scope), but the idealistic scenario of never revisiting a design once you've moved into implementation isn't always reality. 

Far as comparing regular devs to ditch diggers though - you're off.  It is not that simple a task, since there are plenty of bad developers out there and it's a task not many can do well.  This is beyond a training issue; there are people who cannot grasp the concepts, the abstraction, or the math to perform well.  No matter how well your design specs are, there are programmers who can screw them up.  Watch as a malformed loop will destroy performance, for example. 

Unless, maybe, your design specs go beyond class diagrams etc, to the point of pseudeocode - at which point, what the hell are you doing?  That's the purpose of having devs.  If they are thinking for themselves somewhat, even in classes, then they are contributing to design even if in a minor way, and they'd better be aware of what that means.  If you're handing them pseudocode, I promise you can cut costs by doubling your dev salaries and hiring good people. 

And speaking from experience, some of the devs working for me who I've inherited lack creativity.  They aspire to be the "ditch diggers" referred to.  They do nothing but drag me and my team down - they won't last much longer as a result.  Even a junior dev needs enough insight and creativity to ask questions and grapple with abstract concepts.  I agree with Typhon's first post - if you see that the "design is shit" (hopefully, since I'm the designer where I work, that just means "a small problem with the design") and keep quiet, you're in trouble.  There are bound to be flaws in the design just as there are bound to be bugs in code, but they are things that need a lot of (intelligent) eyes to be hammered out.  I can't imagine a team where one architect passes out design From On High (tm) for unthinking minions to impliment, and have the project get pulled off to any respectable degree.  Maybe on a very small project, with a very good lead. 

[Glazius]

So, if programming is basically math, then is there the equivalent of the elegant proof?

Yeah, I know Wikipedia is a terribly unreliable source, but:

Mathematicians describe an especially pleasing method of proof as elegant. Depending on context, this may mean:

• A proof that uses a minimum of additional assumptions or previous results.
• A proof that derives a result in a surprising way from an apparently unrelated theorem or collection of theorems.
• A proof that is based on new and original insights.
• A method of proof that can be easily generalised to solve a family of similar problems.

In the search for an elegant proof, mathematicians often look for different independent ways to prove a result — the first proof that is found may not be the best. The theorem for which the greatest number of different proofs have been discovered is possibly Pythagoras' theorem. Another theorem that has been proved in many different ways is the theorem of quadratic reciprocity — Carl Friedrich Gauss alone published eight different proofs of this theorem.

Conversely, results that are logically correct but involve laborious calculations, over-elaborate methods or very conventional approaches are not usually considered to be elegant, and may be called ugly or clumsy.

In just about every field of human endeavor, there's a difference between elegance and competence.

--GF

[Roac]

So, if programming is basically math, then is there the equivalent of the elegant proof?

Yes, a similar concept.  Not a proof, but there is the notion of elegant solutions or elegant code which fits in with the conepts mentioned; it's simple, easily understood, and flexible.  It's also true in coding that there are usually numerous solutions to a problem (alternately, ways to design a class/function), and more than one may be considered elegant; the right choice is the one which best balances tradeoffs, with a classic one being memory vs CPU.  A large portion of the "creativity" in programming is being able to see through these issues in abstract, and pick from them.  Mathmatical prowess is required to make the abstract concrete. 

[Venkman]

Even beyond design and development though, there's the question of the larger team. Complex though actual execution is, it is infinitely more complex to manage that with a bunch of people with completely different agendas.

I personally find that very few things constitute "fact". There's a bunch of considered opinions only, making it harder for people shy about decisions to make good ones. The amount of delays this causes can't be understated. The needs of a cross-disciplinary developer/publisher relationship probably impacts the execution of an experience more than the technical capabilities of the people doing the actual work.

Not to marginalize the execution of course. I just thought the above fit into the whole "making games is hard" part.

[Margalis]

You know, programming is a lot like math. But, what people don't realize is that high-level math is very much an innate skill, and a high level math mind will absolutely smoke 100 pretty good math people. Math is often considered a discipline for the young, because training and experience end up being mostly irrelevant. If you aren't a math genius by age 14 you will never be one. That's certainly an over-simplification but there is a lot of truth there. Most of the important experience you get in math happens before age 6.

As Gabe pointed out, there certainly are programming tasks that are repeatable and well-understood enough for any semi-competent programmer to write, if you don't care all that much about upgradeability and performance and things like that. Game programming is open ended - and it SHOULD be. Anyone who creates a detailed enough spec for ditch-diggers to implement is wasting time. Making games simply does not work like that.

That kind of process works for doing something like creating space shuttles where the mission is very well understood. In making a game the parameters are constantly changing - and that it itself is NOT an indication of poor design. You wouldn't take a writer to task for not following their original outline to the T, and some don't even bother with outlines at all. Same deal here.

One of the most important things about game design people just don't understand is it's better to simply leave out stuff you don't know, rather than make shitty guesses. There is no point in putting a bunch of items in your initial doc. A healing potion costs 300 gold and heals 200 hp. There is a 99% chance that will be totally wrong.

[Raph]

Content design and system design are quite different. It seems to me that a project should have many more content designers than system designers. What was the approximate split?

Almost all of those folks were content designers, including all the apprentices. There were, lemme count and try to remember here... maybe a half dozen systems designers.

[Typhon]

Took me a couple of days to figure out that f13 wasn't broken, just the thread got split.  Can't slip things past me... forever!

Only thing I wanted to add is the following babble in response to "programming is math":

I've used math (algebra, trig, differential equations, small amount of group theory, non-linear methods), but I've never done math (create new formula's, groups, etc).  I've done programming.  I've used math in programming (statistical analysis).  Programming is easier then doing math, programming is more creative then using math.  The statement, "Programming is math", loses sight of the creativity that is required in programming and the yawning gulf of infinite possibility that is incorporated in "math".

An elegant mathematical proof is one which encapsulates a complex set of ideas in the least number of equations.  An elegant program is one which brings into harmony the demands and capabilities of the language(s), system(s) and users of the program.

Once you add human consumption into the mix, you've added the possibility for art.

[StGabe]

Well as a programmer and former mathematician: programming is like math.  But there are differences and there is no 1-1 correspondence.

There is fairly routine math, that we learn in high school, and can apply using by rote.  Similarly there is fairly routine programming: we can almost all write a loot to print the contents of an array.  Then there is fairly deep stuff which takes creativity and insight.  And the routine stuff gets mingled in with the insightful stuff: you may use algebra in a fairly deep proof and you may use a for loop over an array in a fairly deep program.

In general, a mathematical proof and a program have a lot in common.  The conclusion of a proof is basically the specification of a programming problem.  In both cases, you have a grammar or calculus of possible rules to use.  In math these are axioms, such as the 5 core axioms of Euclidean geometry.   In programming these are programming constructs: if/then/else, for, while, assignment, functions, classes, etc.  Solving a math problem, or solving a a programming problem both involve arranging these symbols into some string where: each symbol is legally placed according to the rules of the system and the set of strings leads to the proper conclusion/specification.

Basically, both are large, complex logic problems.  Or, said differently: both are about problem solving.  Mathematics tends to have more varied and complex axioms.  Euclidean eometry can be defined by 5 axioms but to do interesting geometry work including such stuff as trigonometry, you really need to know dozens of theorems (although I guess  arguably to do interesting programming work you need to know dozens of algorithms which are somewhat analogous to theorems).  Programming tends to be a lot more extensive.  I create tens of thousands of lines of code myself for some projects.  Most proofs can be completed in at most several dozen steps of proof and can often be expressed in less than 10 steps if one condenses some logical steps.

There are some similarities in what makes a proof "elegant" and what makes for good code.  Good code should be easy to read.  It should be extensible to other problems, perhaps even those that have not been thought of.  It should be easily maintainable.  Proofs don't need to be maintained.  But an elegant proof should show some insight into the problem at hand.  It may be relatively short.  It may or may not matter if it is easy to read.    It may use lemmas that make clear certain other properties of the system or that may be reusable for other problems.  Much code is good in the same way that a mathematical proof is good: it makes clear and uses some principle that shows insight into the nature of the whole system.  Generally I would say that code needs to be more refined than proofs.  There tend to be more ways to program a given problem than there are proofs to a given mathematical program.  And it can be incredibly critical that code be of a certain efficiency, i.e. able to draw at X frames per second, able to communicate to the server in Y milliseconds, etc.  And whereas mathematical proof often involves only the invocation of laws of logic, programming is often about juggling constraints.  I.e. it is often impossible to reach a given problem specification, or a problem specification may be open-ended (i.e. do something "as fast as possible") and it is up to the programmer to determine what compromises to make in order to ensure the best possible performance and adherance to the desired specification.

Programming often involves the use of mathematics as well.  For example, creating a physics system is going to require understanding and using a lot of fairly complex mathematics.  But a lot of the challenge, even in that, is of a nature different than the core physics/math.  Having the correct equations is important, but often the hardest challenge is figuring out how to iterate the physical system gven that everything runs digitally through time steps, leading to problems such as collision detection.  Also, physical systems are often too large to calculate entirely in real-time and then the problem becomes one of determining how best to approximate the system so as to capture the spirit of the physical system and yet run under the constraints of your target system.

[sarius]

... Design, Architecture, and Implementation stuff ...

Yah, I tend to roll architecture and implementation together, they are often done by the same people, depending on the scale of the project.

Most people do, I think it's very symbolic of the problems in the software engineering world today.  Once we realize that the tasks are seperate and need to be considered seperate (and thus need to be SCHEDULED seperately, even if the same person is doing it), then we'll see much better software in the world.  The places that put out really really really good software have already realized this fact.

I'd make the case that the Architect and the Programmer should NOT be the same person, but the world is not ready for that.. :(

A truer statement could not be more evident. 

Coming from the world of government communications systems, our team is constantly bogged down in problem solving and implementation by the fact that our systems architect is also the overall development team manager at his contracting company.  Decisions are made as politcally beneficial to the source company far before the project health and implementation comes into play.  At least 5 times this past year he went away on a weekend unable to comprehend a technology (and especially a technology's history within a specific implementation), only to reappear on Monday with implementation directives that could be a mirror of the "MS Best Practices" paragraphs from their knowledge base.

I can't imagine that the management and delivery problems differ between the industries due to much of the same pitfalls.  Of course, this shortcut is pretty common in government circles.  Two day design cuts turn into four year projects.  They wouldn't take four years if the design/programming positions were separated in a much clearer fashion.  I don't believe a person can fill the two roles effectively, even if they allocate conceptual brainstorming to a specific function.