6 ms·

IIRC the Godot IDE is also made using Godot.

nox101 3y ago
that is arguably not a plus. Game engines usually have very different needs then editing tools. a simple example is maybe the ability to undo. Good tools are designed around editing whereas game engines are designed around performance. The two are often in conflict. It's quite often that tools based around an engine are inflexable and engines based around tools are slow. Effectively they should argusblybe built separately with the tool designed to make editing easy and flexible and extensible and then have it generate/bake optimal data for the performabt but l ss flexible engine A concrete example might be the difference between Photoshop and textures in a game. go watch almost any texture artist and they'll have 89 layers in Photoshop but it will all get baked down into just An rgba texture. Photoshop needs to support those layers, layer masks, compositing modes, blend options. The game just needs in rgba8unorm texture. note:I shouldn't have to say this but because some pedantic person will take issue with this example. I get it's an imperfect example. The point is tools and game engines have different needs. The point is not the specific examole of layers. Another example might be that Photoshop virtualizes storage since it was designed to edit gigiabyte images on machines with 4-8 meg of ram. Game engines, even if a few can stream large images, they are generally not dessigned to edit them
- bzzzt 3y ago
  > The point is tools and game engines have different needs. Game engines need to offer sometimes quite complex graphical user interfaces too. Think of menu, windowing systems, dialog boxes and a compositor style approach to drawing them. If you're going that far you might as well build your editor in it.
  - johnnyanmac 3y ago
    Once upon a time, yes. I wonder how much the popularization of "minimalism" came from design trends, how much from the lack of time to refine UI for games, and how much due to the lack of tooling in modern engines to easily translate complex designs mocks into the game?
  - nercury 3y ago
    Right, imagine a company where the team decides to use Macromedia Flash for game UI only because they need to deliver something working on the next sprint. And then everyone gets stuck with that decision for more than a decade.
    - Ekaros 3y ago
      Might not end up too badly... Reminds me of certain "poor" "indie" company with some rather profitable products... But that might be despite that choice.
- nercury 3y ago
  Say, you use the same foundation for both the game and tool. Nothing prevents you from building features on top that are optimized either for a tool or for a game! Plus you dogfood the system all the time.
  - nox101 3y ago
    That's not my experience. It's about momentum. They are vastly different things with vastly different needs. A game needs data in an optimal form, a tool needs data in a flexible form. Those 2 things are in conflict. So game tools based on engines usually suck because they are designed inside the engine's data structures, which don't match the needs of the tools. Yes, in some imaginary ideal world it would work but it never does in actuality.
- PeterisP 3y ago
  I get that tools and game engines have different needs, however, arguably the benefits of better testing/dogfooding the practical usability of multiple parts of your engine are simply more important than whatever cost/time/effort savings you'd get on that editor app by picking some more suitable external tool.

that is arguably not a plus. Game engines usually have very different needs then editing tools. a simple example is maybe the ability to undo. Good tools are designed around editing whereas game engines are designed around performance. The two are often in conflict. It's quite often that tools based around an engine are inflexable and engines based around tools are slow. Effectively they should argusblybe built separately with the tool designed to make editing easy and flexible and extensible and then have it generate/bake optimal data for the performabt but l ss flexible engine A concrete example might be the difference between Photoshop and textures in a game. go watch almost any texture artist and they'll have 89 layers in Photoshop but it will all get baked down into just An rgba texture. Photoshop needs to support those layers, layer masks, compositing modes, blend options. The game just needs in rgba8unorm texture. note:I shouldn't have to say this but because some pedantic person will take issue with this example. I get it's an imperfect example. The point is tools and game engines have different needs. The point is not the specific examole of layers. Another example might be that Photoshop virtualizes storage since it was designed to edit gigiabyte images on machines with 4-8 meg of ram. Game engines, even if a few can stream large images, they are generally not dessigned to edit them

bzzzt 3y ago
> The point is tools and game engines have different needs. Game engines need to offer sometimes quite complex graphical user interfaces too. Think of menu, windowing systems, dialog boxes and a compositor style approach to drawing them. If you're going that far you might as well build your editor in it.
- johnnyanmac 3y ago
  Once upon a time, yes. I wonder how much the popularization of "minimalism" came from design trends, how much from the lack of time to refine UI for games, and how much due to the lack of tooling in modern engines to easily translate complex designs mocks into the game?
- nercury 3y ago
  Right, imagine a company where the team decides to use Macromedia Flash for game UI only because they need to deliver something working on the next sprint. And then everyone gets stuck with that decision for more than a decade.
  - Ekaros 3y ago
    Might not end up too badly... Reminds me of certain "poor" "indie" company with some rather profitable products... But that might be despite that choice.
nercury 3y ago
Say, you use the same foundation for both the game and tool. Nothing prevents you from building features on top that are optimized either for a tool or for a game! Plus you dogfood the system all the time.
- nox101 3y ago
  That's not my experience. It's about momentum. They are vastly different things with vastly different needs. A game needs data in an optimal form, a tool needs data in a flexible form. Those 2 things are in conflict. So game tools based on engines usually suck because they are designed inside the engine's data structures, which don't match the needs of the tools. Yes, in some imaginary ideal world it would work but it never does in actuality.
PeterisP 3y ago
I get that tools and game engines have different needs, however, arguably the benefits of better testing/dogfooding the practical usability of multiple parts of your engine are simply more important than whatever cost/time/effort savings you'd get on that editor app by picking some more suitable external tool.