How to release a mod … 1. Timing

This is the first part of our tutorial about how to release mods. This part will cover aspects of organisation and project scheduling before your actual release.

Timing

Schedule

As you are working on a mod, it’s always worth thinking about a general project schedule. Our estimates are always off and postponements are natural, but it still gives you some feeling of being in control. Always remember to leave room for beta testing. I suggest at least 2 months, for CTDP 2006 we tested almost 6 weeks. We got caught in a different problem, over-tweaking. Long testing is good, but having no deadline is also bad. We got to a point, where we were going in circles fixing little and tweaking the existing stuff to get to a perceived level of perfection, that wasn’t possible to reach at this point. You may not touch the basics anymore, or you have a huge postponement, but you try to squeeze the best results from what you have and you are left with the feeling, just a week longer and you can get it even better. Sometimes these last-minute changes can make or break a mod.

Also, even with quite a big testing team, there is still no warranty that the mod will be bug free. There will always be glitches and you just pray that they don’t brake things. Preparation is important and good organisation helps, but a risk remains always.

Have a date and a fallback

So, when your mod is coming to an end and testing has begun, you should look for the right moment to quit testing and release. As mentioned this is tricky. Too short testing leaves the mod buggy, to long testing can get it stalled in a tweaking-loop.

So when you are looking for this right moment, take your own schedule, and the calendar of your co-workers and see what day suits best. At CTDP it’s pretty much always holidays during the week or on a weekend. Release day will be a long day, so reserve the time. This date should be set about 2-3 weeks in advance. You see early enough, if your team can meet it or if they need longer. Always assume the second case and think about fallback dates. If the first release date can not be met, what would be the best candidate. Make sure all relevant people are online on this day.

Be vague on the dates

Now some insider knowledge, which hopefully doesn’t kill me.

Even though internally you are discussing dates and planing for the release, don’t mention any candidate release dates outside of the team. Obviously the question in the community, when is the mod going to be released is something between a running gag and a meme. Sure you do know an answer and you’d love to tell, but don’t. It may not feel right, but this is one instance, where it is better to remain silent. Otherwise, dates spread, rumors, expectations and when those aren’t meet, you can easily get the blame. I think it’s a fine line to walk and I consider it a necessary white lie. Don’t put yourself on a pedestal, be fair and don’t tease. Be respectful.

Be vague, you can give a rough estimate. For example, leagues asking for mod release dates should be told honestly, if a mod can be ready by date x.
Give absolute dates only when you are absolutely sure to meet them. Otherwise, try to convey releases by increasing the rate at which you report about the project, how other people get access and write about betas. In our devblog, we posted many internal stuff from our betatests to convey the message we are getting close, without the need tell a date.

So far nobody killed us for not answering Release-date-questions. Something we had to learn the hard way. We tried several times to release on a specific date and it only worked 2 out of 5 times. You can do it if you are absolutely sure to meet the date. Announced releases are great, they are epic and because of the expected traffic even a bit harder. They have a price and if you are not sure, I wouldn’t take that risk.

Load estimation

Depending on if and how you announce the release date, you have to calculate with different load curves.
An announced release will give you very many downloads on the first day and this amount decreases quickly in the following days. Surprise releases go slower. People need time to find out, that you released and so downloads are spread over a longer period.

Be aware of the load during the first hours.
Calculate how big your mod is and how many people you expect to download it in the first two days. If you don’t want people waiting and complaining, be aware to set up enough mirrors and organize the servers accordingly. Based on the download stats from our former mods CTDP calculated with 5000 downloads in the first day. With a 1.35Gb mod, this creates up to 6.7TB traffic in the and just assume about 1000 people downloading in parallel. Everybody wants to have it asap and so the bandwidth required is quite big. By the way, based on the torrent we ran we had about 4 TB in the 3 weeks. This figure is only for BitTorrent not counting any download servers.
Think about releasing by night. People who follow your RSS, Atom, Twitter or whatever will be informed imidiately and can download the mod right away. So by the morning, alot of people already downloaded the mod and the big load is reduced a bit.
If you do a torrent release, this also has the advantage of letting the first people download the mod and become seeder very early. So you have a very good share ratio once the big flood begins.

The second part of this tutorial will cover more about File Distribution methods and their advantages and disadvantages.