Making a good game setup?
Blitz3D Forums/Blitz3D Programming/Making a good game setup?
| ||
| Can someone explain to me how you make a proper game setup based around flags? Like in a "if LEVELDATA=0 then the main menu of the game launches or if LEVELDATA=1 then the actual gameplay launches. I've tried many MANY different things to achieve this but none do justice-_- I usually keep myself relaxed and focused when working on my game to avoid getting myself frustrated, but after so many times of failure, it starts breakin' your balls quite a bit. I'm only human. Can someone please help me? |
| ||
| Well.... the base principle is expressed in your post... Can you give a few more details? Then we can make architectural suggestions. Mainly however, the secret is to design first, code later. The golden rule is that writing code is a minor formality: if you don't know where the code is going, close the editor! You should design the flow of logic of your program first, preferably on paper, then implement the code only once you know how the program is going to work. Programming happens in your mind, not in the computer (the computer is just a glorified correctness-checker). So... grab a pad of paper and a pen, sit somewhere comfortable (preferably not at the keyboard), and get drawing! e.g. {Main program -(arrow)-> [box] "consists of functionality units" -(arrows)-> (modules)... (module X) -(calls into Y)-> "does Z then returns value to continue X"}. I suggest you start by breaking your program into core services, e.g. main menu, game client (input + rendering), game server (AI + actor interactions). Break services into functionalities (input = read keyboard, read mouse, provide a list of input events for interested modules to query; rendering = handle animations, handle collisions, apply perticle and other clientside effects, overlay GUI), then arrange those functionalities by category to form modules. Do not worry about how the core service loop will work: have your diagram say "selects then runs service" or something like that, and once you know everything the program actually needs to be able to handle, you can decide at the time when you get to the boring, minor detail of actually writing it out whether If or Select or whatever is the best option. Don't worry about details of loops: have your diagram assume that options will be selected from a list in the correct way when your diagram indicates something needs to be selected. And so forth. Also, have a break. Make some tea. When you get frustrated, stop the detail work and either go back to architecting, or do some research to cool your mind down and get some fresh ideas. Last edited 2012 |
   |