Hacker News Reader

Comment by bodge5000 | Hacker News Reader

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"

View on HN

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.

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

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.

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.

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)

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?

Depending on your ide (e.g. Rider) you can get it directly in the IDE with no setup other than installing the plug-in.

You can always execute via the binary.

https://docs.godotengine.org/en/stable/tutorials/editor/comm...

> 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".

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.

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.

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!

Perhaps contraints was the wrong word, as I absolutely agree. Maybe constraints of the workflow is a better way to say it, though I'm not sure there are any, I just want to try a framework and see if it suits me better.

But back on your point, yeh pico-8 is fantastic, like the game dev equivalent of a pocket operator for music. I never quite got the hang of it, but I do want to try it more, it seems like it'd be fantastic for prototyping, and maybe actually itself gives a decent idea of the code-only workflow Im looking for.

I enjoy love2d for small 2d games.

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.

What's not production ready about Bevy?

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.

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.

Note that https://github.com/bevyengine/rfcs/pull/45 is actually fairly active; it doesn't look like "very low priority" to me.

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.

> The scheduling rework that you're complaining about is extremely high priority

I see.

> I have also personally invested hundreds of hours writing, editing and reviewing docs for Bevy

Do you refer to the API docs and/or examples, or something else? I think it's important to have updated and more or less extensive API documentation, but it's not a proper resource for people to learn. AFAIK the only other semi-official learning resource is the cheat book, which is fundamental, but also incomplete.

> As for serious projects: I've spoken with about a half-dozen commercial teams [...] they've over all been wildly impressed been how easy to maintain, reliable and performant Bevy has been for them.

I don't have this clear. Are 5/6 teams actually building commercial games with Bevy, or they just planning to do it in the future? This is a crucial distinction.

API docs, examples and the revised book: https://github.com/bevyengine/bevy-website/pulls?q=is%3Aopen...

Strongly agreed on the need for better introductory material; the existing book is extremely incomplete.

> I don't have this clear. Are 5/6 teams actually building commercial games with Bevy, or they just planning to do it in the future? This is a crucial distinction.

I know of 2 released commercial projects, the CAD team, a few indie devs who have started and 3 or so small studios who are looking to start. There's a little thread in the Discord where I've rounded folks up: [Bevy in production](https://discord.com/channels/691052431525675048/995713618526...).

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.

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

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.

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

Reply on news.ycombinator.com