Game Design - Methods
Blitz3D Forums/Blitz3D Beginners Area/Game Design - Methods
| ||
| Hi All, its not a programming question, but more a good practice question. I'm currently doing a Certificate IV in IT Programming (mainly using Python). I have been introduced to Nassi Schneidermann N-S charts for program design. I'd never encountered them before and have always only ever written pseudo-code to design anything I've written. I'm basically after everyones ideas of how they actually do the DESIGN of any of their games. Not the actual coding, but how do you sit down and start designing it? Im not after a what is a better method than the other, but simply want to get a feel for how people here plan their games using good game design techniques? I think that I'll probably stick with Pseudo code myself although N-S charts definately help with visualising the program flow and makes it easier to spot errors. So cmon all, give me your workflow methods. Cheers Al |
| ||
| I think the general response you're going to get around here is that the prototype is very useful as both a method of verifying what does and does not work in terms of gameplay, and what is and isn't an appropriate way to implement it. And that a lot of people just dive in. I'd never heard of these structograms of which you speak, but on initial inspection they look ill suited to game design. I wonder if any game studio actually uses them. |
| ||
| I concur. |
| ||
| It depends. For a game I guess the features are listed, maybe the story line is displayed using some kind of structogram, as well as the way the modules are connected together. But I don't think there's this "START" "GOTO THERE" "USER INPUT" thing. The main work is done in modules and they are created in the programmers head fist, based on knowledge about what steps are possible. Once implemented, the modules are integrated into the main project. Then again I am not a typical "structured" programmer :) |
| ||
| i'm hazy on the question, but to the answer of what i interpreted: i like to dive in head-first, start with the fun part, build an engine, and make millions of include files, each containing a nice function, and bring it all together into one massive main file, making it easier to debug :D. always start with a good storyline...it makes it funner to code and gives you motivation to spend bloodshot-eyed hours debugging that HORRIBLE dependant function :D, but then, i'm still in grade school, my methods are most likely flawed :D |
   |