[bdefore]

Unity has learned all the wrong lessons. Their success was largely from the verdant asset store and the asset developers who augmented a creaky platform with wonderful and useful tools to shorten development time. They never figured out how to maintain sane compatibility for these tools version to version, nor a way to sustain and compensate these authors. Which brings us to today: a shady acquisition to sneak malware tech into games while they continue to neglect the community that made them who they are.

[SXX]

You could guess how Unity will end up after John Riccitiello became it's CEO. After all Electronic Arts was one of most hated anti-consumer companies ever.

[BoorishBears]

I'd argue the asset store was the beginning of the (very slow) end.

Before the asset store Unity's community was a hotbed of openly shared innovation.

The moment Unity gave people an easy way to slap together what would have been a quick post to the forums with a webplayer link, some code samples and a few paragraphs explaining it... into a paid package that sells for $5... that ended quickly.

And the worst part is, the skillset to manage a paid library is not the same one needed to develop some cool tech! There are so so many packages on the asset store that are practically abandoned, or poorly suited for integration into someone else's codebase (some people have no issue with warnings everywhere in their code for example...), or are poorly documented, or will break on any platform that wasn't the original dev's personal machine. The list goes on.

-

I don't have anything against indie game devs making money, I know the struggle of slaving away at something and ending up broke for your trouble... but I really wish the asset store had been restricted to game assets like 3D models, sounds, etc.

It's not like people wouldn't be able to sell their code then either. It's just before the asset store if you wanted to create a paid distributed library, the inertia you'd have to overcome was a pretty good filter against low-effort attempts. There were still successful libraries that were worked on full time and sold as products

[sauntheninja]

The compatibility between versions has always bit me when trying to learn unity. I find a tutorial on a short game and when I try to open that in Unity its incompatible with a newer version and you have to then go browse unity forums for an answer

[mordae]

Good times for Godot, nice!

[extrememacaroni]

People keep bringing up Godot but there's no way around the fact that it feels like some guy's homebrew engine through and through, especially once you try to use the native C++ side. But you don't really need to get that far to realize how janky it is. You can't even delete assets that may or may not be used in scenes without running into errors and warnings that may be benign but eat away at your trust that things will still work fine later down the line.

The GUI tools are atrocious compared to Unity's and they fail at the most important thing: make sure that when you play the game the GUI looks exactly the same as in the designer. There's also some weird jank with the GUI, where you have to reload the scene to see some changes being applied (like, imagine setting some property in, say, a winform, and having to close and reopen the winform's editor to see it actually having an effect, wtf) but I don't think it's limited to the GUI, I forgot what those were exactly. But there's no indication that you need to reload the scene, you google the problem and the answer is "reload the scene".

There's a loooooooong way to go for Godot to reach Unity's level. They'd have to essentially become the next Blender, which I use as the benchmark for open source community driven projects.

Godot == Unity at home.

The best thing about it is that you have access to the source for free, so you can fix bugs yourself. "We may run into issues three years down the line with the project but at least we can fix them ourselves". How attractive this sounds to you depends, I assume serious developers who want to build large games for profit, will choose either Unity or Unreal because they're expected to work better overall.

[SXX]

Okay I will share some of my own experience over almost 2 years working with Godot / GDScript. We're building 2D pixel art game for Steam. We're fully funded by publisher and have a team of 10 people with 3 programmers. We have around 100KLOC codebase with a lot of game mechanics.

Primary downside of using Godot for commercial development is lack of official console support. Everything else will vary from project to project since every game is different. Godot have bunch of weird limitations, lack of proper virtual filesystem (e.g boost::filesystem anyone?), really shitty profiler, some weak UI / UX in editor some of which can be easily compansated by using VSCode.

At the same time I can certainly say that you can make proper commercial game using Godot. Engine is stable, performance is not the best, but okay. Will it work for everyone? Probably not, but again it works for us.

PS: I also glad to advertise few Godot projects that are not mine, but I find them really enjoyable (check profile if you curios about project I work on):

https://store.steampowered.com/app/1637320/Dome_Keeper/

https://store.steampowered.com/app/1953670/Quetzal/

[uwuemu]

> some weak UI / UX in editor some of which can be easily compansated by using VSCode

??

What exactly can be compensated for with a code editor? 75% of the value of a "modern engine" is in its tools... with something like Unreal it may be close to 90%. Level editors, object browsers, geometry editing, animation editors, rigging, particle editors, material and UV editors, physics/navigation/ai system and their editors... the list goes on and on. Gameplay code is something you'll either do in visual scripting (UE blueprint) or in an external IDE. Any engine-level coding will be done in an external C++ IDE (Visual Studio). So... I can't imagine what exactly VSCode compensates for?

[cain]

The limitations of Godot's in-engine text editor can be compensated by a more powerful external editor: VScode, emacs, vim, etc. An example would be the lack of remappable keybindings: this can be overcome by using an external editor.

[EamonnMR]

But the strength of Godit's native scripting is its integration with the rest of the editor. Can the vscode plugin match that?

I find the Godot native editor annoying (and it lacks vi keys!) amd clunky and long for multiple tabs but it increases productivity enough that I wouldn't give it up.

[IoI_xD]

The fact that this is an argument for anything at all is questionable because it implies you don't use your favorite text editor for any program similar to Unity. When I was using the program I didn't even know it had a text editor because I just alt tabbed to Sublime Text. I would expect many others to do this too because in general I've always just found that the "built in text editor" of any program (whether it be a VPS's control panel or GitHub) is always bad compared to an external one.

