Traditionally, game development is focused on building up a system, releasing one or two demos for feedback, and eventually coming out with a complete project. In this case, “eventually” usually means months or years down the line.

But what if that could be different? What if a developer decides to generate the complete product first, then improve upon that with subsequent releases? In other words, instead of showing off an incomplete game and trying to finish it, why don’t more people create full games, and then make them fuller?

Hey, it's that flixel guy again! We re-use his pic at every available opportunity.

The idea may sound odd at first, but it makes a startling amount of sense once you dig into it. High-profile developers do it all the time: commonly, it’s the approach used for game development tools and frameworks such as flixel. In these instances, an initial offering is made available to the community and then expanded upon through subsequent versions (flixel, for example, currently stands at v1.25).

Games themselves also fall under this umbrella. It’s not strange to see multiple IGF entrants in any given year sitting on the beta phase, or adopting the label of “work in progress” despite the fact that they seem to be complete titles. Or maybe a long-term project has insisted on keeping its version numbers strictly below that solemn and final 1.0, racking up a long list of nines after the decimal point because they insist that it’s not yet done.

Dyson (now better known as Eufloria) was one of the games to take this approach, as was Spelunky. Both were fairly complete and playable long before their official finals (particularly Spelunky), and both enjoyed considerable media attention and swelling fan bases during their development. These games are only two examples among many.

Dyson (Eufloria) has only just hit the market, but people have been enjoying it for a long time already.

So, how does this paradigm benefit us? Let’s count the ways.

(1) Motivation. More than anything else, releasing and marketing a complete game (even if you’re not yet satisfied with its level of polish) is a huge boost to morale because the product will be acknowledged, played and enjoyed by a far wider variety of people. With this approach, the first version of your game doesn’t merely garner playtesters. It actually secures you a bunch of fans!

(2) Feedback. If you’re prepared to take a few knocks, criticism from “real” players can have untold value. They’re frank, they know what they want, and they’re the best representation of your market because… well, they are your market. (On a side note, if you aren’t good at taking hard knocks, this article may help you out)

(3) Marketing. While demos and previews will sometimes be picked up by game journos looking for news, it’s much easier to construct, promote and hype up a product that people consider relatively complete. And don’t worry about blowing your marketing load too early: if your game’s good, reviewers will come back and do an updated report later!

So if you’re unmotivated, unseen, or otherwise struggling with your game development, consider going with this development style. It’s no guarantee for success, but it’s certainly a fine pick-me-up if you find yourself in a rut.

I used to think that the concept of a simple, straightforward game was rather icky. Things like classic sidescrolling shooters or run-and-jump platformers were, at best, mere paving stones on a path leading to the “good stuff”. Oh, how naïve I was!

The truth of the matter is that many good games out there are simple. To this day, tried and tested formulae are holding strong against exotic RPGs, “revolutionary” FPS mechanics, and convoluted simulations. People find run-and-jump platforming to be as satisfying today as it was back in the era of Super Mario Bros. Many modern racing games hold the same core appeal of Atari’s Pole Position, throwing on bells and whistles like physics and crash models to convince players that they’re somehow doing something new. Sites such as Retro Remakes and the success of games like Lode Runner on Xbox Live demonstrate that people still enjoy core classics. Why add complexity when you already know what sort of cool stuff players go for?

Lode Runner. It's 25 years old, but good design can still keep it fresh.

By using a simple concept for your game, you’re offering yourself several advantages right off the bat. For a start, it’s generally a lot easier to manufacture and polish a product that isn’t bogged down by design complications. Instead of throwing away precious time on building an RPG with fifty billion weapons, enchantments, enemies, and armour combinations, you can craft just a few elements and figure out how to combine them in different and interesting ways. This is a far greater show of design skill than “brute force” content or rule generation. Checking up on Flash portals such as Kongregate will reveal lots of popular games that follow this line of thinking.

If you decide to go along the “retro” route (faithfully reworking a popular concept) there are also quite a few possibilities open to you (as long as you don’t slip up and do something too legally iffy). That’s not to say that you’d necessarily do a cast-iron remake of Sonic the Hedgehog, but taking the core premise and adjusting it to be slightly better can yield some impressive results. Case in point: Tom Sennett and Matt Thorson have a game called Runman, which uses speed and momentum in a way that many reviewers argue was missing from the original Sonic. You’re rarely able to die, there’s no rings to collect, and arguably the game can simply be summed up as “get from A to B in the fastest time possible”. And hey, it does this really, really well.

