5 ms·

Maybe a good place to ask, does anyone have any recommendations for game dev frameworks? Preferably something performant, stable and not too much of a pain to w

Maybe a good place to ask, does anyone have any recommendations for game dev frameworks? Preferably something performant, stable and not too much of a pain to work with. Been using Godot for a year or two and loving it, but I do want to try out the code only workflow, I feel like it'd suit me better being freed of the constraints of an engine, but I'd at very least like to try so I can be sure. I tried Bevy before and it was fantastic, but its just not production ready. Also tried Raylib, the main problem with that being the sheer number of bindings somewhat segments the community and makes it harder to figure out how to start off with, but it might be worth another go. Might also consider going without a framework and just finding libraries to fill in what I need, but that might not play nice with "not too much of a pain to work with"

krapp 4y ago
May be more lower level than what you're looking for but my current drug of choice when I want to write all the code is SDL2 and LuaJIT in Visual Studio.
- bodge5000 4y ago
  SDL2 I've been heavily tempted by, but it has a similar problem as Raylib where everyones writing it in a different language. Great when you know what your doing, but a bit more difficult to get up and started with. But maybe it is worth that extra time investment just for how popular and battle-tested it is
pizza234 4y ago
In Rust, there is none; they're just not ready, and not used either (there are very few full games written in Rust). The Bevy maintainers in particular give very low priority to foundational functionalities (see 1 frame lag and the unusable stages+states), and focus on advanced ones instead. There aren't so many alternatives actually (SDL is a very valid framework, but it isn't a game engine), and the choice depends on what's your real goal (experiment or develop a real game). In my opinion, if the goal is to produce a real game, for somebody who doesn't have significant experience, documentation (including: availability of books) is the top priority.
- bodge5000 4y ago
  Doesn't have to be Rust, pretty much any language (though I'd rather not Java just for personal preference). I'd say my goal is to produce a real game, its really just to experiment, but the experiment is to see if it should replace Godot for me
garrypettet 4y ago
I’ve just started out with Flame and Flutter. As a newcomer to game development (but experienced in other genres of coding) I’ve found it great.
brennopost 4y ago
I enjoy love2d for small 2d games.
Barrera 4y ago
What's not production ready about Bevy?
- norman784 4y ago
  Not stable release yet, so each release might bring a lot of breaking changes, when they release 1.0 the API at least will be more stable.
- pizza234 4y ago
  Two main problems: 1. state/stages can't be used together; since plugins may use states (and even baisc funcionality, like the fixed frame step), you can't use stages 2. in order to flush commands, you need stages, but you can't use them due to 1. The result is that with Bevy itself, writes (commands) become effective only at the end of each frame. There is a plugin written by a 3rd party, but the Bevy developers are treating this as very low priority (it's been open for a very long time, and it's not even scheduled for the next release). Paradoxically, it matters little because there's a lot of hype about Bevy, but there are little (or none) significant projects - only very small ones or demos, which don't require efficiency or precise timing. Additionally: the Bevy team doesn't write documentation at all. The "cheat book" is written by a 3rd party, with the consequence that it's partial, superficial, and it may be halted at any time (note that I don't fault the book maintainer(s); their contribution is crucial!). This isn't great when one approaches the engine for the first time; it actually sucks because engines like Bevy are (relatively) large beasts.
  - pcwalton 4y ago
    Note that https://github.com/bevyengine/rfcs/pull/45 https://github.com/bevyengine/rfcs/pull/45 is actually fairly active; it doesn't look like "very low priority" to me.
  - alice-i-cecile 4y ago
    Hi! I'm one of the four formal maintainers of Bevy. I'm not particularly interested in convincing you personally, but I think it's important to publicly address some misunderstandings. The scheduling rework that you're complaining about is extremely high priority, and I have personally invested hundreds of hours into redesigning and refactoring this mess (which is now in its third serious iteration). It's a challenging problem, and the volunteer who has taken responsibility for the rewrite has needed to step back for a while as they transition to a new job. I have also personally invested hundreds of hours writing, editing and reviewing docs for Bevy. That's what got me involved in the first place, and the team has done a great job. A fully revised book is also in the works, but getting the subtle details right are critical. As for serious projects: I've spoken with about a half-dozen commercial teams, including one with a team size of about 10 and a lifespan of nearly two years. Their feedback is remarkably positive given the immaturity of Bevy and the supporting ecosystem. While there are missing features that they want (hi bevy_ui), and annoying papercuts (yep, those scheduling concerns sure are annoying), they've over all been wildly impressed been how easy to maintain, reliable and performant Bevy has been for them.
