09-13-2017, 09:23 AM
Couple of insights from one of the newer coders, don't take my thoughts and opinions as representative of the rest, they're my own:
If you have an idea you would like to implement, nothing is stopping you. Nothing. Yes, there's one more hoop of "can I have the relevant code parts to build my idea around?", but all that does is slow you down a touch (if it even applies to you). I would be very interested in knowing specifically what idea someone has that they haven't implemented because of the lack of a recent release.
One aspect that I think does hold merit is getting a couple more coders aboard. There's a significant amount of trust issues in that, and it's not a quick process. What I will say is: make decent patches which actually run (seriously, if your code doesn't run on the release you built it on then you need to rethink your approach), include sensible documentation detailing the changes, and respond to feedback appropriately. Not every patch will get implemented. Focus on quality over quantity. One good patch is better than three where we had to bounce it back several times.
- The codebase really hasn't changed that much. There's been some restructuring, and a couple of the mechanics have changed (e.g. materials), but most of the "content" is the same.
- To that end, contributing content is where the community can best help. This would apply regardless of whether there was an updated release or not. We have finite amounts of time/effort, and spriting is easily one of the most time-consuming and complex parts of adding new stuff. If you've got a new bit of content and have a sprite for it, odds are (assuming people generally think it's balanced) it'll get added. They may not add much to the game, but they do add breadth and that level of richness is what makes SS13 feel "real". As an example: while for the most part the food the chef can make is mechanically similar (there's been some cool ideas for getting this changed, but I digress) the fact that I can serve a 5-course meal is awesome and rewarding in its own regard.
- Making the code available (even without secret content) would encourage people to make spinoffs/variant servers. While some may view this as healthy, I view this as fragmenting a fairly small community. If a new "Goon-based" server popped up that was basically just Goon with a different map, say, would you play it? If yes, you'd be furthering the low-pop issues occasionally seen.
- The amount of community patches that have not been implemented/rejected is less than one forum page long. I honestly don't believe that if the codebase was opened up that people would suddenly start putting in huge game-changing patches.
- If you seriously want to do something where the 2016 release is not sufficient to let you do it effectively, just freakin' ask a coder and if we think there's merit to your idea we'll be happy to give you the relevant snippets that let you build on it. Seriously.
- At the moment, the volume of community contributions is fairly manageable by the coders. You might argue "but if the community could contribute directly, coders wouldn't have to waste their time merging it and could focus on new stuff". That's not true at all, as coders would still have to review contributions. It's rare that someone submits a patch that is bug-free or couldn't be done in a better way (this includes my own community contributions pre-coder-status).
If you have an idea you would like to implement, nothing is stopping you. Nothing. Yes, there's one more hoop of "can I have the relevant code parts to build my idea around?", but all that does is slow you down a touch (if it even applies to you). I would be very interested in knowing specifically what idea someone has that they haven't implemented because of the lack of a recent release.
One aspect that I think does hold merit is getting a couple more coders aboard. There's a significant amount of trust issues in that, and it's not a quick process. What I will say is: make decent patches which actually run (seriously, if your code doesn't run on the release you built it on then you need to rethink your approach), include sensible documentation detailing the changes, and respond to feedback appropriately. Not every patch will get implemented. Focus on quality over quantity. One good patch is better than three where we had to bounce it back several times.