Shipping Leader In Detail: Difference between revisions

From Valve Developer Community
Jump to navigation Jump to search
mNo edit summary
 
(30 intermediate revisions by 16 users not shown)
Line 1: Line 1:
== Prelude ==
{{LanguageBar}}


"You should designate a single member of your MOD team as the Shipping Leader (SL). This person will drive progress on the MOD for the next five weeks. All changes made to the MOD from now on should occur only at the request of the SL, and all requests for changes should be funneled through this person. No team member should make any changes, no matter how minor, to the MOD unless the SL has requested that they make a particular change. This doesn't mean the rest of the team are losing control of the MOD... the SL is still a part of the team, and will be listening to all feedback. The point of the SL is to ensure that all changes to the MOD are going through a single person. This avoids problems such as a mapmaker breaking the game by making a last minute change because he didn't realize something else had changed in the game code. The SL will know the state of every component in the game (code, maps, models, textures, etc) at all times throughout the next 5 weeks to ensure this never happens. Choosing the SL isn't easy. Here are a few tips: - Don't immediately assume the person who's currently running the MOD is the best choice for SL, especially if the MOD has been worked on for months and hasn't got any closer to being released. - Game Coders are probably the best choice. As the shipping process comes to an end, most fixes will be made in the game code. - The SL should be highly motivated, disciplined, organized, and as ego-less as possible. The SL will need to be able to commit five weeks of his or her life to this process. - The SL should be able to make global decisions for the MOD. The SL should understand that this often requires cutting features and content in order to ship"
{{Underlinked|date=January 2024}}


From [[Making_a_MOD|Making a MOD]]
== Prelude ==
 
You should designate a single member of your mod team as the '''Shipping Leader''' (SL). This person will drive progress on the mod for the next five weeks. All changes made to the mod from now on should occur only at the request of the SL, and all requests for changes should be funneled through this person. No team member should make any changes, no matter how minor, to the mod unless the SL has requested that they make a particular change. This doesn't mean the rest of the team are losing control of the mod, the SL is still a part of the team, and will be listening to all feedback. The point of the SL is to ensure that all changes to the mod are going through a single person. This avoids problems such as a mapmaker breaking the game by making a last minute change because he didn't realize something else had changed in the game code. The SL will know the state of every component in the game (code, maps, models, textures, etc) at all times throughout the next 5 weeks to ensure this never happens. Choosing the SL isn't easy, but here are a few tips:
I highly recommend making the shipping leader the lead coder. This person usually is the most dedicated to the MOD and has easy access to the code for compilation, something which can be hard for an artist to-do if they don't have access to the compilation tools.
* Don't immediately assume the person who's currently running the mod is the best choice for SL, especially if the mod has been worked on for months and hasn't got any closer to being released.
* Game Coder is probably the best choice. As the shipping process comes to an end, most fixes will be made in the game code.
* The SL should be highly motivated, disciplined, organized, and as ego-less as possible. The SL will need to be able to commit five weeks of their life to this process.
* The SL should be able to make global decisions for the mod. The SL should understand that this often requires cutting features and content in order to ship.


== Creating the base MOD ==
I highly recommend making the Lead Programmer the shipping leader. This person usually is the most dedicated to the mod and has easy access to the code for compilation, something which can be hard for an artist to do if they don't have access to the compilation tools. The shipper leader's compiled code and assets are collectively known as the '''Shipping Master''' version of the mod.


So first it's usefull to create the base MOD from the Source SDK menu, create any kind of MOD you want, I suggest NOT using the source code only option if you are trying to create the shipping leaders copy of the MOD.
== Creating the base mod ==
First it's useful to create the base mod from the Source SDK menu. Create a single player mod if you're doing singleplayer, and multiplayer if you are doing multi player. Do not use the '''Source Code Only''' option if you are trying to create the shipping leader's copy of the mod.


So you now have all the files on your hardrive, the next stage is to familirizre your self with the directory structure and how the files are set up.
The next stage is to familiarize yourself with the directory structure and how the files are set up.


== Other team members ==
== Other team members ==
Other team members need to add their own changes to the mod, so how are you going to let them do it without disturbing the shipping master? There is a simple solution to that.


Other team members need to add their own changes to the mod, how are you going to let them do it without disturbing the shipping master? There is a simple soloution.
Create on your FTP a directory for the shipping master, which can ONLY be modified by the shipping leader. Then create a directory for each of your team members holding a copy of the shipping master, with a text file in a changes folder that will detail what changes they have made. There should also be an easy way to access to the altered files that the team member has worked on in a separate folder.


Create on your FTP a directory for the shipping master, which can ONLY be modified by the shipping leader. Then create a directory for each of your team members holding a copy of the shipping master, with a text file in a changes folder that will detail what changes they have made. There also needs to be an easy access to the changed files that the team member has worked on in a seperate folder.
<center>[[File:Shippingleader_mod_folder.PNG]]</center>


<center>[[Image:Mod.jpg]]</center>
The above image shows a file within the shipping master's directory that is called ''Changes.txt''.


