16
SFML game jam / Re: Wanna another? (early 2016 edition)
« on: February 07, 2016, 10:23:45 am »
Thanks for input! It's really appreciated.
To address you questions in order:
There are jams a month long and probably even longer. I have myself named the very same concerns (lack of motivation to do such a long jam being on top), but people asked for such a long time frame. Several people called for it and no one besides me spoken against it, so I backed up on that one and went with the majority.
My point of view on this one is, that with such long time frame, it doesn't really make much difference, but I have no strong opinions about it. I proposed it this way, because people were asking for more time and it didn't make any difference for me to allow some more hours for this. Some extra time for both were given previously, so I mostly just scaled that time with the jam itself.
There are many reasons why we prefer open source and maybe I haven't pick the strongest ones. My main concerns in this were clarity (everyone can see for themselves) and reusability, for we are often striving for good examples for lot of stuff. The license recommendation weren't meant as part of the rules and I was in fact looking for way to separate them even more. My main concert was some people might have utterly no idea about the whole licensing thing and I wanted to provide some pointers. If people feel the recommendations are really out of place, I can of course completely drop them, but I don't really think any other overview is any more neutral (not implying mine is more neutral than others, but rather that I don't really think any at all can be neutral by nature). I can reduce it to link to fe. ChooseALicense, which is a site provided by GitHub, but its list of licenses is in fact smaller than what I provided and they don't really try to categorize them much or to provide serious alternatives for assets. But I'm open to completely drop this part or bend or reduce it in any way seem fit. I recognize it's a bit controversial and I tried to stay as neutral as possible, just encountered several clear cases of complete misunderstanding in the IRC lately and wanted to provide some elementary help. Maybe I failed at that, hard to judge by myself.
This part comes directly from implementation and isn't my invention. From my point of view, any good, non-duplicate ideas should be let through and rephrasing should mostly be used only for fixing obvious grammar errors or similar troubles, possibly replacing a vulgarity with some equivalent meaning in otherwise good ideas. What were the original intentions would know only zsbzsb.
I worded this part this way, because even I have no idea, how far this is in implementation and what are zsbzsb's intentions with it. My idea about it is pretty much copy-paste what LD got, but we can discuss the categories. I believe zsbzsb should be able to add or remove categories pretty much on go, but last time we were talking about his feature, it was something yet to be implemented.
I was trying to open some discussion on the topic and probably find what people would like. As there wasn't exactly abundance of response, I just took all the ideas I mentioned before and tried to sum them up. Even then, I once again asked for input and only reaction I got to this point was "allow copyleft", so I did. I'm still open to draft the rules further and possibly got rid of any or all of them. But we should hurry a bit on that if we wanna do this before next LD.
These were minus one word copied from last time rules. I had no reason to drop them, but I acknowledge, they don't add much useful information.
In my view, participant is anyone with intention to do the jam. As I reasoned several times before, people may try and fail and that just happens. But we still shouldn't support people to just vote and not even try, despite we know we can't do much against such cases. Still we don't want to actively allow that as such behavior is to be frowned upon if nothing else.
I'm up to try to build in your input and any other input that might come. Tomorrow after I wake up that is. Wouldn't end up well right now.
To address you questions in order:
Quote
16 days is an option, but it's not a game jam anymore. The whole feel of getting something cool done in short amounts of time is lost, and I can imagine motivation with it. It may be worth a try for the sake of people who have no time at all otherwise, but you have to consider that some people who would join short jams may not do so in longer jams. Also, the time available may vary massively between participants, so it's again more difficult to compare the results.
There are jams a month long and probably even longer. I have myself named the very same concerns (lack of motivation to do such a long jam being on top), but people asked for such a long time frame. Several people called for it and no one besides me spoken against it, so I backed up on that one and went with the majority.
Quote
The "24h before" and "48h+ after" are questionable in my opinion, especially when the time frame is already astronomically long. But even otherwise, why can't brainstorming and bugfixing not be part of the project, and hence the deadline? In reality, you don't get extra time for anything you do either, and it's a good skill to incorporate planning as well as refining/bugfixing in the time schedule. Bugfixing especially would even increase the quality in my opinion -- when participants know that their stuff has to work by the end of the deadline, they'll focus more on quality and less on quantity and the motto "I can still fix things later".
My point of view on this one is, that with such long time frame, it doesn't really make much difference, but I have no strong opinions about it. I proposed it this way, because people were asking for more time and it didn't make any difference for me to allow some more hours for this. Some extra time for both were given previously, so I mostly just scaled that time with the jam itself.
Quote
Regarding "this jam is organized by SFML community and the community wants to get something back" -- well, the community gets the game. The main workload and talent lies on the developer's side. The community actually does nothing besides choosing the theme. I'm not saying we should close-source the contributions, but this argument is not the best one. I'd rather see the advantage of open-source in that it helps get insights into game development and SFML, with different people's takes on it. But we should really not dictate what license people have to choose -- its their code and their intellectual property. I would also omit any recommendations, as they're subjective, make the ruleset unnecessarily longer, and lists of licenses can easily be found on other sites (rather add a link to a neutral overview). And besides, as good as "open source" and its pink-glasses ideology sounds, there's a small chance that it may prevent people from integrating "genius" mechanisms they don't like to publish. But it's an effective way of checking whether rules were followed and code was self-written.
There are many reasons why we prefer open source and maybe I haven't pick the strongest ones. My main concerns in this were clarity (everyone can see for themselves) and reusability, for we are often striving for good examples for lot of stuff. The license recommendation weren't meant as part of the rules and I was in fact looking for way to separate them even more. My main concert was some people might have utterly no idea about the whole licensing thing and I wanted to provide some pointers. If people feel the recommendations are really out of place, I can of course completely drop them, but I don't really think any other overview is any more neutral (not implying mine is more neutral than others, but rather that I don't really think any at all can be neutral by nature). I can reduce it to link to fe. ChooseALicense, which is a site provided by GitHub, but its list of licenses is in fact smaller than what I provided and they don't really try to categorize them much or to provide serious alternatives for assets. But I'm open to completely drop this part or bend or reduce it in any way seem fit. I recognize it's a bit controversial and I tried to stay as neutral as possible, just encountered several clear cases of complete misunderstanding in the IRC lately and wanted to provide some elementary help. Maybe I failed at that, hard to judge by myself.
Quote
Why do organizers hand-approve and rephrase ideas? That essentially makes them the decisive force, not the community. I agree that such intervention would be a good thing when the topic is inappropriate, for example when it's too broad (like "puzzle" one time). But why rephrase? Furthermore, it's not 100% clear at what stage this happens -- it seems to be before the voting even stars. But then, a lot of interventions would be required, because several topics are not ideal to base a jam on.
This part comes directly from implementation and isn't my invention. From my point of view, any good, non-duplicate ideas should be let through and rephrasing should mostly be used only for fixing obvious grammar errors or similar troubles, possibly replacing a vulgarity with some equivalent meaning in otherwise good ideas. What were the original intentions would know only zsbzsb.
Quote
Why are game voting categories only known at the beginning of the game voting phase? (Name that differently, to not confuse it with theme voting). If the developer is left in the dark regarding what matters in the end, he can't optimize his game accordingly. For example, if "closeness to the theme" is not one category, the whole point of adhering to the theme is defeated.
I worded this part this way, because even I have no idea, how far this is in implementation and what are zsbzsb's intentions with it. My idea about it is pretty much copy-paste what LD got, but we can discuss the categories. I believe zsbzsb should be able to add or remove categories pretty much on go, but last time we were talking about his feature, it was something yet to be implemented.
Quote
The number of rules is too high. This is becoming a bureaucratic mess rather than something simple, and reading walls of text that say nothing meaningful puts people off. Why do we need to mention obvious things like "you have to credit other's work", and that multiple times? Why can't we replace convoluted anti-concise paragraphs like...
I was trying to open some discussion on the topic and probably find what people would like. As there wasn't exactly abundance of response, I just took all the ideas I mentioned before and tried to sum them up. Even then, I once again asked for input and only reaction I got to this point was "allow copyleft", so I did. I'm still open to draft the rules further and possibly got rid of any or all of them. But we should hurry a bit on that if we wanna do this before next LD.
Quote
7. You are allowed to submit as early as you want, but there is no reward for doing so.
10. Game should be based on the theme, but how the theme is interpreted is up to you!
These were minus one word copied from last time rules. I had no reason to drop them, but I acknowledge, they don't add much useful information.
Quote
Theme voting takes place before theme announcement. Each participant is allowed to vote.
In my view, participant is anyone with intention to do the jam. As I reasoned several times before, people may try and fail and that just happens. But we still shouldn't support people to just vote and not even try, despite we know we can't do much against such cases. Still we don't want to actively allow that as such behavior is to be frowned upon if nothing else.
I'm up to try to build in your input and any other input that might come. Tomorrow after I wake up that is. Wouldn't end up well right now.