This was kind of a weird entry, and the next one will be as well... I timed the demo out to 6 days as usual, but had to break it up over two weeks--let's just say I've been working on 2 AAA games simultaneously and one of them is shipping SOON™.
This may have hurt the demo a bit, but I don't think extra time would change my conclusions here.
SFML is a framework in a very awkward position, in that it seems to advertise itself both as one of those lower-level 'OpenGL/Vulkan access' libraries and also a higher-level 2D multimedia library. Since the goal of this little experiment is not to reinvent the wheel, I can't speak to the former use-case... but I'm not really impressed with the latter.
One common issue, perhaps the main issue I have with SFML, is the problem of trying too hard with its features and making the API worse in the process. Consider these examples:
For each 'instance' of a texture you want to draw to a window, you need to make a corresponding sf::Sprite object. You have to set transforms on the sprite, draw it yourself, manage the lifetimes of both objects, etc. It offers no gameplay functionality like the Sprite class in HaxeFlixel, so you can't use it to replace your objects.
The result is that any game object needs to copy its transforms over to this extra object on a regular basis, and you now have two objects to manage instead of one. Moreover, there's no simple 'just draw the damn texture' function. You can imagine a world where the sprite class never existed, and in that world it would be easier to draw textures onscreen...
SFML offers vector classes that you must use to represent positions. That's pretty standard... but what it doesn't offer is any of the corresponding vector math. There's no dot product, no cross product, and not even the humble length function. These vector math operations are the bread and butter of gameplay programming, but SFML expects you to provide them yourself. You now have a choice: write your own helper functions (which can't extend the API nicely, this ain't C#), or adopt a math library and convert types every time you make an SFML call.
Curiously, this situation is described in a very deliberate and matter-of-fact fashion in the docs. This proves that it wasn't an oversight, and it's almost as if the devs consider this missing critically-important functionality to be a positive.
In both instances the SFML devs thought of a useful feature, created the feature, but stopped short of the part that makes it useful. The result is baggage that the programmer must carry, but benefits little from.
Funny enough, this segues nicely into the next pain-point: C++ itself. I mostly swore off of C++ back in college, and have only used it in brief spurts since. I've grown a lot as a person since then, and I was interested to see how the language felt now... but no, it still sucks. Somehow, young and foolish me was completely right.
It has nothing to do with being lower-level, I've used C in two separate entries so far and been happy as a clam. It's not really about being higher-level either, I've used C#, Lua, and Haxe in this experiment as well. But something about C++ makes every new feature feel like an overdesigned mess that, get this, looks like the start of a useful feature but stops short of being useful. It makes me wonder how much of C++'s dominance in large-scale gamedev comes from inertia.
Well, I think that's enough ranting for one day. I'm tired, and the less time I spend thinking about this C++ and SFML tag-team the better.
Oh, and uh... the API docs are ok but they could really use a search bar.
No comments:
Post a Comment