Recently I started using Project Wonderful to advertise Immortal Defense, which is fun but not very effective, probably because currently most Project Wonderful ad placements are on webcomics.
On the good side, it's very cheap: about one cent a click, or less. $60 can get you 6000 new visitors, which is more than I get a month already, so basically doubling traffic for so little is attractive.
On the down side, they rarely stay very long, they just look because they're curious, and typically don't download anything (only around 6% for me). So you'll probably lose money, and not make as much back as you spend.
However, I don't regret it, because it's fun and I do know that at least one person found out about the game through it, and enjoyed it. So I think of it as money "donated" toward letting more people know about the game, without the expectancy that it'd make as much back as it took.
In general indie games are not good to advertise, because of how low the conversion rate (sales per download and money per sale) tends to be. Advertising tends to work best when it's for expensive products or services, or for recurrent customers. So just think of it as throw-away money, better than spending it on a new game or a larger TV or candy or something.
I can recommend one thing though: it's better to use campaigns with lots of cheap ads than to use larger sites with expensive ads. I've tried both, and the smaller sites tend to work better. I'm not sure why, I suspect it has to do with the owners of the sites themselves being more curious who is advertising on them than the readers of a site are, leading to tons of visits from site owners.
(BTW, check out the sidebar to this entry for an easter egg -- it only appears for this entry.)
For an interesting bit of indie game developer drama, notorious braggarts J Force Games challenged some indie group named GyroVorbis (?) to a contest: which of their current in-production games will get a higher average review score after release?
GyroVorbis was having none of it though, and perhaps wisely refused the challenge, instead making a small game mocking part of their game mock JForce Games.
The videos are entertaining to watch, especially if you've heard of J Force before. I think people tend to take J Force too seriously, GyroVorbis included. They're just kids having fun and making games, nothing you should hate them over.
I talked to their marketing guy over instant message today and he's much nicer and less arrogant in person than he is in his videos. And he does seem to know a lot about marketing, so he's not all just hot air.
All in all, I'm happy J Force Games exists, they liven up the indie game community.
A lot of people don't design their games first in any written form, they keep it all in their head or just make the game up as they go along. That's fine, but some games are too large for that, and some games take so long that you begin to forget some of the stuff in your head. If you have a team, a design document helps everyone as a reference source. So I thought I'd explain how to write a design document.
Some people feel that writing things down is restrictive, but I don't think so myself, I find it makes me more creative to have all the ideas written down in front of me, rather than trying to come up with things as I need them. And it's not as if you design the game once and then make it without editing the design at all, the design usually changes as the game goes through development.
The format doesn't really matter, but I find a Wiki to be the most useful, because it can be edited quite easily as needed, and because it can be shared with others on the team online.
The best two I've come across are MediaWiki (which Wikipedia uses) and DocuWiki. DocuWiki has the advantage that it doesn't require a MySQL database, it runs entirely on text files, so it can be run on free servers without any MySQL benefits. There are also wiki's which can be set up on your hard drive, but I find them less useful because I usually work with others online on games.
I'd recommend using the design document primarily for "lists" -- the type of list varies with the type of game, but often it includes a list of enemies, a list of playable characters, a list of areas or levels, a list of the music the game will need, and so on. Typically my design documents are around 80% lists, and around 20% description of the game in general.
Each item in a list, for example an enemy list, wouldn't just list the names and that's it, it'd also describe it to some degree: what the enemy does, how it moves, strategies the player might use against it, places where the enemy appears, etc., typically a paragraph or two is enough.
It's also important to think about the overall idea of the game, what it's trying to accomplish as a whole, and include a few sections on that.
The length of the design document varies by the complexity of the game; I've written design documents which were only a few pages long, and others which were hundreds of pages. Try to include enough information about something that when you get to coding something or drawing something you have a good idea about what you're trying to do, but not so detailed as to include too much unnecessary information.
Also, it's a good idea to make the game and the design document at about the same time: don't spend a few months making the design document and then a few months making the game, because that just leads to laziness, it's better to start the game prototype first, work on it every day, and occasionally add to the design document during the process of creation. I find that it's easy to fall into the trap of all design no actual work, so try to avoid that.
Here's the design document of the game I'm working on now as an example; it's incomplete and contains spoilers so if you do check it out skip the characters and story section. Although the game of course will change in the future, so don't take the design there to be a good representation of how the game will ultimately end up. But reading that can give you a good idea of the format I use and what a design doc looks like.
Here are two good examples of design documents I've come across:
- Planescape Torment's design document
- Metal Gear Solid 2's design document
I'm sure there are more but those two are the most interesting I've read so far.
The main use of design documents is as a primer for working on parts of your game. For instance, when working on a new enemy, you can go and look at what you wanted that enemy to do, even if you wrote that part 20 months ago, and then have an idea about how to proceed, rather than having no starting point. It's not meant to be something restrictive, don't feel as if you have to translate the document directly, it should work more the way an outline to a novel works.
Also, don't use it as a substitute for a to-do list: you'd still probably need a separate to-do list for all the tasks you want to do next for the game, to list bugs you need to fix, and so on.
Another great use of a design document is to share it with others on the team, get their input, and then change parts of it after discussing the game, to give the team a shared vision of what they want the game to be like. That's more difficult if there's nothing written down, because often team members have completely different ideas of what the game will be like if they don't have a shared reference.
Most likely the design document will be more ambitious than the game itself, if you want to get the game done at all. It's easy to list 100 enemies and all the ideas you have for each, but it's harder to code them all in, so generally parts of the design document probably won't make it into the game. That's true of the MGS2 and Torment documents above, and it's probably true of most design documents, so don't be afraid to "over-design" with the intention of only including the best parts of the design in the actual game. I.e. don't be afraid to write up descriptions for 100 enemies, and then just use the 40 or 20 best ideas in the game. Don't feel that a game is only complete if it contains everything in the design document, it can be complete even if it only includes half of the stuff in there.
Quite Soulless is an interesting game I played today, I found it on the indiegamer.com forums. It was created by a single Russian individual, creating his dream game.
As expected, everyone there laughed at it. But I love it! Just look at that trailer!! So I'm posting it here for you all to love too.
"My dreams have the strange essence."
"Sometimes they scare."
"I don't know where to go. I'll go to you!!"
Here's the game's site: http://www.quitesoulless.com/index.htm
I don't actually recommend playing it though, because it's barely playable. Here's a video I made of myself playing the game, and I narrated it a bit afterwards. Forgive my boring voice, it was my first Let's Play and I'm sure I'll get better at narrating stuff in the future.
There are many 100 Games in 10 Minutes videos on YouTube. I created my own, for Game Maker. But here is a collection of them.
Note I didn't make all of these, only the Game Maker one. There are still plenty of consoles and game engines missing, and I'd like to do 100 Games in 10 Minutes videos for the following: Ohrrpge Games, Indie (Independent Games), and Atari 2600 Games. I also haven't seen these consoles with 100 games in 10 minutes videos yet, which is surprising: Sega Saturn, Dreamcast, Sega Master System, Sega CD, Gameboy DS, PS3, Xbox, Xbox 360, Atari Jaguar, etc., though perhaps those consoles don't have 100 good games worth showing? Anyway, hope you enjoy this collection, and email me (rinkuhero at gmail dot com) if you have any additions.