[SXX]

I guess you are talking from AAA gamedev perspective while making some huge 3D title. Small team like ours working on 2D pixel-art base-management game dont need any of the following: geometry editing, animation editors, rigging, particle editors, material and UV editors, physics/navigation/ai system.

Mmmokay.... We of course use some basic physics for collisions detection, but everything else is mostly animated sprites and a lot of code. There are a lot of game mechanics and they all implemented without any visual scripting.

And even with Godot scene editor is solid I simply don't have to touch that much since all basic objects were implemented long ago and it's mostly duplicating with some editing for integrating new visual content.

95% of time I spend working on gameplay code and here Godot own code editor UX is very lacking compared to almost everything else. So here VSCode comes.

[hesdeadjim]

This * 1000.

I'd love to meet a single person on this site who has used Godot to ship a commercial game of any note. Ship a Godot game on macOS 11+/iOS 13+/tvOS 13+/PC/Linux/Switch/PS4/PS5/Xbox and then come tell me how it went. Godot is basically completely unproven for a game requiring this level of release support.

I feel like a Unity apologist sometimes, but what options are there? If your studio doesn't have high level competency with Unreal, committing to a project using it adds an immense amount of risk.

This merger is a real kick in the gut for me, but I'm all in with Unity and I can't afford to bet my studio on an Unreal switch without major partner financial support.

[SXX]

For the time being Godot going to be PC-first game engine and our 10-people studio dont have any issues building for Windows/macOS/Linux. Test imports for web work amazingly well, but we dont need it.

Lack of console support is just limitation of what can be done with open source code since even SDKs for consoles are under NDA. I guess if you building project for consoles then you have to look elsewhere.

You are not wrong in any way. At the same time there are plenty of small teams that can work with Godot and build some fun games using it.

[hesdeadjim]

And don't get me wrong, I am 100% cheering Godot on long-term. Same with the Bevy ECS.

Options are great, it's just that the first adopters have to pay the hardest price when they want to ship a game using it. If I were doing the indie thing still, I'd consider Godot.

[extrememacaroni]

The lack of console support comes especially from the fact that there's no company behind godot itself that can become a licensed Nintendo developer for example.

