How do you organize your mod development with many people?
- Thread starter pjm2493
- Start date
Users who are viewing this thread
We just had a mini-discussion on this: Which Version Control System are you using?
...so far as being worried about your team members releasing stuff early...I guess that's why you are judicious about who is on your team. Hopefully you can trust the folks you've chosen to mod with.
...so far as being worried about your team members releasing stuff early...I guess that's why you are judicious about who is on your team. Hopefully you can trust the folks you've chosen to mod with.
Yeah, that, and tbh, the gamecode is pretty heavily integrated with the content... so it's no biggie if the MS code gets loose, in most cases. Unless the mod does something both extremely innovative and extremely polished, it just doesn't matter all that much; the total flavor of a mod is more than the sum of the features.
For The Last Days mod, the way we acquire new developers is by seeing which ones actually get stuff done. We get offers of help all the time, but until they turn up with the goods we are pretty non-committal as far dev-status is concerned.
I had contributed for over a year before AncientWanker invited me to the dev board and inner team.
That's pretty much my attitude as far as these things go. Now, I won't lie; personally, I work alone 90% of the time, and TLD is the only project I've really collaborated on. The Hundred Years War did have contributors, but it was the same thing: several people offered to help, so I gave them the necessary direction and waited until they turned up with the promised content, or didn't. In neither case was I in danger of loosing massive parts of the mod, simply because I gave them only the files they needed to work with.
Miserly? Perhaps, but it seriously cut down on the confusion. When a writer volunteered to write some characters, I gave him the few files he needed, he edited them and sent them back. Integrating them back in was a cinch.
For mods with lots of heavy scripting, the answer isn't much different. Depending on the number of collaborators, after you have found a trusted scripter, you set up an SVN version control system or some such that house the full game code/module system, and set up a few rules that must be followed. Such as no committing of work with bugs in it, no committing code that causes the game to crash, etc. Those rules are simply to prevent one person from having to fix another person's code and/or bugs, which is a *****.
If the people won't agree to these rules, you don't want them on your team in the first place. But presumably, if they do have access to your files, it's because they've already shown initiative and helped substantially.
Alternatively, if you have a dedicated scripter, he can do all the scripting and send you the mod creator/coordinator periodic updates for you to work with.
I had contributed for over a year before AncientWanker invited me to the dev board and inner team.
That's pretty much my attitude as far as these things go. Now, I won't lie; personally, I work alone 90% of the time, and TLD is the only project I've really collaborated on. The Hundred Years War did have contributors, but it was the same thing: several people offered to help, so I gave them the necessary direction and waited until they turned up with the promised content, or didn't. In neither case was I in danger of loosing massive parts of the mod, simply because I gave them only the files they needed to work with.
Miserly? Perhaps, but it seriously cut down on the confusion. When a writer volunteered to write some characters, I gave him the few files he needed, he edited them and sent them back. Integrating them back in was a cinch.
For mods with lots of heavy scripting, the answer isn't much different. Depending on the number of collaborators, after you have found a trusted scripter, you set up an SVN version control system or some such that house the full game code/module system, and set up a few rules that must be followed. Such as no committing of work with bugs in it, no committing code that causes the game to crash, etc. Those rules are simply to prevent one person from having to fix another person's code and/or bugs, which is a *****.
If the people won't agree to these rules, you don't want them on your team in the first place. But presumably, if they do have access to your files, it's because they've already shown initiative and helped substantially.
Alternatively, if you have a dedicated scripter, he can do all the scripting and send you the mod creator/coordinator periodic updates for you to work with.
Cjkjvfnby
Regular
CTCCoco said:
If you already release mod. It could be reverse engineered. (about one working day for tool for module scripts. comments and name for local vars will be lost.)
Arts is not protected at all.
If you not release it. You can just block it on most popular resources. (This forum, mbrepository, mbx, moddb)
Any protection from bad peoples will make work of other harder.
My choose:
private:
git repo hosted in Dropbox folder. Share control via Dropbox interface. (git is decentralized system if dropbox folder will be broken, you can restore it)
public:
https://github.com/Cjkjvfnby/mab_compiler # git hub has no free private account.
What Llew said. You have to get proven commitment before sharing the code (or unreleased scenes or graphics stuff), and it's easiest to test this by giving non-trivial tasks first.
When I first signed up on this forum and tried to join the Prophesy of Pendor team, the mod leader wouldn't give me access to the sources for a month, until I implemented some cool features that helped the mod (I had to work in Native!). And that's how you test people if they are ok.
When I first signed up on this forum and tried to join the Prophesy of Pendor team, the mod leader wouldn't give me access to the sources for a month, until I implemented some cool features that helped the mod (I had to work in Native!). And that's how you test people if they are ok.