Runman: Race Around The World is simple, charming, and oodles of fun

Remember: there’s no problem with creating something that has a simple premise, or draws inspiration from classic, “one dimensional” games. Titles which have a simple, easily explained (and easily learned) premise tend to rock people’s socks off: the skill lies in what you do with the game rules that you have, rather than trying to create more just to be interesting.

Game development is about you, your product, and your audience. It’s as simple as that. Unfortunately, many of us struggle with the audience bit — whether it’s through shyness, laziness, or a combination of the two. In any case, something needs to change.

Learning about your potential media outlets is always a good first step. Read on and find out more about where to promote your project — complete with examples of Game.Dev Comp 23 entrants who are using these avenues to successfully market themselves.

Facebook

Regardless of whether or not you actually like Facebook, there’s no denying that it’s a good promotion vehicle. If you have an account, set up a Facebook fan page for your game. Renowned marketers have sung its praises, and Comp 23 entrants such as TF2: Goldrush have used it effectively.

Love it or hate it, Facebook works.

Blog

Though not as powerful a marketing vehicle as Facebook, blogs are still rather useful to keep around. If anybody is interested in your game, it’s nice to have a specific Website to direct them to for additional information.

Just don’t expect blog advertising to swell your ranks: it’s the sort of thing that generally receives attention when somebody is already sold on the concept of your game. Valuable, but not as easy to maintain. Still, Comp 23′s L4D card game has the right idea: in fact, its creator has a pre-existing blog to take advantage of. Bonus points!

Twitter

Twitter is like the lightweight version of blogging: while also arguably more difficult to promote than a well-placed Facebook page, it’s very easy to maintain and is an important way to keep fans in the loop about game updates and future projects.

Here’s a sample Twitter feed from Comp 23, for a game called Pea Adventures. It’s still rather small, but it’s already demonstrating Twitter’s potential for cross-linking and micro updates.

Forums

This point has been drilled in before, but it bears repeating: sign up to a game development community and get involved. You’ll have a free audience, free critiques and free advice. Not to mention that being surrounded by like-minded people is always rad. Starting off somewhere local such as Game.Dev is great, but the more marketing-savvy should also look further afield in places such as TIGSource.

Site Reviews

This may sound like the “big fish” (and looking at IGN may indeed be a bit hopeful), but smaller sites such as IndieGames and even Rock, Paper, Shotgun will gladly check out most indie offerings. Journalists aren’t as evil or snobby as most terrified devs would assume — poke them and see what happens!

I’ve personally enjoyed three reviews on IndieGames without investing any effort (the most recent being Comp 23′s Onslaught of the Electric Zombies), and their general review lineup reveals an openness to newbies and experimentation that is genuinely quite refreshing.

And remember …

When it comes to marketing, just do it. You’ve got nothing to lose, and unless your tactics involve several kittens and a flamethrower, chances are that you won’t do any long-term damage to your reputation.

People are generally more supportive and interested than you otherwise might think: your job is to prove this.

Today, there’s about a bajillion hard-working people out there offering up all sorts of dev tools, programming libraries and miscellaneous cool resources for the average game developer’s use. Many of these resources are — lo and behold — free. Not just free as in “free speech”, but as in “free beer”. And that’s pretty awesome.

Most freeware devs are genuinely quite happy to see their tools and resources being used for someone else’s games. This may well stink of flowers and unicorns, but it’s true: if you’re polite enough to fire off thank-you messages once your project is finished, chances are that you’ll get a bunch of pretty cheerful replies as opposed to legal threats and requests for money.

However, not everything is quite right in the resource-sharing utopia, and one must always be mindful of the following cautionary points:

(1) ALWAYS give credit where it’s due. A simple line in your readme can make the difference between a warm reception and a Limbo of the Lost witch hunt. It’s just like writing an essay — if you don’t want to be accused of plagiarism, you source information properly. It’s not just some law, either: it’s the decent thing to do.

It's time for the illegal adventures of Sir Scammy Stealsalot and his noble steed, Copyright Infringement! Crappy names, we know.

