Every Single Week

Not Good Advice

The following is not advice, and should not be taken as such.

People often ask me how I manage to do AGameAWeek. Particularly, how I manage to cram everything into a single week, and then somehow manage to do exactly the same thing every other week, without going crazy.
What follows might possibly help you understand a little more of what goes on in the world of AGameAWeek. Or it might just be a whole bunch of rambling waffling text.
Not sure!!

-=-=-

Language

Keeping it "old-skool"

In the world of AGameAWeek, speed is essential. If I have to spend twenty minutes trying to figure out how a command is supposed to work, that's twenty minutes I'm not getting any coding done.
Familiarity is the key, here.
I grew up in the 80s, in a world full of BASIC. I learned about keywords, variable and loops the old fashioned way.
As systems got more powerful, so did the forms of Basic.
Today, the Blitz/Monkey set of programming languages are my coding environments of choice, mostly because they're an evolved form of Basic.
I'm comfortable with the syntax, the keywords are still mostly familiar, and I find I can usually transform an image in my head, onto the PC, in a relatively short amount of time.

I understand that people learning today, might be more familiar with GUI driven languages. I can see the appeal in those sorts of languages. But they just aren't my sort of language. I find myself struggling to get any actual "coding" done, when I'm instead spending hours at a time trying to "build a scene" or "define a layout". In Basic it was CLS, and then a bunch of drawing commands! I find that much easier to deal with, but that's a personal preference.

-=-=-

Tools

They're not the best tools. They're simply the tools that I use.

The best tools for the job might not necessarily be the ones that everyone else suggests. In my experience, the best tools are those you're comfortable using.
If you've learned all the keyboard shortcuts for one particular program, and can use it swiftly and reliably, then that's the best one for you to use.
If you're just starting out, and haven't yet had any experience with a particular type of tool, then pick one, any one (preferably free/cheap) and then stick with it until you've gotten the hang of it.
Jumping around from one package to another will only mean you'll be spending all the time relearning how to use each and every one, whereas if you stick to a specific one, you'll grow accustomed to it pretty quickly.
Be sure to make good use of the keyboard shortcuts. That's what they're there for!

For art, I use PaintshopPro 7. It's a version I bought whilst still at college, so that makes it at least 11 years old! Scary!
I've recently also started using the App SpriteSomething on iOS. It's handy for doodling quick little sprites on the go.

For sound effects, I use a combination of FLStudio, CoolEdit and BFXR. FLStudio or BFXR are used to quickly generate the little blips and boops, then CoolEdit is usually used to add reverb, pitch bending or other after effects, as well as compressing everything down to smaller filesizes.

Music wise, it depends on the sound I'm going for. Mp3 audio is usually done in FLStudio, Mods are done using ModPlug Tracker, and anything else is done using my own JMTracker, which creates nice random twiddly tunes as the game is played.
For what it's worth, you won't find a lot of music in my games. I prefer to listen to my own music collection whilst playing games, and generally switch off the ingame music whenever possible.

-=-=-

Code Style

It doesn't matter how clean the code is, as long as you know where all the bits are.

I have a terrible memory. I can't seem to hold thoughts in my head for more than about ten minutes, if I'm lucky!
But my Code-memory seems to be a completely separate part of my brain.
For some reason, I seem to have the uncanny ability to put myself back into the exact mindset I was in, whenever I last had a particular piece of code open.

I can jump through the file, pinpoint a particular section of code, and remember exactly what each little parameter of a function will do.
Over the years, this has led to an absolutely appalling code style. If anyone dares to look into my code, they'll be horrified by the methods that I use.
I rarely comment, I use hardcoded arrays EVERYWHERE, and those oddball 80s style 1 or 2 character variable names that everybody hates, are a particular favourite of mine.
For anyone else looking in, it's a freak show.
But for me, it works.
And since nobody ever DOES look at my code, it does it's job.

-=-=-

Reinventing the Wheel

Constantly rewriting the same thing, rather than making overly complex functions that you'll never actually use.

Everybody tells you that it's a good idea to write a reusable function, and who am I to argue. If you know something's going to be showing up again, make it a simple function, then strip it out so you can reuse it later.
This is good practice.
But sometimes you can go overboard.
A good example is a Tilemap Engine.
What would you want a Tilemap Engine to do?
It might do multiple layers, parallax scrolling, animated tiles, colour cycling, collision.
.. Or it might not, and instead be just a flat scrolling map.
It's hard to know before hand, so any good reusable Tilemap engine will have to account for all possibilities.
Your "simple" Tilemap will inevitably end up spanning thousands of lines of code, to account for every possible circumstance.

