1
SFML projects / Re: #relicsofpast - Ludum Dare 39 platformer - WIP - Mac OSX builder wanted
« on: August 03, 2017, 04:22:31 pm »
Reserved
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.
Pages: [1] 2
2
SFML projects / #relicsofpast - Ludum Dare 39 platformer - WIP - Mac OSX builder wanted
« on: August 03, 2017, 04:22:12 pm »
First of all, this LD, we finally made it. We had made something working in 72 hours, and even if it's not (yet) the best game ever, we're proud of it.
So what did we make?
It's a randomly generated platformer, where you jump in dark. There's a light mechanic, that sadly ended up not very useful, and we'll probably repurpose it somehow.
It has (imho pretty nice) music and pixel graphics done by xclementx, whom I met (online) for first time for this jam, and we'll prob do some more jamming together.
There will obviously be the relics, which we didn't make in time (I had some relic sprites ready, but didn't fit the code in time), and some more minor things like menus, top score chart and such. We have some plans to polish.
If you're interested and especially if you also took part and want to review it, follow here.
Feedback is welcome.
There are builds for Linux, Windows, and Mac OSX available on the LD page, but you'll need SFML installed for the Mac one. (Linked dynamically instead of statically by accident.) If you happen to be a Mac user willing to do us a build (preferably once in a while, but even one time is welcome right now), please PM me here or find me on IRC. Thanks!
Sorry for keeping this page mostly a stub at this point, but I need to prepare some proper gameplay videos and such. Just wanted to release the info into SFML community. News and more proper cover post to follow.
3
General discussions / Re: Real World SFML Meeting in Prague, CZ
« on: April 21, 2016, 02:15:13 pm »
Totally missed the reply for a few days. I'm at #sfml@BoxBox practically 24/7, not that active in here apparently.
We can try the slack thing, if there's interest. I'm practically native to IRC, so I naturally prefer that, but I'm up to try new things. Already installed it, will explore it a bit first I guess.
We can try the slack thing, if there's interest. I'm practically native to IRC, so I naturally prefer that, but I'm up to try new things. Already installed it, will explore it a bit first I guess.
4
General discussions / Real World SFML Meeting in Prague, CZ
« on: April 06, 2016, 02:06:03 pm »
Hi everyone,
some of you might know me from IRC, some might not.
We've noticed over the time on IRC, there are quite some people with .cz domains and some weeks ago, I started to approach them and inquire about where they live and if they might be up for some real world meeting.
The first Prague SFML meeting took place about two weeks ago. We were expecting to be 3-4, but in the end, only two of us arrived.
Just recently, it happened to me, that some more people might be reached using forums.
So, are there more of us? Would there be some interest to meet once in a while, have chat over SFML, C++, gamedev and whatever anyone's currently interested in?
some of you might know me from IRC, some might not.
We've noticed over the time on IRC, there are quite some people with .cz domains and some weeks ago, I started to approach them and inquire about where they live and if they might be up for some real world meeting.
The first Prague SFML meeting took place about two weeks ago. We were expecting to be 3-4, but in the end, only two of us arrived.
Just recently, it happened to me, that some more people might be reached using forums.
So, are there more of us? Would there be some interest to meet once in a while, have chat over SFML, C++, gamedev and whatever anyone's currently interested in?
5
Feature requests / Re: Add support for Opus audio
« on: April 01, 2016, 05:21:46 pm »
Any plans to merge this feature?
6
SFML game jam / Re: 5th SFML Game Jam
« on: March 26, 2016, 01:01:52 am »
Ay, we got a bit delayed on the final judging because of some unexpected troubles. Sorry for not communicating it earlier, but we really hoped to get it all on tracks asap and I wanted to bring the good news rather than the bad ones. So here they are, the judging is on.
To respond to some other topics opened in last few posts:
The turnout is certainly lower than what we all hoped. There are certainly several factors involved including quite fast and somewhat hectic planning and certainly suboptimal promotion. Quite some people got unexpectedly caught in their lifes and so on.
I'd like to start drafting the next one pretty much once this one is over (after some short pause for thinking and relaxation). I'd want it in roughly half a year and start having them more or less periodically, so people can count with them and prepare for them.
I'm more than welcome now or later to hear any ideas about how to promote the jam better (especially if you'd like to volunteer to do that, but not a condition), what do you think might bring more and any ideas for possible sponsors. We don't have much to offer at the moment, but it's a chicken and egg problem and it needs to be cut somewhere.
Overally (I'll try to write some proper postmortem once the jam is really completely over), it could have been better but still we did something. There were games submitted and subjectively not bad ones. We need to build upon what we've got and become better each time.
Eremiell out, we'll hear each other soon.
To respond to some other topics opened in last few posts:
The turnout is certainly lower than what we all hoped. There are certainly several factors involved including quite fast and somewhat hectic planning and certainly suboptimal promotion. Quite some people got unexpectedly caught in their lifes and so on.
I'd like to start drafting the next one pretty much once this one is over (after some short pause for thinking and relaxation). I'd want it in roughly half a year and start having them more or less periodically, so people can count with them and prepare for them.
I'm more than welcome now or later to hear any ideas about how to promote the jam better (especially if you'd like to volunteer to do that, but not a condition), what do you think might bring more and any ideas for possible sponsors. We don't have much to offer at the moment, but it's a chicken and egg problem and it needs to be cut somewhere.
Overally (I'll try to write some proper postmortem once the jam is really completely over), it could have been better but still we did something. There were games submitted and subjectively not bad ones. We need to build upon what we've got and become better each time.
Eremiell out, we'll hear each other soon.
7
SFML game jam / Re: 5th SFML Game Jam
« on: March 05, 2016, 03:09:25 pm »
Was just informed, that just editing the lead post won't bump this thread in people's unread, so yay, an update. The jam is now officially started and you're all invited. still more than 2 weeks to go.
9
SFML game jam / Re: 5th SFML Game Jam
« on: February 19, 2016, 11:52:50 am »
There are still some finishing touches being done on the website, which is why I haven't linked it officially, but you can already register on the site. I'll add it to the top of the thread once it's 100% ready.
10
SFML game jam / 5th SFML Game Jam
« on: February 17, 2016, 03:00:21 am »
The site's prepared! Go and register now! We're looking forward for all of you!
"Failure is an option" is the theme for this jam!
The jam has officially ended! It's final judging time!
Come join us to our jam IRC channel #sfmlgamejam @ irc.boxbox.org. Open in browser via KiwiIRC.
The Final Judging categories for this jam are:
Innovation - How innovative, unexpected and refreshing the project is.
Gameplay Mechanics - How interesting the mechanics are, how originally are they composed.
Fun - How much fun it is to play the project.
Theme - How well it captures the theme. (Please be open minded for various theme interpretations.)
Graphics - How well it looks, how original it is visually.
Audio - How well it sounds, how original it is audibly.
Mood - How much it captures you into the story and world in general, how much you feel inside the project.
Game Flow - How smoothly the project goes.
Overall - Computed from all the previous.
Terms for this SFML Game Jam are:
Rules:
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, 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 jamming phase.
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.
This post should stay up to date and may be edited later. To discuss the rules, please use the original planning thread.
"Failure is an option" is the theme for this jam!
The jam has officially ended! It's final judging time!
Come join us to our jam IRC channel #sfmlgamejam @ irc.boxbox.org. Open in browser via KiwiIRC.
The Final Judging categories for this jam are:
Innovation - How innovative, unexpected and refreshing the project is.
Gameplay Mechanics - How interesting the mechanics are, how originally are they composed.
Fun - How much fun it is to play the project.
Theme - How well it captures the theme. (Please be open minded for various theme interpretations.)
Graphics - How well it looks, how original it is visually.
Audio - How well it sounds, how original it is audibly.
Mood - How much it captures you into the story and world in general, how much you feel inside the project.
Game Flow - How smoothly the project goes.
Overall - Computed from all the previous.
Terms for this SFML Game Jam are:
| Theme Proposal | Theme Voting | Theme Announcement | Jamming | Delivery | Final Judging | Winner Announcement |
| 29. Feb - 1. Mar | 2. Mar - 3. Mar | 4. Mar | 5. Mar - 20. Mar | 21. Mar - 22. Mar | 23. Mar - 3. Apr | 4. Apr |
Rules:
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, 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 jamming phase.
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.
This post should stay up to date and may be edited later. To discuss the rules, please use the original planning thread.
11
SFML game jam / Unofficial Jam Project License Recommendations
« on: February 17, 2016, 02:47:41 am »
License Recommendations:
Those are just recommendations meant primarily for those that don't have any idea how to license the project. 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. In case of multiple license mention shortly which part is licensed by that given license, like "All code in this projects is licensed under those conditions:". 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 while the first one keeps it short and simple, 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
OGA-BY
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:
ChooseALicense
FreedomDefined
OSI
FSF
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.
This post should stay up to date and may be edited later.
Those are just recommendations meant primarily for those that don't have any idea how to license the project. 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. In case of multiple license mention shortly which part is licensed by that given license, like "All code in this projects is licensed under those conditions:". 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 while the first one keeps it short and simple, 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
OGA-BY
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:
ChooseALicense
FreedomDefined
OSI
FSF
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.
This post should stay up to date and may be edited later.
12
SFML game jam / Re: Wanna another? (early 2016 edition)
« on: February 17, 2016, 01:57:56 am »
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.
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.
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.
13
SFML game jam / Re: Wanna another? (early 2016 edition)
« on: February 16, 2016, 06:03:34 am »
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.
I'll incorporate the latest set of proposals hopefully tomorrow (Tuesday CET time) and we'll get the beast moving.
14
SFML game jam / Re: Wanna another? (early 2016 edition)
« on: February 12, 2016, 04:17:34 am »
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:
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:
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.
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.
15
SFML game jam / Re: Wanna another? (early 2016 edition)
« on: February 11, 2016, 04:58:21 pm »
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.
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.
Pages: [1] 2