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.
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):
> 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?
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.
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.
I can't speak to the strengths of the VScode plugin, but if it's anything like the emacs gdscript plugin (which I use with Spacemacs + vi keybindings), then the integration is very tight. I get just as much completion as I do in the in-engine editor, I can run/debug/breakpoint etc. I've been using it for ~2 years.
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.
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.
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.
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.
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.
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.
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.
I think all the reservations about Godot are valid, but let me offer my perspective. In 1996-1997 I remember meeting with Epic to evaluate their engine in develop for a game a AAA game at Activision. I remember in the late aughts (like 09?) being asked to evaluate Unity for a VC that was considering investments and wondering how much commercial developers would actually use it.
These engines are all risky until they aren't. And Godot certainly seems at the tipping point of adoption. Also, all game engines have strengths and weaknesses so that you would want to use Unity or Unreal in many particular cases for a long time. But Godot also has some strengths, not the least of which is that it is open source.
The key thing I would watch is the transition to 4.0 and Vulkan. That seems like a point at which they can either pick up momentum or lose it. The SDK problem for consoles can easily be solved by contractors / middleware if there is enough good games to make it worth the time to bother.
I like the engine but I don't think it is super competitive in 3d. For example, to use it on Quest you have to use GLES2, which is missing a number of features. Quest 2 is a mobile GPU, so you aren't going to be state of the art but I have seen more games that seem to squeeze more performance out using Unreal on that platform. Hopefully the switch to Vulkan will help them get better 3d performance on mobile gpus.
There are a ton of changes in the works from Godot 3. to 4. One of the biggest problems with Unity, in my experience is compatibility as the engine moves forward in versions. You always see projects that are stuck on older versions of Unity because the team doesn't have the time to make the changes so it works with the new version. In general I haven't seen that as a big issue for Godot. Code for old versions seems to run on new versions. But I have never seen a jump as big as the one to 4.0. The question I am wondering is will they be able to make that many changes to the engine and have it be reasonable to transition projects.
They can't be universally true can it? I know Hades is built on a basically in-house engine, and I think it released on all platforms simultaneously... then again that studio might not even qualify as "indie" especially now... are custom engines like that really that rare nowadays?
Supergiant games doesn't have a publisher, they publish it themselves so they can do whatever they want. I don't really consider them indie, to me "indie" is when the people developing it are also the people funding development, meaning people make choices without worrying about what others opinions.
As for self made engines, if you make it yourself then that is a risk. If you make it in unity or unreal then the publisher knows they can easily find people to help you ship it if there are problems, but for a self made engine it could be unsalvageable.
I guess it's depend on your goals and what kind of game you are buidling:
* Funding. Making games is hard and while some of them can be finished using limited resources and free time. Having even small salary is better than living off kebabs and ramen (depend on location). Also artist dont usually work for free.
* Expertise in limiting your creativity. If you actually want to finish and release something then having deadlines and feature cuts is actually a good thing. Yeah most of these 1000 cards on "Ideas" list wont be implemented, but you'll get something done.
* Marketing. Making a good game is not enough nowadays to get any return on time and money invested. Bare minimum to launch on Steam is to collect 10,000 real wishlists before release since otherwise your game wont be features. Wishlists alone is a difficult task that require deep know how in traffic arbitrage since otherwise you'll spend 5x more money. Also making good marketing
* PR. Even in a team of 10 project management and coordination take a lot of effort. Dealing with press, youtubers, streamers and possible future community is a hard work that might require more capacity than you have.
Yes you can be self-funded and everything like marketing and PR can be done in-house, but it's cheaper for publisher since they usually have dedicated people working on each area full-time. It's doable to make it all yourself, but every unique role will distract you from actually making fun game.
Also publisher that invested money into your project will also be motivated to at least get that money back.
> 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.
> 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 is a port of SDL2 to Nintendo Switch that is accessible to anyone that has a distribution agreement signed with Nintendo. There's no reason Godot couldn't have the same kind of support there.
I’ve never done any game dev but have been programming in various domains for a long time. If I wanted to spend a few weekends making a “hello world” game in Godot, where do you recommend I start?
As a starting point, I’d like to make a single-player open world procedurally generated isomorphic map that I can explore with a hovering camera. Is this easy to do?
Thanks. Dwarven Skykeep is my first real commercial project too. So I'm not going to give you any obvious learning tips as anyone can find some good tutorials on youtube. Advice about trying out gamedev that I could actually give are:
* If you can start with some paper prototype or just create some digital visual gameplay screen mockup. Its easier to work toward something you can see.
* Start small and dont bother with code architecture or quality. If 3D seems to hard start with just 2D. Your first goal is to get MVP as quickly as possible. Prototyping on boxes is the best.
* Once you get literally anything running more ideas will flood your mind. So write them all down instead of concentrating on just a single task.
* If you stuck with one idea just jump to another one within the same project. This way you'll find what works.
* Dont hesitate to look for references or play some demo versions off Steam and look for ideas. It much easier to see good and bad sides in someone else game and it help to make your one fun.
As about technical side: isomorphic map does sound like algorithm problem and not game-engine problem. At least on 2D side that I primarily work with Godot have all you need to procedurally generate scenes and reuse them afterwards.
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.
> 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
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.
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.
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.
Yeah, Mac's UI of spaces/desktops is so busted that it usually takes me a couple tries to get the window I want. I've also watched another user lose track of every window that goes fullscreen.
>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.
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.
> 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.
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.
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.
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.
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.
> 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.
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
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.
I mean, there's rimworld for an example of "dwarf fortress with better UI but slower simulation". Commercially it's worked out for them, but I do find myself wishing for the scale of DF when playing rimworld. The new game UI does warn you away from even the larger map sizes they do have implemented though.
Rimworld implemented their simulation using unity objects, if they wanted to increase scale they could rewrite it to run the simulations in custom code and thus run just as fast as dwarf fortress. Or faster if you parallelize it well. Then they could just look at the world state and render that every frame, which is super cheap since its just a bunch of 2d objects and a bit of text.
> 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?
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.
> Godot profiler for their "scripting" be it GDScript or C# is a dumpster fire. ... In case you use C++ you will be able to use mature profilers
Why couldn't you use your regular mature C# profiler like you do anywhere else? It's officially supported. Both the mono profiler and JetBrains work.
> 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.
You can do exactly that right now. Use the C++ profiler to find hotspots in Godot and the C# profiler to find hotspots in your code.
I can easily answer both of your questions. Because I obviously want to know how much time exactly game code takes together: both engine and "scripting". Using weird combinations of two different profilers is not a good day to work on code. Both Unreal and Unity have proper usable profilers and Godot doesnt.
Also unfortunately our project is usingGDScript and there is no profiler for it.
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.
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.
> 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.
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.
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).
> 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.
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...
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. :)
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.
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.