(2) Speaking of Limbo, here’s another piece of important advice: always remember that some resources simply aren’t free. Using a copyrighted image from Oblivion, for example, fits squarely in the “totally illegal” category of resource sharing no matter how many times you throw “BETHESDA RAWKS” into your credits section. Similarly, but less obviously, other file resources may be free for use in some respects but not others. Read the fine print: if a particular resource is only free for non-commercial use, don’t throw it into a game that you’re planning to sell.

(3) If you’re making a fan game or a project that somehow nods to your favourite AAA Xbox title, understand this: you’re entering shaky legal territory. It doesn’t matter that you’re a small-time dev. It doesn’t matter that the game is free, or that you’re making absolutely no cash from it. It won’t even help if you generate the art and sound resources by yourself. The original game developers, if they so choose, have every right to bring down the hammer.

(4) On the flipside, making “Bob’s Super Mario Adventure Land 6″ doesn’t necessarily make you a felon or instant lawsuit fodder (AGD Interactive’s Sierra remakes have done fine enough). And fan remakes are super duper fun! Just understand — and accept — that you may be called out at some point with the “cease and desist” spiel. It’s a slap on the wrist, but you’ll emerge unscathed: assuming, of course, that you weren’t trying to sell anything!

In the end, just bear in mind that there’s a lot of stuff out there. Some of it shouldn’t be used in your game. Some of it should be used rather carefully. Don’t let it scare you off using the stuff that is genuinely free: just approach the matter intelligently. The industry will thank you for it.

Creating a game involves having others play it. Unless you’re a weird, smelly hermit who doesn’t like people or the Internet (in which case you wouldn’t be reading this), you’ll eventually want an audience for your masterpiece.

These guys are totally checking your game out.

Of course, it’s this same audience who will be providing you with feedback while the game is in development: after all, how else will you figure out that your game is way too hard/easy/filled with unicorns? So here are a few points to consider when you’re on that all-important quest for player responses:

Sourcing

As a rule of thumb, it’s best to approach fellow game developers when you’re looking for initial feedback. Not only will criticisms generally be fairer and more constructive, but you’ll be addressing people who are used to analysing games on a deeper level than the average gamer. What you’ll effectively have is a two-in-one bundle: people who can put themselves in the shoes of your audience while still relating to you as a developer.

That’s not to say that you shouldn’t use “ordinary gamers” for your feedback process: in later stages of the game testing process, their input will actually become the most valuable. It’s just a lot easier to get input from people who are in the same merry boat as you.

Intimacy

You don’t have to go cuddle the playtesters in a corner (unless that really is your thing), but it’s a good idea to grab willing participants, sit them down in front of your PC and ask them to play the game in front of you. Watching players fumble through your game can offer pointers that you wouldn’t find anywhere else: you can watch them struggle, excel, or otherwise deviate from your “intended game plan” with greater precision than their own understanding would offer.

There are drawbacks to this method, of course. Your very presence can potentially interfere with a game session, either through intimidation or spoilers. Make yourself inconspicuous, whip out a notebook in some darkened corner, and learn to shut up. Every bit of information that you volunteer during game time will reduce the play session’s integrity: if you warn testers about a boss character before it arrives, don’t expect them to react naturally when it bursts out of the wall.

Selection

Finally, bear in mind that not everyone’s feedback is valuable. On the most obvious level, there will be people who either slander your game outright (“I HAD MOVE BUG UR GAME SUX KTHXBAAI”) or praise it unnecessarily (which is kinda nice, but not exactly helpful). But you have to be picky about constructive feedback, too. On occasion, people will make suggestions that won’t fit with your game’s ethos, or may even just be plain ol’ bad. Sometimes, one group of people will like a certain feature while others don’t, and then it gets really tricky.

In the end, no matter what feedback rituals you follow, it’s important to remember that any given piece of advice isn’t the Word of God™: it’s just a springboard, and the big decisions ultimately have to be made by you.

Approach the matter critically. If you can properly balance faith in your own design with respect for your audience, your game will be far better for it.

To put it simply: new developers make a lot of mistakes. It kinda comes with the territory of being, well, new. If you’re interested in spotting (and avoiding) some very common newbie pitfalls, have a quick gander at this checklist of what you should absolutely, positively, never ever do. It’s educational, we promise.

Don’t build an MMO

