Game Submissions now open

[Nexus]

Please calm down, both of you.

I agree that it's not ideal that therocode has not submitted the binaries, but at least he participated and submitted, unlike everyone else. That should not be forgotten. Even if I too think that not everybody should be expected to build the game himself. So let that be it please, and stop this useless discussion.

therocode, it would be nice if you revised your opinion of both providing the web version and participating in the next jam. I would really like to see your game as well as future contributions, and I'm sure I'm not the only one. This 3rd game jam has been very unfortunate regarding literally everything, but let's use the opportunity to do everything better next time. We must find a way to make the jam more attractive and accessible for both developers and users.

[Nexus]

In order to do better next time, what do you think of the suggestion I proposed before? Some concrete points:

• Only dependencies that are portable and available on all platforms may be used.
• The developer is responsible of providing binary versions for at least one platform. Ideally, he ships the needed dependencies so that a user has the least possible configuration effort.
• Source code must be uploaded at the fixed deadline, but binary versions can be built some time afterwards. This allows the developer to concentrate on the game rather than packaging, and makes sure there is enough motivation to provide a working and easily installable binary.
• Other people are welcome to compile the source code for different platforms.

[eXpl0it3r]

• Source code must be uploaded at the fixed deadline, but binary versions can be built some time afterwards. This allows the developer to concentrate on the game rather than packaging, and makes sure there is enough motivation to provide a working and easily installable binary.

IMHO creating a deployable package is also part of the process of creating a game, as such one binary has to be provided within the deadline.

[therocode]

Please calm down, both of you.

I agree that it's not ideal that therocode has not submitted the binaries, but at least he participated and submitted, unlike everyone else. That should not be forgotten. Even if I too think that not everybody should be expected to build the game himself. So let that be it please, and stop this useless discussion.

therocode, it would be nice if you revised your opinion of both providing the web version and participating in the next jam. I would really like to see your game as well as future contributions, and I'm sure I'm not the only one. This 3rd game jam has been very unfortunate regarding literally everything, but let's use the opportunity to do everything better next time. We must find a way to make the jam more attractive and accessible for both developers and users.

Thank you, I  couldn't have said it better myself.

In my opinion, for things like this it is good to keep discussions sane and reasonable. I admit that I got quite upset and emotional by exploiter's posts but I just don't like when people accuse me for unfair things, and call me "elitistic" and say that I "demand things to change" when I am just trying to come with calm constructive criticism and just explain why things turned out the way they did.

I agree that it is a shame to not provide the web links for everyone just becuase what one person said got to me. I can probably reconsider that, sorry about that. As for participating in the future, we'll see. I really don't like how this discussion turned out and if risk being up for that in the future, I'd rather stay away.

Of course, if others also agree that it warrants being angry at us for not providing the binary, of that I came across as being elitistic for not providing them, and that I was making lame excuses for being lazy, then I apologise because that was definitely not my intention. But I really don't think what I said was like that.

Also I think it is not right to get angry at participants in either case. Even if it is against the rules. One can calmly explain to them why, and then if the issue persists, just disqualify the game, no big deal.

An apology from you, eXpl0it3r would be nice too.

[Tank]

I think the "at least one binary package for one platform" rule is not ideal, as well. If someone uploads a Linux and/or Mac OSX binary package, then a very high percentage of users are still not able to test it without building it.

The suggestion to automatically build all entries for all platforms sounds good though. That requires to limit the dependencies however, as Nexus suggested.

[eXpl0it3r]

I could now write a page or so about how your writing and actions went into what I wrote and what mistakes I made alongside, but since it has already been decided that I'm the bitching and angry dude that gets everything wrong, it's useless to do so.

Sorry if my interpretation of your actions and writing offended your view of things.

To not further change the course of this topic, it would be best to use PMs, if anything else needs to be said.

[therocode]

I am not sure about if anything was decided or not, I merely wrote what I thought about things and how things came across to me.

But thanks for the apology and I apologise as well for any offending things I might have said (like calling you a bitch).

I also hope that this discussion can now take a more constructive turn, and that no one need to feel offended, unfairly judged or anything like that. I am not one to hold a grudge.

As for on-topic stuff, what do people think of the old idea to have the next jam be longer? Like, about a week or so?

IMO that is likely to yield more participants since there were quite a few this time that had planned to join but didn't end up having time. It would also give more time to deal with binaries and stuff like that. If not for anything else, it could be an interesting experiment.

[MorleyDev]

If this was primarily a Java or C# jam, then expecting people to be able to build themselves may be less problematic. There are well-defined tools and processes that can do all the dependency management for you and any build tasks for those languages. Maven, Visual Studio + NuGet are common and easy to use.

