Programming: A Necessary Evil for Amateur Game Designers?
What I'd like to ask is, "How do amateur game designers who don't know how to program and are not backed by a programming team, and who never get to see their ideas implemented a) find satisfaction or b) get better?"
I can see some of the satisfaction of brainstorming game design ideas that are never implemented. But, isn't there some frustration in not being able to see whether your ideas are actually succeeding or not? Which leads to the second part of the question: If you can't see your ideas in action, how can you ever know if they are "good" or not and learn what you need to improve? Also, how can you know what details your design is missing if you never get to see them implemented?
As a programmer and game designer, I can think of hundreds of things that I did not think about during design phase but was forced to think about during implementation. Every designer faces this (or else, after designers wrote design docs and implementation began, designers would simply leave the team. However, it doesn't work that way: designers have to stay to answer unforseen questions.)
So in the end, what I'm asking is: 1) Is it possible for game designers to get true practice and skills in game design without experiencing some implementation and going through the implementation process? And what I'm advocating is: 2) Perhaps anyone who's thinking about becoming a Game Designer should invest a year or two in learning some simple programming languages (Visual Basic, Dark Basic, etc.) which will allow them to implement their ideas and truly begin to understand Game Design. I also now understand why 3) Most game companies never hire "game designers" unless they have proven track records as either testers, programmers, or some other non-game design entry level position. Only through testing or programming can game designers begin to truly grasp what is needed for game design. Another idea is: 4) offer a course in game design that runs concurrently with a game programming course. The game designers write the specs, the programmers implement, the designers learn about details they failed to spec or understand (and learn if their design ideas were actually good or not.) A final idea is: 5) Can we get former game designers to review amateur game designer's ideas? Get people with experience to critique what others are doing wrong? Perhaps former game designers will become professors in the future... 6) Perhaps, if more aspiring game designers knew how to program, they could implement, by themselves, some of the more wacky ideas that game designers have. These would serve as proof of concepts that the ideas are good (or bad), making it easier for the designer to sell the idea and putting more pressure on the industry to be creative!
The idea for this thread came from another thread: http://www.igda.org/Forums/showthread.php?threadid=6563&goto=newpost.
as an apprentice i think getting some knowledge from different area, is good to become a good game designer, whithout learning i couldn't get some design issue i resolve whith knowing procedural in programmation
seeing the game running help a lot because even if you can emulate things in your brain, the emulation is a kind of 'too perfect', the implementation leads to some error which can give a full free thinking brain more idea to ameliorate the concept in adapting these error into concept and broaden the gameplay.
i've seen many game which were to well build and lack of these little details you see in experimentation.
well i use to get some experiment by let some portion of the game running (only battle, only move) and that which happen is that there are like little game which we begin to ameliorate (move only become fun without anything else for example), it's also kno as the 'miyamoto complex' design (i've seen many people playing zelda only to cut herb or only to use the horse or to wandering aimlessy in mario 64, because these move are fun by themselves)
i use any kind of program to experiment some kind of gameplay, even those which the purpose is not to do these kind of things (the fill tool in 2D drawing software)
my religion is design and the god is fun, whatever is the restriction :p
Warden --
I agree with you completely! I actually posted somewhere else about the ability to have "game making" be an automatic or commoditized process. Basically, you write a document, you give it to a "game making" company/factory and after X weeks, they spit out the finished game.
For this to work, there must be a standardized language to describe the game so that there would be no "subjectivity" in the process of implementing a game. The idea is to make the game design be exactly equivalent to the implementation, with no extra interpretation needed. This would make game design ideas worth actual money, because it would be a known quantity to translate these ideas directly into funcitoning games.
In a sense, this problem of creating a standardized language to describe interactions has already been solved: It's called C++. Or Java, or C#, or any other programming language. Each programming language is objectively constructed and can describe and implement almost any imaginable game. So, in a twisted sense, a game's code can be viewed as a perfectly explained game design document!
And, of course, any CS major will tell you that a crude finite state machine can describe everything that a computer can do... so there has to be some measure of making the language easy for programmers/designers. (Thus, while a state machine can describe everything perfectly, it is not a good choice for the universal game design language.)
So, obviously, the question becomes "Can we come up with a higher level language to describe interactions?" But then you come across another problem. The higher level the language, the less flexibility the designer has. For example, some would argue that the Aurora Toolset that comes with NWN is high level RPG description language -- however, the language would not work well to describe a First Person Shooter.
You may want to check out Second Life. In SL, every subscriber can create objects in the world. The object scripting language is a state machine that also has higher level 3D commands. (Actually, my game at societygames.com also runs off of a very similar state machine with high level commands concept. The essence of the language is state driven, but you have commands like "Show animation." The help doc explains the language and you can see some of the scripts that are included as samples. Unfortunately, the program is not nearly complete and probably never will be completed.)
Warden, I'm sure you've thought about this much more deeply than I have. I would love to see your thesis if you have a draft...
Having some sort of high level language is a good idea. A more low tech idea would be to prototype your design in a board game. However, board games dont always translate well into computer games. At least you would have some idea.
I'd love to see some sort of collection of genre-specific middleware. In particular, I'd like to see a C++ library specifically created for making RPGs, and another one specifically created for making racing games, and so on. Middleware is how you would solve most of the problems mentioned - but it is very costly to develop. On the other hand, you could make such a huge amount of money selling RPG middleware to indie developers 
You could probably get $100 to $300 for each package... perhaps even more for professional versions of the packages.
It's all about middleware - the only thing that can keep indies at all competitive, IMO.
one problem to teach game design maybe a common language, we must find a conventionnal talk for everything in game , because the game world looks more like babel tower than anything else, there is many discussion which end or stop a while because we don't know if nonlinear, multilinear, agency,is the perfect word, we just need convention not conviction (even a correct definition of video game is fuzzy, because game exist without video we much find what is very specific to video games)
Every day I fume about some idea that I have that I cannot implement. Sometimes it's because the programming involved is way over my extremely limited abilities, but also there is the problem of art and other talent.
Sometimes my ideas are for board games or card games, and those I am able to test out without the aid of computer programming. However, this kind of work doesn't really seem to grant any credit.
I did an ASCII-based game for a project at DigiPen. After the game was turned in, I took the source code and continued to mess around with it. I tried out new features, tweaked some of the numbers, and got rid of things that weren't really any fun. Meanwhile, I was reading articles on magicthegathering.com, especially those written by Mark Rosewater (which directly address game design).
As you analyze specific details of a game and understand the player's reaction to them, you get a feeling for what you should do more and what you should do less. A game designer is really a lot like an entertainer. You have to understand the audience and please them. Not everyone is a good entertainer, but for those that have the mindset required, there should be opportunities for them to refine their talents.
If you could just send a game in and have somebody make it, that'd be great. However, I think to narrow things down a little (and make it more interesting), you could make it into a contest. For example, every month/year/decade/whatever, aspiring game designers send in their ideas and then people get to vote on which idea they'd like to see become a game.
Rapid prototyping for software is hard -- there's no duck tape equivalent in programming. You can't just pick up a bunch of approximately good enough pieces and build a quick prototype because program run, or they don't.
However, that doesn't mean it's impossible. To make prototyping easier, we must be willing to let go so key aspects (because it wouldn't be a prototype, nor be rapid, otherwise). What can be let go? I'd say stability, reusability, beauty and scope.
Not making stability a requirement means that you don't care much about bugs, so it increases a programmer's productivity. If it doesn't matter if the end result crashes every 15 minutes, then the programmer can concentrate on putting in features rather than on QA.
If you don't care about reusability, then you can code using whatever language is the most appropriate for the task. You could use Visual Basic or HTML for an interface mock-up, even if the finished game will only use C++ for example. Not caring about reusability also means making quick and dirty code that does not follow "good" computer science principles. Again, it makes it all quicker but you have to rewrite in the future.
When beauty is optionnal then any programmer-art icons will do in the place of important components. Not involving artists in the prototype only speeds things up (if only because less people means less communications needed and, hence, less time spent communicating). Also you save some time on animations and other pretty stuff.
Finally, when I say you shouldn't care about scope I mean you shouldn't prototype everything in the game -- just a part of it. Prototyping a whole project wouldn't be much less work than doing it right in the first place, but if you just prototype, say, the movement system then you can learn about this without the complexity of everything else.
What's the point of such a prototype? To fail early. To know quickly what the obvious flaws in the design are before they cost a lot to correct. I've heard the saying that "You must fail your way to success" and it's very true: we learn from our mistakes, so if we can make it so mistakes don't cost much to make then we can make more mistakes and learn more from them.
Of course, this still requires designers to know how to code or to have a coder available. I think that's like film directors needing to be able to use a camera, pretty much inevitable... The prototypes you make don't end up allowing a game designer to make a big game alone, but that unavoidable: if we found a way to make big games quicker then the definition of what a big game is would just move.
This is my first post in this forum, I'm a 25 italian Industial Design college student close to graduation, and want to share my (very) little experience.
Actually I'm working (as stagist - no payoff - close to change this) as game designer at a multiplayer mobile game in a sw house that have absolutely no experience in entertainment.
What is the point? Communication with the developing team! I have experience in programming, wich it means NOT that I'm goint to code and test my ideas, but simply that I KNOW if an idea that I have could be implemented or not - and HOW.
What I think a designer must have, is not knowledge on C++ or any other languare sintax, but at least knowledge of of how a software (anc a computer!) works at high and low level
By knowing such, when interaction is implemented in code, it will work exactly as you have planned and as you have figured out in your mind! There is no need to see things moving on the screen, you should see if an idea you have is working just by plotting it on a diagram on paper. This means theory, not pratice in programming, that is a much different thing. I know lot of people that knows all the secrets of java coding but have no clue on how to implement a tetris game, for example!
JhinAlexander talks about a need of a high level desgners'language. If you mean a language to tell how things should look in the game, well, use natural language and everybody will understand you (if not you have to perform your writing skills).
If you mean a very-high level implementation of your ideas, then you should learn to write use-cases (the top level of UML), that is enought to tell a programmer what is EXACTLY have to do.
But, for this, you need some programmers knowledge
If you mean a very-high level implementation of your ideas, then you should learn to write use-cases (the top level of UML), that is enought to tell a programmer what is EXACTLY have to do.
But, for this, you need some programmers knowledge
well it's what i've attempt to do but there is some problem, a lot of programmer don't like someone tells him EXACTLY what to do, i've gotten problem with that because it's a kind of saying them they are stupid, do what i say.
even if it's not youre intention, the best idea is to come in thought with them and sharing idea before got where u want, but in order to be take seriously you have to be a programmer yourself and show you merits.... which turn to be the same as Jhinalexander sez
i recommand STRONGLY to gamedesigner to get a little in programmation, it's a serious joker
Originally posted by neoshaman
lot of programmer don't like someone tells him EXACTLY what to do, i've gotten problem with that because it's a kind of saying them they are stupid, do what i say.
even if it's not youre intention, the best idea is to come in thought with them and sharing idea before got where u want,
My experience in game design is limited to this project I'm actually working on, and here my task is to tell programmers what to do exactly- but looking around it seems to be not a common way to work.
I recently asked Tom Sloper about this in his own bullettin board, so check his answer for an expert point of view. Link here:
http://www.sloperama.com/advice/bulletinbd.htm
thanks i'll check this board too
Originally posted by Lukino
What I think a designer must have, is not knowledge on C++ or any other languare sintax, but at least knowledge of of how a software (anc a computer!) works at high and low level
By knowing such, when interaction is implemented in code, it will work exactly as you have planned and as you have figured out in your mind! There is no need to see things moving on the screen, you should see if an idea you have is working just by plotting it on a diagram on paper. I don't think this is true for any but the simplest games. The ideas in your mind often depend upon assumptions which don't really hold, or they exclude unforseen patterns of undesired behavior. The images in your mind are less concrete than a running implementation, and even professional designers find that certain features do not work as expected once they're implemented.
A relevant quote from A.A. Milne, which I think applies to all bears and not only those of "very little brain": "Sometimes, when you are a Bear of Very Little Brain, and you Think of Things, you find sometimes that a Thing which seemed very Thingish inside you is quite different when it gets out into the open and has other people looking at it."
Prototypes are useful because they let you test new approaches to a problem, commit to effective solutions and rule out ineffective approaches early on. The cost of correcting omissions and fixing mistakes in the middle of a project is often greater than the cost of prototyping, and quality suffers due to temporal and monetary constraints.
Originally posted by Adrian Lopez
I don't think this is true for any but the simplest games. The ideas in your mind often depend upon assumptions which don't really hold, or they exclude unforseen patterns of undesired behavior. The images in your mind are less concrete than a running implementation, and even professional designers find that certain features do not work as expected once they're implemented.
[/B]
You are right, I was too confident in writing that thigns will run as in your mind...
But I also talked about paper. I have a high school grade as programmer, and worked as programmer not in videogames, but in multimedia production too.
Now, it is clear to all that nothing is like the implemented idea, even in a prototype, but my point is: If you know how to implement an idea, and you can make clear documentation on it, then coding it is nothing more than bug-fixing.
Another sure thing is that one person alone could not implement everything in a VG, but if you are experienced as programmer (that is the point of the topic here) it will be much easier to share your ideas with people who have to work on it, and easier for your team to help you to figure out how you ideas will work, so you might eventually be able to find weakponts even before a working prototype is implmented.
This might be not the top designers quality, but it sure can help, don't you think?
Granted, an understanding of the techincal never hurts. However, if my discreet math course has taught me anything this semester, it's that natural language is extremely ambiguous, and isn't easily read or used. This is why notations exist for software specifications and software design (the most prevalent of which being UML), to resolve the ambiguity of language, and also to allow people to quickly and easily locate information they need. In this way, trained software designers can quickly locate design problems before the software goes into development. A design notation for interactive system would not only allow us to unambiguously (or less ambiguously) convert a vision to implementation, but it allows us to find common patterns in interactivity design, as well as potential problems quickly and easilly. And, generally, though they would require some familiarity with the technical, they could be designed without them (just as some software designers are terrible programmers).
But beyond that... a good design notation would allow us to support interactions and concepts we haven't considered (or haven't considered fully) in game design. Though it is true that, eventually, computers convert themselves into state machines, fuzzy AI and input interpretations are taking a new foot hold. Instances where the behavior of a character is based on a continum between states, not just the presence or absence of a specific state. Newer input devices and rules should allow the AI to interpret not just "shoot, move, jump, duck" but "vicious, pitiless, scared, sneaky, tactical". How are these implemented in code I can't say now, but a designer may want to consider them as dependencies to possible game state transitions. And they should be able to without worrying about the underlieing technicalities.
Coding is not just bug fixing, just like design is not just balance. Coding is figuring out the best and fastest way to implement a problem that satisfies all the specifications. Design should, at least, be able to specify the problem clearly.
I don't think this is true for any but the simplest games. The ideas in your mind often depend upon assumptions which don't really hold, or they exclude unforseen patterns of undesired behavior. The images in your mind are less concrete than a running implementation, and even professional designers find that certain features do not work as expected once they're implemented.
well i don't think it's true for simple game but for non emergent game, when the game doesn't provide that much liberty ( i think of game like adventure/puzzle, where a chess game or a true puzzle game can be difficult)
but the experiance learn me it's not that easy
i made one game some day on by beloved 64ko casio, it was just an exercise then GAMEPLAY wasn't my priority, it's turn to be my best success ever...
it was an adaptation of the lightcycle sequence from TRON the movie and was called RAYTRACE
it was just a try, a design exercise, a defy
it was about making the first and only game with two player in real time on casio, it was a demonstration of my theory on design among the programmer community from my school...
i knew that the game wouldn't be fast, it would be more like snail than lightcycle, and the command respond would be also not apealing for a game in real time and you can't push two button the same time (it was the challenge to give a 2p design with that), another part is that i have felt that the screen space will be to big for the speed of the game, and player should avoid each other easily because the game was not fast enough to keep stress, well bad gameplay that was i felt, and don't care that much of the game.
it apear that was i have feelings like weakness turn to be the strength of the game:
FIRST, the speed combinated with the response of the button works like a tempo meter, the player understood that there is cycle in the game to push the butto and having the game respond to that button, it was also a factor for immersion because the player have to focus on tempo and the tempo help focus
SECOND, in oder to provide a 2p game i use only 2 button (turn left and turn right) and if i choose the TRON setting it's ecause if you keep turning you collide with your 'ray' and lost the game.
then player has develop a strategy that they push the button the same time while the other player push his button but can't turn either, in order to acheive this you must be aware of your situation and anticipate the reaction of the opponent, if he doesn't push, you turn and it can change a lot of things
the THIRD, in programmation implementation it apears that i couldn't test a collision for the two 'ray' the same time, that's mean if they came from 90° from each other and test the same case in front of them, they didn't collide and can share the same coordinate, that was high skilled player use to called the perfect rectanble rule, and they start to build tactics with calculate the range of distance between the opponent in order to make a rectangle (or any shape) in order to share the same cordinate collision test, it was use for bluff and evade move an brings tension because they can do a mistake in calculation
thinking in term of 2D swifting from the other was an ability to learn in order to master the game because each ray goes at the same speed and they can only turn at 90°, focus on tempo was important to adjust the shift and losing a tempo step maybe lethal for the rest of the strategy
FOURTH the game was about survival but you cannot attack directly your opponent and the 'trace' you left was as lethal as opponent's, it was about strategy of movement and space, creating room, dividing space and get your opponent in trap you set without falling yourself in, read the opponent moves was the challenge, it was a great simple game (maybe the greatest i will ever made??)
when i release the game i have not expect such a sucess that even in class there is people to challenge each other, player even start recording best party in millimetric paper and pattern of movement apear for each game's problem case
the game sucess ends when player start to see gap between them when people start to get the same old rank and the best can not be challenge any more
here is an example of the problem to game design, even if you can emulate the game because it a simple game, there is something you can't emulate it the player itself and then the fun...
this game was a great unexpected lesson of design
But beyond that... a good design notation would allow us to support interactions and concepts we haven't considered (or haven't considered fully) in game design. Though it is true that, eventually, computers convert themselves into state machines, fuzzy AI and input interpretations are taking a new foot hold. Instances where the behavior of a character is based on a continum between states, not just the presence or absence of a specific state. Newer input devices and rules should allow the AI to interpret not just "shoot, move, jump, duck" but "vicious, pitiless, scared, sneaky, tactical". How are these implemented in code I can't say now, but a designer may want to consider them as dependencies to possible game state transitions. And they should be able to without worrying about the underlieing technicalities.
well i know that with my emotion engine, common word are not accurate and cover many things which blur the understood of the system, i have hard time to design that even if it's not code yet.
in pure conception language you have the same probleme (i can't emulate something with my brain which are not purely logical for a game)
we have to study everything related to the word and cross some line of knowledge, sometimes in unexpected domain, so , programmation is not that a problem if you can't build a clear model before it's the same (i think stuff like priority and dependency are more buzzier in programming if you done a good job in analysis, modelisation and conception)
Coding is not just bug fixing, just like design is not just balance. Coding is figuring out the best and fastest way to implement a problem that satisfies all the specifications. Design should, at least, be able to specify the problem clearly.
Originally posted by neoshaman
well i don't think it's true for simple game but for non emergent game, when the game doesn't provide that much liberty ( i think of game like adventure/puzzle, where a chess game or a true puzzle game can be difficult)
In many ways, what we are talking about is similar to the problem faced by psychologists. Every psychologists knows that at a very low level, every human behavior is a function of neurons and hormones. However, neurons are too low level to deal with, so psychologists instead talk at a high level about human behavior.
maybe the book a new "kind of science" of steve wolfram have a a part of the answer or just the beginning, it's about thinking in cell automata (with emergent behaviour and low level system) the whole universe??
but i didn't get the book yet
for the matter i was discuss about design rather than coding but maybe i confuse some thing, it was about predicting and controling the set of experiance, but we get in a system which had an infinite complexity and from simple level grow to infinite complexity, maybe some hints from the chaos theory too??(thinking in term of strange attractor???)
well it just idea like that i have a head ache i have not think properly
the fact is that emergent system give more and more complex pattern which raise from their rule, when i mention wolfram works it's because he have make a classification from some kind of emergent behaviour in simple system, i hope there is data to create a pattern definition language, rather than a describe pure mechanics
Jhinalexender> thx to toure example i've seen that the whole matter lie in pattern which emerge drom a sys.
well the brain is good at seeing pattern which are abstract of situation, maybe that we needs is a to create a meta language to explain and describe pattern from the range of the ruleset, something as i say previuously which looks like to strange attaractor, it will be a powerful tool but i doubt that's we find something by ourself, we have to stay alert of science reshearch in the domain to borrow some idea
and it will be powerful too to systemic level design and procedural game
For the golden age of making games without programming, I direct your attention to the age of Commodore 64 where a wealth of game construction sets were offered to the lowly non-programmer like me 
Check this wonderful site:
http://www.mts.net/~bbagnall/commodore/gamemaker/info.html
well i have seen a lot of true amateur game which is really kick ass, there is a lot of solution to make game whithout feeling programmation (even if the in reality did)
for ex there rpgmaker, klick and play, gamefactory, mugen etc...
We are in a golden age, but they are at the very edge of game community and there is no relation from the two world, because pro are too confident and see only the lacks just as the hobbyist can't compare from pro
they're is a lot of community which stay in the edge and where there is a large amount of experimentation, and it's truly amazing to see how they get out the limitation of the software they use...
because they sometimes know nothing and reinvent the wheel, we see new pattern emerge, but there is nothing to keep them and they lie in the shadow of the mass production of game
i've play a game (in french) which is called DARKSOUL from el diablo, the gameplay, the diversity and the scenario kick any previous rpg (console) i've play into hell, it was damn good!!
and yes you have to deal whith programmation to make a game but don't have to know that, it can be hidden in the practice :p
i say this because most hobbyist (i think in the rpg mk community which i belong too recently), have not the feel they are actually programming (even if they deal with complex problem, mostly to ge beyond limitation)
I think a game designer should know how to programm but not necesarily know a programming language.
He must know how to express problems in a logical way, how the engine or programming process works, its useful to him since he will know what can (and can't) be done and what tools he counts with.
I think is totally useless for a Game Designer to invest several years studying and trying to be a good C++ programmer, in the end he will be working with a person who's 100% dedicated to game programming hence better than him...
If you wanna be a Game Designer, understand how the programming process works, learn how to programm but don't spend half your life learning complicated languages or comlpicated mathematical stuff, thats not your role, instead use tools like the ones mentioned 1 post above mine, I use Multimedia Fusion (clickteam.com) a GREAT authoring tool for quick game creation. You need to program and all, but you dont need to mess with complicated stuff like memory managers, memory restrictions, API's, code, libraries, etc, etc..
yeah i was use to play with the ancestor (klik n play) and knowing the limitation , i was amaze of what people did with (no scrolling in, but i've play a megaman rebuild in, with all option, i'm still amaze), the fact is these program are use by hobbyist which some time doen't know a lot, and still they make brilliant things which are never release and never known because no one take care, constraint lead to a state of art some one say, and i have seen a lot of originality becasuse of constrain (the more you have to deal with, the more you find new brilliant solution)
programming, then, is a neccessity but not knowing about a language is not a problem (yeah i've finally say it without a flaws!! my english improve??)
WARNING: Ambitious protest rant
I really don't see how computer programming is intrinsic to game design. Everyone seems to say that a game designer must have programming experience, but I'm not really convinced. I've heard "because the designer needs to understand if something isn't possible." I have issues with that logic.
My feeling is that most "game designers" do not actually know how to design games, but they have a "cool" idea for a little fantasy world that they want to escape into. A game usually involves organized information which makes it fundamentally easy to put into a computer program because it's essentially book-keeping. A fantasy world is vague, and tries to mimic reality, making the limitations of computer programming much more prevalent.
You can learn to be a good game designer just by studying other games. However, the best you can do is independent study; nothing that you can get credit for. The criteria for game designers, in my opinion, is completely wrong. A game designer needs to be an entertainer who can relate to the audience. While it involves some wacky, creative thinking, it also requires a strong grip of reality. A game designer has to understand people more than he/she needs to understand computers.
To address everyone's good points:
1) Neoshaman is correct about designers making games "without programming" using things like Click and Play. So, to revise what I was saying, "1) It's hard to learn how to be a game designer without seeing some implementation. 2) There are few opportunities to implement a game without programming. 3) The easiest way for someone to see their game implemented is to program it themselves (though there are alternatives, such as Click and Play or finding some willing programmer to program it for you.) We need more non-programming game making software.
Oh and your English is perfectly understandable. I do like the way you tend to replace "and" with "et" and spell a lot of things French style (sociologie vs. sociology.) Keep up the posts.
2) Booda -- I was not saying that programming is intrinsic in design. I was simply stating that in most cases if a game designer can't program, she can't see her game implemented. If a game designer can't see an implementation how does she know what she did wrong and whether the idea is actually good or not? Studying other games and understanding how they work is a good start, but I think understanding someone's elses art is not equivalent to being able to create good art. (For example, there are some very excellent art critics who can't create art themselves. There are also excellent artists who can't critique the art of others very well.)
3) Skanda -- I agree with what you said and it applies to the "real world" and the industry. But what about the situation where you have a 6th grader who has a good game idea. How is she supposed to convince someone else to program her game for her? She pretty much has to do it herself.
I guess what I'm saying is this: An amateur song writer will have a much easier time writing songs if she can sing. If she can't sing she has some options: a) get someone else to sing the songs b) find someone else to evaluate her songs "on paper" (preferably someone with a lot of experience who can tell if something is good or not by just seeing it onpaper.) c) Try to trust her own instincts.
a&b are hard because she must find another person to commit time to help her out. c is difficult, because she must already have the natural talent to evaluate her own work -- something most people don't have.
It's much easier for an amateur song writer if she can sing her own songs. It's much easier for an amateur game designer if she can implement her own games.
I don't know if the songwriter is a good comparison. Writers come up with funny dialogue, yet the actors are the ones who portray the characters in the script. If the writer has to be a good actor to write good material, why isn't he/she the one acting it out? Writing and acting are two different arts. So are singing and songwriting, game design and programming.
So why is it that game designers can't just come up with a good game design and have it critiqued? Surely that can give at least some measure of the game designer's talents; enough to determine whether he/she needs improvement or is ready to begin working in the industry.
I am not sure a good game designer needs to program his own gam ein order to see how it behaves.
But I am convinced that the designer needs some programming notions so that he may modelize his concepts.
Designing a game is quantifying various effects and creating logical relations between them. Do you need programming ? Maybe not, but you definitively need logic.
To add some fuel to the fire...
Game middleware is getting to the point where you don't need to be a programmer to be able to use it for prototyping. An understanding of how the process of programming works and how modules inter-relate to one another is useful. But an in-depth understanding is, in my opinion, detrimental. Yes, understand how to set up scripts and camera systems, physics and AI triggers, etc., within a game engine. But game design isn't programming...it's where art and programming meet to create gameplay.
Also, game development is a collaborative process. Why not draw on the talents of multiple individuals? Believe it or not, not all programmers and artists are also good designers, and not all of them feel confident taking on that role.
As a professional writer one thing I have realized is that everyone thinks they are a good writer, because writing is something we all know something about, and can claim to be proficient in to some degree ("Sure, I wrote essays in school and there was a poem for the school paper..."). Writing, like any other skill, is something that must be practiced and studied if one is to become good at it. So too for game design. It's one of those 'soft' disciplines that's not yet well defined and so everyone thinks they are capable of doing it, and to a degree they are right.
Right now, programming is essential to the process of creating a game, but it is also a huge hurdle to be overcome, and in many ways interferes with the creation of new and innovative projects. Imagine if every time someone wanted to make a movie, they had to re-invent the whole process of film-making, the technology behind it, the terminology, theories, cameras, lenses, etc. A bit of an extreme analogy, sure, but not altogether inaccurate...
Right now, programming is essential to the process of creating a game, but it is also a huge hurdle to be overcome, and in many ways interferes with the creation of new and innovative projects. Imagine if every time someone wanted to make a movie, they had to re-invent the whole process of film-making, the technology behind it, the terminology, theories, cameras, lenses, etc. A bit of an extreme analogy, sure, but not altogether inaccurate...
it's true but technology can lead to new and innovative form if we took time to think them, they can broaden our own imagination, the fact is we are too selfish sometimes to let down our precious world to learn from another
i'm talking to the race of realism versus pure game world which, if think in a proper way, can lead to stong new universe, as example think about TRON which have an authentic world based on computer, video games, and 3D and still innovative even in our times
then in video games by using pure gameplay mechanisme as the world setting and themself metaphore (auto reference) we can help new form to born because not anymore parasited by other reference but themselves, and after these can also help old classic reference to find new way to express themselves (TRON vs MATRIX, matrix translate undergrounds references to mass public and offer new view of old things and other way to do them)
well the more ofthen it's not the tool wich are the true limitation but our simple desire contradiction which lead to cul-de-sac, and voila!!
Constraint is art
Leonardo da vinci
I think this demonstrates the need for two things. First, a good rapid prototyping software that allows you to specify rules quickly and easilly. The closest we've come really is Director or Flash, but even that requires you understand some programming concepts (in ActionScrip or Lingo) in order to get it right. In general, since design is based of rules a lot of the time, programming is an inevitability in some language or another. However a simpler language with a GUI would be preferable than things that require some 3D knowledge or programming knowledge to use.
The second thing is a way to specify game rules independently of game implementation, and the study of patterns that come up a great deal. When I was first working on my thesis, I wanted to create a notation for interactive systems that would allow for the quick creation of rulesets and examination of those rulesets in comparison to patterns... totally seperate from their implementation. Basically, a version of UML / design patterns for game design. If that was created, it would be possible to make utilities that created (incomplete) code from those rules, and it would also assist the creation and criticism for non-techies. Allas... that's too daunting a task for an undergrad. I would still love to see others work on it (and help) though.