There are other companies that can port your godot games to consoles and publish them, but in the stores the games will be listed as theirs not yours. If you're an indie without a publisher, that's probably not a big deal. Although it would be if it were me, I'd want the game to be listed under my own name, not someone else's, especially if a player might start to avoid games published by X because they played games they did not like in the past. But if you're already backed by a publisher, that will probably not fly.

[SXX]

I will just add a note about publishers: if your project is not using Unreal / Unity most huge publishers just wont be interested. It has nothing to do with Godot console support or anything else about Godot itself.

Basically all big publishers have their own pipeline and in-house teams for porting / QA / certification and it's all built around Unity or Unreal. So it's all about market share.

So yeah choosing Godot will certainly limit your options in terms of what publishers might fund your project.

[erik]

> The lack of console support comes especially from the fact that there's no company behind godot itself that can become a licensed Nintendo developer for example.

The lack of commercial entity isn't the problem. The problem is that adding any sort of platform support to an open source engine is completely incompatible with the license terms of the console SDKs.

> There are other companies that can port your godot games to consoles and publish them, but in the stores the games will be listed as theirs not yours.

Why would this be the case? You can contract with a company that has experience porting Godot games to Switch to do the technical work. But you would have your own distribution agreement with Nintendo and you would certify and publish the game yourself.

[CJefferson]

Have you actually released a game using Godot? If so, can you share a link?

[SXX]

Link is in my profile. Our game gonna be released this year after ~3 years in development. It's fully funded by a publisher and close to gold master.

Feel free to ask whatever about development process :-)

[dagmx]

For what it's worth, Godot is actually used quite a bit for gambling machine games. I've got a few friends who work for companies in that space doing the art.

[omoikane]

Maybe not the best example, but Sonic Colors had Godot in it:

https://www.reddit.com/r/linux_gaming/comments/pi1ioo/sonic_...

https://twitter.com/falessandrelli/status/143385695747621684...

[nrjames]

Not a game, but my understanding is that the 3D elements and renderings of traffic in the Tesla (and Tesla app) is made with Godot.

[brundolf]

> You can't even [common action] without running into errors and warnings that may be benign but eat away at your trust that things will still work fine later down the line.

To be fair, in my experience this is par for the course in Unity too

[noobermin]

Caveat, this is a meta post. I'm not a gamedev (not professionally at least), and don't have experience in either.

This reminds me of something I rant about often, linux naysayers on HN. Because of them, I tried buying a macbook in 2015 and had some of my most frustrating experiences in my life, culminating in a talk for a national conference I had to redo on a friends windows laptop in half an hour because it failed to display on the projector. Turns out the HN crowd who kept saying "mac is unix like linux but better since it's not a bazaar open source mess" aren't always right after all.

People have some bad experiences with X product where X product is often open source and being open source explains the bad experiences. However, when Y product also offers similar bad experiences (and even worse ones) but they paper over it in their minds because "it just happens" although it's probably just because they're used to it. Repeat for photoshop and gimp (my SO is an animator and adobe products crashing is a common experience, as is redoing work in case a save was forgotten), linux and mac, etc.

Anyway, I'm not a gamedev, I just see a similar pattern and it's hard not to notice.

[entropicdrifter]

As a Linux user on my daily drivers and a Mac user on my work-issued machine, I agree with this sentiment completely. Linux has weird issues a good amount of the time if you're trying to do unusual stuff, but so do Windows and Mac, and on those platforms you're less equipped to pop the hood and fix the underlying issue.

[sfteus]

I have to agree with this. I moved off Windows into Linux as a daily driver mainly due to issues with docker support (pre WSL2, but even that had filesystem issues the last time I tried to used it). I recently accepted a new position that provided a Mac M1 and it's just a generally frustrating experience comparatively. Specifically, anything that involving keyboard directed window management is either non-existent or flaky at best, and a ton of functionality that it just inconsistent with the rest of the OS / applications (why is a separate fullscreen the default functionality, and why can you no longer Alt-Tab + Cmd + Tilde to a window that's been made fullscreen if you have a second non-fullscreen window open?).

