Sign in to follow this  
bgilb

Programming Planning

Recommended Posts

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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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..

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
The way I've more or less adopted for game dev is one of using tracer bullets and prototypes, moreso the former. The idea with the tracer bullet paradigm is you try to get something functional up and running, but not necessarily feature complete. You treat each bit of code you write as "final" production code rather than prototypical code. The way I apply it to writing a game is as follows: I figure out what my fundamental components are going to be, which in my case was pretty much an engine kernel that allowed for a "client" to register one or many services as well as provide a cooperative task manager that would act as the main game loop. I spend a bit of time working out the bare minimum design details, then I worked to building a closed loop system (something that'll start up my game's executable, initial the kernel, add a simple task, like print "Hello World" to the console, shutdown, then exit the game). Once that was up and running, I would make a mini task, like create a blank window, then work on the graphics service just enough so that I could get a window up and running. Every little bit that I added I ended up keeping in my final code base.

Also don't be afraid to rewrite code. It's generally not practical (and in some instances, not possible) to foresee how every little bit of code will interact with everything else. You're bound to make some design decisions that seem logical now but pose problems down the road. In those instances, just refactor (or if it's more severe, redesign) the code to better solve the problem. Writing solid software is something that just takes practice, and in the beginning there'll be a good amount of trial and error.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this