jasonjmcghee 4y ago
You can do Godot with a code only workflow. The UI is just an abstraction over setting variables and writing configuration files. You’ll likely want to use a language with good IDE support though, like C# (Mono). The Scene files can also be written by hand. But the Tool class (which you use to leverage the GUI) is so useful in Godot. You’re probably going to use egui or imgui to build a replacement yourself in any other engine anyway. The instant feedback of changing key variables and seeing their effect is too useful not to leverage.
- bodge5000 4y ago
  Really good idea actually, I could test out the workflow of a framework whilst working with something I know. I remember I briefly looked this up in the past and there wasn't much on it, but maybe I should take another look. As for the tool class, I don't use that much in regular godot to be honest. It always felt a little like variable exports, a bit of a hack for users coming over from Unity to feel more at home but not "standard practice". Not sure why it feels like that to me, but I do alright without it.
  - jasonjmcghee 4y ago
    Oh man, it’s so much more. You can put any code behind Engine.EditorHint condition and it only runs inside the editor. You can make shortcut keys to do things or execute code in _Process. For example, i’ve made a script where editing one tilemap updated another, the first being a palette for wave function collapse, generating the other. When i implemented vector fields, i first had it track the mouse instead of the player and did it all in the editor (not hitting play)
    - bodge5000 4y ago
      Quick question, if I were to try the code only workflow, how would I actually run the game? Is there a cli godot has or something, or would I need to go back to the editor itself to click play?
      - 4y ago
lc9er 4y ago
There’s Monogame, if you know C#. It’s got a decent sized community and it's been used to create a number of popular games.
- bodge5000 4y ago
  Monogame is really tempting, I've heard great things about it. Funny little anecdote actually, I was originally against it as I felt it sat too close to microsoft, so decided to try a different framework with my usual editor, VSCode. Took me longer than you'd think to figure out the irony of that
otikik 4y ago
> being freed of the constraints of an engine I am going to suggest the opposite: subject yourself to more constraints. Try programming on a retro-fantasy console like Pico-8 or some of its free alternatives. I found the (sometimes ridiculous) restrictions very liberating. In exchange you get raw immediacy. I want a game with a chicken on it. I spend doodle something with the 8-bit 8x8 bitmap editor. I draw it with 1 line of code, 4 more lines to control with the arrow keys. Total time: maybe 2 minutes. This radical immediacy is something I really missed in more unconstrained environments. I would get analysis paralysis "should it be a male or female chicken? what shader should I use to properly render the chicken wings when there's rain".
- hypertele-Xii 4y ago
  Developing an actual game on PICO-8 is like solving a Zachtronics puzzle. Appealing to a small subset of developers who enjoy hex editing, hacking, and squeezing performance out of a limited system. But if you're more artistically inclined, you will only find frustration where PICO-8 flaunts its "cozyness". It imposes completely arbitrary and unnecessary restrictions where there should be none. These restrictions will become a brick wall you eventually hit, and then you have to start peeking and poking raw memory with hexadecimals like you're programming in fucking C, or just give up trying to make the game you wanted to make.
  - otikik 4y ago
    I realize that this might not be for you, and that is fine. I must object to the “arbitrary and unnecessary” part. You might not agree with the reasons, but there are reasons for the restrictions. I also want to say that I think of myself as actually very artistically inclined. An 128x128 screen in 16 colors is just a medium. You prefer other mediums and that’s fine, but the implication of “Pico-8 isn’t for artistic people” is simply not true.
    - hypertele-Xii 4y ago
      You're talking about surface level details and artistic choises. I'm talking about the underlying workings of the engine, and the strangling limits placed thereupon. Limits like token count, which only serves to force you to "optimize" your code somewhere along development of your game because you suddenly "run out of words" to code a new feature you just thought of. Then the framework turns from "helps you make games quickly" to "grinds your progress to a halt because REASONS". Or if you wanted to make another level, the creative artist you are, but there's just not enough room in the map editor, so now you have to plug in a data compression library and lose access to the built-in map editor!

