Basic Approach
Hi,
Currently i am really just a dabbler in the game programming. So i am want everyones options on the best way to approach making a small game and in what order to program the various features and modules.
From what i have read the progression is:
Decide Game Theme and Story
Decide Game Features(i.e. scripting, special effects etc)
Decide Major Game Modules( i.e. Interface, Scripting Enginge, Graphics Engine, AI Engine)
Programme Modules
First of all, you may take my words with a grain of salt cause I''m the young, inexperienced type, just have tried and looked at a lot of things. That said...
The way I officially start a design, after tossing around ideas in my head and on paper, is to summarize it in one sentence. This sentence should be like the topic sentence of a good essay(though I find that it''s usually easier to create than those) - the clearest possible statement of two things: what the project is about and how it will get there.
Here is one that I did from an unfinished design doc I started for practice(I knew doing it that I was not going to have any chance of creating it in the forseeable future even in a heavily stripped-down form):
SuperFighter(henceforth simply SF) will be a single-player and online multiplayer third-person-perspective action game which allows players to create their own characters by combining thousands of choices of appearance, abilities, and weapons, and then go on an adventure with their character from a choice of different scenarios.
Looking at it now, I''d say my summary goes in the wrong direction, starting with what the game will use(and I forgot the target platforms), and then getting to what the overall concept of the game is. It also lacks detail, but that''s kind of to be expected with a grandiose design like the one I did there.
Also, it gets cumbersome when you have a truly unique concept that the gameplay is dependent on, such as Tetris:
Tetris is an action-puzzle game which requires the player to clear blocks from a 2-dimensional, linear, unit-grid-bound pit by rotating and positioning shapes of blocks as they fall down the pit one at a time so that they form solid horizontal lines, getting rewarded for clearing many lines at a time.
I don''t think any description of Tetris will hook people, even if you trimmed it down to say "it''s about directing shapes into a pit to clear blocks." Fortunately, your summary and your design document doesn''t necessarily have to hook anyone; a good marketing pitch can do that if it''s necessary for the project you have in mind.
The real purpose is to just organize what you have in mind. From there you can get to the specifics of storyline, technology, interface, and mechanics.
The way I officially start a design, after tossing around ideas in my head and on paper, is to summarize it in one sentence. This sentence should be like the topic sentence of a good essay(though I find that it''s usually easier to create than those) - the clearest possible statement of two things: what the project is about and how it will get there.
Here is one that I did from an unfinished design doc I started for practice(I knew doing it that I was not going to have any chance of creating it in the forseeable future even in a heavily stripped-down form):
SuperFighter(henceforth simply SF) will be a single-player and online multiplayer third-person-perspective action game which allows players to create their own characters by combining thousands of choices of appearance, abilities, and weapons, and then go on an adventure with their character from a choice of different scenarios.
Looking at it now, I''d say my summary goes in the wrong direction, starting with what the game will use(and I forgot the target platforms), and then getting to what the overall concept of the game is. It also lacks detail, but that''s kind of to be expected with a grandiose design like the one I did there.
Also, it gets cumbersome when you have a truly unique concept that the gameplay is dependent on, such as Tetris:
Tetris is an action-puzzle game which requires the player to clear blocks from a 2-dimensional, linear, unit-grid-bound pit by rotating and positioning shapes of blocks as they fall down the pit one at a time so that they form solid horizontal lines, getting rewarded for clearing many lines at a time.
I don''t think any description of Tetris will hook people, even if you trimmed it down to say "it''s about directing shapes into a pit to clear blocks." Fortunately, your summary and your design document doesn''t necessarily have to hook anyone; a good marketing pitch can do that if it''s necessary for the project you have in mind.
The real purpose is to just organize what you have in mind. From there you can get to the specifics of storyline, technology, interface, and mechanics.
If you are focusing on learning game programming, and not game design, I''d suggest building a clone of a game already out there. The classic arcade games seem to be pretty good starting points (pacman, tetris, missle command). You''ll have enough to worry about without trying to come up with a fun game idea.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement