What is game design?
Author
I am curious about what game design is. If you are making an adventure game I guess one part of design is the character stories, world history and so on.
Then we have the engine design. How much should you design here? For my Arkanoid-clone project I began with a small design which I later didn't use much because I didn't have much idea how DirectX worked. That made a lot of the design I did do flawed and not working with DirectX.
My current approach is to code without much technical design. Of course I have notes about what each type of bonus should do, and so on. I also made a few notes about how classes were connected. I have not made many notes about how the game engine should work however.
How much should you design the code? Should the level of design be that when finished you look down on your paper notes and realize you have the code written there?
Thanks for helping me.
Game design, in this forum at least, is the area of planning related to a game that doesn't include coding details. Although some would argue that it's worth 'designing' down to the level of individual functions in the code, that's beyond the scope of this forum. It's also beyond the scope of what a 'game designer' would usually do.
Quote:I am curious about what game design is. If you are making an adventure game I guess one part of design is the character stories, world history and so on.
Back before genres for computer games existed, somebody had invent the entirety of the gameplay concept from the ground up. They couldn't say: "Let's make an adventure game with this gimmick in it!" Back then, design was a really involved and technical process. They had to consider the limitations of the technology and use what resources they had to make a fun toy.
A designer is to games like an architect is to architecture. Architects are not contractors, they do not build the house, they only provide the criteria by-which the builders do their work. Of course, it's best if an architect knows what kind of designs are feasible and what kinds of restrictions the resources put on the creativity of the building. It's good for game designers to have some background in game development -- that way they know what's possible. This is why the two jobs of design and development tend to overlap onto the same person (among countless other reasons).
Quote:Then we have the engine design. How much should you design here?
well, if you're actually making an engine, then you should probably sketch it out; since most of the classes handle large portions of the game (rendering, sound), its important to determine how they will interact with each other (if at all). on a more practical level, having a basic layout done helps to debug your game/engine. 'nuff said there, i hate to preach.
as for the actual game, generic details are essential to lay down; like kylotan said, not into specific detail; place more emphasis on the 'what' as opposed to 'how'. i.e. these details might include what the player attacks with - guns or hand - to - hand, is the viewpoint 3rd person or 1st ? simply the details that determine how the game is played. its much easier to code when you know what you want/need/are forced to do.
basically (as everyone has said) game design is the what, leaving the how to the coders.
Game design is the definition of gameplay. A game design describes how the game will play and what parts are in it. It is however not the same thing as saying which classes the game should be built with, or which data structures that should be used (that should be in the technical design).
Author
Quote:Original post by Srekel
Game design is the definition of gameplay. A game design describes how the game will play and what parts are in it. It is however not the same thing as saying which classes the game should be built with, or which data structures that should be used (that should be in the technical design).
I see. It sounds as if some people here think you don't need to do much of a technical design. How detailed should a technical design be? As a newbie I felt it very tough to design my Arkanoid-clone as I didn't have many ideas on how DirectX handled things like sprites for example.
Thanks for all the answers so far. They have really gotten me to think some, and realize that perhaps it is sometimes better just to code, rather than planning too much.
Quote:Original post by Ranor
I see. It sounds as if some people here think you don't need to do much of a technical design.
No, it's just that the technical design is a seperate entity from the game design. The technical design generally gets written by one of the more experienced programmers on the team, which isn't usually the same person as the Game Designer, who may not even know the first thing about programming.
The more complex the project, and the more people working on it, the more important it is to have a decent technical design document.
Quote:How detailed should a technical design be? As a newbie I felt it very tough to design my Arkanoid-clone as I didn't have many ideas on how DirectX handled things like sprites for example.
It's very difficult to write a technical design document unless you're already reasonably familiar with how everything fits together - if you're still learning how it all works, then any technical design you create is likely to be completely useless, because there'll probably be some dependency or technical issue you've overlooked which completely screws up the whole thing.
Once you've learned how it all works and start moving on to larger, more complex team projects, you're going to need that technical design though. How much detail you go into probably depends on who you're working with, but mapping out the class hierarchy and defining the class interface functions and their expected behaviour is a good start.
Currently me and five friends are making a racing game. We decided to use two free engines, OGRE for graphics and ODE for physics. We realized that we couldn't really start coding or planning the technical design for the real game until we tried the two engines out and learned how to do simple stuff like collision detection and moving the camera around.
The moral of the story is that you shouldn't make a technical design until you know how to :) Hehe, or something like that. But sometimes you also have to try and then see what went wrong.
The moral of the story is that you shouldn't make a technical design until you know how to :) Hehe, or something like that. But sometimes you also have to try and then see what went wrong.
Quote:We realized that we couldn't really start coding or planning the technical design for the real game until we tried the two engines out and learned how to do simple stuff like collision detection and moving the camera around.
Well, this is called research. It's astonishing how much this is underestimated. Even amongst the professional game developers. I held a talk in early 2003 for german game developers stating that you have to include the research into your actual game development plannings (ie. write a research document with what you have to research and which results you would like to find). "We don't have time for this." is all I heard of them. Well...
And the research document is only one of the design docs you'll need to complete the game. As is the game design doc.
A game design doesn't include the engine design (which in fact can be included into the technology design and/or system architecture design doc).
As for the content of the game design doc, Srekel is quite right.
As for some hints on the game design doc itself, you can take a look at the books here :
Game Design Book List
Best regards,
Metron
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