krapp 4y ago

May be more lower level than what you're looking for but my current drug of choice when I want to write all the code is SDL2 and LuaJIT in Visual Studio.

bodge5000 4y ago
SDL2 I've been heavily tempted by, but it has a similar problem as Raylib where everyones writing it in a different language. Great when you know what your doing, but a bit more difficult to get up and started with. But maybe it is worth that extra time investment just for how popular and battle-tested it is

pizza234 4y ago

In Rust, there is none; they're just not ready, and not used either (there are very few full games written in Rust). The Bevy maintainers in particular give very low priority to foundational functionalities (see 1 frame lag and the unusable stages+states), and focus on advanced ones instead. There aren't so many alternatives actually (SDL is a very valid framework, but it isn't a game engine), and the choice depends on what's your real goal (experiment or develop a real game). In my opinion, if the goal is to produce a real game, for somebody who doesn't have significant experience, documentation (including: availability of books) is the top priority.

bodge5000 4y ago
Doesn't have to be Rust, pretty much any language (though I'd rather not Java just for personal preference). I'd say my goal is to produce a real game, its really just to experiment, but the experiment is to see if it should replace Godot for me

garrypettet 4y ago

I’ve just started out with Flame and Flutter. As a newcomer to game development (but experienced in other genres of coding) I’ve found it great.

brennopost 4y ago

I enjoy love2d for small 2d games.

Barrera 4y ago

What's not production ready about Bevy?

norman784 4y ago
Not stable release yet, so each release might bring a lot of breaking changes, when they release 1.0 the API at least will be more stable.
pizza234 4y ago
Two main problems: 1. state/stages can't be used together; since plugins may use states (and even baisc funcionality, like the fixed frame step), you can't use stages 2. in order to flush commands, you need stages, but you can't use them due to 1. The result is that with Bevy itself, writes (commands) become effective only at the end of each frame. There is a plugin written by a 3rd party, but the Bevy developers are treating this as very low priority (it's been open for a very long time, and it's not even scheduled for the next release). Paradoxically, it matters little because there's a lot of hype about Bevy, but there are little (or none) significant projects - only very small ones or demos, which don't require efficiency or precise timing. Additionally: the Bevy team doesn't write documentation at all. The "cheat book" is written by a 3rd party, with the consequence that it's partial, superficial, and it may be halted at any time (note that I don't fault the book maintainer(s); their contribution is crucial!). This isn't great when one approaches the engine for the first time; it actually sucks because engines like Bevy are (relatively) large beasts.
- pcwalton 4y ago
  Note that https://github.com/bevyengine/rfcs/pull/45 https://github.com/bevyengine/rfcs/pull/45 is actually fairly active; it doesn't look like "very low priority" to me.
- alice-i-cecile 4y ago
  Hi! I'm one of the four formal maintainers of Bevy. I'm not particularly interested in convincing you personally, but I think it's important to publicly address some misunderstandings. The scheduling rework that you're complaining about is extremely high priority, and I have personally invested hundreds of hours into redesigning and refactoring this mess (which is now in its third serious iteration). It's a challenging problem, and the volunteer who has taken responsibility for the rewrite has needed to step back for a while as they transition to a new job. I have also personally invested hundreds of hours writing, editing and reviewing docs for Bevy. That's what got me involved in the first place, and the team has done a great job. A fully revised book is also in the works, but getting the subtle details right are critical. As for serious projects: I've spoken with about a half-dozen commercial teams, including one with a team size of about 10 and a lifespan of nearly two years. Their feedback is remarkably positive given the immaturity of Bevy and the supporting ecosystem. While there are missing features that they want (hi bevy_ui), and annoying papercuts (yep, those scheduling concerns sure are annoying), they've over all been wildly impressed been how easy to maintain, reliable and performant Bevy has been for them.