When the shipping leader makes a cumulative change that changes the shipping master the individual team member should branch their changes off into a separate directory with the date stamped on the folder. So they can start afresh and it's easier for the shipping leader to identify what the newest changes to that team members files are.


<center>[[File:Shippingleader_changes_txt.PNG]]</center>


<center>[[Image:Changestxt.gif]]</center>
== Gathering changes ==
 
The shipping leader should provide a regular timetable for collecting changes and merging them into the shipping master, because this is the version of the mod's files that the team will be playtesting and developing with.
The above image shows a folder within modeller bobs directory that is called changes.
 
When the shipping leader makes a culmative change that changes the shipping master the individiual team member should branch their changes off into a seperate directory with the date stamped on the folder. So they can start afresh and it's easier for the shipping leader to identify what the newest changes to that team members files are.
 
<center>[[Image:Changesfdate.gif]]</center>


== Gathering changes ==
The shipping leader should go through each directory individually and look at the <code>changes.txt</code> to find out exactly what has changed and then merge the changes into the shipping master.


The shipping leader should provide a regular timetable for collecting changes and merging them into the shipping master, because this is the version of the MOD's files that the team will be playtesting and developing with.
Then, test the mod to see if you merged successfully, and then replace the old shipping master with the new shipping master and inform all the team members to manage their files like described in the "other team members" section.


The shipping leader should go through each directory individually and look at the changes.txt to find out exactly whats changed and then merge the changes into the shipping master.
<center>[[File:Changesfdate.gif]]</center>


Then test to see if you merged successfully, and then replace the old shipping master with the new shipping master and inform all the team members to manage their files like described in the "other team members" section.
== See also ==
* [[Making_a_MOD|Making a mod]]


<center>[[Image:Changesfdate.gif]]</center>
[[Category:Technical]]

Latest revision as of 08:49, 27 October 2024

English (en)Русский (ru)Translate (Translate)
Underlinked - Logo.png
This article needs more Wikipedia icon links to other articles to help Wikipedia icon integrate it into the encyclopedia. Please help improve this article by adding links Wikipedia icon that are relevant to the context within the existing text.
January 2024

Prelude

You should designate a single member of your mod team as the Shipping Leader (SL). This person will drive progress on the mod for the next five weeks. All changes made to the mod from now on should occur only at the request of the SL, and all requests for changes should be funneled through this person. No team member should make any changes, no matter how minor, to the mod unless the SL has requested that they make a particular change. This doesn't mean the rest of the team are losing control of the mod, the SL is still a part of the team, and will be listening to all feedback. The point of the SL is to ensure that all changes to the mod are going through a single person. This avoids problems such as a mapmaker breaking the game by making a last minute change because he didn't realize something else had changed in the game code. The SL will know the state of every component in the game (code, maps, models, textures, etc) at all times throughout the next 5 weeks to ensure this never happens. Choosing the SL isn't easy, but here are a few tips:

  • Don't immediately assume the person who's currently running the mod is the best choice for SL, especially if the mod has been worked on for months and hasn't got any closer to being released.
  • Game Coder is probably the best choice. As the shipping process comes to an end, most fixes will be made in the game code.
  • The SL should be highly motivated, disciplined, organized, and as ego-less as possible. The SL will need to be able to commit five weeks of their life to this process.
  • The SL should be able to make global decisions for the mod. The SL should understand that this often requires cutting features and content in order to ship.

I highly recommend making the Lead Programmer the shipping leader. This person usually is the most dedicated to the mod and has easy access to the code for compilation, something which can be hard for an artist to do if they don't have access to the compilation tools. The shipper leader's compiled code and assets are collectively known as the Shipping Master version of the mod.

Creating the base mod

First it's useful to create the base mod from the Source SDK menu. Create a single player mod if you're doing singleplayer, and multiplayer if you are doing multi player. Do not use the Source Code Only option if you are trying to create the shipping leader's copy of the mod.

The next stage is to familiarize yourself with the directory structure and how the files are set up.

Other team members

Other team members need to add their own changes to the mod, so how are you going to let them do it without disturbing the shipping master? There is a simple solution to that.

Create on your FTP a directory for the shipping master, which can ONLY be modified by the shipping leader. Then create a directory for each of your team members holding a copy of the shipping master, with a text file in a changes folder that will detail what changes they have made. There should also be an easy way to access to the altered files that the team member has worked on in a separate folder.

Shippingleader mod folder.PNG

The above image shows a file within the shipping master's directory that is called Changes.txt.

When the shipping leader makes a cumulative change that changes the shipping master the individual team member should branch their changes off into a separate directory with the date stamped on the folder. So they can start afresh and it's easier for the shipping leader to identify what the newest changes to that team members files are.

Shippingleader changes txt.PNG

Gathering changes

The shipping leader should provide a regular timetable for collecting changes and merging them into the shipping master, because this is the version of the mod's files that the team will be playtesting and developing with.

The shipping leader should go through each directory individually and look at the changes.txt to find out exactly what has changed and then merge the changes into the shipping master.

Then, test the mod to see if you merged successfully, and then replace the old shipping master with the new shipping master and inform all the team members to manage their files like described in the "other team members" section.

Changesfdate.gif

See also