In my eyes, that's a mess!
Instead, every time I need a Tilemap, I redo it from scratch.
It isn't hard to achieve. A simple little for-loop, screen boundaries, grid points, keep it simple.
And if you need any special abilities, you can simply tweak the code as you go.
Once you've done a whole bunch of these things, it becomes second nature, and you can quickly whip up a Tilemap, particle engine, or anything else, in a few minutes.

-=-=-

Include the Includes

What works for one might not work for the other fifty.

Similarly, includes are handy. For the past few years, I've built a "framework" in my current language, which takes care of sprite drawing, multiple resolutions, scoreboards, menus, and all those other things that are typically the same on all projects.
The problem you find with AGameAWeek, however, is that some things aren't necessarily perfect for all tasks.
My current framework, for example, includes a set of functions to draw and use an onscreen DPad. But a DPad that feels great in one game might not be as good with a different game. The other game might need a more analogue style slider.

If all the code used a single "include" base, this would be tricky to implement, without breaking either of the two game's code.
If I dare to tweak a function for the newer game, it might break the old one, thus making future updates impossible.
For this reason, I've learned to keep all my includes within the individual game's sourcecode folder, so that every game has it's own unique copy.
It starts from a simple copy of the template folder, with framework and everything ready for use, then each game is created in it's own unique environment.
All major useful changes are then put back into the template, for future reuse.

-=-=-

Ideas

Head scratching time in the middle of the night.

My ideas come from a variety of sources.
One of the most frequent methods is the "start coding something, and see what happens" method, which usually involves me trying to create random swirly effects on the screen, somehow, then attempting to make it playable, somehow.

Sometimes, I might open up my art package, and start plotting random points until a character emerges, then creating a game around that.
Other times, I might be fiddling around with BFXR, generating random sound effects, when a particular effect jumps out and an idea pops into my head.
A recent source of inspiration is Twitter. Having so many random tweets in your feed can occasionally lead to odd phrases sticking out, and silly ideas forming.

Whichever way it happens, the challenge is to act on it as quickly as possible, before you've forgotten what it was! It's probably also a good idea to jot them down somewhere. I have a fairly large "Sticky Note" pinned to my desktop, with a whole lot of random phrases on it!

-=-=-

Freeform

It doesn't matter, as long as it's fun.

Since AGameAWeek gives me the freedom to constantly try new gameplay styles and ideas, it also brings the ability to develop games in a much more freeform nature than other developers might like.
I don't ever plan out a game. I never have a target, or a specific set of goals.
Things like number of levels, and general layouts are usually generated on the fly, and I tend to work within the confines of what gameplay is emerging from the code, rather than trying to fit the code into a pre-designed set of parameters.

The same sort of thing goes when building pseudo-random generated levels. I'll tend to get some sort of rough level building to work, then fit my game around it's output, as opposed to struggling to get a level generator to work towards a specific style.
It's quicker to build around what you can easily achieve, than struggle to get a certain kind of output.

-=-=-

Schedule

Cramming everything into a tiny amount of time.

The only specific point in my schedule is "New game release : Tuesday morning". Everything else is done as it occurs.
I tend to generally start a game on a Friday, and work on it over the weekend, but sometimes I'll have a great idea earlier on in the week, and spend more time on it.
Every so often, you'll spot a terrible "quicky" game. Those are usually started late on a Sunday and rapidly cobbled together within just a few hours! As anyone who's tackled a Ludum Dare style coding event can tell you, these sessions can be intense, and fraught with danger. But that's half the fun!

I try not to set myself a specific schedule, though. Good ideas don't come from sitting down at a pre-determined time, and forcing them out. They're spur of the moment, random things, and can happen at any time. Go with the flow!
.. Unless it's getting too late, then you really need to come up with something!!

-=-=-

Failure

Anything is possible, as long as you bother to attempt it.

Doing AGameAWeek, I've learned that failure is a possibility. And not only is it possible, it's sometimes fun to do! What most developers tend to do, is imagine an idea that will definitely work, and then build the game.
AGameAWeek allows for the alternative. Since I'll be starting something fresh, the next week, it doesn't really matter if a game idea doesn't work out.
As such, I have an almost infinite supply of game ideas.
Anything that other people have thrown out, I can usually give it a whirl.
If it fails, it's no biggy. Next week will be another game.

This is something other developers can't afford to do. You can't devote months/years of your life, developing a game which might fall flat on it's face. And when it does, it can be devastating. Living with failure is a very difficult thing. I think I'm lucky in the fact that I've learned to just move on, but even still, it can occasionally be tough when a project I really enjoy seems to get completely ignored.

Motivation is the key, and my motivation is simple.
.. Next week's game could be awesome!