How To Contribute

How do I contribute?

The easiest way is to fork the project, and from there follow the usual git flow: either create a feature branch and merge or work directly from the develop branch. I would suggest creating a feature branch (from the develop branch), but that's up to you.

Once you have your code ready, you can submit a pull request.

What should I look in my code? (Coding standards?)

• Ideally, you want to follow these conventions: http://javascript.crockford.com/code.html
• Specifically:
  • anonymous functions have one space between the keyword function and the parenthesis, like this:

var a = function (arg1, arg2) {}; ```

• respect the forms for the if-while-for statements
• All declarations end with a semi-colon, even functions:

var someFunc = function (arg1, arg2) { ... }; ```

• Avoid creating new objects in methods that will be called every frame: use a "static" buffer. When in doubt, take a look at mouse handlers in core.js, the functions there are using the shared vector chesterGL.__tmp_mouse_vec to avoid the creation of a new one every time the event is called. Creating too many objects might be easier for you, but it is bad for GC: you don't want the GC to kick in and drop 5-10 frames because it's disposing temporary objects in the middle of your game.

Ok, I'm ready to contribute

After you finish your bug fix/new feature, make sure the code compiles with no warnings using make and make debug (they should both output the same result, the make debug only does a pretty-print of the minified code).

Also, make sure your code is typed as much as you can, currently the code is 94.6% typed, and we want to keep it that way (or even more).

Now, if it's a bug fix and it's already reflected in one of the test cases, then you're almost ready. If it's a new feature, usually you want to create a new test case to show the rest of the users what your new feature actually does. In that case I would recommend to duplicate test_single_block (since it's the most simple example) and add your feature there. You can even replace the whole assets if you need to.

After a make clean and make, test every existing test case and make sure the framerate is ok, or at least it is the same as it was before: it should be around 16ms in all cases, except in the performance test, where it depends on your machine, but it should reach the same amount of blocks with and without your changes. If you're developing in a feature branch, then it's easy to test that you didn't introduce bad code: just get back to the develop branch, run the tests there and compare with the results on your branch.

If everything is ok, then you can safely issue a pull request.

In all cases, I will probably do the same on my end, but it would be great if you could issue the pull request after making sure your feature meets the requirements. Remember: we want ChesterGL to be as efficient and performant as possible :)

You already merged my code, now what?

Thank you!

You'll be added to the list of contributors/authors. Again, thank you for contributing to an open source project.