Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Eremiell

Pages: 1 [2]
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:

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.

17
SFML game jam / Re: Wanna another? (early 2016 edition)
« on: February 04, 2016, 04:19:13 pm »
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 tl;dr;Legal
CC0 tl;dr;Legal

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 tl;dr;Legal
MIT tl;dr;Legal
BSD tl;dr;Legal
ISC tl;dr;Legal
Apache tl;dr;Legal
Artistic tl;dr;Legal

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 tl;dr;Legal
CC-BY tl;dr;Legal

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 tl;dr;Legal
LGPL tl;dr;Legal

Strong copyleft for your code:
GPL tl;dr;Legal

Weak copyleft for your assets:
Against DRM
CC-BY-SA tl;dr;Legal
FAL

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
OSI
FSF
ChooseALicense

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.

18
SFML game jam / Re: Wanna another? (early 2016 edition)
« on: February 04, 2016, 05:25:15 am »
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?

19
SFML game jam / Re: Wanna another? (early 2016 edition)
« on: February 03, 2016, 09:37:22 am »
The previous wording was:
Quote
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.)

20
SFML game jam / Re: Wanna another? (early 2016 edition)
« on: February 01, 2016, 12:07:25 pm »
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.

21
SFML game jam / Re: Wanna another? (early 2016 edition)
« on: February 01, 2016, 05:13:02 am »
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 proposalTheme votingTheme announcementJammingDeliveryVotingWinner announcement
1)15. Feb - 16. Feb17. Feb - 18. Feb19. Feb20. Feb - 6. Mar7. Mar - 8. Mar9. Mar - 20. Mar21. Mar
2)22. Feb - 23. Feb24. Feb - 25. Feb26. Feb27. Feb - 13. Mar14. Mar - 15. Mar16. Mar - 27. Mar28. Mar
3)29. Feb - 1. Mar2. Mar - 3. Mar4. Mar5. Mar - 20. Mar21. Mar - 22. Mar23. Mar - 3. Apr4. Apr
4)7. Mar - 8. Mar9. Mar - 10. Mar11. Mar12. Mar - 27. Mar28. Mar - 29. Mar30. Mar - 10. Apr11. 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.

22
SFML game jam / Re: Wanna another? (early 2016 edition)
« on: January 21, 2016, 12:10:12 am »
Quote
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.

23
SFML game jam / Re: Wanna another? (early 2016 edition)
« on: January 20, 2016, 08:53:31 pm »
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.

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.

24
SFML game jam / Re: Wanna another? (early 2016 edition)
« on: January 12, 2016, 09:19:17 pm »
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.

25
SFML game jam / Wanna another? (early 2016 edition)
« 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'!

Pages: 1 [2]
anything