Standards and Conventions
Follow the C# Conventions for all submitted C# code. Basically its Upper Camel Case for functions, interfaces (which also start with an I), properties and structs/classes, with Lower Camel Case for variables and everything else (basically). You should install StyleCop since it'll automatically tell you exactly where and why certain bits of code fail to meet these standards. You can find more information here
For LUA code follow the LUA Conventions, we use very similar conventions to C# just to keep it easy. Nothing will automatically scan and indicate errors, but we are much less strict on formatting of LUA since it is modded and is very subject to change.
If you submit a PR please put [WIP] in the title if it isn't 'finished', put [Feedback] if you want feedback, if it is a small change put [Small], if it is purely art/music put [Art] or [Music] respectively (if it is art + code then don't put [Art] and same for music, that tag is ONLY if it is purely just more art and music).
Every bit of code submitted for a PR has to be properly documented before it will be accepted, this includes summaries for every public exposed class, function, property, variable... along with parameters for functions and return summaries if a function returns something. Pressing the '/' key three times on visual studio or mono develop will automatically include a summary tag (for you to fill out) and parameters/return summaries (if it is a function that has those things and again for you to fill out). Please just do this, otherwise it is very difficult to understand your thinking later on :D.
To log from lua use
ModUtils.ULog, ModUtils.ULogWarning, ModUtils.ULogError (uses a default channel) or
ModUtils.ULogChannel, ModUtils.ULogWarningChannel, ModUtils.ULogErrorChannel lets you specify a channel.
Use UnityDebugger.Debugger instead of Unity's standard by using the following commands
UnityDebugger.Debugger.Log, UnityDebugger.Debugger.LogWarning, UnityDebugger.Debugger.LogError instead of Debug.Log, Debug.LogWarning, and Debug.LogError respectively. Note there is also a format variant. More info here
We cannot accept any uncompressed audio files. Please make sure any audio files is .OGG
When submitting a PR changing art, please follow these guidelines below. These make it easier for Gatekeepers/Art Critics to judge, streamlining the process, and also hopefully avoid hurt feelings because everyone knows what to expect.
These are aimed at sprite changes, but a similar guideline - within common sense - applies to sound and other art.
-
Replace one sprite per PR. This allows a decision on a case-to-case basis
-
Until further notice, all sprites are liable to be replaced.
2a) When replacing a sprite that is not an obvious placeholder, give some indication why your sprite is better than what's in place. Art is subjective so it's worth making your case to convince unbelievers.
2b) Sprites are not likely to be replaced unless they are ...
... placeholders
... outdated in function
... jarringly inconsistent with other sprites -
Include screenshots of how the art looks in-game. It can be hard to judge how something looks from the spritesheet only.
-
The community is king. If there is a community consensus that the sprite you made is better, then it'll be merged even if the old sprite wasn't obsolete. So show your artwork!
5a) As a common courtesy, if they are still around, it's good to discuss with the author of the old sprite.
Our pixels per unit is 64. That means that each tile is 64 x 64. If you make a sprite, keep it a factor of 64 if it is larger than one tile.
To help everyone's sprites work together try to make the 'world light' come from north/up, this way sprites won't feel inverted (a box won't turn into a hole and pits won't be hills).
