Difference between revisions of "How not to start a mod"

From Cube Wiki
Jump to: navigation, search
 
(No difference)

Latest revision as of 16:59, 12 December 2014

How not to start a mod: a very good writeup by Aardappel and eihrul on the forums, wikified here. Compare it to How to approach modding.

Since this seems to come up a lot, here is how to fail spectacularly with any particular modding idea:

Premises:

  • Propose starry-eyed idea
  • Ask for significant help to start the project

Conclusion:

  • Always fail

Summary

  • Ideas are cheap. Everyone has cool ideas.
  • If you make a mod, you must be willing to do the majority of the work by yourself.
  • Any skill your mod requires you need to have yourself.
  • Anything you plan to do, plan to do entirely by yourself.
  • Present your project only after some significant work has already been done.
  • It's usually better to team up with more skilled people and follow their lead. Working on a finished project is worth more than a failed personal project.
  • Do not release screenshots, etc. until they are at least up to par with Sauerbraten's default maps.
  • If your screenshot is the ugliest, throw the map away and start again. No one wants a map that goes backward in quality.

The reality is of any volunteer project is: if the people you want to help are significantly more skilled than you, or just significantly skilled, they will be more likely to work on their own projects than bother at all helping you.

Why is this? Ideas are cheap. Everyone has cool ideas. But very few people have the skill to follow through with them. When they do, they're usually not very altruistic about using them for the good of someone else.

Leadership skills matter not for starting something. People won't take marching orders from someone they perceive as less skilled. Leadership only matters in the endgame, when you have a lot of stuff to manage.

So what does this mean for someone wishing to start a mod or just volunteer project in general (one might say any non-commercial project, particularly open source ones)? It means: You must be willing to do most -- often all -- of the work yourself'.'

And when the critical mass of your project makes coming across it by accident via word-of-mouth unavoidable, then you'll start to get... a few, but very limited number of somewhat skilled people proposing to help. Very rarely, you might even get one or two skilled people.

The breakdown:

Of your users, a very small amount will express interest in helping. Let's say ten percent, being generous. Of those, a smaller amount will actually try to help you. Again: ten percent. Extremely generous. Of those, a much smaller amount will be capable of doing what they're trying. Ten percent. Of those, a much smaller amount will be capable of doing what they're trying to do well. Ten percent.

So, being overly generous, maybe one hundredth of your users will help you. So unless you have several hundred users, there is very little chance you will get much help. BUt the bigger and more prestigious your project is the more the ratios will grow.

Consider the whole Cube and Sauerbraten project: it is about six years old by now. It's been quite successful by anyone's standards as a game/engine project (millions of downloads, etc.), yet even with this project there are less than twenty truly dedicated people -- programmers, artists, etc. (Level design has always been easier because this project was designed as the ultimate level design tool).

So if such a huge project gets so few contributors, even that many years in, why should your project get any right at the start?

Consider the mods that have been attempted for Sauer: there has been only one really successful one so far, Red Eclipse , and that worked out because a couple very skilled people got together, managed to keep the same vision, and, more importantly, managed to keep determined enough to continue it.

When you think you have something 80% finished, it's probably closer to 20%. Finishing something and polishing it takes a lot of determination, and usually isn't fun. It is work. Why do you think game programmers get paid like they do?

    • Any skill your mod requires you need to have yourself.

This includes C++ for gameplay changes, modeling and exporting for art, etc. Similarly, this means that the less skills your project requires (e.g. a map or map pack), the more likely you will be able to finish.

    • Any project you do, plan to do it entirely by yourself.

Any people that will want to help you at some stage will be a bonus, but don't rely on it.

    • Present your project only after some significant work has already been done.

People may see your skill and determination, which makes them ten times more likely to participate.

    • If you want to work on a mod, unless you are super-skilled, it's better to team up with more skilled people and follow their lead than start your own.

Yes, it's attractive to do your own ideas, but there are infinitely more ideas than means to execute them, so something has to give. Having made a contribution to a finished, polished project of someone else is worth so much more than a failed personal project.

This one goes not just for mods, but for anything:

    • Do not release screenshots, etc. until they are at least up to par with other good maps.

Do this test: compare a screenshot of your map with the ones for the maps on the main Sauerbraten page .

    • If your screenshot is the ugliest, throw the map away and start again. No one wants a map that goes backward in quality.