SFML community forums
General => SFML game jam => Topic started by: Jebbs on August 24, 2013, 02:49:53 am
-
Allowing the usage of OpenGL was debated before the first jam took place, but since we needed a definite decision for the final set of rules I ultimately decided that we should allow it. I know this was a little confusing for some and caused a bit of controversy, so sorry for that. I want to bring attention back to this topic and decide with a vote this time.
As a refresher, some reasons for OpenGL were that since OpenGL integration is an easy thing(there is even a tutorial for it) it should be allowed, plus my own reason was that I would hate to limit the jam to just 2D.
The big reason against its usage were that it isn't a part of SFML itself and thus it defeats the purpose of the jam being dedicated to SFML.
Feel free to continue the discussion if you have other reasons for/against, or if I missed any! I'm not sure how long to leave the poll open for, so for now it is open for the foreseeable future.
-
My meaningless two cents:
The idea of rejecting OpenGL entirely because it's not really part of SFML sounds as silly to me as rejecting the use of audio because OpenAL-Soft/libsndfile aren't really part of SFML, or rejecting the use of the image formats that libjpeg/stb_image/stb_image_write support, and so on. So I'm definitely in favor of allowing it.
What would seem reasonable to me is rejecting any program that just creates a window with SFML, then does absolutely nothing else using SFML itself. In that case the game could be effortlessly "ported" to SFML's competitors and probably would behave exactly the same (right?).
Since I saw open source in the requirements already, it should be pretty obvious if someone does that, and I can't imagine anyone would want to do it anyway since it's so easy to use SFML for handling user input and loading music/fonts/images as well as creating the window, even if the actual graphics are all OpenGL.
-
The idea of rejecting OpenGL entirely because it's not really part of SFML sounds as silly to me as rejecting the use of audio because OpenAL-Soft/libsndfile aren't really part of SFML, or rejecting the use of the image formats that libjpeg/stb_image/stb_image_write support, and so on. So I'm definitely in favor of allowing it.
I don't know if that's the right way to look at it. While all of those are external libraries, they are still a part of SFML as a whole, and while the same could be said of OpenGL, drawing in an SFML window with raw OpenGL is not a part of SFML. That's where the debate comes into play.
-
Yeah, personally I don't see a meaningful difference there. Maybe that's just me.
-
Instead of continuing the old discussion, I'll just post the most important points against the use of OpenGL:
- It is called SFML Game Jam, there are tons of other game jams where OpenGL is allowed.
- We can push the library and demonstrate what is possible using SFML alone, including its Graphics module.
- By restricting to SFML, we have a clearly defined scope that matches the community. There is no confusion about OpenGL versions or extensions. Results are more comparable if the same technology is used.
- Users will learn to be creative with SFML, new techniques or best practices might emerge.
There are many libraries that provide access to OpenGL, SFML is in no way specific here. In order to push SFML, one should focus on the strenghts and the differences from other libraries. Among those is the Graphics package, which allows very efficient high-level and low-level access to graphics. It's probably the most often used module, and with its clean API it is the SFML flagship; not using it would be a missed opportunity.
-
Just my 2 cents on the topic. I believe that if any kind of 3rd party unofficial code is used in the jam, OpenGL should be allowed to.
I mean, if no engines or libraries made by the user are allowed, the OpenGL should be constrained too. If the purpose of the jam is to exploit SFML capabilities to its fullest while getting creative, then using only the SFML API's is the only thing that makes sense. If you are allowed to expand on SFML with libraries and tools, it also makes sense to use OpenGL, even if as a means to achieve more kinds of drawables, a perfectly valid extension to what SFML already provides.
-
I think it's different whether you expand SFML on a higher level (using Wiki codes or libraries like Thor) or on a lower level (using OpenGL), because the former are still purely based on SFML technology -- they provide only an abstraction layer that the user could as well build himself.
But this is another point that should be discussed; the rule "You only have 72 hours to create [...] the code [...] of your project" is not clear here. Forbidding higher-level libraries is not really a solution, since users can still copy their implementations and modify them slightly. Furthermore, it encourages reinventing the wheel, instead of focusing on unique art, style and gameplay.
-
Instead of discussing about OpenGL directly, one might want to think about, what makes this jam The SFML Game Jam?
If we just say "you have to somehow use SFML", it would be enough to link against SFML System and somewhere use a sf::Vector2<T>, but is that really what we want the SFML Game Jam to be about? Don't we want to make people use the full power that comes with SFML?
With that said, it's kind of use less to let people use OpenGL in any way they want. Because it would be perfectly fine to link against the System and Window module, to create a window and handle some events, but leaving all the graphics to OpenGL, thus defeating the purpose of utilizing SFML to its full extend.
Given that OpenGL is some important addition to the rest of SFML I understand the argument of allowing OpenGL, but as listed my argument above, the usage must be restricted and defined (i.e. switching out sf::Window and sf::RenderWindow still doesn't make you "use" SFML's graphics module). Either that or disallow it completely.
I don't agree that if OpenGL should not be allowed all the other libraries shouldn't either. There's just a difference between having to write a JSON/XML parser and using SFML to draw a rectangle or OpenGL to draw a rectangle. For a parser you'll need a lot of time to implement it and are essentially just reinventing the wheel again, where as with the rectangle you'd explicitly opt for something SFML already provides functionality for. So maybe the use of libraries that replace SFML's functions should be disallowed.
This of course then puts libraries like Thor and SFGUI in question. For Thor I don't see any problems, because Thor builds directly on top of SFML's function (afaik), so you'd still be indirectly using SFML.
For SFGUI the question is a bit harder. They are also using parts of SFML, but also utilize OpenGL. Personally I'd allow to use of it, because SFGUI currently can't function without SFML and the functionality of creating a GUI is not included in SFML, so you won't be replacing anything from SFML.
So my conclusion would be:
- OpenGL can only be used as addition to SFML's rendering.
- Everything that can be done with SFML, should be done with SFML - no replacement libraries.
-
Me too I agree with using OpenGL but should pe a category of pointing in the SFML Jam wich will point how much you used SFML.
-
I think the problem can be reduced (http://en.wikipedia.org/wiki/Reduction_%28complexity%29) to the problem of determining what the purpose of the SFML Game Jam is. If it is as some say to showcase the capabilities of SFML, then I would not allow OpenGL usage, since this would allow detours (shorter or longer) around SFML's graphics API. If part of the "capability" of SFML is it's interaction with OpenGL then this becomes a harder problem. In that case I wouldn't mind seeing people use OpenGL alongside SFML to get things done, as long as whatever can be done in SFML is done in SFML (no glBegin(GL_QUADS) etc.). This means that the fact that you are allowed to use OpenGL is there to not limit you in your creative freedom, nothing more, nothing less. The last thing we want is people lamenting how they were "limited" to using SFML only for their graphics, which might even detract people from even taking part.
A good analogy would be an artist's paintbrush. SFML takes the basic paintbrush and makes it much easier for children to use, while at the same time limiting it's usability to use cases that cover 99% of all children. If you were to make a commercial promoting this paintbrush, you wouldn't expect to see a famous artist using it to paint their masterpiece would you? That would not promote what it was meant for, and to be honest, the artist also wouldn't be crazy enough to limit themselves to something like that ;). On the other hand, if you watch an artist paint a masterpiece and notice this paintbrush in their collection as well, it also promotes the paintbrush albeit in a completely different way.
SFML is a multimedia library, you can promote its usage in many other ways than just its graphics API. If you ask me, using SFML for window, event and context management is enough to label something as an "SFML application". It is probably the only thing you can compare SFML to its competitors by anyway.
And on a side note: showcasing SFML's integration with OpenGL 4.3 features is more challenging than many people think, even more so than getting things done using pure SFML. Whoever can get an SFML application done that doesn't use deprecated functions and a lot of 4.3 functions within 72 hours will receive my utmost respect ;). Oh, and the tech demo might also open SFML up to a more "serious" audience... just saying...
-
Yes.
No one is probably going to use it anyway and you are having analysis paralysis over it. :P
GLUT and GLFW(and most libs) are competitors of SFML in the area of input, context and windowing, not 2D(like SDL).
Also GL is not 'other library', SFML needs it, you can't run SFML without it, just nope, and it's not made into implementation detail, it's exposed for you. Something like DirectX should be (obviously ;) ) not allowed, even though it has D3D since this is jam for cross platform GL based library and DX has nothing to do with it. Also things like IrrKlang, Irrlicht, Ogre, Horde, etc. should not be allowed because they replace part or all of SFML functionality, but have nothing to do with it. Thor, TGUI, SFGUI, CEGUI etc. should be allowed, even if they use GL, because you are not 'rendering' something, they are not 'renderers', they get you something very very specific rendered to a context, you can't build a game on that kind of graphics(unlike building a game on Irrlicht, which can render arbitrary things). Something like 'personal codebase 3D renderer' might in theory come up(probably won't) and that probably shouldn't be allowed because someone like Nikolaus Gebhardt could come here and mop the floor with us all using entire 'personal, written by him' Irrlicht with custom irr::IrrlichtDevice that uses sf::Window for window, context and events. :-X
So: OpenGL - during jam - yes, in the codebase for use with jam - no(maybe, if you're paranoid.. that or some looser rule that you can't bring in entire custom renderers in).
Also:
If someone replicates 2D API they just screwed themselves majorly on time unless they are extremely good programmer.
If someone goes 3D they just screwed themselves on time or are very good artist/designer and programmer and will pull through with high quality or stylized assets and alright game(play).
So OpenGL goes one of two ways in both 2D and 3D:
- total suicide timewise, might as well give up on submitting
- super skilled competitor, good PR for SFML that they even used it
glBegin(GL_QUADS)
90s called and they wanted their immediate mode API back. :P
-
Yes
It should be allowed, but within limits as stated above. Everything that can be done with SFML should be done with SFML and OpenGL specific code not covered by SFML should be allowed. Also in 3D games SFML should be used to draw something other than being just the window manager.
Anyone reading this scroll to page 2 for my latest thoughts
-
Well, I don't think we'll be getting much more feedback on the subject. It looks like it was pretty close though. Based on the voting and what some of the people have said I am proposing the following changes to the rules.
Rule 5 get's changed to: "External libraries are allowed, but not SFML's competitors, such as GLFW, SDL, Allegro, etc."
And we add a new rule after it stating: "Everything graphical that SFML is capable of must use SFML. OpenGL is only allowed for things that are outside the capabilities of SFML's graphics package."
Exact wording is subject to change.
-
"Everything graphical that SFML is capable of must use SFML. OpenGL is only allowed for things that are outside the capabilities of SFML's graphics package."
= Goodbye SFGUI cus of GL renderer? :P
-
Honestly, I think people are making this into a bigger deal than it is. It's a Game Jam for making games and having fun, and it's the SFML Game Jam. People who join are, on whole, gonna be using SFML. To make games. In a jam.
Really, if you have to do something maintain a "spirit of the jam" clause and reserve the right to penalise games that are felt to have broken that spirit.
-
Rule 5 get's changed to: "External libraries are allowed, but not SFML's competitors, such as GLFW, SDL, Allegro, etc."
And we add a new rule after it stating: "Everything graphical that SFML is capable of must use SFML. OpenGL is only allowed for things that are outside the capabilities of SFML's graphics package."
I agree with this change. I think the wording should be something like "All drawing that SFML is capable of must be drawn with SFML, all other unsupported drawing can use OpenGL." Word it however you want ;)
-
"Everything graphical that SFML is capable of must use SFML. OpenGL is only allowed for things that are outside the capabilities of SFML's graphics package."
= Goodbye SFGUI cus of GL renderer? :P
Where does SFGUI use GL? I've never used it so I don't know it that well.
Honestly, I think people are making this into a bigger deal than it is. It's a Game Jam for making games and having fun, and it's the SFML Game Jam. People who join are, on whole, gonna be using SFML. To make games. In a jam.
Really, if you have to do something maintain a "spirit of the jam" clause and reserve the right to penalise games that are felt to have broken that spirit.
Maybe, but having rules and structure is important too.
Rule 5 get's changed to: "External libraries are allowed, but not SFML's competitors, such as GLFW, SDL, Allegro, etc."
And we add a new rule after it stating: "Everything graphical that SFML is capable of must use SFML. OpenGL is only allowed for things that are outside the capabilities of SFML's graphics package."
I agree with this change. I think the wording should be something like "All drawing that SFML is capable of must be drawn with SFML, all other unsupported drawing can use OpenGL." Word it however you want ;)
Yeah, not really sure how to word it exactly. I just got back from a work trip so I haven't had a lot of time to think about it until now, but I'm open to other suggestions too.
-
Where does SFGUI use GL? I've never used it so I don't know it that well.
Everywhere.
-
Where does SFGUI use GL? I've never used it so I don't know it that well.
Everywhere.
... where it is needed, to keep framerates decent after experiencing 30FPS in our test app after the SFML graphics API rewrite.
-
Doesn't matter, there is no exception to this rule for stuff that SFML can do, the
majority minority of voters(as shown above) decided to not allow OpenGL. :P
-
Where does SFGUI use GL? I've never used it so I don't know it that well.
Everywhere.
... where it is needed, to keep framerates decent after experiencing 30FPS in our test app after the SFML graphics API rewrite.
I'm not sure if anyone used SFGUI in any of the, but I know that having a GUI system they could use might make some things easier. Should performance reasons be an allowed reason to use OpenGL?
I like the suggestion I made about the rule changes, but I don't want to go ahead and make a change unless I know everyone is happy with it. :P
-
Let's put it this way... if not using OpenGL causes the player to suffer because of the game running at 2 FPS then... there is no other way to get it done. Maybe the author envisioned something that was a bit too "big" for SFML, but that shouldn't prevent them from creating something awesome during the jam... As already stated, using OpenGL is a risk. You stick more time into your graphics, but it will run as fast as it needs to to be enjoyable, if you manage to finish on time...
-
Yeah, I agree. Obviously the focus of this jam should be SFML, but I think the priority is still to make great games.
Let's try this instead.
Just like before, rule 5 get's changed to: "External libraries are allowed, but not SFML's competitors, such as GLFW, SDL, Allegro, etc."
And the new rule becomes: "Everything graphical that SFML is capable of must use SFML. OpenGL is allowed for more complicated graphics, such as 3D, and for performance reasons."
I'm still not quite satisfied with the wording, but I like it better. Also, I think we can let "performance reasons" be left up to the participants. Like you said, using OpenGL is a gamble. They can decide if it makes sense to use it to get that performance boost or not.
-
I'm going to try to think about the wording a little more before anything actually happens, but if no-one has any objections to this change then it'll be something that I'll update in the rules.
-
Jebbs,
We were discussing the entire OpenGL rule (yea this came up again over on IRC)... Anyways I think I came up with a good solution to this entire OpenGL issue. As we all can see from the poll it is almost split 50/50 in the community about allowing OpenGL.
Now having this conversation on IRC it seems like disallowing OpenGL is a turn off for lots of people, but yet allowing it can also (depending on how it is used) can take away from entire idea of an "SFML game jam". What I think should happen is the rules be opened up and allow OpenGL as long as SFML is used in some way (albeit even if it is just used as a window manager). After all SFML is not solely focused on graphics...
Since the rules have been opened to include everyone the last thing would be to require the person to simply state, "I/We have used pure SFML rendering" OR "I/We have used SFML and some/all raw OpenGL for rendering" on the game entry. (or maybe have a small flag in that fancy new site ;))
Another option would be to simply require at least two components of SFML to be used. Such as window management and audio, window management and networking, and so on. This would allow any combination of SFML and/or OpenGL while making sure it is still in the spirit of using SFML. ;D
After more thought, I believe simply requiring at least two components of SFML is the way to go, this will eliminate any complicated questions regarding use of raw OpenGL while still allowing great libraries that utilize OpenGL to be used.
-
Since the rules have been opened to include everyone the last thing would be to require the person to simply state, "I/We have used pure SFML rendering" OR "I/We have used SFML and some/all raw OpenGL for rendering" on the game entry. (or maybe have a small flag in that fancy new site ;))
Another option would be to simply require at least two components of SFML to be used. Such as window management and audio, window management and networking, and so on. This would allow any combination of SFML and/or OpenGL while making sure it is still in the spirit of using SFML. ;D
I am for either or both suggested rules. This would keep the game jam loosely structured and fun (participants won't have so much concern with breaking the rules) and it would continue to showcase SFML great features of SFML. I might change the wording of the second suggestion in some way to reflect that participants must use two APIs from SFML, and not just two classes from the same header.
-
I am undecided as to whether or not allowing OpenGL is a good idea.
However, zsbzsb's most recent suggestion of "totally removing anything about opengl from the rules and simply requiring 2 components of sfml" does sound like the way to go if OpenGL is to be allowed.
-
However, zsbzsb's most recent suggestion of "totally removing anything about opengl from the rules and simply requiring 2 components of sfml" does sound like the way to go if OpenGL is to be allowed.
You can't enforce the use of SFML by rules like that, it's easy to use tiny parts.
I still think the SFML Game Jam would be the opportunity to show to the world how much one can achieve with SFML within a very short time. It demonstrates that even without OpenGL knowledge, it's possible to develop nice games. This is the whole point behind the SFML Graphics module: Abstracting low-level operations and OpenGL while still remaining very flexible.
Since OpenGL was allowed last time, why don't we make a test run without OpenGL this time? Then we have two scenarios to compare and to take our lessons from.
-
Here is my thinking:
There are no prizes, people would join the jam just for fun. So why the restrictions? I would go with an honor system. There is nothing to win, so there is no reason to be so strict on the rules. Just have a nice get-together where people use SFML because it is good, not because of some rules. We should say "the game should use SFML" of course, and leave the usage thereof to the scrutiny of the community. Let the community rate it down if it doesn't use SFML to their liking.
Some of you said that those using OpenGL would "mop the floor" with the others. I don't understand this. If they are so good with OpenGL, you can bet that they will be good with SFML too. Also, if they are good, then they deserve to get more points! Knowledge should be rewarded! It IS a competition, right?
-
So why the restrictions?
See here (http://en.sfml-dev.org/forums/index.php?topic=12740.msg89085#msg89085) and here (http://en.sfml-dev.org/forums/index.php?topic=12740.msg89102#msg89102).
-
So why the restrictions?
Because it's fun making pointless rules that are not needed in the first place and don't change the outcome.
I said same thing for the most part with exception that(to satisfy paranoid people who fear GL will take over just because it can) it should be rather not OK to bring too much GL code into competition because someone can bring entire own engine and then it really isn't about SFML anymore but that is extremely unlikely someone with skills like that would care about this competition to the point where they want to win in such dirty way.
http://en.sfml-dev.org/forums/index.php?topic=12740.msg89167#msg89167
You're getting into politics at this point, that's why I don't even post here except above long post and jabs at SFG using GL thus being possibly rule breaking, there's no point in 'discussion' like that, just let someone authoritative make a decision, any decision.
-
Can't we rely on people's common sense and ditch all those technology rules?
I think it would be ideal to force every submission to be open source, so in case anyone thinks that game is "cheating", that person would just look through the source code and the community would consider disqualifying that submission if appropriate.
Other than that, I don't see any benefit in imposing rules about not being able to use low-level API's such as OpenGL. Following that thought, why allow STL? Why not force everyone to write their own container classes in those 48 hours? As long as no one drops a massive engine on top of SFML, its pretty fair to use some extensions to aid in getting a better game, faster. We have nothing to lose if we get better games than we would by imposing these restrictions.
Things like the SFML user interface extensions are a great thing in order to allow people to make a nice game in 48 hours. What these extensions usually do aren't trivial things we can just replicate in 48 hours. Just let people do their best game without imposing such hard barriers, allowing them to focus on the creative side rather than technical details. Just my opinion!
-
Although I haven't chimed in until now, I have been reading the new posts. It really is a tricky thing since I feel like both sides have good arguments. I feel like a bit of a flip-flopper that can't make up his damn mind, but right now I am kind of agreeing with Nexus and his suggestion.
I still think the SFML Game Jam would be the opportunity to show to the world how much one can achieve with SFML within a very short time. It demonstrates that even without OpenGL knowledge, it's possible to develop nice games. This is the whole point behind the SFML Graphics module: Abstracting low-level operations and OpenGL while still remaining very flexible.
Since OpenGL was allowed last time, why don't we make a test run without OpenGL this time? Then we have two scenarios to compare and to take our lessons from.
The reason I am coming around to this is because, well, it is called the SFML Game Jam after all! We really should be using as much SFML as we can.
Like I have said in the past, I don't really like the idea not allowing OpenGL only because I think it would be silly to not let someone make a 3D game if they wanted to. That said, if we change it to only being able to use SFML(At the core. Frameworks/libraries built on top of sfml are still ok), then everyone is on the same level and has to use the same set of tools to make their game.
Can't we rely on people's common sense and ditch all those technology rules?
Maybe we should!
Kind of an interesting idea, really. An honor-system jam?
-
I guess the question to ask is:
Is this jam about game development or about showcasing SFML?
For the first answer, limiting technology is silly and it will only limit people's creativity and SFML will be used anyway!
For the later, if this is about showing the world what SFML can do, which I don't feel like it is, since the jam games are not highly featured by SFML website itself, the technology barriers make all the sense.
You guys decide :)
-
So last year I was of the opinion that if someone wanted to use OpenGL, it would be silly to tell them they can't participate because of it.
This year, my opinion has evolved somewhat. Let's be honest: there are a lot of game jams, just go look at Compohub (http://"http://compohub.net/"). The SFML game jam is never going to be as big as events like Ludum Dare and the Global Game Jam. As Grimshaw said, there are basically two reasons to even run the jam at all:
- To have a small jam among community members for fun and an excuse to work with each other and see the fruits of everyone's labor at the end.
- To demonstrate the variety and quality of games made under tight time constraints with SFML to the game development community, and to provide good examples of interesting SFML uses or best practices.
The last jam very clearly fell under the first scenario. There was no publicity, and the whole thing was contained to a couple threads on the forum. Restricting the use of OpenGL in this setting doesn't do a lot of good.
If we were operating under the second set of assumptions, at the very least entries should be clearly marked as to whether or not they use SFML for rendering. I would argue that if we're really trying to showcase SFML, then there need to be some changes:
- Featured Games: Several (1-3?) of the entries should be "featured" by the SFML community and website. What do I mean by featured? Well, I'm really trying to avoid using the concept of "winners", but these games should essentially be the "best" entries. How is best defined? Well, if we're going to show these entries off on the front page, or bring some other form of prominent attention to them, they should be good examples of what can be done with, or how best to use SFML. That sort of leads me to a few other ideas...
- SFML Requirement: In order to be considered as a game to be featured, the entry must use SFML for rendering. Not to say that games using OpenGL don't belong in the jam, they just wont be eligible to be chosen as featured entries.
- Open Source Requirement: In addition to using SFML for rendering, games that want a chance at being featured must be open source so that others have good examples of how to use SFML, or how that awesome visual trick was done in just a few simple lines, or whatever.
So, really, it's a question of who we're doing this for. Ourselves (the SFML community), or others (those who don't know about or haven't used SFML). Personally, I would prefer to see the jam focused on showing off SFML to others since there are a bunch of other general game jams to participate in.
tl;dr:
What Grimshaw said.
-
On a side note, do we have a theme or a pool of themes already? I'm not sure if I ll be able to participate, but I'd like to :D
-
On a side note, do we have a theme or a pool of themes already? I'm not sure if I ll be able to participate, but I'd like to :D
The website only needs a few more things before it has all the functionality I want it to have, but once I have the poll stuff finished I'll get the ball rolling on picking a theme. I just got a little overwhelmed due to homework during the last few days, but it should be ready before the weekend.