This thing has basically ended up as a "don't do this" rant but it still has a few answers in it and has been posted on both Obsidian and Gizka.
When making a major mod it would be wise not to repeat the mistakes of the M4-78RP team (jokingly named Team Bantha by a group of mad forumites). Each of us made our own mistakes and we all made collective mistakes.
Get the difference between concept and actuality drilled into your head. There were all kinds of wonderful plans in place for M4-78, made possible by the awesome abilities of Archon II and 3ds max. I remember that my particular pet-project (and I was pleased with the writing for this) was an elaborate flashback sequence which meant many an hour sitting there informing Archon II of camera positions and drawing story-boards for my own use (never did get around to sending him them). Hours that would have been better spent working on the actual mod and putting such a project on the back-burner. It would be nice to have the Harbinger fly over the Central Zone when Vash is about to be captured by Sion’s Sith Assassins… but working on that while other sections were still not even up to a beta stage made no sense! In essence: Use milestones, please, for the love of God use milestones.
Milestones allow you as the mod leader (or as a whole team) to set targets which *must* be met. Here are some examples:
M1: Plan out the main plot and all its intricacies with a core team.
M2: Implement the major structure of the mod with very little scripting – using notes held in square brackets and describe camera angles but do not make them.
M3: Set the leading designers (the people who originally came up with most of the plot) to work on the cut scenes in the game, adding in animated cameras and scripting the actions to take place. While this is being done, set others to work on creating rudimentary sidequests in much the same manner as M2’s plot was implemented.
M4: Pull on beta testers for the main plot, people who can point out the gaping flaws that always occur in your (read: my – I have a habit of overlooking stupid things in scripting logic) logic. M3’s team of sidequest creators should now be working to polish the quests to the standard of the main plot. The main plot implementers should be bug fixing in the main plot as well as helping with the sidequests.
M5: Begin rendered film development and move everyone onto bug fixing. If it is desirable: advertise to budding voice actors so that you can voice all of that dialogue.
M6: Release the mod and provide support in the form of content and bug-fixing patches (each patch must undergo the same milestones as the actual mod).
We had a plan… but it wasn’t as structured as the milestone system adopted later on in our (me, Archon II, Blacknadger and later Emperor Devon) frequent attempts to keep the thing from falling apart. The milestones are vitally important for a successful mod, it ensures that if you get sick of the mod after half a year of working on it, you actually have something to release. In essence, the idea of milestones was something of a learning curve for me (it was only near the end of the mod’s life that I suggested the idea to Emperor Devon) and I don’t think it should be a learning curve for others because it costs time and effort and may ultimately cost so much of your time that the people you were about to ask to tackle problem x have already left the mod, or disappeared into the ether.
It’s wonderful to have a dream but can you implement it? The fact is that the original team had very little exposure to KotOR modding (I think all of them had done some form of modding in the past – I seem to remember Blacknadger talking about a Baldur’s Gate mod of some sort, I have no idea of the details). As many, many people inform you in Holowan, start small – for the sake of humanity and your sanity start small! Having a core team filled with people who didn’t really know what they were doing who were sitting in front of a large mod led to a lot of talking about doing things but not a lot of doing them. This got better, of course, as the team learnt their stuff and brought aboard new members.
Where’s my file, Jenkins? And who’s working on the waterfront project? Where do you put all those files? When you work with a reasonably large team it is difficult to know who is working on what… there is a simple solution that can be difficult to implement due to the troubles of geography and time-zones (getting up extra early to talk with Archon II about how a planet approach should look is soul destroying). Set up wiki which will hold all of the team’s essential information. The trac wiki
project comes with a nifty built in ticket tracker, which allows you to split assignments up between people on the project.
CVS. It truly is a wonderful version control system, set a server up and no one will ever be in danger of overwriting anyone else’s work and everyone’s work is stored in the same place so a realistic tab can be kept on progress and if your computer crashes, all of the project files are not lost – it’s wonderful. Again, this is something that was not sorted until much later on in the project. I really would recommend using a program like Eclipse
for managing your files it can be a little hefty for just CVS (it is a Java development platform at the same time) but after flitting between programs I've pretty much decided that the lumbering Eclipse is the best bet.
When it comes to actual story concept, a live chat is absolutely essential. Do you think game developers contact each other by email? No, they sit around their conference tables with copious amounts of coffee. Use AIM, MSN, IRC whatever floats your boat. You need a live chat to get a coherent story and you need someone willing to devote time to typing the plot up and placing it as a master document on the wiki, or (if you prefer) on CVS. Also, make sure that the team assigned to the story is fairly small; an artist may not be able to write as well as person x but they may have ideas about the plot - listen to them. Create several rough drafts and put them on display for the rest of the team to nitpick/(as Dashus says) use as toilet paper. Then take into consideration what they've said and create a second draft and then a third draft and so on until everyone is happy with the plot. If someone is unhappy then you have to find out why and consider whether or not the fact that the radiation in the central zone doesn’t have a half-life is really worth your attention. If one person is not happy you can (a) come up with another draft or (b) shoot them dead – which is not exactly recommended.
In the case of M4-78, it does not matter what the developers wanted the planet to be like (there's not enough of it to restore properly, anyway). So long as it fits the mood of the game (it doesn't have to... you could texture Citadel Station lurid pink and fill it with pixies if you liked - no idea why you would want to but some people are fond of these ideas) make what you and your team-mates
want to make because that's the only way anything of quality will come out. If you try to think like Kevin Saunders (I think he was the lead for M4-78, don't kill me if I'm wrong) then it will inevitably fail because guess what? You're not Kevin Saunders.
When writing your dialogue… please think of how normal people interact and offer the player multiple role-playing options. If they don’t want the droid to be sent into the Central Zone just yet, or are having second thoughts about going to the planet, allow the person to back out of it at most points. You cannot guarantee that your mod will be liked by all so a get-out clause is a blessing for someone who doesn’t want to continue just yet. Dialogue nodes (outside of plot essential conversations i.e. cut-scenes) that do not possess a “I’m sorry, I must go” option, or the rough equivalent, can be hellishly annoying to the click-happy player… do not make them fight your mod, they won’t like you for that and you may receive angry letters in the mail with various crude references to your parentage. Do not feed the player a cut-scene that is far from essential that cannot be skipped.
Consider a character’s personality traits and think about how realistic it is that they will say… commit suicide (I’m thinking of Kaah - Vash's padawan - here). After listening to Hamlet’s “To be or not to be” soliloquy would you expect him to go off immediately and murder Claudius in cold blood before considering the possibilities? No… you would not, unless you’re bored with the play by that point and are hoping that it will end very, very soon. People are strange, yes, but they are very mechanical at the same time – they will only do something unusual if they are driven to by extreme circumstances, or pressures. For Kreia to murder rather than manipulate would be unusual and would either leave the player thinking “Oh that was cool” (if done well – like the Jedi Master scene) or “kweh?!” (if done badly).
Don’t splice voice over together – it will result in bleeding ears and you hearing problems with your created voice files that no one else can hear. Sure it may sound cool and adds something to the mod but for the amount of time it takes up it’s really not worth it. And then add into that: if you want the lines to sound natural then dialogues with your party become exceptionally limiting. Many successful mods have been done without voice over, just look at Princess Artemis’ Dustil mod, or even the Dark Apprentice series – or almost every mod for Neverwinter Nights 1/2. If you really want to voice the dialogue for your party members then make sure it is low on the priorities list and is done after the main body of the mod is made. This is another case of (me) spending a lot of time on polish when other parts of the mod aren’t even implemented.
These are lessons that were not learnt until much later on in our project… and by that time one or two people had already begun to drift and Valec had already left – admittedly due to work but the point is still valid.
Work we have done will most likely not be released...
1) I do not have the permission of everyone involved to do so.
2) I don't like releasing a jumble of files that are in a playable but somewhat pathetic and slightly broken state.
3) The story we came up with is not the story of the designers... you'd be restoring someone's attempts to recreate someone's work.
4) I have had bad experiences with seeing beautiful visions shattered by someone else doing the work in the past
. Take one of the dialogues I have planned out step by step, for example, describing camera angles and actions with time references - what if someone wants to use my writing but do it in their own way? I wouldn't be happy with what was produced, quite simply. Call it pretension, if you will (yay! I used a big word
5) The time taken to transfer all the information to a new set of modders, explain what point x meant on the plan and why y is sarcastic when he's a droid... would be ridiculous and right now I have not the time to answer a thousand emails a minute.
6) A lot of the files produced by the other members (or they swore were produced) were never uploaded to CVS.