How do you organize your building team?
Faerûn
Member Posts: 39
I'm a long time player first time builder that's making a PW with some friends. I was wondering if the community could give me some (any) tips on building my own module.
In particular, what is the best method of passing files back and forth and ensuring that all of the builders are using an up-to-date version? This is of course assuming that everyone working on the module can be trusted and that having an entire, up-to-date copy is necessary. In my case there are only three of us participating so far and we share all of the roles - building, scripting, and play testing, therefore it's been necessary that we pass the WIP module file back and forth quite a bit.
I imagine most big servers are organized quite differently than we are, so I would also be interested in knowing how more "professional" teams work on their modules, in the hopeful event that our server becomes a great success.
Thanks!
In particular, what is the best method of passing files back and forth and ensuring that all of the builders are using an up-to-date version? This is of course assuming that everyone working on the module can be trusted and that having an entire, up-to-date copy is necessary. In my case there are only three of us participating so far and we share all of the roles - building, scripting, and play testing, therefore it's been necessary that we pass the WIP module file back and forth quite a bit.
I imagine most big servers are organized quite differently than we are, so I would also be interested in knowing how more "professional" teams work on their modules, in the hopeful event that our server becomes a great success.
Thanks!
0
Comments
Here is a good link to get you started:
https://github.com/jakkn/nwn-devbase
It is well worth it to learn all this stuff, i use it for my PW/Team and it is really awesome being able to work like in an real development environment.
Sending the one .mod file back and forth between Team-Members will not work out well in the long run and sooner or later someone will overwrite someone else's work.
Without version control it is basically impossible to work on the same module simultaneously.
But with version control everyone can work on the same module at the same time.
The short of it, is that when you open a module, it dumps/extracts everything in modules/temp.0
From there, you can manage those files in version control.
But it's a bit awkward because the toolset always tries to repack as *.mod (and git on windows is also slightly wonky compared to linux)
I think it was NWN2 that had option to work with directories instead of mods. I wish NWN toolset would implement that and then have a separate "build mod for deployment" command.
That is how we manage it now, but like I said, it's a bit awkward to use because the toolset has it's own strong opinions on when to pack into .mod file.
One Important thing Is communication, nothing will do you or your team any good, if two of your guys suddenly decide that they want to create the starting area. Everyone needs to always know the general gist of what each other Is currently working In, so they don't overlap each other.
Take a look at the link above i posted, there is nothing akward once you understand how it is working.
You don't have to worry about the toolset at all or what it does with the .mod file and the \temp.0 folder.
Actually, you can completly ignore the \temp.0 folder.
I can only strongly recommend it, any other way is/can be seriously frustrating in the long run.
The process is simple:
YOU:
- make changes to your module.
- extract module
- commit/push
- done
SOMEONE ELSE IN YOUR TEAM:
- makes some changes too
- extract
- commit/push (gets notified someone else pushed changes)
- now gets notified to pull
- merge
- pack module
- done
Git on Windows actually works quite good, i don't have issues with GitHub Desktop for example.
Expecially exporting (the toolset often includes more things you actually wanted to export) and someone else imports it with the hopes to not accidently overwrite some of his own work he may have forgotten
Version control totally eliminates such problems.
Ofc. it is always good to communicate who is doing what to avoid having too many conflicts in version control. But thoose can be easily fixed if they come up.
One conflict you will have on an regular basis for example is the "Starting Point" (module.ifo file) you can set up in the module.
Everyone who is working and testing with the module will place the Starting Point in some area at some point.
But you get notified with the conflict and it takes you only 5 seconds to either accept your "Starting Point" or the "Starting Point" of the latest commit/push from someone else.
I disagree, it still controls the versions of the binary blobs... but I agree that it's hard/impossible to diff or merge in easy manner.
> The process is simple:
Which is basically our work flow too.
> Git on Windows actually works quite good, i don't have issues with GitHub Desktop for example.
Yea, it works good. I'm just saying, generally unix command line is a lot nicer to work with them cmd/console or power shell... but guess that's a matter of personal preference. (windows also has bash shells, etc)
Sharing code for development and testing is something the software industry solved a while ago. As mentioned above it is called version control and has been implemented with several tools, most notably SVN and Git, the latter having replaced the former as the industry standard in many (if not most) places. Version control comes with many benefits beyond code sharing, among which is the ability to roll back the code base to a previous state, viewing change diffs, handling merges, and more.
Because a .mod file consists of code, the only sensible option to share a module is to use a tool that was built to share code. You can use any tool, but I can highly recommend Git based on ease of use and documentation.
If this is something you want then it is important that you are aware of the learning overhead attached with introducing a new tool. It can't be just one or some of you that use it. Everyone has to know and use the tool, so you need to be committed.
Now it gets a bit more complicated, because .mod files are binaries that contain gff binaries (the content of the temp.0 folder), so you'll be facing binary diffs if you apply version control to these files, and you (probably) don't want to go down that road. So you need some extra tooling in order to convert gffs to a textual format that is suited for version control. The process of converting gff to text requires further tooling, which is what the nwn-devbase project tries to simplify and optimize. It contains a build script that automates the steps of converting from .mod to .yml and back again, so that you can apply version control to YAML files.
I'm aware that nwn-devbase does require a fair bit of environment configuration and tool installation, and I realize it is not a straight forward process. But it improves a bit every time I get feedback, so if you try to use it and run into trouble, feel free to contact me about it (preferably on discord or email). I have also put significant effort into explaining why and how the workflow is the way it is in INTRODUCTION.md, so please have a look there.
- halgroth/jakkn
Thanking you in advance.
Derek