21 ms·

Oooh, this is cool. I always like to see different approaches to game dev (despite never having published a game!). So far I've tried - Bevy (Rust ECS engine),

Oooh, this is cool. I always like to see different approaches to game dev (despite never having published a game!). So far I've tried - Bevy (Rust ECS engine), which is nice at first but has a lot of problems with its implementation and can become rather messy. I think it's heavily dependent on the game. Part of it will be my own incompetence. - Unity. IMO the system of gameobjects with composed modular components is the most utilitarian - it gets out of the way, and it's easy to avoid spaghetti without requiring a really strict engine-dictated structure. - Godot. I hated it. All of the awful heirarchy of OOP, a really poor builtin language, and "signals", which are meant to decrease spaghetti but only increased it for me. Maybe I was using it wrong? I very rarely use inheritance to the point of being bad at using it. - Pygame, back when I first learnt to code. It's quite nice for small projects - it's procedural at heart but you can make your own OOP or functional layers over it. There have been some surprisingly large projects made in it. I don't know Clojure, but it's interesting to see someone make a functional implementation of something that stereotypically seems like a good fit for OOP.

spoiler 2y ago
> - Bevy (Rust ECS engine), which is nice at first but has a lot of problems with its implementation and can become rather messy. Can you expand a bit about why this was messy or comolicated? I found the paradigm leads to pretty well organised code (sometimes you get the odd large system, but it can be broken down into smaller systems, sub systems or composed out of smaller functions).
- pizza234 2y ago
  While any design requires discipline, ECS systems have little or no coupling between them, and they very easily end up all over the place; in addition to the chaotic design, one ends up also not having an idea of what happens when. For this reason I agree - developing games using an ECS design requires more discipline to manage complexiy, compared to an imperative one.
  - spoiler 2y ago
    I've not had much issues understanding what runs when, because for the most part I didn't need to care that much, and when I did it was possible to order/schedule systems in Bevy. That's even a bit easier nowadays too, since the API improved! With regards to the chaos: I think it can be avoided, but like you said it requires a bit of discipline. I don't feel like it required that much more than normal software engineering (but I'm also the type of person that documents and tests everything even on personal projects lol). The plug-in system makes it easy to help bring order too. This is all through a bevy-tinted lens, since I've done very little game dev (dabbled with UE and Godot) outside of bevy, though!
  - p1necone 2y ago
    I agree with this - ECS lets you write totally decoupled, composable bits of game logic very easily, which is super powerful. But in my experience if you're not careful you end up with a hundred perfectly decoupled little things and it's really difficult to remember how they actually all come together to make the whole game you've built. Easily grokable filenames and file structure are very important, and bevy specifically has a pretty nice plugin system which lets you really clearly 100% isolate groups of state/logic into more sensible sections instead of ultimately having some root level game loop that's directly setting up your 100 tiny little poorly named things.
  - alice-i-cecile 2y ago
    Yeah, I'm one of Bevy's maintainers, and I've seen folks get tangled up (or overengineer things wildly) if they go in without a clear plan. ECS (and a strong compiler) makes things much easier to refactor, but I generally agree that the more flexible nature demands more discipline.
- noelwelsh 2y ago
  I started using Bevy for a small game and abandoned it after a little while. There are two issues: 1. The fundamental issue is that the ECS model has independent subsystems communicating via a relational database. This breaks the connection between function callers and callees, makes control flow incredibly hard to trace, and means the type system can give you very little assistance. 2. Bevy also does not leverage Rust's type system in other ways. E.g. you can use resources that you forget to create and it will only crash at runtime instead of giving a compile time error. I think you can create a good game in Bevy, and if you come from a C/C++ world you probably won't notice the lack of type safety. It didn't meet my goals, however.
  - CaptainOfCoit 2y ago
    > 2. Bevy also does not leverage Rust's type system in other ways. E.g. you can use resources that you forget to create and it will only crash at runtime instead of giving a compile time error. Would something else even be possible in Rust? My understanding is that you cannot really add type safety in the way of "This should be a i64 and between 32 and 128, otherwise fail to compile", so not sure how it could be addressed by the language. Or taken to the extreme "Fail to compile if the user creates an instance of this but doesn't call function F with that newly created instance"
    - noelwelsh 2y ago
      Let me explain a bit more about "you can use resources that you forget to create and it will only crash at runtime instead of giving a compile time error". Plugins are the main abstraction in Bevy. A plugin has two parts: build and run. Build creates stuff, and run uses stuff created by build and created by the build of other plugins running at the same time. Build is pure side-effects, so the result type of build tells you nothing about what it builds. Therefore there are no types that can constrain what resources run uses, and therefore failing to create a resource that is used in run is a run-time, not compile-time error. The alternative is the build returns a type representing the collection of resources it creates, and run's type is a collection of resources it uses. This requires some type level programming (a type level heterogeneous set). This is some of the simplest type level programming, but type level programming itself is quite foreign to most programmers. I assume this is why the Bevy developers went for the easier to write solution that doesn't enforce constraints at compile-time. More generally, just like in regular programming some things are easier and some are harder to do in common type systems. Your first example (integer constrained to a range) is harder because you need to solve linear inequations at compile-time, which is not a feature of most type systems (though see refined types). You second example (must call a method) is relatively easy with linear types, as they express "must do something with this value".
juliangmp 2y ago
> Godot. I hated it. All of the awful heirarchy of OOP, a really poor builtin language, and "signals", which are meant to decrease spaghetti but only increased it for me. Maybe I was using it wrong? I very rarely use inheritance to the point of being bad at using it. Not game dev either but I do have to say that I find Godot's design to be one of the best oop desings I worked with. I tend to not use oop much today (C++ embedded), though I did learn programming with C# so I'm fairly used to inheritance.
- deleted 2y ago
  [deleted]
HideousKojima 2y ago
>and "signals", which are meant to decrease spaghetti but only increased it for me. Signals are basically just event subscriptions. In fact, if you use C# with Godot you can actually just use C# native delegates/events.
- d13 2y ago
  And you don’t need to use signals in Godot at all.
nightowl_games 2y ago
As a professional game dev who has years of experience producing real products in both Unity and Godot, I am totally not with you about your thoughts on Godot vs unity. Godots signals are such a huge step up over Unity's built in classes having a lack of modularity. How do you even make sense of that? Godot vs Unity basically have the same scene/node/component model except Godot does it better imo. Eg) What is the difference between a prefab vs a scene in Unity anyways? Basically nothing, it's just (I'm speculating) a tech debt mistake in their design, probably still going because of how light maps work today. Unity's advantage over Godot is it's 3D renderer, built in physX, il2cpp backend for C#, profiler, general runtime performance and console support. Godots design is objectively more cohesive, as Unity has simply splintered into 10 different design directions since ~2018. I'm not trying to be a hater, I just think signals are a huge advantage for writing modular, simple stuff in Godot. I think there's plenty of great reasons to prefer Unity to Godot but "signals" is not one of em.
- seanthemon 2y ago
  I think the original commenter just really likes "plug and play" solutions with a lot of hand holding which is what Unity is excellent at. The problems come down the line. Godot is objectively a way way better tool
  - monkeydreams 2y ago
    > Godot is objectively a way way better tool If you like things like Godot, Godot is the type of thing you will like. Seriously though, Godot works way better for me using C# than it does with GDScript and the OOP structure means I can refer to classes by their identity.
    - deleted 2y ago
      [deleted]
  - bentt 2y ago
    That doesn't make any sense. Unity may have a pedigree of being for beginners, but in recent years they can barely keep current documentation on their new systems. This smells like a comment from someone who has never used it.
NotAnOtter 2y ago
I'm not that familiar with Godot but the built in language always felt like a misstep. Maybe someone more familiar with it can make a defense. I view 3 users 1. Complete Novice 2. Engineer dabbling in games 3. Professional game designer. For #2, they are more likely to prefer C# as they probably already have experience with it, or otherwise will be familiar with the similar Java language. Also it's a nice resume boost to say you've used C# For #3, I can't imagine the godot language is better for large scale games than any custom language. C# just has way more resources put behind it For #1, I kinda see it. But they would probably be better learning a language with more tutorials available. Or if they're struggling, pygame is probably a better place to start.
- r-w 2y ago
  Godot lets you use whatever language you want. C# included.
  - Supermancho 2y ago
    https://github.com/Godot-Languages-Support/godot-lang-support https://github.com/Godot-Languages-Support/godot-lang-suppor...
    - the_gorilla 2y ago
      I don't use godot and know more about its limitations than its advocates in this thread. Are they being disingenuous? Do they just not know basic information about their own tools?
- steeleduncan 2y ago
  Godot has supported C# for a while now. There is no need to use GDScript
  - vyrotek 2y ago
    Unfortunately Web Export is not supported with C# in Godot 4.X. And probably won't be for a while*. It's the ONLY reason I even bother with GDScript. https://github.com/godotengine/godot/issues/70796#issuecomment-1618006609 https://github.com/godotengine/godot/issues/70796#issuecomme... And despite my best efforts to statically type everything in GDScript, the language is full of holes that lose all the safety.
lairv 2y ago
Isn't pygame closer to SDL or raylib than a game engine ?
- raytopia 2y ago
  Pygame is a wrapper around SDL.
smitec 2y ago
I'd recommend giving Raylib a look if you haven't. I've been working on a couple small ideas using it lately and it feels very aligned to being a game 'engine' for people who come from a more classic software engineering background.
Supermancho 2y ago
> Godot. I hated it. All of the awful heirarchy of OOP, a really poor builtin language, and "signals", which are meant to decrease spaghetti but only increased it for me. Having programmed for over 25 years now, this was my experience. I feel like a little more IDE introspection or tooling to make the signal/listener connections more manageable, is the special sauce that's missing. The event pubsub moel becomes unmanageable to document/control with any non-trivial application. Godot has no encapsulation or tracking support, allowing all modules to hook to any event leads to spaghett, which you learn when working with large projects in various languages (JS et al).
vyrotek 2y ago
I recently learned that the popular game Balatro was made in LÖVE. I had never heard of it until then. But looks interesting. https://love2d.org https://love2d.org
- hvis 2y ago
  Also Moonring. Not as huge as Balatro, but fairly well-known too.
- boredtofears 2y ago
  Loved that I could open up balatros game files and examine the source. Pretty cool how far the author took the framework.
  - sigseg1v 2y ago
    I had similar fun with Don't Starve when I opened up some files in the game directory and noticed they were all Lua, all using an ECS system, and easily extensible. Having never used Lua before, I made a rudimentary multiplayer server for it by opening a socket and sending game events to another instance of the game on another machine. I planned to actually start making it into a multiplayer mod but then they announced Don't Starve Together and I scrapped my implementation for obvious reasons.
- mdaniel 2y ago
  LÖVR (MIT) was posted last week: https://news.ycombinator.com/item?id=41446248 https://news.ycombinator.com/item?id=41446248
panza 2y ago
I'm a commercial dev, previously used Unity, now using Godot. This comment rings true of GD Script and signals. I get around this by using C# and its event handling. Working with nodes and editor bugs (or features? Hard to know really) is probably the most frustrating - you can really feel that this was initially built for 'smaller' projects. For this reason, I rarely use the editor outside of setting up the scenes and a general hierarchy. Daily tools: Emacs (with C# LSP) most of the time. VS Code for debugging. Godot editor for tweaking the scene tree. Perhaps this perspective is useful for other devs thinking about Godot.
- cpeterso 2y ago
  How does Godot performance compare using C# versus GDScript?
  - panza 2y ago
    Not sure. I hear C# is at least as fast if not faster, though there may be situations where GDScript is more performant.
    - kragen 2y ago
      i haven't tried c# with it, but gdscript is slow, comparable to cpython. intuitively i'd expect c# to be an order of magnitude faster
gxd 2y ago
Godot is excellent, and I believe it will be the "Blender of game making" in 5 years or so. Version 4 is ready for prime time and is able to tackle most indie projects. Where Unity beats Godot is in the "Triple I" and "Double A" categories, as it has better 3D/performance features, tooling and add-ons. Neither engine is the best choice for AAA projects. For 2D and simple 3D games, I see no reason to use Unity anymore; I predict a steady decline in Unity's market share as Godot slowly overtakes it.
- yumaikas 2y ago
  In the GMTK game jam, there was a -dramatic- shift usage towards Godot from Unity this year
- ingenieros 2y ago
  > Where Unity beats Godot is in the "Triple I" and "Double A" categories, as it has better 3D/performance features, tooling and add-ons While this is true it does come with a big caveat. Every single AA developer has had access not only to the Unity source code, but in some instances also to Unity employees who became directly embedded in the production cycle. There’s a GDC presentation from the team behind Ori and The Blind Forest where they talk about how some Unity devs were flown to Austria to help out with custom tooling. Playdead also has a really nice blog where they talk about all the changes they had to make to the engine in order to achieve good lighting performance/fps for Inside. https://blog.playdead.com/articles/inside_presentations/inside_publications.html https://blog.playdead.com/articles/inside_presentations/insi... I’m sure that if the Godot foundation had enough resources at hand then you would also see more games like Cuphead and the ones previously mentioned above.
optymizer 2y ago
I gave Godot a good shot. There's reasons not to like it, but IMO GDScript is not it. It's basically python with slot/emit semantics to integrate with the editor, which is actually rather nice, compared to other more complex ways of achieving such integration - via build systems, or some metadata or external configuration files. In Godot it's integrated into the language.
frompdx 2y ago
I disagree that GDScript is a poor builtin language. It is somewhere between Python and JavaScript. It gets the job done and there is a lot you can do with it. Signals are great for things like state management. I'm not really sure what you mean by spaghetti code and how signals are supposed to help. I do agree that there are some annoying OOP aspects like providing a path to a scene (module). It's verbose but not unlike library imports in other languages.
- Buttons840 2y ago
  When using the optional typing in GDScript, I'm surprised at how many errors are caught before runtime. The optional type syntax is nicer than Python's and the auto complete is good. Godot could have built on Python, but they would have had to also include a language server (and maybe ipython or jupyter or something) to get the full seamless experience that GDScript gives. Including all that seems a bit much. So, like you, I appreciate GDScript and have sympathy for why it was created. Also, GDScript hasn't done anything like implicit type coercions (see JavaScript) and so GDScript can improve without breaking backward compatibility. If needed, breaking backwards compatibility in GDScript won't be as bad as breaking backward compatibility in a real programming language, so they can steer it where it needs to go for the benefit of Godot.
  - kragen 2y ago
    early versions of godot were actually python modules; they added gdscript because embedding python was taking too much work
samiv 2y ago
Don't want to be a bother but if had the time I'd love to hear your thoughts on this https://github.com/ensisoft/detonator https://github.com/ensisoft/detonator It's a (2D only) game engine I've been putting together for years and obviously not yet at a level comparable to Godot, maybe more like haxe or lowe2d. The target is simple single player, single developer "weekend" games.
_the_inflator 2y ago
I find libGDX to be highly underrated. For me it hit just the sweet spot between being too low level and too fancy with Entity Component System for everything.
bowsamic 2y ago
I totally agree for Godot. All the worst mistakes of OOP which I thought we got rid of years ago. Bizarre situation
- SteveSmith16384 2y ago
  Godot much prefers composition over inheritance. It's possible to use inheritance in Godot, but no-one recommends it, except maybe for a data structure.
SteveSmith16384 2y ago
I'm not sure why you were using Inheritance in Godot? Just use the "gameobjects" paradigm as you did with Unity.
- IX-103 2y ago
  If you need to customize the behavior of certain interactions (such as modifying physics with a specific type of object), you need to subclass since some behaviors are only available as overrideable functions, not as signals. Also the documentation tends to push this approach.
makotech221 2y ago
Try out Stride3d. Sorta like Unity, but pure c# engine and much better architecture.
hungie 2y ago
I've been a game dev (and services dev) for a two decades and I could not disagree with you regarding Unity and Godot more strongly. Having gotten into Godot with v4, it was a huge breath of fresh air coming from Unity and Unreal (which isn't really hobby friendly). Composition of nodes is quick, easy to compartmentalize, and having signals as an interface makes building them very, very quick. Yes, the debugging story on Godot isn't quite there yet, but I genuinely doubt I'll ever touch Unity again unless I have to for a job.

spoiler 2y ago

> - Bevy (Rust ECS engine), which is nice at first but has a lot of problems with its implementation and can become rather messy. Can you expand a bit about why this was messy or comolicated? I found the paradigm leads to pretty well organised code (sometimes you get the odd large system, but it can be broken down into smaller systems, sub systems or composed out of smaller functions).

pizza234 2y ago
While any design requires discipline, ECS systems have little or no coupling between them, and they very easily end up all over the place; in addition to the chaotic design, one ends up also not having an idea of what happens when. For this reason I agree - developing games using an ECS design requires more discipline to manage complexiy, compared to an imperative one.
- spoiler 2y ago
  I've not had much issues understanding what runs when, because for the most part I didn't need to care that much, and when I did it was possible to order/schedule systems in Bevy. That's even a bit easier nowadays too, since the API improved! With regards to the chaos: I think it can be avoided, but like you said it requires a bit of discipline. I don't feel like it required that much more than normal software engineering (but I'm also the type of person that documents and tests everything even on personal projects lol). The plug-in system makes it easy to help bring order too. This is all through a bevy-tinted lens, since I've done very little game dev (dabbled with UE and Godot) outside of bevy, though!
- p1necone 2y ago
  I agree with this - ECS lets you write totally decoupled, composable bits of game logic very easily, which is super powerful. But in my experience if you're not careful you end up with a hundred perfectly decoupled little things and it's really difficult to remember how they actually all come together to make the whole game you've built. Easily grokable filenames and file structure are very important, and bevy specifically has a pretty nice plugin system which lets you really clearly 100% isolate groups of state/logic into more sensible sections instead of ultimately having some root level game loop that's directly setting up your 100 tiny little poorly named things.
- alice-i-cecile 2y ago
  Yeah, I'm one of Bevy's maintainers, and I've seen folks get tangled up (or overengineer things wildly) if they go in without a clear plan. ECS (and a strong compiler) makes things much easier to refactor, but I generally agree that the more flexible nature demands more discipline.
noelwelsh 2y ago
I started using Bevy for a small game and abandoned it after a little while. There are two issues: 1. The fundamental issue is that the ECS model has independent subsystems communicating via a relational database. This breaks the connection between function callers and callees, makes control flow incredibly hard to trace, and means the type system can give you very little assistance. 2. Bevy also does not leverage Rust's type system in other ways. E.g. you can use resources that you forget to create and it will only crash at runtime instead of giving a compile time error. I think you can create a good game in Bevy, and if you come from a C/C++ world you probably won't notice the lack of type safety. It didn't meet my goals, however.
- CaptainOfCoit 2y ago
  > 2. Bevy also does not leverage Rust's type system in other ways. E.g. you can use resources that you forget to create and it will only crash at runtime instead of giving a compile time error. Would something else even be possible in Rust? My understanding is that you cannot really add type safety in the way of "This should be a i64 and between 32 and 128, otherwise fail to compile", so not sure how it could be addressed by the language. Or taken to the extreme "Fail to compile if the user creates an instance of this but doesn't call function F with that newly created instance"
  - noelwelsh 2y ago
    Let me explain a bit more about "you can use resources that you forget to create and it will only crash at runtime instead of giving a compile time error". Plugins are the main abstraction in Bevy. A plugin has two parts: build and run. Build creates stuff, and run uses stuff created by build and created by the build of other plugins running at the same time. Build is pure side-effects, so the result type of build tells you nothing about what it builds. Therefore there are no types that can constrain what resources run uses, and therefore failing to create a resource that is used in run is a run-time, not compile-time error. The alternative is the build returns a type representing the collection of resources it creates, and run's type is a collection of resources it uses. This requires some type level programming (a type level heterogeneous set). This is some of the simplest type level programming, but type level programming itself is quite foreign to most programmers. I assume this is why the Bevy developers went for the easier to write solution that doesn't enforce constraints at compile-time. More generally, just like in regular programming some things are easier and some are harder to do in common type systems. Your first example (integer constrained to a range) is harder because you need to solve linear inequations at compile-time, which is not a feature of most type systems (though see refined types). You second example (must call a method) is relatively easy with linear types, as they express "must do something with this value".

juliangmp 2y ago

> Godot. I hated it. All of the awful heirarchy of OOP, a really poor builtin language, and "signals", which are meant to decrease spaghetti but only increased it for me. Maybe I was using it wrong? I very rarely use inheritance to the point of being bad at using it. Not game dev either but I do have to say that I find Godot's design to be one of the best oop desings I worked with. I tend to not use oop much today (C++ embedded), though I did learn programming with C# so I'm fairly used to inheritance.

deleted 2y ago
[deleted]

HideousKojima 2y ago

>and "signals", which are meant to decrease spaghetti but only increased it for me. Signals are basically just event subscriptions. In fact, if you use C# with Godot you can actually just use C# native delegates/events.

d13 2y ago
And you don’t need to use signals in Godot at all.

nightowl_games 2y ago

As a professional game dev who has years of experience producing real products in both Unity and Godot, I am totally not with you about your thoughts on Godot vs unity. Godots signals are such a huge step up over Unity's built in classes having a lack of modularity. How do you even make sense of that? Godot vs Unity basically have the same scene/node/component model except Godot does it better imo. Eg) What is the difference between a prefab vs a scene in Unity anyways? Basically nothing, it's just (I'm speculating) a tech debt mistake in their design, probably still going because of how light maps work today. Unity's advantage over Godot is it's 3D renderer, built in physX, il2cpp backend for C#, profiler, general runtime performance and console support. Godots design is objectively more cohesive, as Unity has simply splintered into 10 different design directions since ~2018. I'm not trying to be a hater, I just think signals are a huge advantage for writing modular, simple stuff in Godot. I think there's plenty of great reasons to prefer Unity to Godot but "signals" is not one of em.

seanthemon 2y ago
I think the original commenter just really likes "plug and play" solutions with a lot of hand holding which is what Unity is excellent at. The problems come down the line. Godot is objectively a way way better tool
- monkeydreams 2y ago
  > Godot is objectively a way way better tool If you like things like Godot, Godot is the type of thing you will like. Seriously though, Godot works way better for me using C# than it does with GDScript and the OOP structure means I can refer to classes by their identity.
  - deleted 2y ago
    [deleted]
- bentt 2y ago
  That doesn't make any sense. Unity may have a pedigree of being for beginners, but in recent years they can barely keep current documentation on their new systems. This smells like a comment from someone who has never used it.

NotAnOtter 2y ago

I'm not that familiar with Godot but the built in language always felt like a misstep. Maybe someone more familiar with it can make a defense. I view 3 users 1. Complete Novice 2. Engineer dabbling in games 3. Professional game designer. For #2, they are more likely to prefer C# as they probably already have experience with it, or otherwise will be familiar with the similar Java language. Also it's a nice resume boost to say you've used C# For #3, I can't imagine the godot language is better for large scale games than any custom language. C# just has way more resources put behind it For #1, I kinda see it. But they would probably be better learning a language with more tutorials available. Or if they're struggling, pygame is probably a better place to start.

r-w 2y ago
Godot lets you use whatever language you want. C# included.
- Supermancho 2y ago
  https://github.com/Godot-Languages-Support/godot-lang-support https://github.com/Godot-Languages-Support/godot-lang-suppor...
  - the_gorilla 2y ago
    I don't use godot and know more about its limitations than its advocates in this thread. Are they being disingenuous? Do they just not know basic information about their own tools?
steeleduncan 2y ago
Godot has supported C# for a while now. There is no need to use GDScript
- vyrotek 2y ago
  Unfortunately Web Export is not supported with C# in Godot 4.X. And probably won't be for a while*. It's the ONLY reason I even bother with GDScript. https://github.com/godotengine/godot/issues/70796#issuecomment-1618006609 https://github.com/godotengine/godot/issues/70796#issuecomme... And despite my best efforts to statically type everything in GDScript, the language is full of holes that lose all the safety.

lairv 2y ago

Isn't pygame closer to SDL or raylib than a game engine ?

raytopia 2y ago
Pygame is a wrapper around SDL.

smitec 2y ago

I'd recommend giving Raylib a look if you haven't. I've been working on a couple small ideas using it lately and it feels very aligned to being a game 'engine' for people who come from a more classic software engineering background.

Supermancho 2y ago

> Godot. I hated it. All of the awful heirarchy of OOP, a really poor builtin language, and "signals", which are meant to decrease spaghetti but only increased it for me. Having programmed for over 25 years now, this was my experience. I feel like a little more IDE introspection or tooling to make the signal/listener connections more manageable, is the special sauce that's missing. The event pubsub moel becomes unmanageable to document/control with any non-trivial application. Godot has no encapsulation or tracking support, allowing all modules to hook to any event leads to spaghett, which you learn when working with large projects in various languages (JS et al).

vyrotek 2y ago

I recently learned that the popular game Balatro was made in LÖVE. I had never heard of it until then. But looks interesting. https://love2d.org https://love2d.org

hvis 2y ago
Also Moonring. Not as huge as Balatro, but fairly well-known too.
boredtofears 2y ago
Loved that I could open up balatros game files and examine the source. Pretty cool how far the author took the framework.
- sigseg1v 2y ago
  I had similar fun with Don't Starve when I opened up some files in the game directory and noticed they were all Lua, all using an ECS system, and easily extensible. Having never used Lua before, I made a rudimentary multiplayer server for it by opening a socket and sending game events to another instance of the game on another machine. I planned to actually start making it into a multiplayer mod but then they announced Don't Starve Together and I scrapped my implementation for obvious reasons.
mdaniel 2y ago
LÖVR (MIT) was posted last week: https://news.ycombinator.com/item?id=41446248 https://news.ycombinator.com/item?id=41446248

panza 2y ago

I'm a commercial dev, previously used Unity, now using Godot. This comment rings true of GD Script and signals. I get around this by using C# and its event handling. Working with nodes and editor bugs (or features? Hard to know really) is probably the most frustrating - you can really feel that this was initially built for 'smaller' projects. For this reason, I rarely use the editor outside of setting up the scenes and a general hierarchy. Daily tools: Emacs (with C# LSP) most of the time. VS Code for debugging. Godot editor for tweaking the scene tree. Perhaps this perspective is useful for other devs thinking about Godot.

cpeterso 2y ago
How does Godot performance compare using C# versus GDScript?
- panza 2y ago
  Not sure. I hear C# is at least as fast if not faster, though there may be situations where GDScript is more performant.
  - kragen 2y ago
    i haven't tried c# with it, but gdscript is slow, comparable to cpython. intuitively i'd expect c# to be an order of magnitude faster

gxd 2y ago

Godot is excellent, and I believe it will be the "Blender of game making" in 5 years or so. Version 4 is ready for prime time and is able to tackle most indie projects. Where Unity beats Godot is in the "Triple I" and "Double A" categories, as it has better 3D/performance features, tooling and add-ons. Neither engine is the best choice for AAA projects. For 2D and simple 3D games, I see no reason to use Unity anymore; I predict a steady decline in Unity's market share as Godot slowly overtakes it.

yumaikas 2y ago
In the GMTK game jam, there was a -dramatic- shift usage towards Godot from Unity this year
ingenieros 2y ago
> Where Unity beats Godot is in the "Triple I" and "Double A" categories, as it has better 3D/performance features, tooling and add-ons While this is true it does come with a big caveat. Every single AA developer has had access not only to the Unity source code, but in some instances also to Unity employees who became directly embedded in the production cycle. There’s a GDC presentation from the team behind Ori and The Blind Forest where they talk about how some Unity devs were flown to Austria to help out with custom tooling. Playdead also has a really nice blog where they talk about all the changes they had to make to the engine in order to achieve good lighting performance/fps for Inside. https://blog.playdead.com/articles/inside_presentations/inside_publications.html https://blog.playdead.com/articles/inside_presentations/insi... I’m sure that if the Godot foundation had enough resources at hand then you would also see more games like Cuphead and the ones previously mentioned above.

optymizer 2y ago

I gave Godot a good shot. There's reasons not to like it, but IMO GDScript is not it. It's basically python with slot/emit semantics to integrate with the editor, which is actually rather nice, compared to other more complex ways of achieving such integration - via build systems, or some metadata or external configuration files. In Godot it's integrated into the language.

frompdx 2y ago

I disagree that GDScript is a poor builtin language. It is somewhere between Python and JavaScript. It gets the job done and there is a lot you can do with it. Signals are great for things like state management. I'm not really sure what you mean by spaghetti code and how signals are supposed to help. I do agree that there are some annoying OOP aspects like providing a path to a scene (module). It's verbose but not unlike library imports in other languages.

Buttons840 2y ago
When using the optional typing in GDScript, I'm surprised at how many errors are caught before runtime. The optional type syntax is nicer than Python's and the auto complete is good. Godot could have built on Python, but they would have had to also include a language server (and maybe ipython or jupyter or something) to get the full seamless experience that GDScript gives. Including all that seems a bit much. So, like you, I appreciate GDScript and have sympathy for why it was created. Also, GDScript hasn't done anything like implicit type coercions (see JavaScript) and so GDScript can improve without breaking backward compatibility. If needed, breaking backwards compatibility in GDScript won't be as bad as breaking backward compatibility in a real programming language, so they can steer it where it needs to go for the benefit of Godot.
- kragen 2y ago
  early versions of godot were actually python modules; they added gdscript because embedding python was taking too much work

samiv 2y ago

Don't want to be a bother but if had the time I'd love to hear your thoughts on this https://github.com/ensisoft/detonator https://github.com/ensisoft/detonator It's a (2D only) game engine I've been putting together for years and obviously not yet at a level comparable to Godot, maybe more like haxe or lowe2d. The target is simple single player, single developer "weekend" games.

_the_inflator 2y ago

I find libGDX to be highly underrated. For me it hit just the sweet spot between being too low level and too fancy with Entity Component System for everything.

bowsamic 2y ago

I totally agree for Godot. All the worst mistakes of OOP which I thought we got rid of years ago. Bizarre situation

SteveSmith16384 2y ago
Godot much prefers composition over inheritance. It's possible to use inheritance in Godot, but no-one recommends it, except maybe for a data structure.

SteveSmith16384 2y ago

I'm not sure why you were using Inheritance in Godot? Just use the "gameobjects" paradigm as you did with Unity.

IX-103 2y ago
If you need to customize the behavior of certain interactions (such as modifying physics with a specific type of object), you need to subclass since some behaviors are only available as overrideable functions, not as signals. Also the documentation tends to push this approach.

makotech221 2y ago

Try out Stride3d. Sorta like Unity, but pure c# engine and much better architecture.

hungie 2y ago

I've been a game dev (and services dev) for a two decades and I could not disagree with you regarding Unity and Godot more strongly. Having gotten into Godot with v4, it was a huge breath of fresh air coming from Unity and Unreal (which isn't really hobby friendly). Composition of nodes is quick, easy to compartmentalize, and having signals as an interface makes building them very, very quick. Yes, the debugging story on Godot isn't quite there yet, but I genuinely doubt I'll ever touch Unity again unless I have to for a job.