Contributing
Contents
Code
examples of code contributions
- bug fixes
- additional features
- cleanups
if you've any of the above, send them to Hirato, the code will be included if he approves. He can be contacted through the forums (the PM system) or via IRC (the latter is recommended).
If you desire any feedback on your code, post it in the "Show of Your Work in Progress" forum, and tag it with [patch] - eg "[patch]continuous jumping", for a patch that makes you jump nonstop.
If you lack any ideas of what to implement, should you wish to contribute in this way, there are various todo lists that should help you out
- http://www.svn.kids.platinumarts.net/32pas32/trunk/sandboxtodo.txt
- http://www.svn.kids.platinumarts.net/32pas32/trunk/src/rpggame/rpgtodo.txt
- http://www.svn.kids.platinumarts.net/32pas32/trunk/src/sspgame/ssptodo.txt
Making several good patches, which are accepted, is a good way of convincing us you have what it takes to be on the development team.
Style
The files in the engine and the respective game modules use slightly differing styles... The easiest way is simply to remain consistent with the style present in the file.
Braces
Braces are not indented and are to be placed on a new line (unless the statement in question is a one liner). Braces are not required inside switch statements. They are not required after if's or else's either, PROVIDED there's only 1 statement following their invocation.
Indents
Indents are done either via Tabulators or 4 spaces. Make sure you know which style the files use, and that your text editor currently uses that style before modifying them. Hirato uses a size of 8 spaces for the Tabulators, mimicking him might help you identify the style in the files.
things to indent
- The body within braces
- cases within a switch
- any lines beyond the first of a macro
- items after their respective if and else statements
One-liners
One liners are permitted, but only if they are short small and simple. If the length is in excess of 30 characters, you should consider just expanding it out instead.
Pointers
To help ease confusion, pointers are written C style. That is next to the variable name (char *string) instead of next to the type (char* string). To those not in the know, char* string1, string2; does not declare two pointers, but a pointer and a character.
Whitespace
when declaring functions, there must be 1 empty line of whitespace between the end of the prior definition and the beginning of the new one. Variables and prototype definitions may be declared without any whitespace between each declaration. Provided they are grouped sensibly. It's recommended that the code also be grouped into 2-10 line blocks which concentrate on a certain aspect to help with readability. A series of one liners may also be grouped without spaces between.
licensing
By sending in your code, YOU give US permission to relicense the code under the zlib/libpng license and include it as part of our source distribution(s), irregardless of the code's original license. By extension, this means you're NOT PERMITTED to REVOKE permission for us to use the code, should you decide you no longer wish for your code to be inside sandbox
Art
This category includes custom maps, models and textures. Just send them in, if they're of acceptable quality, and of an acceptable license, we'll add them right in.
You can also post them on the forums, we tend to look there occasionally, and the community would doubtlessly be excited to see what people are making/working on for sandbox
licenses
These are a listing of licenses we recommend for art assets included in sandbox.
- Creative Commons - Attribution
- Creative Commons - Attribution + Share-Alike
- MIT/X11
- Public Domain
Other
Testing
As a rule of thumb, there are ALWAYS bugs, if you're up to it, just use sandbox as you normally would, and keep an eye out for any oddities, and put extra effort into trying to break things. Should something go wrong, give us the exact steps you took, and we'll do out best to fix it. We recommend using the SVN version.
See Also
