An art teacher once told me that a piece of Artwork can never be finished or complete (you can always do better). Could this philosophy apply to Game Design?

Yes, absolutely. Because of the pace that technology is advancing, there are always new and better ways of doing things, and as the technology level increases, it makes ideas previously thought to be too complex a reasonable goal.

I''ve made a couple programs, and a couple games, and no matter how long I worked on them, I always come up with new ideas for things I can do.

So, to sum it all up, I would say that game design is an art, and production of a game can conceivably go on forever (if the project is worth it)

quote:Original post by BigBlueMonkey

Yes, absolutely. Because of the pace that technology is advancing, there are always new and better ways of doing things, and as the technology level increases, it makes ideas previously thought to be too complex a reasonable goal.

Ok, but can a game design element be "perfect". As in, could make the GUI better for this game? So if one game design element could be done perfect then they all could be right?

quote:
I''ve made a couple programs, and a couple games, and no matter how long I worked on them, I always come up with new ideas for things I can do.

Yes, i know what you mean. But sometimes i sit there wondering if i''m going to come up with a new/better idea. It doesn''t always happen and then you wonder if it''s possible because maybe you''ve done it the best way.

So expanding a game = improving it? Is this always the case? Or when you expand a game design are you actually creating a new game?

quote:
So, to sum it all up, I would say that game design is an art, and production of a game can conceivably go on forever (if the project is worth it)

That''s a bloody big project ;-)

When the game is published, the game design is complete. Any lingering ideas for add-ons or modifications become the game design for the sequel

Seriously: game design, and to a lesser extent software design, is an evolutionary and self-modifying process. Unlike the strict "analysis-design-implementation-testing-maintenance" model often stated by academics. Each major piece of software tends to include its own Research and Development. This is a shame for the industry, as separate, dedicated research would improve the state of play - but in the real world, developer teams are having to learn as they go along. Sometimes they find a better way of doing something, so the design must change. Sometimes they find something is impossible, so the design must change. Sometimes design follows implementation rather than the other way around ("we have 2 free bits, can we think of another 2 monster AI flags?"). This would seem ''wrong'' to someone who believes in rigid design, but would seem right to the guy who wants to get as much game as possible out of that computer. Another common effect is where you can''t quite fit the specification: but you can fit 90% of it if you make a small change elsewhere A very basic example is having to cut down the number of frames of animation so that you can store them in a byte-indexed array. Again, the design evolves to fit the specification.

The only design that is not going to change, where you have control over such changes, is a design that it is either being done as an academic exercise, or is so loose to be almost useless. Design and Implementations are 2 sides of the same coin, inextricably intertwined and as one changes, so will the other.

quote:Original post by Kylotan

When the game is published, the game design is complete. Any lingering ideas for add-ons or modifications become the game design for the sequel

Then you are saying that expanding a game design IS a new game/yes? In which case, the previous game may have been considered perfect.

quote:
Seriously: game design, and to a lesser extent software design, is an evolutionary and self-modifying process. Unlike the strict "analysis-design-implementation-testing-maintenance" model often stated by academics. Each major piece of software tends to include its own Research and Development. This is a shame for the industry, as separate, dedicated research would improve the state of play - but in the real world, developer teams are having to learn as they go along. Sometimes they find a better way of doing something, so the design must change. Sometimes they find something is impossible, so the design must change. Sometimes design follows implementation rather than the other way around ("we have 2 free bits, can we think of another 2 monster AI flags?"). This would seem ''wrong'' to someone who believes in rigid design, but would seem right to the guy who wants to get as much game as possible out of that computer. Another common effect is where you can''t quite fit the specification: but you can fit 90% of it if you make a small change elsewhere A very basic example is having to cut down the number of frames of animation so that you can store them in a byte-indexed array. Again, the design evolves to fit the specification.

Todate i would agree with you. Mainly because the tools for making games are still in the development cycle of the industry. These tools will obviously continue to be developed as long as the technological side of the industry (computer speed/memory etc) continue to evolve. But then what happens?

quote:
The only design that is not going to change, where you have control over such changes, is a design that it is either being done as an academic exercise, or is so loose to be almost useless. Design and Implementations are 2 sides of the same coin, inextricably intertwined and as one changes, so will the other.

I disagree. I believe that it is possible to make/design a game that does not need to be changed when it comes to coding time. I don''t think such a game design would be useless. Implementation is merely a transformation of English into Binary (C,Java,Assembly). Yes, i do agree though that game design requires the some of the logical thinking that goes into software design but this isn''t the all important "conceiving" process of game design.

I presume you''re saying that game design is an implementation process not an artistic one? A process that revolves around whether or not this or that can be done or not. But what if the Game Designer already knows that the team he/she is working with can already acheive full implementation of the game logic.

Maybe game design should be officially split into to sections? Section A representing the creative portion and Section B representing the logical portion? High level (creative/conceptual) game design and low level (game logic/implementation) game design.

I could go on but i''d prefer to tackle this one small chunk at a time ;-)



The measure of intelligence is in the question not the answer.

Game Design is finished when publisher says that you are 3 months late fron schedule, but you don''t have to worry about it, right, you live in heaven as long as those nasty provinces run to your account. Now it''s time for programmers to try to clear up your brainwave, but now worry you have left to Bahamas for 3 week holiday, because your job is so stressing.

Now poor coders work 24h and they try to contact you. Fotunaletly you lost your cell phone while you were fishing sharks, what a bad luck.

Time comes, time goes and I only am.

There''s nothing wrong with spliting the task of the logic with the creative. We as game designer must contend with this all the time. In fact, if we did it more often than not we would probably find the work at lot more progressive and easier to deal with.

I can''t see an explaination why the game design process can''t not be catorgorised in this way.

We would be able to say that this element idea is this much implementable. Rather than trying to shoe horn idea''s into code once the game design is done (and losing half of the game design in the process).

By segregating the logic from creative we would actually be creating tools for the artist to use.

The measure of intelligence is in the question not the answer.