But SFML is primarily a C++ library, used by C++ developers. Most games for the jam will most likely be written in C++, and C++ is a difficult language to build things for simply because building is more complicated. CMake, Configure/Make, Scons, Visual Studio, Custom scripts, Makefiles. There are a lot of different ways to build things and a lot of tools for a lot of compilers. Building can be a painful process. Providing a binary package seems like a courtesy if nothing else.

Now, as for platforms...well, that's interesting. Forcing people to build for all platforms seems wrong. But at the end of the day, if you don't provide a binary for a platform then the users of your platform won't be able to play your game which means less exposure and less votes and less publicity. Seems to defeat the point of submitting anything in the first place.

But the target platform maybe should still be the decision of the developer, just with that knowledge that less platforms = less players = less eyes = less opinions to act as a counterweight.

Week long things aren't jams. I've said it before and I still believe it. Jams are short, once you start reaching the 1 week - 2 week range it becomes too long to call a jam and instead just "another project".

I didn't partake of this jam because I had an exam on the Monday that got higher priority. Making it one week long would have made me partaking less likely.

[therocode]

Good points about how C++ is hard to build for. That's why this is indeed a problem in the first place.

And I agree that providing a binary is courteous.

Imo forcing that the developer provides a binary for all 3 platforms is imo not reasonable. Very few developers have access to all three of them, and even less know how to build for them.

Forcing at least one binary has the problem that those devs that are on Linux/Mac will still have games unplayable by the majority of people.

Forcing no binaries at all, has the issue of as you said, dependency handling and all that.

None of those solutions are optimal, so maybe it is indeed a better approach to put constraints on dependencies. Making it more into a vanilla SFML game jam. Then many of the issues would be alleviated. But of course, it still doesn't answer concretely what binaries (if any!) should be enforced.

[kimspindel]

Hello!

I'm Kim, I worked on Chromoshift with therocode for the game jam and I'm quite pleased with the result of our game

Here: http://kim.pallkars.net/sfml-gamejam-2014/chromoshift.7z is a link to a working Linux binary (you need to have both SFML 2.1 and Feather Kit installed). It should've been properly included with our download link but we ran out of time, but late is better than never I guess!
Unfortunately I've never developed on Windows so I can't provide a Windows binary; if anyone feels like compiling one for us then feel free to do so.

Otherwise you can play our web port here! http://kim.pallkars.net/sfml-gamejam-2014/ (no music though) music has been fix'd!

The rules are:

• You are the square in the middle of the screen, trying to become a specified colour (as shown on the edges of the "colourmeter")
• You can pick up either additive or subtractive colour blocks in order to change your own colour, to try and reach the desired colour.
• It skips to the next level when you reach the desired colour (didn't have time to implement anything cool for winning)
• You lose if you get too much of one colour channel (R, G or B) or too little of one colour channel.

I would like to add a tutorial to make these rules much clearer, and also perhaps some interface that helps the player work out how much RGB they will gain/lose from picking up a pickup (I found that I was mostly guessing, so it was a bit boring/difficult). Adding other elements like traps, enemies etc. could potentially be fun, too

[Nexus]

Maybe we could limit the dependencies to SFML and the popular extension libraries (SFGUI, FeatherKit, Let There Be Light, Thor, ...)? That would also allow a build-bot.

Other people who have their own specific engine can still use it, but they would directly include it in source code rather than link to it.

Kim, thanks for providing the game!

[therocode]

(also, we haven't made many levels yet D: )

[Jesper Juhl]

Some suggestions/discussion points:

Since these are supposed to be SFML jams, why not limit the allowed dependencies to SFML + the C++ standard library + STL (and equivalent for bindings). Maybe one or two other libs that are commonly used and available on all platforms/bindings - but no more.
This would make it far easier to provide binaries (or for people to build themselves) and would emphasize that this is about what you can do with SFML and not arbitrary other libraries.
It would also make it fairly simple to provide pre-made cmake, scons etc recipies for people to use as starting points if they are not familiar with how to create such for building across platforms.

[kimspindel]

Some suggestions/discussion points:

Since these are supposed to be SFML jams, why not limit the allowed dependencies to SFML + the C++ standard library + STL (and equivalent for bindings). Maybe one or two other libs that are commonly used and available on all platforms/bindings - but no more.
This would make it far easier to provide binaries (or for people to build themselves) and would emphasize that this is about what you can do with SFML and not arbitrary other libraries.
It would also make it fairly simple to provide pre-made cmake, scons etc recipies for people to use as starting points if they are not familiar with how to create such for building across platforms.

Even though this would make it take longer to write games, I would be fine with this if just for the sake of simplicity It would be cool with a few projects that are just pure SFML!

[therocode]

I'd also be fine with that, but in that case I'd not even have a "maybe" for other libraries since that would be very ambiguous in terms of which ones that should be allowed or not. IMO anyway.