SFML community forums
General => SFML game jam => Topic started by: Eremiell on January 11, 2016, 11:59:29 pm
-
Hi everyone!
As it seems, the last SFML Game Jam was nearly a year ago, so I opened the topic up at IRC and was asked to bring it here.
So, ladies and gentleman (and queerfolk and strange lurking creatures and whatever you consider yourself to be), would you like to have another SFML Game Jam?
My idea would be to have it at least month (or at least say two weeks) away from both Global Game Jam and Ludum Dare, which gives us space sometime February/March or well, sometimes after.
What would you think?
I'd also like to push the rules a bit to roughly LD Jam level (unlimited team, use what you want, if you have rights to do so) to encourage people go wild and make games, but that would be up for another discussion if we agree we want to have another. We may as well split the leagues just as LD does, if there are people that wanna push and people that wanna stay. Just start meditating over it.
So right now the main question is: do you wanna have another SFML Game Jam? Secondary question is: would sometime February/March be good? (Try to propose other options if not.)
Thanks for any feedback and seeya jammin'!
-
I will gladly support another jam. However, I really don't want to see it like the last time where only 4 games were submitted. To me planning a jam and then only having 4 games is more of a disgrace (congrats to those who did participate) than a real showcase and competition. If people are willing to support it and turn out (this is the key) then another jam is a great idea.
With regards to rule changes, I'm fine with having some changes - the website already supports jams with different time lengths (was part of what I built into the website rewrite in-case we wanted something like this). Just keep my above point in mind, if there isn't really a good turnout I'm not sure if splitting an already small pool into smaller pools would be a very good idea.
Jebbs: If you read this, when does the web server have to be renewed?
-
However, I really don't want to see it like the last time where only 4 games were submitted.
Well, to make something decent in 3 days you have to have a lot of experience with SFML and at least some experience in gamedev, and you need to have 3 days free, because I don't work very productive after 8h in the office :)
-
Also have a look at this thread: Competition style voting (http://en.sfml-dev.org/forums/index.php?topic=15516.msg110434#msg110434)
Regarding the low participation and things that went wrong, I tried to analyze the situation multiple times, these were my impressions:
In my opinion, we must do something differently than last time, in order to motivate people to participate and to give them the feeling that their projects are at least looked at. This has really been a pity in the past -- once the jam was over, 2 people checked out your game and that was it.
Another thing, even more crucial than voting, is to allow only themes that are a bit more specific and challenging. In my opinion, "Puzzle" was a really awful theme ;)
[...] Yes, there are several quite interesting themes, but also some very generic ones. It's a pity that people keep suggesting themes that are rather genres or that allow to do anything :(
[...] Same to me. I was quite disappointed that the theme was so generic and vague again. Even though I started working on something (on Sunday afternoon, I didn't have time before), the concept was too broad and ambitious to finish in such a short amount of time. Even though I would not have been able to do something big in one day anyway, I might at least have come up with a nice prototype.
I'd really love if the theme was more concrete and specific, but of course that's democracy. The ironic part is just that people who do vote for a topic don't even participate (3 submitted games out of 13 votes). Seriously guys, if you push a certain theme then please at least try to work on it... Otherwise you're just blocking other themes where truly motivated people would contribute. ::)
[...] I'm not saying they actively sabotaged the jam, sorry if my statement sounded a bit harsh. What I wanted to say is: you can't deny that people who potentially participate are more motivated to do so if they like the theme... which in turn is likelier if their own votes carry more weight. If, among the voters, there are more people not participating than participating, then what effectively happens is that spectators dictate the ideas. This is not bad per se; there are different view on what "game jam" means. I'm just trying to give one explanation for the low participation -- which was already low last time, possibly also because of the broad theme (puzzle).
If I remember correctly, the second jam had the highest participation, and I claim that the inspiring theme (time travel) was a strong reason for it. I can say that it was for our team, and I'm pretty certain that others felt the same way. This is also supported by the great amount of creativity and variety in the submissions. I would say the 2nd game jam was a big success in that regard.
Of course, participation also has to do with users' availability, and there are only limited measures we can take to influence this part. One such measure would be what Tank said: make the jam last longer. Of course it's then not a jam in the classical sense anymore. But it's something to consider.
tl;dr:
- Too broad themes -- too much freedom is not an advantage, otherwise we can as well do a game outside the jam
- Theme is decided by spectators, demotivating developers with good ideas that carry no weight
- Too few attention to the results -- other people who have a devlog in the project forum post multiple times a day, while the jam entry is forgotten almost instantly
Another thing is the occasional lack of guide or "officialness" or clear informations... for example, those 4 days extension for submission, a time frame that was 1 hour in earlier jams. But in general, it was really well organized and website suggestions were quickly implemented, thumbs up for that!
-
I'm now (more or less) working together with zsbzsb to make things going and any suggestions are more than welcome.
It looks like one of the crucial troubles is low awareness about the jam in general which leads to low participation etc. No big thing was build overnight and my impression is, we should push the promotion a bit, make things clear and predictable as in there's a SFML Game Jam x times a year around this and this time, so people can expect it, note it into their (mental) diaries, prepare for them and just get used to the idea of doing the jam that time of the year. Just what LD and GGJ does. Periodicity, promotion, awareness, preparedness.
It's honestly one of those circular problems. Not many games are done in the jam because not many people care about it at the moment and not many people care about it at the moment because not many games are done. And as the games won't make themselves, it's clear it must be cut at the people awareness part.
About the theme, voting, etc. Well, this can be really hard thing to crack. At most jams I've been to, the general feeling about the final theme was "why this one, there've been much better ones on the list", but yeah, that's democracy. About more people voting than delivering, I don't think people vote just to have games served to them, but people might vote, try to develop but in the end miss the deadline or generally screw. That happens and there's probably not much that can be done about it. We can make the timeframe a bit more benevolent (say 96h, from Friday 12 AM UTC to Tuesday 12 AM UTC) so people can better plan their time and not be affected that much by their timezone, but in the end, there will always be someone, who dislikes the setting no matter how it is.
My experience about much longer jams is bad in general. Once you have plenty of time, things get postponed, motivation and drive goes away after the first few days, work, family and life gets in the way and then, the jam silently ends. Some projects are delivered, but not many people care at that moment anymore. Some longer jams even embrace the idea, putting weight on the personal achievement and skipping any kind of voting or presentation in general besides "here's the list of games made, have fun".
Themes can be redacted a bit in the current system, but some clear key would probably be good, so people don't have bad feelings about their theme put down before voting without clear reason why. To broad might be a good marker along with offensive, nonsense (asdfghjkl) and probably other flags.
Completely different question is, how large really SFML user base is and how much of us are even interested in doing game jams. Also if those numbers might get better with enough promotion, periodicity and care in general.
My feeling from countless hours of chat on IRC is, there are people, who'd like to give it a try. Some might be more experienced than others, some might fail to deliver (hack even I failed to deliver more than one time, that happens) and there are other people who might try if motivated. We should be able to build and cultivate a community around this jam, if we give it some care. And that doesn't mean one run, that means some continual work and active and positive approach from everyone from organizers to participants. Maybe this run will have a really bad theme. Maybe we will end up with very few games. The point is to still take it positively, as there were new games developed that wouldn't be otherwise, there were lessons learned, experiments tried and of course fun doing so.
The goal is to have the people come next time and bring friends. To motivate people idling around IRC and Forum to come and try. Even if they do just another flappy bird clone, it counts. Lessons learned, fun delivered. Because if you can do something trivial this time, you should be able to do something bigger next time.
For the looked at part, we might promote the games through the jam channels (mostly twitter right now), but again that would need some clear key so no one is able to spam it and everyone has the same chance to get attention. First idea out of my mind would be have participants tweet about their game once they submit and retweet those posts based on special hashtag, one tweet tops for each project at time authors decide (by tweeting about it with the hashtag). Sure, we're nowhere near the LD size and popularity, but big things aren't built overnight.
I know the competition is large. Ludum Dare, Global Game Jam, hundreds of small jams running all the time. We also cater only a specific segment of gamedevs, the SFML users. But I still think this might be viable, if we want it viable. There are more than 10000 registered users on this Forum. SFML is mentioned around the web and compared to SDL, Allegro and other popular libraries. Of course it's not Unity (meant in user base size), but the potential is there.
It also goes hand in hand with SFML popularity itself. More people using SFML, more people potentially interested in this jam. More people interested in this jam, more people (considering) using SFML.
I'd like to give it a try. We might fail in the end, but that's true about most things worth the effort. Even if we fail, hopefully there will be some people having fun in the process.
tl;dr;
Let's try and see. There are things we can try and every problem has a solution. IMHO all we need is better awareness and will to continue even if we don't get big results instantly. After all it's about fun and trying new things.
-
Sure let's have another one. :)
I'm fine with a "fixed" schedule which was from my understanding the original idea anyways.
I think with some promotion and clearly communicated information, things can turn out nicely. And I do believe that we can also reach some people through Twitter who usually don't lurk around much here on the forum.
-
It would be great to see this one have more participation so your advertising ideas are really good. It's nice to see people are still interested in this; I thought it had been totally retired.
Although it's difficult to pick up the motivation since the last one, I am interested in this. It's been a while and I don't work on actual games enough. I only hope I can find some time this time too!
-
Since i've always been "stalking" on these game-jams , this time i'd like to participate too ^^
-
I would also support another game jam ;D
It's always a good occasion to test oneself and see what one is really capable of.
One thing I noticed that seems to discourage a lot of people in some other game jams was the like of free time, I mean when they're not done other the weekend for example,that really make it harder and restrain people ( as a students in an intense pathway, time for investment in other matters really is hard :( )
-
I would also like to give it a go and test my knowledge that I've accumulated over the past year in a game Jam. I think the big problem for me would be the time frame the game Jam would take place because I work full time and also go to school full time. Crossing my fingers for a weekend Jam.
-
Jams on weekends are completely incompatible to people who have a family. What's wrong with a longer duration, e.g. 1, or even better, 2 full weeks?
-
Tank: As I've mentioned before, I have quite bad experience with that. The motivation fades away the longer the time goes. But it's definitely up for discussion. I'm not strictly against and zsbzsb is probably neither.
Everyone:
So, as there seems to be some interest, let's discuss the rules.
Let's start where the previous jam stopped: http://en.sfml-dev.org/forums/index.php?topic=12738.0 (http://en.sfml-dev.org/forums/index.php?topic=12738.0).
Some things, that are completely missing out of the rules:
- Theme Drafting: most of it is already implemented, so mostly just describe it and include it in the rules. My impression is it should work similarly to how LD draft works. Current implementation does two things differently: there's no theme slaughter (probably not looking at 30k suggestions though) and everyone has a limited amount of votes each round (I'd get rid of this, as people need to think more about the themes if they should vote all of them yes or no, maybe is just weak opinion and probably lack of thinking about it).
- Voting & Categories: unfortunately as I'm writing this, zsbzsb is not available, but my understanding is, there should be voting system very similar to the LD one. Some categories like music and visuals and gameplay and theme and whatsoever. Categories are probably also up for discussion, though if we aren't coming with anything special, the usual ones should apply just fine.
- Re-uploads: fixing small issues in the game and any issues with the packaging should be allowed even after deadline, just as porting is. I hope people can be reasonable about what constitutes a small issue.
- Theme: should not be offensive, vague, non-sensual (asdfghjkl), same or too similar to one already done (just by SFML Game Jam, or should we drop also past LD and GGJ themes?), something else it shouldn't be?
What I'd change:
- Team size: any. If you can build and manage a 10 person team, here you go. I'd like to encourage creativity here. Let people group however they seem fit.
- Preexisting Resources: Once again, free creativity. I'd say what other jams do, use whatever you legally can, but all resources (including source code) should be released under free/open licenses (are we going to say which? or make a list of acceptable ones? or are we just trusting people to be reasonable? should we allow preexisting assets with different licenses if used legally? Up for some discussion here apparently.)
- Duration: I'd say 96 hours, from Friday midnight UTC till Tuesday midnight UTC, so everyone's weekend is covered. But I'm not strictly against longer duration. I'd keep the 1 hour warm-up brainstorming (we can probably have 12 hours or even a day, if we're going for some longer format). Also see the next item.
- Delivery: probably depends a bit on duration as well. If we're doing a 72 hours, something like 2-3 hours after might be reasonable, if 2 weeks, well 2 days seems reasonable now for all the packaging stuff to be done proper, because why not. 2 weeks is enough time to do a lot of stuff and 2 days doesn't make that much a difference anyway. I'd allow to submit even some longer time after that, so people who miss deadline can still apply and show in the gallery, but I'd disallow such projects to score on the jam results. They can be still voted for and probably have some category of their own, which might or might not include the regular deadline check-ins.
Did I miss anything? Well, there are some points up for discussion. Cast your opinions and feel free to open topics I didn't touch here. In the end, results will probably come from zsbzsb's benevolent dictatorship, probably with my small help, unless I'll be fed to sharks and replaced by mini-zsbzsb or something.
-
should be released under free/open licenses (are we going to say which? or make a list of acceptable ones
Shouldn't any open-source license be OK?
-
Shouldn't any open-source license be OK?
Maybe, depends on what we want and need. This question somewhat reaches above the jam itself.
If we wanna bunch of games, that can be played and form a showcase, we don't really need to care about license.
If we wanna the code to be showcased as well, we need some open-source license. Any is OK. Even just putting the code up somewhere without any license is OK.
If we wanna the code or its snippets to be reusable and serve as possible example base, to be linked as reply for questions without any troubles for the receiver, we need a license, that allows it. That among other means a permissive, not a copyleft license. Like zlib, MIT, BSD or CC0 (PD) for code, CC-BY or CC0 (PD) for the assets. Otherwise the resources cannot be fully utilized, even if the original creator doesn't really care. You'd have to get an explicit permission by them.
So the quite important part of this question is, what we wanna achieve. I believe and I'm not alone, that more extensive publicly available codebase would be really useful. For it to be further available to be used as showcase, examples and fe. distilled into tutorials, best practices and samples, it needs to be as permissive as possible.
Of course, we can just believe everyone has that in mind and chooses the most permissive license possible depending on the resources they use. Or we can make some rules.
Consider it an idea, a line of thinking as of now. Inputs are welcome.
-
I'm with Tank, one single weekend is pretty much impossible for me (and I've tried twice now)
-
OK, some time has past, let's more further. Here's my proposal of rules:
Time Frame:
1. Participants are given 16 days (Saturday midnight UTC to Monday midnight UTC) to work on their game.
2. The theme of the jam is released 24 hours before the jam officially starts, and everyone is encouraged to use this time for brainstorming ideas.
3. Additional 48 hours are given to participants for packaging the game. No major development should be done in this time.
Submission Info:
4. A link to source is required when submitting. Source and any assets created for the game has to be release into Public Domain or under permissive license unless they're a derivative work of someone else's work, which can't be released so.
5. A link to a playable version of the game for either Windows, Mac, or Linux is required when submitting. This must include the executable and all assets/extras needed to run the game.
6. Games with NSFW or shocking content must be marked as such.
7. You are allowed to submit as early as you want, but there is no reward for doing so.
Rules:
8. You can work on a team of any size, or by yourself. Team size and members must be stated when submitting.
9. You only have 16 days to create any original code and audio/graphic assets needed for your project. Any resources are allowed as long as you have rights to use them, but you shouldn't work on creating or obtaining any resources meant specifically for the jam between theme announcement and jam beginning.
10. Game should be based on the theme, but how the theme is interpreted is up to you!
11. Any programming language may be used, as long as SFML (or one of its bindings) is used.
12. External libraries are allowed, but not SFML's competitors, such as GLFW, SDL, Allegro, etc. The use of OpenGL is allowed, however.
13. You have to give credit to original authors of any resources you use, that are not your own, even when the license doesn't enforce that. (Mostly so it's clear what is and what isn't your work.)
14. Porting to other OS's after the 16 days mark, as well as fixing small bugs in your game and any issues with your packaging is allowed and encouraged!
15. You're allowed to continue work on your game, but you have to keep the version made during the jam (with exceptions per rule 14) for voting.
Themes:
16. Theme voting takes place before theme announcement. Each participant is allowed to vote.
17. Initially participants are allowed to submit theme ideas.
18. Theme ideas must not be offensive, vague, too similar to theme of any previous SFML Game Jam or recent iterations of any major game jam and must make sense.
19. Themes will be hand approved by SFML Game Jam organizers. Organizers can also slightly rephrase the idea. Approval or disapproval of any idea and any rephrasing is final.
20. The approved themes will be voted on in several rounds.
21. Each round each participant has limited amount of votes decided by organizers based on amount of approved theme ideas. The number of votes as well as the number of rounds will be known to participant at the beginning of the first voting round. Number of votes will be the same in all rounds including the final round.
22. Votes can be used to cast positive or negative points on ideas in the given round.
23. Theme ideas with best scores from each round will progress to the final round. Winner of the final round will be announced as the jam theme.
Voting:
24. Once delivery phase is over, voting takes place. Everyone with an account of the jam site has right to vote (even non-participants).
25. Voting takes place is several categories, that will be known to voters on the beginning of the voting phase.
26. Participants can decide to not take place in voting for some categories for any reason.
27. Winner in each category as well as overall winner will be announced once the voting is over.
It's just a proposal, feel free to comment and propose changes to it.
Now for something completely different, as we're already past GGJ and LD is closer every day, let's talk terms.
As I see it, this is what's on the menu:
| Theme proposal | Theme voting | Theme announcement | Jamming | Delivery | Voting | Winner announcement |
| 1) | 15. Feb - 16. Feb | 17. Feb - 18. Feb | 19. Feb | 20. Feb - 6. Mar | 7. Mar - 8. Mar | 9. Mar - 20. Mar | 21. Mar |
| 2) | 22. Feb - 23. Feb | 24. Feb - 25. Feb | 26. Feb | 27. Feb - 13. Mar | 14. Mar - 15. Mar | 16. Mar - 27. Mar | 28. Mar |
| 3) | 29. Feb - 1. Mar | 2. Mar - 3. Mar | 4. Mar | 5. Mar - 20. Mar | 21. Mar - 22. Mar | 23. Mar - 3. Apr | 4. Apr |
| 4) | 7. Mar - 8. Mar | 9. Mar - 10. Mar | 11. Mar | 12. Mar - 27. Mar | 28. Mar - 29. Mar | 30. Mar - 10. Apr | 11. Apr |
As next LD is going to happen on 15 Apr - 18 Apr with their theme voting happening some time before that, I'm inclined to prefer option 2) giving us all a bit more time to prepare (and relax after GGJ) and keeping reasonable time delay between the end of SFML Game Jam and beginning of next LD.
tl;dr; rule proposal in line with my previous posts modified as requested by giving everyone 2 weeks + extra weekend to work on their game. 1 extra brainstorming day, 2 extra packaging days. I propose for the next SFML Game Jam to take place from 27. February to 13. March with other activities taking place right before and after those days, as listed in item 2) of table just a bit up. Comments welcome.
-
21. Each round each participant has limited amount of votes decided by organizers based on amount of approved theme ideas. The number of votes as well as the number of rounds will be known to participant at the beginning of the first voting round. Number of votes will be the same in all rounds including the final round.
What's the aim of this rule? What if I vote for X themes that I like, but then see another theme I like more than the others? surely one vote per theme per participant makes more sense? Especially as you're having up/down votes?
Other than that, I like the change to 16 days, as others have said this might actually mean I can get involved!
-
Ask zsbzsb about that one. I would do it just like you say, but this is how it's implemented right now and zsbzsb seems to prefer that way because "you have to focus on what you really care about".
EDIT: On a side note, it's possible to set some insanely high number, so you have enough votes for everything.
-
[...]new rules[...]
Sounds good. It's pretty inspiring to have such enthusiasm and effort going into the organisation.
I'm not sure about the time-frame though as you can't focus every hour of every day for over 2 weeks. It can be possible for 2 or 3 days. This might very well lead to some people spending approximately the same time they would spend on the 3 day jam spread out over the 2 weeks, possibly less focus and motivation.
Please don't misunderstand me; I do think this time-frame is worth trying. It's not about creating the most awesome games ever invented but it is about lots of people being able to participate. I think this time frame will help a lot for that.
surely one vote per theme per participant makes more sense? Especially as you're having up/down votes?
Only having up/down votes is a good reason to not vote all of the themes. Consider it a vote of three states, not two: negative, neutral, positive.
What if I vote for X themes that I like, but then see another theme I like more than the others?
This, however, is possible. You can change which themes you have voted for to the ones you are more passionate about.
e.g. You found a theme you like more, "un-vote" one that you care less about and then vote for the newly found favourite.
-
stuff about voting
Ah, I see your point - I was under the impression votes were committed once selected. If you can modify your votes afterwards then I don't see a problem with that
Regarding the timescales, I guess people who prefer doing the whole "Work solidly for 72 hours" method there's nothing stopping them, but it also allows those of us who can't do that to participate. I certainly wouldn't be able to participate without the longer timescale. But i guess it all depends on the results of the jam - the proof is in the pudding...
-
I may be mistaken about the voting. I seem to remember the ability to remove a vote but I may have dreamed that.
The only thing to 'worry' about is the people who decide to work on theirs solidly for the entire 16 days. Poor souls.
-
I may be mistaken about the voting. I seem to remember the ability to remove a vote but I may have dreamed that.
Nope, nothing is permanent until that state/round is over. You can edit your theme suggestions until suggestions close and you can change your vote until the round is over (and the results are shown) ;)
(http://i.imgur.com/OguUAV5.png)
-
Firstly, I would also be up for a new jam and will participate, subject to it not conflicting with anything else on.
Secondly, I am also in favour of everyone publishing their code, to serve as practical examples of game development with SFML. On the other hand, don't let this become another license debate; don't try to tell me whether I should copyleft it or not.
-
Make sure when this happens to advertise it on other platforms (I.E /r/gamedev)
-
Over a weekend, over two weeks, either way count me in! How do I get notified of new posts to this thread? I guess this reply will do. 8) Can't wait!
-
Firstly, I would also be up for a new jam and will participate, subject to it not conflicting with anything else on.
Unless you're away for two weeks, that shouldn't be a problem! ;)
Secondly, I am also in favour of everyone publishing their code, to serve as practical examples of game development with SFML. On the other hand, don't let this become another license debate; don't try to tell me whether I should copyleft it or not.
Submission Info:
4. A link to source is required when submitting. Source and any assets created for the game has to be release into Public Domain or under permissive license unless they're a derivative work of someone else's work, which can't be released so.
As far as I'm aware, this has always been in the rules.
Over a weekend, over two weeks, either way count me in!
It's actually 16 days, which is three weekends! ;D
-
The previous wording was:
A link to source is required when submitting. (open source is good for the soul, man.)
I took the liberty to clarify it a bit while ensuring maximal usefulness, as code that's just posted somewhere without any license is as good as none, as no one can reuse it for anything (no rights given).
If people have problem with permissiveness and would prefer copyleft, we can probably allow that even though that would disallow quite some uses including using snippets as examples in future books or indie games trying to sell a few copies, unless all sources of such books and games would be released under given copyleft license. (If I'm wrong, just correct me someone, but this is how I understand copyleft.)
We can probably go with some compromise allowing copyleft while recommending permissive for anyone without a reason to go copyleft, or we can even recommend one specific license for people that doesn't want to dig in the legalese at all. (Probably CC0, as it can be used for both code and assets, or some combo like zlib & CC-BY, even though it makes things more complicated for everyone.) Downside it, people still couldn't re-license any third party stuff, so they would still need to at least list it with authors and licenses.
EDIT: Should anyone have opposite problem (wouldn't like to provide sources at all), well, this jam is organized by SFML community and the community wants to get something back. The open source rule has been there before and is about to stay, unless there're some very good arguments against it. Open sourcing is also quite common practice in jam world (though not all jams set it by rules).
You have quite limited time to create your jam entry (even though I'd prefer to limit it much more), so don't expect to create gems. Should you create something really good you'd like to develop into commercial game, you're free to do so and you can completely close any development past the jam deadline (or past any early point you decide to deliver). There has been such games before. In that case your jam entry provides you with free publicity and serves as free demo/alpha. The game most probably still needs quite some polishing and the final version should have quite some added value (better graphics and sounds, more levels, more options, etc.)
-
The previous wording was:
A link to source is required when submitting. (open source is good for the soul, man.)
I took the liberty to clarify it a bit while ensuring maximal usefulness, as code that's just posted somewhere without any license is as good as none, as no one can reuse it for anything (no rights given).
If people have problem with permissiveness and would prefer copyleft, we can probably allow that even though that would disallow quite some uses including using snippets as examples in future books or indie games trying to sell a few copies, unless all sources of such books and games would be released under given copyleft license. (If I'm wrong, just correct me someone, but this is how I understand copyleft.)
This is more or less correct. You can of course get in touch with the author, and they can license it appropriately for you.
(The same applies to code with no license; you can always communicate. Being able to study the code is already quite a useful thing too.)
-
As I don't gather from your last post, do you (or anyone) has any serious objection about the current license ruling? Or can we proceed?
Any comments on the proposed term?
-
No objections from me.
-
After some further discussion on IRC, we're going to allow copyleft licenses. Updated rules ahead. As we require participants to have some kind of license, I also prepared an introductory text for those without clue. If you have a clue, that text isn't really meant for you, but feel free to read it anyway or skip it at your discretion. It's not part of official rules and I ask everyone to not start flames about licenses. If you wanna have civilized chat about it, come to #sfmlgamejam @ BoxBox IRC.
Time Frame:
1. Participants are given 16 days (Saturday midnight UTC to Monday midnight UTC) to work on their game.
2. The theme of the jam is released 24 hours before the jam officially starts, and everyone is encouraged to use this time for brainstorming ideas.
3. Additional 48 hours are given to participants for packaging the game. No major development should be done in this time.
Submission Info:
4. A link to source is required when submitting. Source and any assets created for the game has to be release into Public Domain or under permissive or copyleft license unless they're a derivative work of someone else's work, which can't be released so. Participants are encouraged to use permissive license for maximal reusability of the work. Recommendations for participants not fond of any given license are given on the bottom of the rules.
5. A link to a playable version of the game for either Windows, Mac, or Linux is required when submitting. This must include the executable and all assets/extras needed to run the game.
6. Games with NSFW or shocking content must be marked as such.
7. You are allowed to submit as early as you want, but there is no reward for doing so.
Rules:
8. You can work on a team of any size, or by yourself. Team size and members must be stated when submitting.
9. You only have 16 days to create any original code and audio/graphic assets needed for your project. Any resources are allowed as long as you have rights to use them, but you shouldn't work on creating or obtaining any resources meant specifically for the jam between theme announcement and jam beginning.
10. Game should be based on the theme, but how the theme is interpreted is up to you!
11. Any programming language may be used, as long as SFML (or one of its bindings) is used.
12. External libraries are allowed, but not SFML's competitors, such as GLFW, SDL, Allegro, etc. The use of OpenGL is allowed, however.
13. You have to give credit to original authors of any resources you use, that are not your own, even when the license doesn't enforce that. (Mostly so it's clear what is and what isn't your work.)
14. Porting to other OS's after the 16 days mark, as well as fixing small bugs in your game and any issues with your packaging is allowed and encouraged!
15. You're allowed to continue work on your game, but you have to keep the version made during the jam (with exceptions per rule 14) for voting.
Themes:
16. Theme voting takes place before theme announcement. Each participant is allowed to vote.
17. Initially participants are allowed to submit theme ideas.
18. Theme ideas must not be offensive, vague, too similar to theme of any previous SFML Game Jam or recent iterations of any major game jam and must make sense.
19. Themes will be hand approved by SFML Game Jam organizers. Organizers can also slightly rephrase the idea. Approval or disapproval of any idea and any rephrasing is final.
20. The approved themes will be voted on in several rounds.
21. Each round each participant has limited amount of votes decided by organizers based on amount of approved theme ideas. The number of votes as well as the number of rounds will be known to participant at the beginning of the first voting round. Number of votes will be the same in all rounds including the final round.
22. Votes can be used to cast positive or negative points on ideas in the given round.
23. Theme ideas with best scores from each round will progress to the final round. Winner of the final round will be announced as the jam theme.
Voting:
24. Once delivery phase is over, voting takes place. Everyone with an account of the jam site has right to vote (even non-participants).
25. Voting takes place in several categories, that will be known to voters on the beginning of the voting phase.
26. Participants can decide to not take place in voting for some categories for any reason.
27. Winner in each category as well as overall winner will be announced once the voting is over.
License Recommendations:
Those are just recommendations meant primarily for those that don't have any idea how to license the game. As code/assets without any stated license doesn't provide any rights and therefore can't be reused in any way, but are also (wrongly) seen by many as in Public Domain, it's important to always state your license and therefore your intentions with your work. All participants are free to use any other licenses as long as they're either permissive or copyleft.
This part is completely informal and meant just as help for those completely lost in the world of licenses. It's not meant to indicate some license or group of licenses is better than another. Things might be slightly simplified here for the sake of clarity, so read further sources and primarily the license text itself if you want to be sure. This should not be interpreted as a legal advice of any kind.
Once you pick your license or licenses (you can license different parts of your work by different licenses and it's usually good idea to split at least by code and assets as they behave quite differently), just copy it's full text, edit any parts like <author> or <year> and put in into file called LICENSE in your repository/work folder. You can also mention the license in your README or in header comment of individual source files, but that shouldn't be needed. You should always redistribute your license with sources and possibly even with binaries (that depends on license, but it doesn't hurt you to do so).
Generally speaking, you have three options. Let's dig into each a bit.
1. Public Domain
This option is for you, if you don't care tiniest bit what anyone does with your work. You want to give it to everyone, for free, to be used however they like. They can reuse any parts or the whole thing and don't have to bother you about it. You're basically giving it away, for real.
Unless you want to compose your own Public Domain statement, you've got two main options in this category and the nice bit is, you can license your code and your assets using one license, as you just waive all rights and there's not much to care about further.
Unlicense (http://unlicense.org/) tl;dr;Legal (https://tldrlegal.com/license/unlicense)
CC0 (https://creativecommons.org/about/cc0/) tl;dr;Legal (https://tldrlegal.com/license/creative-commons-cc0-1.0-universal)
It shouldn't make much difference which one you choose, the second one is probably slightly more popular, but that's about it.
2. Permissive license
If you don't want to give the thing away fully, but also want to let anyone use it for anything they want without much concern (that is including commercial use and about anything), you should consider a permissive license. Details might slightly differ, but mostly you require to get your copyright notice and that's it. No one has to bother you to reuse the work, yet you still own it.
Some good choices for code here are:
zlib (http://zlib.net/zlib_license.html) tl;dr;Legal (https://tldrlegal.com/license/zlib-libpng-license-%28zlib%29)
MIT (https://mitlicense.org/) tl;dr;Legal (https://tldrlegal.com/license/mit-license)
BSD (http://www.freebsd.org/copyright/freebsd-license.html) tl;dr;Legal (https://tldrlegal.com/license/bsd-2-clause-license-%28freebsd%29)
ISC (http://opensource.org/licenses/isc-license) tl;dr;Legal (https://tldrlegal.com/license/-isc-license)
Apache (https://www.apache.org/licenses/) tl;dr;Legal (https://tldrlegal.com/license/apache-license-2.0-%28apache-2.0%29)
Artistic (http://www.perlfoundation.org/artistic_license_2_0) tl;dr;Legal (https://tldrlegal.com/license/artistic-license-2.0-%28artistic%29)
The first four are quite similar, short, permissive, the other two are slightly longer. What they allow and disallow also slightly differs, but the main idea is similar. The first one is used by SFML itself.
And you'll want to license the assets with a different one:
MirOS (https://www.mirbsd.org/MirOS-Licence) tl;dr;Legal (https://tldrlegal.com/license/miros-license-%28miros%29)
CC-BY (https://creativecommons.org/licenses/by/4.0/) tl;dr;Legal (https://tldrlegal.com/license/creative-commons-attribution-4.0-international-%28cc-by-4%29)
Here, the first one derives from BSD license and gives roughly the same care to your assets, while the second one is probably the most popular permissive asset license.
3. Copyleft
Now you not just wanna give, but you wanna everyone else to give back. That sounds wonderful, but also poses some limitations, as generally any derived work must reuse the same license and that's not always practical. Still, you can do this. There's also slight difference between strong and weak copyleft, where the first one demands even other components to adapt, while the second one only cares about itself, so it can be used together with things under other licenses.
Weak copyleft for your code:
Mozilla (https://www.mozilla.org/en-US/MPL/) tl;dr;Legal (https://tldrlegal.com/license/mozilla-public-license-2.0-%28mpl-2%29)
LGPL (http://www.gnu.org/licenses/lgpl-3.0.html) tl;dr;Legal (https://tldrlegal.com/license/gnu-lesser-general-public-license-v3-%28lgpl-3%29)
Strong copyleft for your code:
GPL (http://www.gnu.org/licenses/gpl-3.0.html) tl;dr;Legal (https://tldrlegal.com/license/gnu-general-public-license-v3-%28gpl-3%29)
Weak copyleft for your assets:
Against DRM (http://www.freecreations.org/Against_DRM2.html)
CC-BY-SA (https://creativecommons.org/licenses/by-sa/4.0/) tl;dr;Legal (https://tldrlegal.com/license/creative-commons-attribution-sharealike-4.0-international-%28cc-by-sa-4.0%29)
FAL (http://artlibre.org/licence/lal/en/)
I don't know about any way to strongly copyleft assets, as they mostly behave like solitary units.
If you're not sure you want to copyleft your code, you might consider one of the first two approaches as in that way, your work will become much more useful.
Some further reading to help you decide:
FreedomDefined (http://freedomdefined.org/Licenses)
OSI (http://opensource.org/licenses)
FSF (http://www.gnu.org/licenses/licenses.html)
ChooseALicense (http://choosealicense.com/licenses/)
If you still don't know, probably just pick one of the three approaches and use the first one on list for code and for assets or ask around, but expect quite mixed feelings about any of them.
Regarding the license recommendation, I'm pretty sure some people would disapprove about something, as licensing is one of never ending hot topics around the software community. Please keep the flame down. It's meant for people totally lost in licensing so they have some starting point. If you have some serious practical objections (like I seriously misinterpreted something, which could happen as I'm no lawyer), approach me preferably on IRC or in some private manner to not induce flamewars. I'm prepared to fix any real issues with the text. Also note that the text is informal and not part of official rules. It's meant to help people, not to tell you which license to use, if you have any preferences.
-
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.
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".
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.
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.
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.
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
Source and any assets created for the game has to be release into Public Domain or under permissive or copyleft license unless they're a derivative work of someone else's work, which can't be released so. Participants are encouraged to use permissive license for maximal reusability of the work. Recommendations for participants not fond of any given license are given on the bottom of the rules.
and all the other related ones with
Participants can choose the license of their code and assets freely, but must follow licenses of external work (libraries, assets) used in the game.
Some rules just add to the verbosity without carrying useful information i.e. constraints, such as
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!
Others appear to be entirely obvious with the barest minimum of common sense, but have a hidden important constraint:Theme voting takes place before theme announcement. Each participant is allowed to vote.
People who do not participate are not allowed to vote then? Does the delivery make participants, or anybody who just begins? How to know in advance?
Others are duplicate and can easily be rephrased in fewer points, e.g. 1-9 (time) or 9-12-13 (use of external work).
-
Thanks for input! It's really appreciated.
To address you questions in order:
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.
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.
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.
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.
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.
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.
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.
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.
-
Several people called for it and no one besides me spoken against it
Yes, I think it's worth a try, it's just a different experience. Would be cool if more people got to participate when they now have time.
My point of view on this one is, that with such long time frame, it doesn't really make much difference
I agree, I meant it more generally (in case we have shorter jams in the future).
The license recommendation weren't meant as part of the rules and I was in fact looking for way to separate them even more.
Maybe something like "participants can choose the license freely" and a link to potential options (on a different page) is a good compromise.
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.
Yes, unfortunately I haven't had a lot of time recently and so only saw it now. If I can help simplify some rules, I'd gladly do so (but I don't want to just change everything, as you've had a lot of effort drafting the ruleset).
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.
Yes, my main idea is to keep the rules short and to the point, so that people actually read and remember them and can quickly look up what they need. And I think omitting redundant and information-less ones helps in this regard.
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.
;D
-
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.
No, organizers are not decisive force at all. All that is done if a theme is appropriate and not generic like 'puzzle' (yes Nexus I know how much you disliked that jam ;)) is that the organizer can click on it [approve/disapprove] and it will be voted on by the community. Now the ability is there for the person with permission to edit a theme suggestion to whatever they want (if theme suggestions are still open the user will see those changes), but it isn't used that way (same way a mod has permission to edit posts on a forum, but they don't). It is there to be used as a grammar correction tool ('massive puzzle' => 'Massive Puzzle') so all themes appear consistent on the site.
@Eremiell mentioning theme approvals is not necessary in the rules. The way it is done may change and really should not have an affect on the outcome of the jam. It was added simply to avoid the problem of having generic/uninteresting/bad themes in the voting rounds.
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.
Categories in LD are hard coded into their site, its always the same for every jam. That said, I can make categories customizeable per jam - but they would be announced with the jam. There is no reason to withhold that information from anyone.
-
Firstly, sorry it took me some two more days than expected, other stuff got in my way. Will try to reserve a bit of my time every morning for this from now.
I tried to restructure the rules a bit, which could hopefully bring more clarity and everyone should have clear idea which rules are important for them at any phase. In the end, there's now even slightly more rules, as some old rules needed to be split into several phases, but I think, it's much more readable now and gives better idea about phase progression and what applies when.
Also tried to get rid about any fixed time units anywhere in the rules besides the initial Time Frame section, so it could be easily edited for different durations.
Cleaned up the style a bit too, got rid of all you/your and replaced it with participants/the. Project/game and similar got normalized to entry to allow maximal creativity. Do whatever you want, even if it might not feel like hitting the "game" lable in your mind. (But note generic media player will probably not do very good in the final judging.)
Time Frame:
1. The jam starts with theme polling, with 48 hours for theme proposal and another 48 hours for theme voting.
2. The theme of the jam is announced 24 hours before the jam officially starts, and everyone is encouraged to use this time for brainstorming ideas. No work should be done yet.
3. Participants are given 16 days of jamming (Saturday midnight UTC to Monday midnight UTC) to work on their entry.
4. Additional 48 hours are given to participants for packaging the entry. No major development should be done in this time.
5. Everyone has 12 days to try the entries and cast their votes in final judging.
6. Together start to finish, the jam takes 5 weeks. Most of the participant's activity is expected in the 16 days of jamming.
Theme Polling:
7. Each participant (person intending to try to make an entry during the jamming phase on his own or in a team) is allowed to take place in theme polling. Non-participants are asked to abstain from theme voting while their input is welcome in theme proposal.
8. During theme proposal subphase, everyone's welcome to propose theme ideas.
9. Theme ideas must not be offensive, vague, too similar to theme of any previous SFML Game Jam or recent iterations of any major game jam and must make sense.
10. During theme voting subphase, the theme ideas will be voted on in several rounds.
11. Each round each participant has limited amount of votes decided by organizers based on amount of received theme ideas. The number of votes as well as the number of rounds will be known to participant at the beginning of the first voting round. Number of votes will be the same in all rounds including the final round.
12. Votes can be used to cast positive or negative points on ideas in the given round.
13. Theme ideas with best scores from each round will progress to the final round. Winner of the final round will be announced as the jam theme.
Theme Announcement:
14. Participants are free to publicly or privately brainstorm entry ideas and form teams. No actual work on the entry should yet be started.
15. Participants can continue to do whatever they're normally doing even if that would be useful for their jam entry, but they shouldn't specifically work on the entry itself.
Jamming:
16. Paticipants can work in a team of any size, or by themself. Any participant is allowed work on several teams or entries (like asset creators can provide music or graphics for several entries, etc.).
17. Participants should only create any original work needed for their entry during this phase.
18. Any programming language may be used, as long as SFML (or one of its bindings) is used.
19. External libraries are allowed, but not SFML's competitors, such as GLFW, SDL, Allegro, etc. The use of OpenGL is allowed, however.
20. Any additional resources are allowed as long as participants have rights to use them, but they shouldn't be presented as original content created for the jam. Previous rule is the only limitation to this.
21. Participants have to give credit to original authors of any resources they use, that are not their own, even when the license doesn't enforce that. (Mostly so it's clear what is and what isn't their work.)
Delivery:
22. Team size and members must be stated when submitting.
23. A link to source is required when submitting as well as link to assets/anything needed in addition to compiled source in ready to use form (archive with expected directory structure, directory with expected contents and subdirectories on some cloud storage service, ...).
24. Source and any assets created for the entry has to be release into Public Domain or under permissive or copyleft license if that's possible. Participants are encouraged to use permissive license for maximal reusability of the work. Recommendations for participants without prior understanding on licensing are provided [here] (imagine link to the previous text, probably slightly edited), but are not part of these rules in any way.
26. A link to a working version of the entry for either Windows, Mac, or Linux is required when submitting. This must include the executable and all assets/extras needed to run the entry.
26. Entries with NSFW or shocking content must be marked as such.
27. Porting to other OS's as well as fixing small bugs in the entry and any issues with the packaging is allowed and encouraged.
28. Particpants are allowed to continue work on their entry, but they have to keep the version made during the jamming phase (with exceptions per previous rule) for final judging.
Final Judging:.
29. Everyone with an account of the jam site has right to vote (even non-participants).
30. Final judging takes place in several categories, that will be known to everyone at the beginning of the jam.
31. Participants can decide to not take place in judging for some categories for any reason. Participants who didn't create any original content in given category are encouraged to do so.
32. Porting to other OS's as well as fixing small bugs in the entry and any issues with the packaging is still allowed and encouraged.
33. Participants are allowed to continue work on their entry, but they have to keep the version made during the jamming phase (with exceptions per previous rule) until this phase is over
34. Winner in each category as well as overall winner will be announced once the final judging is over.
I'll leave it here for comments, will come back later tomorrow to discuss terms. The time is slightly running up and we might concider even a later term after the LD.
EDIT: Renamed Final Voting to Final Judging to further differenciate from Theme Polling, which still has Theme Voting as subphase.
-
Ok, let's look at the terms.
First, LD recapitulation, as it's what kinda limits our possibilities.
Next LD comes 15-18 April. Their theme proposal start 5 weeks before that, which is 11 March, theme voting 3 weeks later which is first April and their final judging goes for 3 weeks, meaning 9 May.
Now for most participants the most crucial time will be in both LD and SFMLGJ the actual jamming time, but the rest is important as well. Everyone likes to have a word about the theme and the final judging serves as promotion. So we'd like to minimize any overlapping and maximize the gap between the jamming parts.
From another point of view, we'd like maximize the participation, which means both getting some some promotion outside this forum on SFML IRC and letting people prepare for the jam.
OK, let's revisit the terms proposed last time:
| Theme proposal | Theme voting | Theme announcement | Jamming | Delivery | Final judging | Winner announcement |
| 1) | 15. Feb - 16. Feb | 17. Feb - 18. Feb | 19. Feb | 20. Feb - 6. Mar | 7. Mar - 8. Mar | 9. Mar - 20. Mar | 21. Mar |
| 2) | 22. Feb - 23. Feb | 24. Feb - 25. Feb | 26. Feb | 27. Feb - 13. Mar | 14. Mar - 15. Mar | 16. Mar - 27. Mar | 28. Mar |
| 3) | 29. Feb - 1. Mar | 2. Mar - 3. Mar | 4. Mar | 5. Mar - 20. Mar | 21. Mar - 22. Mar | 23. Mar - 3. Apr | 4. Apr |
| 4) | 7. Mar - 8. Mar | 9. Mar - 10. Mar | 11. Mar | 12. Mar - 27. Mar | 28. Mar - 29. Mar | 30. Mar - 10. Apr | 11. Apr |
The first one's clearly out of question, too soon. The second one kinda as well. The later two might still be viable.
Alternative would be going after LD. That would mean probably something like:
| Theme proposal | Theme voting | Theme announcement | Jamming | Delivery | Final judging | Winner announcement |
| 5) | 9. May - 10. May | 11. May - 12. May | 13. May | 14. May - 29. May | 30. May - 31. May | 1. Jun - 12. Jun | 13. Jun |
Which seem kinda late, if you ask me.
So my proposal right now is to go with number 3). That means some 3 weeks from now before the theme polling, roughly 4 weeks to start of jam, which should give us some tim to prepare and advertise and with the jamming phase ending 20. March, that gives roughly 3 weeks to the LD with our final judging ending slightly into their theme voting.
Comments welcome, if there are none before Sunday, we'll move forward with this.
EDIT: Reflected the change of Final voting to Final judging.
-
Nice work, thanks for the fundamental restructuring! It's really much clearer, now that phases are separated.
Some comments:
- Polling = proposal + voting? To increase clarity, I would suggest to omit the term "polling" entirely and split proposal and voting phase. The separation would make clear that the two phases are done after each other, not in parallel.
- There are still some duplications, like "No work should be done yet." or "No actual work on the entry should yet be started." Maybe the time frame should only give an overview over the phases, while each of them is explained in its respective section.
- Little typos:
"Source and any assets created for the entry has to be release" -> "Source and any assets created for the entry have to be released
"Particpants are allowed to continue" -> "Participants..."
"until this phase is over" -> fullstop at end - "Entry" sounds very abstract, it might confuse more than it helps. "Game" would be okay in my opinion, and otherwise "project" would still be generic enough. But anyway, this is a really minor point, we can also leave "entry".
If you'd like, you can also post this on the SFML Wiki so I can help editing. But I think it's almost finished anyway.
-
3) seems fine to me.
-
Battling the time again, those dastardly deadlines. Lucky us the system watches the jam deadlines, so it won't get two days late just because I had to finish the movement code in time. :)
I'll incorporate the latest set of proposals hopefully tomorrow (Tuesday CET time) and we'll get the beast moving.
-
OK, (final?) draft of the rules? I honestly liked the entry more, but let's compare. I'm up to edit it back if needed.
Time Frame:
1. The jam starts with 48 hours for theme proposal.
2. Another 48 hours are given for theme voting.
3. The theme of the jam is announced 24 hours before the jamming officially starts.
4. Participants are given 16 days of jamming (Saturday midnight UTC to Monday midnight UTC) to work on their projects.
5. Additional 48 hours are given to participants for packaging the projects and delivery.
6. Everyone has 12 days to try the projects and cast their votes in final judging.
7. Together start to finish, the jam takes 5 weeks, all phases follow each other immediately. Most of the participant's activity is expected in the 16 days of jamming.
Theme Proposal:
8. Everyone with an account on the jam site is welcome to propose theme ideas.
9. Theme ideas must not be offensive, vague, too similar to theme of any previous SFML Game Jam or recent iterations of any major game jam and must make sense.
Theme Voting:
10. Each participant (person intending to try to make a project during the jamming phase on his own or in a team) is allowed to take place in theme voting. Non-participants are asked to abstain.
11. The theme ideas will be voted on in several rounds.
12. Each round each participant has limited amount of votes decided by organizers based on amount of received theme ideas. The number of votes as well as the number of rounds will be known to participant at the beginning of the first voting round. Number of votes will be the same in all rounds including the final round.
13. Votes can be used to cast positive or negative points on ideas in the given round.
14. Theme ideas with best scores from each round will progress to the final round. Winner of the final round will be announced as the jam theme.
Theme Announcement:
15. Participants are free to publicly or privately brainstorm project ideas and form teams. No actual work on the project should yet be started.
16. Participants can continue to do whatever they're normally doing even if that would be useful for their jam project, but they shouldn't specifically work on the project itself.
Jamming:
17. Participants can work in a team of any size, or by themselves. Any participant is allowed to work on several teams or projects (like asset creators can provide music or graphics for several projects, etc.).
18. Participants should only create any original work needed for their project during this phase.
19. Any programming language may be used, as long as SFML (or one of its bindings) is used.
20. External libraries are allowed, but not SFML's competitors, such as GLFW, SDL, Allegro, etc. The use of OpenGL is allowed, however.
21. Any additional resources are allowed as long as participants have rights to use them, but they shouldn't be presented as original content created for the jam. Previous rule is the only limitation to this.
22. Participants have to give credit to original authors of any resources they use, that are not their own, even when the license doesn't enforce that. (Mostly so it's clear what is and what isn't their work.)
Delivery:
23. Team size and members must be stated when submitting.
24. A link to source is required when submitting as well as link to assets/anything needed in addition to compiled source in ready to use form (archive with expected directory structure, directory with expected contents and subdirectories on some cloud storage service, ...). Additional libraries should be listed and providing precompiled binaries or ways to obtain or compile them is encouraged.
25. Source and any assets created for the project have to be release into Public Domain or under permissive or copyleft license if that's possible. Participants are encouraged to use permissive license for maximal reusability of the work. Recommendations for participants without prior understanding on licensing are provided [here] (imagine link to the previous text, probably slightly edited), but are not part of these rules in any way.
26. A link to a working version of the project for either Windows, Mac, or Linux is required when submitting. This must include the executable and all assets/extras needed to run the project.
27. Projects with NSFW or shocking content must be marked as such.
28. Porting to other OS's as well as fixing small bugs in the project and any issues with the packaging is allowed and encouraged.
29. Participants are allowed to continue work on their project, but they have to keep the version made during the jamming phase (with exceptions per previous rule) for final judging.
Final Judging:
30. Everyone with an account of the jam site has right to vote (even non-participants).
31. Final judging takes place in several categories, that will be known to everyone at the beginning of the jam.
32. Participants can decide to not take place in judging for some categories for any reason. Participants who didn't create any original content in given category are encouraged to do so.
33. Porting to other OS's as well as fixing small bugs in the project and any issues with the packaging is still allowed and encouraged.
34. Participants are allowed to continue work on their project, but they have to keep the version made during the jamming phase (with exceptions per previous rule) until this phase is over.
35. Winner in each category as well as overall winner will be announced once the final judging is over.
Let's assume no major changes will be made. We're still open for comments, but mostly small fixes.
Also let's fix the dates and start promotion.
| Theme Proposal | Theme Voting | Theme Announcement | Jamming | Delivery | Final Judging | Winner Announcement |
| 3) | 29. Feb - 1. Mar | 2. Mar - 3. Mar | 4. Mar | 5. Mar - 20. Mar | 21. Mar - 22. Mar | 23. Mar - 3. Apr | 4. Apr |
I'll slightly edit the license recommendation text and make new thread for the jam announcement and another one for the recommendations. Let's make this large. :)
-
The results or the next jam — which comes first, we never know.
-
The results or the next jam — which comes first, we never know.
or neither...