Maybe my flow just isn't compatible with the OS (it feels very visual + mouse oriented), but between a previous ~2 year stint with another Mac-only job and these ~3 months, about the only thing I have to say that's positive about the OS is the spaces feature.

And like you mentioned, even when I had an ambiguous error on Linux, there was usually enough information to find a similar enough problem online to at least narrow down what I should investigate.

[dkonofalski]

>I had to redo on a friends windows laptop in half an hour because it failed to display on the projector

What situation would possibly require you to redo a presentation because it can't display on a projector? PowerPoint is cross-platform and Keynote can export to PowerPoint. This seems like hyperbole.

[gg2222]

I second this opinion. As a (non-hobbyist) game developer, I started my current game with Godot, but after running into many issues including performance which was the final dealbreaker, I decided to port the whole game to Unity.

Finally I could focus on developing the game rather than running into engine related issues and limitations and having access to all the time saving assets in the Asset Store was (literally) game changing. Having the Asset Store is a whole new world. And as a dev with funds, paying for assets to save weeks of time was a no brainer.

Back to Godot, yes deleting stuff in Godot is pretty scary cause there is (or at least was) no way to know what effects/errors it could cause.

GUI system (at least last time I used it) was very unfortunately not well designed making it extremely hard to get consistent positionings. I feel it's so bad that just using HTML+CSS would be better cause then it would be possible to confidently put things and keep them where you want to.

And yes, overall as someone who has also used the C++ side, it does feel like some guy's homebrew engine. I felt things weren't as solidly designed as they could be. And this is talking about foundational stuff.

The C++ source code is really not modern C++ (or you could call it anti-modern C++).

I would not advise anyone to develop a game on it if your livelihood depended on your game's success.

Of course people can and will prove me wrong by still powering through and creating a successful game with it, but your time is better spent using a more mature engine like Unity or Unreal.

Even if you want to get your hands dirty and help fix bugs or add features to the engine, there is no guarantee that your PR will be merged.

Game development is probably the most riskiest type of software development already business-wise. No need to up your risk.

Of course if you are a hobby indie dev and do it just for the enjoyment of building things, then no problem.

As for Godot's future ... well it's been many, many years, but if I understand correctly they're mainly still working on 3D rendering features. There are tons of other areas that are still the same with the same limitations as they were years (5 years+) ago. I think with not so solid foundation and the pace of development, it will take many many years if ever to catch up to Unity.

I do like the way Godot engine does some things and I do hope for it's success as competition is always good. I just don't have much faith in it from what I've seen. I do hope I will be proven wrong though.

[johnnyanmac]

> I assume serious developers who want to build large games for profit, will choose either Unity or Unreal because they're expected to work better overall.

they'd ultimately choose them because of support more than jank, to be honest. They care less about the ability to fix a bug 3 years down the line than the ability to phone up engine experts they don't have to directly hire to fix it for them.

I'm assuming Godot doesn't have such support past enthusiast forums.

[hesdeadjim]

Yep, I bought enterprise support for my studio for exactly this reason.

Great example: Apple updates Xcode to 14, which includes some undocumented change to Clang that ends up completely breaking Burst static initialization. Unity's fault? Nope. But they fixed it quickly. When Godot breaks, glfh, that's on you.

[Pulcinella]

Is this something that happened or an example of something the could happen? I mainly target Apple’s platforms and while moves like this don’t leave me feeling confident about Unity, the acrimony and legal battles between Apple and Epic (and Epic’s level of support for development on Max, especially ARM Mac)leaves me feeling even less confident about switching to Unreal.

[darkteflon]

I think Epic’s doing a pretty reasonable job of distinguishing between Apple, and people that develop in its engine on Apple machines. The 5.0.2 release, for example, had loads of MacOS-specific bug fixes. There are compromises versus developing on Windows, of course - you lose hardware Lumen, for example. No native AS support either yet, but it runs okay through Rosetta depending on what you’re doing.