jasonjmcghee 4y ago

You can do Godot with a code only workflow. The UI is just an abstraction over setting variables and writing configuration files. You’ll likely want to use a language with good IDE support though, like C# (Mono). The Scene files can also be written by hand. But the Tool class (which you use to leverage the GUI) is so useful in Godot. You’re probably going to use egui or imgui to build a replacement yourself in any other engine anyway. The instant feedback of changing key variables and seeing their effect is too useful not to leverage.

bodge5000 4y ago
Really good idea actually, I could test out the workflow of a framework whilst working with something I know. I remember I briefly looked this up in the past and there wasn't much on it, but maybe I should take another look. As for the tool class, I don't use that much in regular godot to be honest. It always felt a little like variable exports, a bit of a hack for users coming over from Unity to feel more at home but not "standard practice". Not sure why it feels like that to me, but I do alright without it.
- jasonjmcghee 4y ago
  Oh man, it’s so much more. You can put any code behind Engine.EditorHint condition and it only runs inside the editor. You can make shortcut keys to do things or execute code in _Process. For example, i’ve made a script where editing one tilemap updated another, the first being a palette for wave function collapse, generating the other. When i implemented vector fields, i first had it track the mouse instead of the player and did it all in the editor (not hitting play)
  - bodge5000 4y ago
    Quick question, if I were to try the code only workflow, how would I actually run the game? Is there a cli godot has or something, or would I need to go back to the editor itself to click play?
    - 4y ago

lc9er 4y ago

There’s Monogame, if you know C#. It’s got a decent sized community and it's been used to create a number of popular games.

bodge5000 4y ago
Monogame is really tempting, I've heard great things about it. Funny little anecdote actually, I was originally against it as I felt it sat too close to microsoft, so decided to try a different framework with my usual editor, VSCode. Took me longer than you'd think to figure out the irony of that

otikik 4y ago

> being freed of the constraints of an engine I am going to suggest the opposite: subject yourself to more constraints. Try programming on a retro-fantasy console like Pico-8 or some of its free alternatives. I found the (sometimes ridiculous) restrictions very liberating. In exchange you get raw immediacy. I want a game with a chicken on it. I spend doodle something with the 8-bit 8x8 bitmap editor. I draw it with 1 line of code, 4 more lines to control with the arrow keys. Total time: maybe 2 minutes. This radical immediacy is something I really missed in more unconstrained environments. I would get analysis paralysis "should it be a male or female chicken? what shader should I use to properly render the chicken wings when there's rain".

hypertele-Xii 4y ago
Developing an actual game on PICO-8 is like solving a Zachtronics puzzle. Appealing to a small subset of developers who enjoy hex editing, hacking, and squeezing performance out of a limited system. But if you're more artistically inclined, you will only find frustration where PICO-8 flaunts its "cozyness". It imposes completely arbitrary and unnecessary restrictions where there should be none. These restrictions will become a brick wall you eventually hit, and then you have to start peeking and poking raw memory with hexadecimals like you're programming in fucking C, or just give up trying to make the game you wanted to make.
- otikik 4y ago
  I realize that this might not be for you, and that is fine. I must object to the “arbitrary and unnecessary” part. You might not agree with the reasons, but there are reasons for the restrictions. I also want to say that I think of myself as actually very artistically inclined. An 128x128 screen in 16 colors is just a medium. You prefer other mediums and that’s fine, but the implication of “Pico-8 isn’t for artistic people” is simply not true.
  - hypertele-Xii 4y ago
    You're talking about surface level details and artistic choises. I'm talking about the underlying workings of the engine, and the strangling limits placed thereupon. Limits like token count, which only serves to force you to "optimize" your code somewhere along development of your game because you suddenly "run out of words" to code a new feature you just thought of. Then the framework turns from "helps you make games quickly" to "grinds your progress to a halt because REASONS". Or if you wanted to make another level, the creative artist you are, but there's just not enough room in the map editor, so now you have to plug in a data compression library and lose access to the built-in map editor!