For developers willing to contribute/add new levels.

[AkshayAgarwal007]

To add to #40 that @Vigneshsekar has raised.

Ideas posted by someone who himself wishes to work on that idea/ developers who want to contribute to Tux4ME should follow a few guidelines while developing their games and this is based on the prior discussions on developers who have contributed games previously as well as a few issues that we would want to address, specifically referring to #1 #25 #2 #37 #39 #28 and #30.

For Developers We would want that every developer succeeds in getting their code committed to the repo as well as gets its featured on the Tux4ME website and their names being added to the contributor's list and why not when you have developed it after so much of hard work, everyone deserves the appreciation. But the code has to maintain certain guidelines or rather say address a few issues that we are working upon :

1. We are trying to implement the use of game.paused , an inbuilt function in phaser to pause the game instead of the logic that we currently use. This will help us in our quest to make the code more modular, removing unnecessary logic and in making the code simpler and efficient. So we would want you to use game.paused in your code instead of the pauseState variable that is currently used. And that is bound to change soon. You may want to see previous work done by other developers and discussion following it. #11 #12 #38 #1.
2. The complexity of the games should increase with the levels and shouldn't be repetition of the same things again and again. Also one way of increasing the complexity could be to reduce the time limit in which the kid is supposed to do a certain task. This would help in increasing the interest of the kids towards the games and would also be a quick drilling exercise for them. We would want this to be implemented in any further games. For a read - #2 #25.
3. There are a few common mistakes while making the games. This is being referred to the mistake of creating text objects again and again and this often doesn't show up because an already created text object is overlay-ed by a button and then again a text object over it. And in cases they are visible too. You may want to be careful with this, we don't want overlapping texts or too many objects being created unnecessarily. For a read - #28 #38 (changes for motion commotion/migrating flocks).
4. We want to make the code more modular and parts of the code should be loosely coupled. We want functional cohesion.Don't try to implement all the logic into a single function. Break it into parts so that a new developer can understand it very easily. Also, so that for the developers maintaining the code they would not have to go through all of it again to make minor modifications. For e,g say a function that implement a replay logic should not call a function that implements a pause logic. We are working to change this and we would want this to be addressed in any future contributions.A modular code would also help in the idea of dashboard implementation. For a read - #37 #38.#30
5. We want game states to be implemented. Though this not as necessary, it would be good if this can be implemented in any future games. #39
6. We might be working on an idea of a blog in the future.Keep a documentation or say a tutorial sort of a thing involving what you are developing, how you built that game, what tools you used etc. Writing such a thing while developing a game makes the writing process a little more easier than if you do it after you have developed the game. Keep that with you, we may need that if the idea of a Tux4Kids blog for kids is implemented.

These are a few suggestions from my side based on prior discussion on the repo with @Vigneshsekar that I felt might be helpful to any developer who wishes to contribute. Anyone who wishes to add something to this, modify something or wants me to take something off or report any discrepancies with what I have written are welcomed with their suggestions. Also some of them are ideas that still needs the approval of the community.

[scottmc]

Another thing we will be adding soon should be a set of style guidelines. This is open right now but will probably be defined by the student(s) who get selected to work on it during GSoC2016. Having a defined style guide helps when more than one developer is actively working on the code base.

[Vigneshsekar]

Adding to it,

After making the code more modular as @AkshayAgarwal007 suggested, we may also create a template kind of a file. Since we are using the same UpdateScore, UpdateTime, UpdateLife, UpdateLevel and PlayAndPause functions and rewriting the game logic in new functions for any respective games, this is feasible.

During this process, we could also figure out and frame the style guidelines as @scottmc suggested. And it would be better if we could complete it before the community bonding period so that the selected student(s) can easily start working on the code-base.

Having a reusable code may help new developers to work only on the game logic and not to worry about the other implementations. And also, this will add in uniformity to the Tux4ME games.

[AkshayAgarwal007]

@Vigneshsekar Doing this would be very helpful for anyone who would continue with this project. Do you want to use something like generator-phaser-browserify for making it structured? @scottmc I wrote this because I saw developers contributing games but not trying to address these issues in their code though some of the issues were already there before they contributed. This might serve as a base for anyone who wishes to contribute now or would continue with this project during GSoC.