[bermanoid]

Game engines are different. It's a tiny market relative to web, and really the only people in the market for an engine other than Unity or Unreal are indies, who have near zero revenue and even less willingness to spend it. Those two are so far ahead in terms of features, support, and battle-hardening that you'd pretty much have to be insane to pick anything else if you had paying users.

Always be wary of any market where someone's willingness to try your product is in itself a negative indicator of ability to pay. Hit-driven markets that attract large numbers of non-serious dabblers are extremely difficult to sell tools profitably to, but it's easy enough to get minor attention that makes you think you might have something worthwhile (music production is another one that scatters corpses all over the place despite seeming large at first glance).

[makeee]

Yeah I guess the game equivalent to my tool would be one that helps people build faster with Unity or Unreal. Like I do with React, better to latch on to a tech that already has huge mindshare.

> Hit-driven markets that attract large numbers of non-serious dabblers are extremely difficult to sell tools profitably.

If I'm understanding correctly, do you mean it's easy to overestimate the size of the market? That makes sense to me. And there's certainly an upper-limit to how much dabblers are willing to pay. Still, for a solo founder that can sometimes be more than enough. I can think of a few tools like mine doing over $10k/month.

[zanny]

And Godot. You know, the 15 year old totally free engine of 30,000 commits 2.5 million LOCs that also does pretty much everything.

[imtringued]

What I noticed is that it's actually much harder to use Godot than expected. Yes it does significantly reduce the amount of code you have to write for your game but it opens up questions of how to structure your project because the scene editor doesn't actually match how I would make my own games if all I had was SDL2. For example if you just straight up write code to add nodes to the scene graph it will create a disconnect between what is displayed in the editor and the actual game. Figuring out how to keep the editor and code in sync is a problem unique to Godot and this is very disconnected from general software development.

[PinkMilkshake]

> What I noticed is that it's actually much harder to use Godot than expected. Yes it does significantly reduce the amount of code you have to write for your game but it opens up questions of how to structure your project because the scene editor doesn't actually match how I would make my own games if all I had was SDL2.

I agree. But what I've learned in my short time using Godot is embracing Godot's scene system and not fighting it seems to help.

This area in the documentation is helpful: https://docs.godotengine.org/en/stable/getting_started/workf...

You can also bypass the scene system. The scene system is a optional abstraction on top of a seemingly more data-oriented core where everything is just a RID (Resource ID).

More here: https://docs.godotengine.org/en/stable/tutorials/optimizatio...

> For example if you just straight up write code to add nodes to the scene graph it will create a disconnect between what is displayed in the editor and the actual game

You can solve this to some degree by putting "tool" at the top of your scripts. See https://docs.godotengine.org/en/stable/tutorials/misc/runnin...

[zanny]

It does happen in Unity and Unreal too when you strictly work in the visual editor without writing much code.

It also happens in Qt and similar WYSIWYG visual editors where they often cannot render full dynamic content in the editors. But in all those cases you can just write everything in code without using the visual tools, and you can do that with Godot as well.