Many many many many many people have asked me how on earth I manage to cram game making into the space of a single week.
Ironically, most of those people seem to have forgotten that they, themselves, have previously taken part in Ludum Dare "Make a game in only 48 hours" style competitions.
Hmm..!

Anyway, today's rambling waffling blog is about the steps I take to ensure I can achieve AGameAWeek.
-=-=-

Framework

If you don't have a good framework, you're not going to get very far. Or at least, you'll have wasted 95% of your week struggling to get a framework going, and be left with just 5% of the week to tackle the actual game.

By "Framework", I mean something that copes with the "None-Game" bits.
Most modern programming languages will give you a multitude of methods to achieve the same goal, like 2D vs 3D sprites, and different ways to rotate and scale them, and all kinds of other nifty things.
My framework, for the past 5 or so years, has taken whatever methods are presented, and created a batch of reusable functions.
In Blitz3D, for 2D-in-3D sprites, you had to first build a bunch of 3D objects, then each frame you'd add the textures, then rotate them and scale them, and finally order them onscreen.
My Framework whittled all of this down to a simple DrawImg(Image,x,y,frame) command.
There are extra commands to SetRot() and SetCol() and SetAlpha() and so on.

In BlitzMax and Monkey, they handled most of the interior stuff for you, but left you with a quirky multi-part giganto-draw command, where you had to include rotation and scaling with each and every draw.
Sod that!
My Framework whittled all of this down to a simple DrawImg(Image,x,y,frame) command.
There are extra commands to SetRot() and SetCol() and SetAlpha() and so on.

In Cocos2D..
Um..
I can't actually remember any of the internals of that, but it drove me crazy for a couple of days, so it can't have been pleasant!
My Framework whittled all of this down to a simple DrawImg(Image,x,y,frame) command.
There are extra commands to SetRot() and SetCol() and SetAlpha() and so on.

Once all is said and done, I can jump from project to project, language to language, and as long as my framework is in place, I can really simply use the same common "Jay Code" to produce the same objective.
My code might look a crazy mess (and it is!) but most of that is the framework stuff. Once you get down to the actual game's code, you'll notice that a lot of my games use roughly the same sort of functionality. They're very samey, and once you get used to how I code, you'll see they're usually easy to follow.

The framework does all the background stuff, too.
Not only does it handle basic drawing methods, it also handles all the other nonsense that I wouldn't normally be bothered with.
Control methods (Redefinable Keys in BlitzMax, or Multiple-All-At-Once in Monkey), different Screen Resolutions (Achieved within the DrawImg functions), audio stuff (including the recent JMTrackr additions), Menus, Highscores, Badges and much more are all handled by the framework.
This means that every week, when I'm about to start a brand new game, I already have the crappy nasty 95% of the game done.
All I need to do is focus on creating the actual gameplay part of it.

One whole week, and all I have to do is write a piddly little game, then let the framework take care of the rest.

Some things my Framework doesn't do, however, is make the actual Game-Making parts easier.
It doesn't do tilemaps, it won't handle level loading, and it definitely doesn't have a half finished platform engine pre-made and ready to go!

I've found that, if you try to build those for every possibly occasion, you'll usually make it too big, too bulky, and just overdone in every possible way.
Instead, each time I need a tilemap, I code a new tilemap.
People seem to think I'm an idiot, doing it that way, but I've found that each time I start, I get a little better.
I learn little tricks, each time, and get a little better at doing it.
There's also no horrible surprises from old-code that I'd forgotten about.
Every tilemap has it's own code, because every game has it's own set of rules.
*shrugs* That's how I feel, anyway!!

If you're currently attempting rapid-game-development (perhaps you're trying to achieve OneGameAMonth) you'll probably want to spend some time making a nice reusable framework for yourself. If nothing else, it's a fun challenge to try to develop an entire menu/game cycle, with scoreboards and achievements, without actually having any sort of game within!