[hesdeadjim]

Yep, real: https://forum.unity.com/threads/burst-xcode-13-3-builds-for-...

[light_hue_1]

I'm surprised you would say that Godot has more bugs than Unity. Unity is an endless fountain of bugs that keeps on giving when you least expect it.

Godot does lack some features. But that depends entirely on the kind of game you're aiming for. The 2D market like RimWorld could easily move to Godot.

On that note. UI skinning isn't a feature that's lacking in Godot. https://docs.godotengine.org/en/stable/tutorials/ui/gui_skin... If you easily implement that screenshot what prevents anyone from matching any designer's dreams?

[SXX]

> The 2D market like RimWorld could easily move to Godot.

I really all for Godot and our team have positive experience with it, but I think that it's will be hard to mantain game that is heavy on simulation with a lot of moving parts. Might be Godot 4.x will get improved profiler, but for now it's really lacking.

So unless you move everything into C++ I dont think you'll manage good performance in Dwarf-Fortress-like simulation game. Though might be I overeastimate how much simulation / physics game like RimWorld require.

[entropicdrifter]

Personally, as a professional programmer who's interested in developing a Dwarf-Fortress-like sim game as a side project, I've been keeping an eye on Bevy as an open-source game engine that would likely have good performance for a sim game with lots of moving parts. Being a Rust-based ECS game engine lends itself to a lot of potential for heavy parallelization, which you'd need to maximize that sort of number crunching performance on a modern CPU

[Jensson]

You can implement the heavy stuff in C++/Rust, compile it to a dll and import it into whatever engine you want. The hardest part about making a game like dwarf fortress is to implement a good UI, making it run fast is much easier and shouldn't be a priority when selecting engine. Game engine performance is mostly about rendering and not your custom simulation code.

[light_hue_1]

> I think that it's will be hard to mantain game that is heavy on simulation with a lot of moving parts... C++

I don't see why that would be. Godot has bindings for all sorts of languages including C#. Why would it be any harder to write C# code with Godot bindings than C# code with Unity bindings?

[SXX]

Problem is not to write GDScript or C# code in Godot, but profiling and performance optimizations: toolset of the engine is really lacking in this area so it's really hard to find out what are major bottlenecks are and what is eating most of frame time.

Godot profiler for their "scripting" be it GDScript or C# is a dumpster fire. If you have a lot of objects and non-obvious performance drops it's really hard to find them.

In case you use C++ you will be able to use mature profilers for C++ projects like built-in one in Visual Studio or Xcode, Valgrind on Linux or some 3rd-party solution like Intel XE Studio. All of them are just 10000% better than what Godot have at this moment.

[ensignavenger]

Another option that is still young (young as an Open Source project, but has a lot of historic development behind it) is O3DE (https://www.o3de.org/) I think this has a lot of potential if it gets enough attention and development.

[fyrn-]

I don't have much hope for it, I know several people that worked for amazon lumberyard (it's old name), that have quit because that organization is collapsing in on itself, losing engineers way faster than they can hire, and the engine is still buried under a mountain of tech debt inherited from Cryengine (that real Cryengine has resolved a long time ago)

One quit because the new render was so performance intensive, an rtx 2080 super was min spec for the lightest of scenes to achieve 60fps.

Another because he became the last engineer on his team after all the others quit and moved elsewhere at Amazon.

Even hoping open source saves it is unlikely, as it's only in name. The CI and infrastructure to meaningfully develop it open source does not exist.

As a final nail, the install process takes over two hours, which is just not competitive.

[beepbeepcabbage]

C# vs C++

Godot is C#

[seba_dos1]

Godot is C++. You can use C# (among others) to write game logic in it.

[adamrezich]

but also, maybe it's a good time to try dropping the scene graph/ECS way of doing things—there are other ways to make video games!

[HelloNurse]

> dropping the scene graph/ECS way of doing things

