Five things you'll forget to do before you release
Part of a Series on Campaign Design by Nuclear1 |
|
(Original post by Nuclear1, here.)
Alright, so your campaign is nearly done. You've got everything you need for a great mod--shiny new ships, a compelling storyline, memorable characters. The mod's certain to be an instant hit.
So you log onto Hard Light, you head to the Missions and Campaigns Forum, and you start a new thread: RELEASE: MY AWESOME MOD.
You go to sleep, satisfied with a job well done. After dreams about people falling in love with your campaign, you wake up in the morning, eagerly refresh Missions and Campaigns (because, let's face it, you never even logged off), open your thread, and...
Oh no.
- "CTD for me on Mission 2"
- "There's no objectives for the third mission..."
- "(epic long FRED error dump)"
- "dude, it's spelled T-U-R-R-E-T"
- "ah god this thing is a nightmare"
It seems, in your eagerness to post your campaign, you missed a few things. Well don't worry, because I'm going to tell you exactly what it was you forgot.
Contents
#5 -- You Didn't Make A .VP
The Complaints You'll See
- "Why is the mod so big? Couldn't you compress it?"
- "Which folders do these files go in?"
- "Did I get all the files...?"
Why This Is Important
.VPs are, quite simply, an easy way to manage your campaign's files. Instead of you (or, worse, the users) having to create individual folders and sort out the files, you can compile a .VP and let that one file sort out all of your organization issues. The process of making a .VP essentially involves you organizing the files in the same way you would without one, but it all becomes compressed and neatly organized in one file.
Easy for you to organize, patch, and keep track of, and easy for the user to install.
Crap, How Do I Avoid This Problem?
Head on over to FreespaceMods, and find the VP Editors section in the downloads (or just click me). VPMage and VPView are essential tools. VPView allows you to open and extract files from a .VP, and VPMage allows you to build a .VP
#4 -- You Didn't Make A Mod.ini
The Complaints You'll See
- "Do I need mediavps for this?"
- "It said it can't find a ship class..."
- "This needs FSPort? I'm not copying into my FSPort folder..."
Why This Is Important
You don't want to ruin people's Freespace folders. Freespace Open is touchy enough when it comes to installation that you don't want people improvising to get your mod to work. It'll break their installation and cause them to come after you with the nonfunctional flamethrowers. They don't actually shoot flames, they're filled with water, but they still hurt when you get clubbed by angry HLPers.
The mod.ini file allows you to configure how your mod looks when it's selected in the Launcher, and, more importantly, it designates which mods it's supposed to use in conjunction with yours. Say, if your campaign is based on FSPort, you would designate FSPort under the multimod section.
Crap, How Do I Avoid This Problem?
Nearly every single mod released in the last year has a mod.ini file included. You can simply copy/paste in your mod's folder and makes changes as needed. Or, if you want to learn how mod.ini's are constructed and do it yourself (not recommended), you can head here.
#3 -- You Didn't Test On A Recent Build
The Complaints You'll See
- "CTD on mine...using a nightly"
- "dude which build did you test this on?!"
- "*unbelievably stupid long error dump message*"
Why This Is Important
As our wonderful Freespace Open programmers continue to work on the Source Code, they publish builds on a regular basis. Lots of people have a habit of working with an older build (one of these may be you, in fact), but many choose to update fairly regularly with the Nightly Builds.
While changes aren't typically drastic between builds over the course of, say, two weeks, or even a month, if you're still using a build from 2010, your mod is likely to have compatibility issues with some of the more recent builds.
Crap, How Do I Avoid This Problem?
Update your Freespace Open Build on a regular basis. It doesn't have to be an update every time a new build is released, but once a month or once every two weeks is a good way to go. When it comes time to test, download the most recent build, no matter when you last updated, and test your missions on that. You don't necessarily have to build-creep, but keep a fairly recent one handy.
You can also have playtesters with other builds do your testing for you, which brings us to our next topic...
#2 -- You Didn't Test, Period
The Complaints You'll See
- "Mission X is way too easy/hard"
- "There's no RTB directive...."
- "i accidentally mission 4 is this bad"
Why This Is Important
Testing may very well be the most important part of finalizing a mod. It allows you to weed out all of the nitpicky or show-stopping bugs in your campaign, and it shows you did a damn thorough job in making sure your campaign is top-notch. It allows you to avoid the absolute headache of having to continually patch annoying problems that should have been caught on the fifth or six playthrough of a mission.
Let's face it, when you design a mission, you know how it's supposed to play out. You go into the mission knowing how the player is supposed to react to everything that happens, and you play the mission how you know it's supposed to be completed. The end-users don't know this, however, and if they play even remotely differently than how you intended, they may break the mission or cause some bug to pop up that you hadn't expected.
Crap, How Do I Avoid This Problem?
Recognize that very bias as soon as you're done FREDing. Realize that others will play your mission differently, and use that to your advantage. Have some playtesters go through your missions, and make it their goal to try to break your mission in every way they can imagine. The more perspectives you have on a mission and the more playthroughs you have, especially of your more complex missions, the more possibilities for errors and bugs you and your playtesters can locate and correct.
The honest truth is that, no matter how much testing you do, your campaign won't be 100% mechanically sound. Lots of people will play your mod, and the more people play, the greater the chance that someone will find a new and interesting way to make your mod break. But it's much easier to do one patch for an error that comes up weeks after release than doing many patches for bugs that come up instantly upon release.
Bugs you can avoid if you test.
#1 -- You Didn't Spell-check
The Complaints You'll See
- "T-U-R-R-E-T"
- "wth is a detstroery"
- "i before e except after c n00b"
Why This Is Important
Alright, I'll be fair, spellchecking won't break your campaign. Spellchecking is never a show-stopping bug. But it does show a lack of scrutiny, a lack of testing, or not having a firm grasp of the English language.
It shows a level of professionalism when a mod is released and there's no significant grammatical or spelling errors. It just makes the mod look nicer.
Crap, How Do I Avoid This Problem?
While you're playtesting, have your testers look for spelling and grammar errors as well. Or, better yet, ask a native speaker to go through your mission files and correct to their heart's content. Spellchecking is something that doesn't take a whole lot of time, and there's plenty of native speakers in most languages on Hard Light that would be more than able to go through your mission files in an evening or an afternoon they have free.