Mandatory intro text:

You know, I've always thought we needed an Article media type, where members could submit compilations of programming/art/musics, with a moderation queue, and a nice page for itself (With categories).

I was actually about to design this, but then the server move happened, and I forgot to e-mail FSX about it. Heh.

Regardless, I thought I'd write a little bit of advice, specifically geared towards the beginners in the community.

Anyway, it's another "List of 10 things I think you should be doing, because I do them, so ignore them". Seriously, don't bother paying any attention, it should be obvious by the fact that I've won two competitions on this site that I don't know what the heck I'm doing. [/ReversePsychology]

Oh, and anybody not interested in this crappy information can scroll down to the bottom for some blog relating to my project.

1. Choose your tools carefully

This should be obvious to anybody, but it affects the entire development of a project (Duh). When I start any competition, given the time I have and the idea I come up with, I make an educated decision to use the development tools best suited to the task at hand.

By the way, I'm not referring to compilers (Or programs like Game Maker) exclusively, but I'm throwing in art programs, trackers/sequencers, level editors, or whatever you need to use.

A case in point would be choosing Wings3D over Blender in a short competition where I wanted to create a simple 3D game. Blender's interface can take time to work with (And loads of time to learn in the first place), while Wings3D is what I'd call a "Rapid Modeling Suite". It's file formats are easy(ish) to work with as well.

That brings me to another consideration that is inexorably tied in with the choice of tools: The data generated by the tools.

Ask yourself this, when you're about to choose a program: Can I use the data exported from this program in my game?

2. Underdesign your game

Sound ridiculous? Actually it's the only way to get anywhere, even with a long-term project. What I mean by this is: Remove all gimmicks and 'features' from the design document until you're left with a very simple core-concept.

In my case, this was a platformer.

So what am I doing now? I'm creating a stable platformer (I actually have. I can jump around platforms in large scrolling levels, which is platforming IMHO).

Then what? I dress it up. Because essentially, even your fancy never-before-seen gimmick/unique feature becomes a mere cherry on the cake.

And that brings me to…

3. Don't oversell your game

I've seen a lot of blogs already with people stating "I'm going to do <x> and <y> will be in my game and it will be awesome". Ad infinitum. Hype, is the word.

"What's wrong with that?", I hear you whine. Simple: You tell people throughout the development of the game about your ever-expanding to-do list. People latch on to certain features that sound like good ideas, and wonder where they are when you release the game (Because to-do lists are never completed, not even in the professional industry.)

And of course, people miss the features that you said you'd add to your game, but didn't. And that hurts the overall experience.

4. Log your progress

And I don't mean on the net. Keep a local log in a notepad file (Or a WikiPad file, if you want), and use timestamps if possible. It helps you to keep track of what you've done. Also, a nice long log full of progress is a great morale booster.

So what about the internet, then?

5. Be sneaky

As a game designer, you ought to be creating an experience for the player. You want them to see things in your game with 'new eyes'.

So basically, show progress, but don't show too much (Spoilers, in other words).

All my screenshots and videos tend to come from my debug/test rooms, to display new features in my games (If I want them to be shown).

Because what's the point of playing a game if you already know how to reach the Secret Final Boss and defeat it, because of the game developer's series of "Let's Play" videos?

6. Be wary of teams

I know there are quite a few teams in this competition, and I wish them the best of luck; but teams formed over the internet are cursed from their inception.

OK… that was a bit harsh. Let me rephrase that:

Internet based teams lose morale quicker than an On-site team, or even a lone-developer.

I'm not trying to stop anybody from forming teams, but consider: Do you need a team? Does your game need a team?

Even if you have got other people on board to help you, design your game as if you were making it on your own anyway. (See hint number 2 again. Basically: Create the core game first, add frosting later).

7. Know your limits

WARNING: Difficult

This I have trouble with myself. In some cases, jumping into the deep-end can be invigorating and will force you to hone your skills so you don't drown. But most of the time we end up drowning anyway.

Art. Music. Programming. Level Design… All of these things require skill and practice (and patience). Bad at creating 32x32 sprites? Create 16x16 ones instead.

Still looking horrible? Consider looking for a spriter to help you out, read some of the useful spriting tutorials on the net, or go low-detail (ASCII, for instance, like Dwarf Fortress).

Music not your forte? Try licensing (AKA: Asking for permission to use) some free music (SoundCloud is a good place to look). This depends on the rules of the competition you're entering, of course.

Can't seem to make an RPG framework in <insert your language here>? Then consider using a Rapid Development tool like RPG Maker, so you can focus on your game.

Level design is something I can't help you with, though. Because it depends on the game. All I can say is, as with art and music: Draw inspiration from your surroundings.

A word of warning though: Never allow yourself to fall into the bad habit of relying on others to fulfill the roles you cannot. In your spare time, practice your art/programming/music/whatever, and you will eventually improve.

8. Don't leave your players out of the loop

Scaled difficulty. An interesting term for a potentially complex field in the art of game design. Don't just abandon your player at the first screen, use visual cues to help them out for a while.

A sign with an arrow pointing to the right will imply that you can move to the right. But how? (Some people assume that the WASD keys must be for movement).

On the other hand, a sign with a right-arrow key drawn on it explains itself pretty well. And if on the next screen, a sign with the 'x' key appears, that too will be tested and the player will discover how to jump.

(Interesting fact: 9 out of 10 players never read the instructions you provide with your game).

Also, make sure that the player's skill isn't being tested too much at the beginning of a game. Most players are impatient little buggers, and can't stand the sight of a game-over screen to early in the game.

Focus on the 'benign' abilities the player has (Moving around, Jumping, Puzzles, etc), before moving onto trial by combat :3

9. Closed testing is good

Get some friends. If you don't have any, make some. Friends are useful minions companions, providing company, somebody to talk to, and who are often willing to test your game.

Enslaving your family will work too, and their friends can be suckered into working contributing to your game as well.

My brother and his friend often test my games, provide feedback on visuals and aren't afraid to tell me when something just plain sucks.

10. Push for a release

Make your goal this: To create a playable version of your core game concept at least. Once you have that, you can decide "Now I want the game to have <feature x>". This is what we call incremental construction. It works, and means that by the end of the competition you'll at least have something to enter.

And you know what? Even if you didn't finish your game, submit it anyway! Just don't tell anybody that you didn't 'finish' it. They won't know any better, unless you gave them your design documents :3

Your party has slain the Living Wall!

You receive 1590 words!

You find a cookie.

The rest of the blog

Well, now that I've got that out of my system, I can talk about what I did this weekend. And it amounts to something between 'bugger-all' and 'nothing-bloody-much'.

Essentially, I modded Code::Blocks a bit to integrate Doxygen (Tools Menu automation), and converted my crucial comments on the engine to documentation comments (///, //!, /**, etc).

In addition to this, the sword attacks have been added successfully, the HUD background is being drawn, and nothing else.

Though a lot is being considered.

I've already finished the platformer side of things, now I just want to finish some of the fighting code, and modify the room loader to read in the mapcodes from the level file and place objects at the specified positions via a table of static 'template' classes (A good design to follow; Minecraft uses it as well, I see).

My next artwork will probably involve something to cut to ribbons, and something to burn to ashes. Hmm…

* Mega looks up

Oops. I wrote a wall of text again. :P

1760 words.