If you’re relatively new to game development, chances are that you’re not going to be able to match the efforts of dozens of industry veterans equipped with the latest in computer and networking hardware, slaving away 24/7 in a market where all but the most high-profile games are constantly running the risk of fading into obscurity and bankruptcy. Point made yet?

Look, it may be fashionable, but don’t launch yourself into a behemoth just yet. This advice applies to MMOs, projects of technical wizardry, and Fallout 3 clones. Sure, you may think that you have the time and dedication required. But consult the following professional-looking graph first:

Don’t try this one at home, kids.

Don’t go hardcore

This piece of advice is the bugger that has to be reinforced the most often. People will leap into C++, 3D, machine-level assembly coding, and those abstract DOS tools that nobody really uses anymore unless they’re trying to prove a point (you know the kind) and then produce… well, nothing. They’ve found themselves so caught up in all the little intricacies, that they’re actually struggling to make a product.

There is definitely an argument for using these sorts of tools: it’s a learning experience, to be sure, and the mad rep you get from it will certainly earn the respect of your Grove Street homies. But it’s not the route that you go down if you want to produce results. And if you think that coding 3D geometry from the ground up is cool, remember Einstein’s famous words:

Don’t hide

When you show your game to people, they’re going to give you feedback. Not all of it is going to litter your path with rose petals and chocolate bunnies, so you must accept that your game is going to be picked apart at some point. Even the best devs out there still receive crits for the projects that they make – you’re no exception.

Also, while idea theft is a sad, sad reality in the world of game development (particularly in the more mainstream areas, where legal things like NDAs suddenly become very important), chances are that it’ll probably not happen to you. Seriously: if you have a cool little idea and post it on a small forum somewhere, there is a very, very low possibility that somebody is going to be a dedicated enough dick to go ahead and sweep your idea from under your feet. Stop worrying.

In conclusion: just relax a little more with your game creation! When you’re a beginner, there’s no shame in doing beginner’s stuff. You’ll learn faster, better, and with a great deal more enjoyment. We promise.

If you’re working on an ambitious game development project (which you totally are, so don’t go and hide it now), it’s pretty much guaranteed that you’re going to get lost at some point. Why? Because game development isn’t a trivial undertaking, silly. You have to get yourself organised if you want to max out your game development potential, so here are three easy pieces of advice to follow:

1. Start commenting your code!

Code comments can add clarity. And sometimes flavour.

It may sound cheesy — or painful — but you need to get into the habit of commenting your code. Why? Because it’s very, very easy to remember what your code does for, say, a few days. After that, things get hazy. Writing a “plain language” comment in the middle of your code, such as “//This algorithm lets the character do backflips” (the slashes are comment markers so that your compiler doesn’t throw a fit) allows the future-you to look at the code you’ve written now and go, “Ohhh, THAT makes sense!”

Commenting your code also prepares you for work in a team-based environment: after all, how is another person supposed to interpret the gobbledegook that you’ve scrawled unless you leave an explanation?

More code commenting evangelisation over here.

2. Get a design doc!

Design documents are the theoretical skeleton of your game, outlining rules, interactions, and classes, so that you have a nice overview of everything before you dive in and realise that you have to rework entire sections due to poor planning.

“Proper” design docs are pretty technical, involving scary stuff like state diagrams, interaction events and data modellers. For hobby dev, however, you’ll want to do something a little less intense: just get yourself a notepad document where you can scribble all of your game design ideas, flesh out potential obstacles, and try to make predictions about what the game will need.

You can even go wild and use the doc as a canvas for free writing.

3. Start a dev diary!

A dev diary is a very flexible concept. It can be personal and informal, or public and structured. It can even take the guise of a simple forum thread, where the game’s creator regularly posts updates about the project’s progress.

Writing about the work that you do can have a positive effect on your productivity: it forces you to think about what you’re doing and how quickly you’re achieving your project milestones. This promotes a more disciplined, deadline-oriented mindset.

If you get more ambitious, it can even be used as a marketing tool for more high-profile game development projects. For a great example of this, consider the Wolfire Blog.

A screenshot from the Wolfire dev diary. Pretty-looking, yeah?

And don’t forget …

Have fun with all of the above! Make witty commentary in your algorithms. Sit down for ten minutes and scribble the most random ideas you can think of in your design doc. Start working on a Starcraft-themed brawler and post up your dev diary for entertainment value and great justice.

Get organised in a fun way, and the rest will follow!