28 May 2005
Every modder should read this!
Ever since Quake, I’ve tended to follow news about mods quite closely - it’s really cool to see what’s being developed. There are some really good ideas out there (and lots of bad ones), so it’s interesting to see how they progress.
However (as always) some things about them do annoy me. Or more specifically, I believe these mods would progress better if they conducted themselves in different ways. I’m specifically thinking about organisation and publicity.
Hence, I propose my list of suggestions.
Start small
For the first few weeks/months of your mod, you’ll only need a few people, maybe even just yourself. This is the chance to establish the single major feature of your mod, the primary purpose of it’s existence. Create the defining feature. This is very important. Without it, there is no point having a dozen maps, models and thousands of textures.
Start big
If your mod doesn’t differ considerably from anything else, you might as well join forces with a mod or game of similar style. There are enough CS-style mods out there. You have to be different to survive.
A map is not your mod
One of my biggest pet peeves. Just because you’ve got a single map to show does not mean you should show it, especially not before it’s playable in the context of your game. You should never show something until you’re absolutely sure you will deliver. Soon. Your first screenshots should be of the game, not a feature. Model and character renders upset me unless they’re in-game.
A model/texture/sound/soundtrack/person is not your mod
Just because you’ve got [something] to show does not mean you should show it.
Simplicity is key
The simple ideas work the best. Combinations of them work too. Being able to describe this in a single sentence is good - this should be enough for the player to work out what they’re meant to do as soon as they join the game.
Generally, a player will give a game 5 minutes to get them hooked. If they spend all this time wondering what to do, you’ll lose them. The best online mods are those that can be enjoyed in short bursts or long hauls. If someone plays for 10 minutes, make sure that 10 minutes was worthwhile.
Websites come later
So you’ve thought up your mod and you’ve made a website. Terrific. Where’s that mod again?
Maintain secrecy
Best way to maintain interest: hide things. Daily updates are good for some things and not others. Everytime you reveal something, it should be exciting. But always keep some things secret until the very end.
Develop iteratively
Do not aim to have a fully complete mod. Aiming for a complete, fully-featured game from the start is a bad move. You should release in stages, utilising the lessons of each to direct where you go next. Each release should be completely playable. The following releases should consist of major improvements. The Counter-Strike major/minor beta model is a perfect example of how this works. Major releases (BETA X) contain many new features and big improvements compared to the last major release, whilst minor releases (BETA X.Y) feature fixes made in response to the last major release. This approach lets you identify problems early on, allowing you to improve and change direction, whilst also maintaining an interested user base.
(Finally) A bunch of developers does not a mod make
Throwing people at a project does not lead to the project being completed. You should grow your team very slowly, as the project grows. You’ll only need a very small team initially.
Every modder should read this!
Ever since Quake, I’ve tended to follow news about mods quite closely - it’s really cool to see what’s being developed. There are some really good ideas out there (and lots of bad ones), so it’s interesting to see how they progress.
However (as always) some things about them do annoy me. Or more specifically, I believe these mods would progress better if they conducted themselves in different ways. I’m specifically thinking about organisation and publicity.
Hence, I propose my list of suggestions.
Start small
For the first few weeks/months of your mod, you’ll only need a few people, maybe even just yourself. This is the chance to establish the single major feature of your mod, the primary purpose of it’s existence. Create the defining feature. This is very important. Without it, there is no point having a dozen maps, models and thousands of textures.
Start big
If your mod doesn’t differ considerably from anything else, you might as well join forces with a mod or game of similar style. There are enough CS-style mods out there. You have to be different to survive.
A map is not your mod
One of my biggest pet peeves. Just because you’ve got a single map to show does not mean you should show it, especially not before it’s playable in the context of your game. You should never show something until you’re absolutely sure you will deliver. Soon. Your first screenshots should be of the game, not a feature. Model and character renders upset me unless they’re in-game.
A model/texture/sound/soundtrack/person is not your mod
Just because you’ve got [something] to show does not mean you should show it.
Simplicity is key
The simple ideas work the best. Combinations of them work too. Being able to describe this in a single sentence is good - this should be enough for the player to work out what they’re meant to do as soon as they join the game.
Generally, a player will give a game 5 minutes to get them hooked. If they spend all this time wondering what to do, you’ll lose them. The best online mods are those that can be enjoyed in short bursts or long hauls. If someone plays for 10 minutes, make sure that 10 minutes was worthwhile.
Websites come later
So you’ve thought up your mod and you’ve made a website. Terrific. Where’s that mod again?
Maintain secrecy
Best way to maintain interest: hide things. Daily updates are good for some things and not others. Everytime you reveal something, it should be exciting. But always keep some things secret until the very end.
Develop iteratively
Do not aim to have a fully complete mod. Aiming for a complete, fully-featured game from the start is a bad move. You should release in stages, utilising the lessons of each to direct where you go next. Each release should be completely playable. The following releases should consist of major improvements. The Counter-Strike major/minor beta model is a perfect example of how this works. Major releases (BETA X) contain many new features and big improvements compared to the last major release, whilst minor releases (BETA X.Y) feature fixes made in response to the last major release. This approach lets you identify problems early on, allowing you to improve and change direction, whilst also maintaining an interested user base.
(Finally) A bunch of developers does not a mod make
Throwing people at a project does not lead to the project being completed. You should grow your team very slowly, as the project grows. You’ll only need a very small team initially.