A scene graph and an ECS are basically polar opposites, arbitrarily heterogeneous object trees to facilitate genaral manipulation vs. rigorously organizing data to facilitate good performance. Please explain what you mean.

[adamrezich]

engines like Unity and Godot encourage you to organize your conceptual model of your game in their scene/node and component systems. if this is the only way you learn to make games, you will only ever think about things in these high-level, abstracted terms, instead of thinking about what the computer is really doing, thinking about what you want the computer to do, and thinking about how simple you could make things if you didn't force yourself to use such systems inherent to these engines.

[HelloNurse]

Do you mwean, why use a good, "abstracted" game engine if you can make a bad, "simple" one yourself? Or why make portable games "instead of thinking about what the computer is really doing"? Do you think advanced games could be made if the designer doesn't "think about things in these high-level, abstracted terms"?

I suggest an exercise to understand the value of abstraction: a remake of a Commodore 64 game using JavaScript (Canvas to simply draw pixels, nothing fancy).

[adamrezich]

> Do you mwean, why use a good, "abstracted" game engine if you can make a bad, "simple" one yourself?

you should definitely make something good instead of something bad. I don't understand what you mean by this.

> Or why make portable games "instead of thinking about what the computer is really doing"?

I'm assuming by "portable games" you mean the code is easily able to be ported to other platforms. code portability and "thinking about what the computer is really doing" are not orthogonal concepts.

> Do you think advanced games could be made if the designer doesn't "think about things in these high-level, abstracted terms"?

there is nothing wrong with thinking about game design in high-level, abstracted terms. what is misguided is thinking code should be written this way.

> I suggest an exercise to understand the value of abstraction: a remake of a Commodore 64 game using JavaScript (Canvas to simply draw pixels, nothing fancy).

I'm having trouble understanding why you've made this suggestion for me? what does it have to do with anything?

I was the engine architect for a couple of team game projects I worked on in college a few years back. at the time, the Unity ECS/scene hierarchy system was The New Hotness and everyone was evangelizing it, professors were encouraging us to explore using it (without giving any implementation or theory advice—our first project had to be written in C89, the second, C++).

it was a gigantic waste of time and resources. we could have made our games functionally identical in a fraction of the time if we just did things the easy, obvious way, and then we could have used all that extra time to make those games that much better.

[JoeyJoJoJr]

I’m a big fan of immediate mode rendering. Unfortunately not a lot of engines/tools/libraries support this way of working.

[nomel]

> there are other ways to make video games!

Any interesting, practical, examples?

[adamrezich]

I'm having trouble understanding the question—there's plenty of open-source games that do not use ECS or a Unity-style scene graph. this mode of thinking being the default is relatively recent in the history of video game development. if you've never tried something like that before, PICO-8 might be a good starting point. this blog post might also prove useful: https://www.gamedev.net/blogs/entry/2265481-oop-is-dead-long...

[nomel]

> I'm having trouble understanding the question

I've only slightly dabbled in game engines, and have only been exposed to ECS and scene graphs, so I was asking for other methods, since they don't seem to be nearly as popular. Searching gives me results, but I can't qualify them, so maybe aren't "interesting" to actual game devs. I added "practical" because this is HN, where sometimes theoretical tangents take hold. :)

But thanks!

[ummonk]

Honestly I think most sensible ways of organizing renderable entities end up approximating either ECS or scene graphs. The difference is that you’re doing the management yourself instead of relying on engine’s functionality, so you get way less features but way more performance due to lack of unnecessary overhead.

[seba_dos1]

Any SDL tutorial out there, I guess?

There are kinds of games where simply having a input handling function, logic tick function and draw function executed in a big loop is pretty much all you need, and I assume that's what GP is talking about. I like to write games this way on game jams and it serves me well.

OTOH, there are also kinds of games that I simply wouldn't dare to write this way without figuring a solid abstraction out first, and things like ECS can often fit pretty well for that.