Programming Planning
Author
So i'm about to start a project. Slightly large. I know how the game should work, but whats the best way to plan out the code so its most efficient and I don't find myself rewriting anything or having messy code?
You can try UML, if the project is going to be object orianted.
(Im using UML in my current project)
(Im using UML in my current project)
Sketch it out using any medium and notation you like - pen and ink on paper, spray-can tool in Paint, whatever. There's no "best" notation (and frankly a lot of options like UML introduce a lot of overhead for relatively little benefit). All that matters is that you're comfortable with the method you choose and stick with it.
Also, don't be afraid to rewrite code. If code gets sticky, rip it out and redo it. If you find a better way to solve a problem, by all means implement the better option. It isn't a bad thing to make improvements; in fact it's a good habit to get into. Obviously you should be careful not to go too far with this and just rearrange things endlessly for no real reason; but there's absolutely no reason to shy away from redoing a piece of code if it really needs it.
Also, don't be afraid to rewrite code. If code gets sticky, rip it out and redo it. If you find a better way to solve a problem, by all means implement the better option. It isn't a bad thing to make improvements; in fact it's a good habit to get into. Obviously you should be careful not to go too far with this and just rearrange things endlessly for no real reason; but there's absolutely no reason to shy away from redoing a piece of code if it really needs it.
Author
Whats hardest for me is the fact that there can be multiple game modes. I mean, what i'd want is something like this:
GameMode2 gameMode = new GameMode2();
setGameMode(gameMode);
would that be good?
GameMode2 gameMode = new GameMode2();
setGameMode(gameMode);
would that be good?
For game modes, you can take a look at different state management techniques.
For example, you can use a simple stack for the pushing, and poping of game
modes. This allows easy transition from one game mode to the next (A simple push
or pop), while easily getting access to the current mode (The topmost item on
the stack)
This is assuming you are referring to game state modes..
For example, you can use a simple stack for the pushing, and poping of game
modes. This allows easy transition from one game mode to the next (A simple push
or pop), while easily getting access to the current mode (The topmost item on
the stack)
This is assuming you are referring to game state modes..
Author
no no. like you know how within a game like UT2004, well theres like CTF and 2v2 etc. only for me its harder because you can pick out the things in UT2004 that all game modes share, like they're all FPS's, they all involve power ups. For me its a little less clear cut. and i have to keep in mind that there will be future unplanned game modes
One way to do it is use a scripting language to write the game mode rules, then just load the script. Each script has the same functions...but different filenames so depending on which game mode you want to play it'll load the functions from that script.
Or a slightly easier way is you can create a base class of IGameMode with whatever functions you want like initialize() logic() etc. Then just have each game mode inherit from IGameMode and implement the virtual functions. THEN you can have one object like...
IGameMode *currentGameMode;
currentGameMode = new gameModeCTF();
currentGameMode->initizize();
in loop:
currentGameMode->logic();
If you need different items or layout for a specific game type then you just create a CTF map for example with the right stuff. If you really wanted to you could create one map with all the stuff you ned for each game mode (IE a flag) and if the game mode isn't CTF, then your game doesn't do anything with the flag that you placed in the map editor.
Or a slightly easier way is you can create a base class of IGameMode with whatever functions you want like initialize() logic() etc. Then just have each game mode inherit from IGameMode and implement the virtual functions. THEN you can have one object like...
IGameMode *currentGameMode;
currentGameMode = new gameModeCTF();
currentGameMode->initizize();
in loop:
currentGameMode->logic();
If you need different items or layout for a specific game type then you just create a CTF map for example with the right stuff. If you really wanted to you could create one map with all the stuff you ned for each game mode (IE a flag) and if the game mode isn't CTF, then your game doesn't do anything with the flag that you placed in the map editor.
I say, combine the two! Use the stack approach suggested earlier, combined with a virtual IGameMode interface type thing. After all, your menu might as well be a game mode. It needs to update, render, get input and play sounds just the same as any other mode. That's how I'd treat different modes. After all, you really want to change the high level logic like scoring and starting conditions and so on, preferably without restrictions, even if you end up re-using most of the classes that make up your other game types to create the gameplay (which hopefully you will). It doesn't solve the problem of adding new modes of course.
What I recommend is getting your game working as soon as possible. Then add features from there. Within a few days of starting the project you need to have some input and some output, even it is just text. Code can't really be made from plans, it evolves based on feedback. I try to test my programs after every change. It seems like slow going but it has massively improved my productivity.
I have to disagree with the "Getting it working asap" way of doing things. That's what I did for the longest time, and I never finished a single game. What I've been doing with my current project is being very thorough; I wrote out everything that I could think of I'd need, made a schedule for when I think I can get it done by, and I'm following the outline and the schedule as close as I can. Otherwise you just get sucked up programming the fun stuff, like effects, and other critical sections never get much done in them. Maybe it's just me, but this is what I'd recommend.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
