A few pointers please on designing a game
Author
oki, so im quite good with my OpenGL and C++, BUT im terible at designing and planning things, can anyone help me out with how to get down my ideas etc, im absolutely appauling at drawing. Usualy just throw everything away.
Any pointers would be useful
The first thing to do is check out some of the articles here. They''re quite good and helped me out a lot
Well, the next thing to do is get that idea down somewhere. Keep a notebook that you can just scrawl anything that comes to mind into. It doesn''t matter if it makes sense, or contradicts itself, or if it isn''t complete. But it''s good to have a reserve where you can go back and look in case you ever need to refresh what you thought up last week.
Lets say you do have an idea now. I usually try to build things around that. Say, if I want to make an RTS with deformable terrain, then I can figure that: 1) gotta be some way to deform terrain. 2) Terrain matters in combat
Then I do the same thing with each of those ideas (recursive game generation, wheee!). With ways to deform terrain, lets say terraformers can change terrain, and bombs can change terrain. Well, that means I have some sort of terraformers, and someone throws bombs. Not to mention there needs to be some way to protect your base''s landscape from enemy bombs, concrete slabs maybe?.
After 5 or so iterations on the whole process I''ve got a good chunk of ideas to work with. Then I try to look at the whole picture and ask myself "Ok, what''s the important stuff in here?"
From the important stuff, I try to get a single sentence that describes everything I want my game to be.
Usually from there it''s a lot of writing, specifying everything that needs to go into the game.
Then plan on looking at the specifications of what goes into the game, and have to figure out how the hell to implement it.
Hope that helps a bit
Well, the next thing to do is get that idea down somewhere. Keep a notebook that you can just scrawl anything that comes to mind into. It doesn''t matter if it makes sense, or contradicts itself, or if it isn''t complete. But it''s good to have a reserve where you can go back and look in case you ever need to refresh what you thought up last week.
Lets say you do have an idea now. I usually try to build things around that. Say, if I want to make an RTS with deformable terrain, then I can figure that: 1) gotta be some way to deform terrain. 2) Terrain matters in combat
Then I do the same thing with each of those ideas (recursive game generation, wheee!). With ways to deform terrain, lets say terraformers can change terrain, and bombs can change terrain. Well, that means I have some sort of terraformers, and someone throws bombs. Not to mention there needs to be some way to protect your base''s landscape from enemy bombs, concrete slabs maybe?.
After 5 or so iterations on the whole process I''ve got a good chunk of ideas to work with. Then I try to look at the whole picture and ask myself "Ok, what''s the important stuff in here?"
From the important stuff, I try to get a single sentence that describes everything I want my game to be.
Usually from there it''s a lot of writing, specifying everything that needs to go into the game.
Then plan on looking at the specifications of what goes into the game, and have to figure out how the hell to implement it.
Hope that helps a bit
I''ve been known to give how-to-design lessons; this is lesson one:
How to design computer games, lesson 1: What design areas are there?
Hello. The first thing to realize is that game design is unified in theory and philosophy, but divided into many different technical areas. A technical area being a particular type of design requiring it’s own set of knowledge and terminology. These areas are:
ART [visual character design, clothing, backgrounds (buildings, plants, geographical features, statuary), props/items]
STORY [character, character dynamic, plot, worldbuilding, atmosphere, word choice (register, diction, posey)], how to storyboard
GAMEPLAY [genre, morals and philosophy, puzzles, battle system, gui, inventory, cursor types (for PC games), 2-d vs. 3-d, overhead vs. first person vs. sidescroller, contingency theory, player psychology]
MUSIC [atmospherics, themes, sound effects, vocals]
TECHNICAL [what language to program in, what engine, what platform, what system load, lots of other stuff].
From this point there are a two different approaches you can take:
-pick one area and learn all you can about it
-start designing a game and investigate each area as you come to it in the design process
How to design computer games, lesson 1: What design areas are there?
Hello. The first thing to realize is that game design is unified in theory and philosophy, but divided into many different technical areas. A technical area being a particular type of design requiring it’s own set of knowledge and terminology. These areas are:
ART [visual character design, clothing, backgrounds (buildings, plants, geographical features, statuary), props/items]
STORY [character, character dynamic, plot, worldbuilding, atmosphere, word choice (register, diction, posey)], how to storyboard
GAMEPLAY [genre, morals and philosophy, puzzles, battle system, gui, inventory, cursor types (for PC games), 2-d vs. 3-d, overhead vs. first person vs. sidescroller, contingency theory, player psychology]
MUSIC [atmospherics, themes, sound effects, vocals]
TECHNICAL [what language to program in, what engine, what platform, what system load, lots of other stuff].
From this point there are a two different approaches you can take:
-pick one area and learn all you can about it
-start designing a game and investigate each area as you come to it in the design process
Author
Thanks guys, so if i just do as ThoughBubble said, and divide into the categories sunandshadow mentions
Go and buy Game Architecture and Design . It is a stonkingly good book (even if I dont agree 100% with the RPS stuff 
)
)
If you''ve got patience and time, try learning an industrial strength OO modelling language like UML. It''ll help you get good techniques from the start and it''s a great asset on your CV - especially for Java related jobs (not strictly game programming but it applies to all OO coding).
Don''t just get the reference book though - get an applied tutorial otherwise it''ll fly right on over. And only go to the level of detail you need.
Of course, this is only for the coding... it can be used for anything but it''ll fry your brain
~~~
Cheers!
Brett Porter
PortaLib3D : A portable 3D game/demo libary for OpenGL
Don''t just get the reference book though - get an applied tutorial otherwise it''ll fly right on over. And only go to the level of detail you need.
Of course, this is only for the coding... it can be used for anything but it''ll fry your brain
~~~
Cheers!
Brett Porter
PortaLib3D : A portable 3D game/demo libary for OpenGL
Marvin my man, I have all your answers right here in this nice little four-part package. Enjoy
You Got Game!
==============================
"Need more eeenput..."
- #5, "Short Circuit"
==============================
You Got Game!
==============================
"Need more eeenput..."
- #5, "Short Circuit"
==============================
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
