FF on Source SDK 2013
Go to file
Ryan Liptak e16bdd07e1 Added some file/dir guidelines 2013-09-04 11:37:00 -07:00
mp Now that building raytrace.lib has been added to the game project, remove it from the repo (since it will more than likely show as modified and we don't want to ever commit it I don't think) 2013-09-04 00:08:00 -07:00
sp * Fixed Source Mod back-compatability by reordering methods in a couple interfaces. 2013-09-03 16:02:10 -07:00
.gitattributes Update text & binary attributes. 2013-07-05 12:08:13 -07:00
.gitignore Better .gitignore take 2 2013-08-31 21:39:55 -07:00
CONTRIBUTING Revised the contribution guidelines to encourage more interaction within the community. 2013-07-30 09:29:15 -07:00
DOCUMENTATION.md * Added initial DOCUMENTATION.md 2013-09-03 23:03:31 -07:00
LICENSE Fixed various missing files 2013-06-27 14:27:15 -07:00
README.md Added some file/dir guidelines 2013-09-04 11:37:00 -07:00
thirdpartylegalnotices.txt * Added support for building shaders in your mod 2013-07-17 18:26:59 -07:00

README.md

Fortress Forever (Source SDK 2013)

Git

We will be using the branching model laid out here: http://nvie.com/posts/a-successful-git-branching-model/

  • Never push to the master branch, it should only recieve merges from the develop branch or a hotfix branch (per release)
  • Merge any source-sdk-2013 changes into the develop branch (will probably have to deal with conflicts)
  • Only use rebase when you have unpushed local changes and someone else pushed changes to the corresponding remote branch; never rebase a remote branch (see this and this and this)
  • Only merge from the develop branch to a feature branch when absolutely necessary (important bugfix, etc); features should ideally be self-contained

Committing

  • Always make sure the code you are committing compiles
  • Try to commit changes separately, rather than 20 files at once. This means we can easily revert certain pieces if we don't like them, rather than going through manually to remove stuff
  • Be descriptive in your revision comments.
  • If you aren't sure you're doing something the best way, comment it in code and possibly comment ("First pass, needs cleaning up!" for e.g.)

Code

  • Avoid making changes in the base Source engine files; always try to move those changes into a FF-specific source file that derives from the base class.

Syntax

Variable and Function Names

  • TODO Decide on a naming convention
  • Always make variable and function names as descriptive as possible (if 'i' stands for 'currentPlayerIndex' then use 'currentPlayerIndex')

File Names and Directory Structure

  • Always put FF code files in the src/game/<server/client/shared>/ff/ directory.
    • TODO Decide on a subdirectory scheme
  • Always prefix Fortress Forever code files with ff_
  • Add a secondary prefix depending on the usage of the file; for client-only files, use cl_; for server-only files, use sv_; for shared files, use sh_
    • Example: the "player" source files would be named: ff_cl_player, ff_sv_player, and ff_sh_player

Adding/Removing Files

Solution and makefiles are no longer stored on the repo, they are generated using VPC. To add/remove files from the project, you must edit the game/client/client_ff.vpc and/or game/server/server_ff.vpc files and then execute createallprojects(.bat) in the src/ directory. To remove a non-FF-specific file from the project (like HL2DM files), add exactly what you would to add the file (or copy the line from the .vpc that includes it), but put a - before "$File".

Documentation

DOCUMENTATION.md

For documentation of general Source engine things or of implemented features, commit to the develop branch. For each feature branch, document the in-development feature as it is worked on; the documentation will get merged along with the feature once it is complete.

Doxygen Inline Commenting

Note: only use Doxygen commenting as necessary (see section Variable, Function, File Names and Directory Structure)

To describe classes/functions/files (List of available @ commands):

/// Brief description. (optional)
/** Detailed description. 

    @param parameterName Description of the param
    @returns Description of the return value
*/

To describe member variables:

int var; ///< Detailed description of the member variable
         ///< and more if needed