Comment by danbolt

Comment by danbolt 11 days ago

12 replies

View on Hacker News

I think the paragraph after is really interesting:

“Also when creating things with nodes, you have to go back and forth between node GUI and code.”

You can see Godot’s Node/GDScript setup as a bit of a response to this argument. Or, they try to make the “going back and forth” as seamless and integrated possible with things like the $ operator and autocomplete.

That said, I do think at the end of day, the “thing is a thing” mindset ultimately prevails, as you have to ship a game.

notnaut 11 days ago

I’ve been trying to learn godot for years and I’m not doing so hot. This chatter feels very relevant to my struggles but I’m not the best with software design, so what do I know? I was in a tizzy the other day and spammed my thoughts out about it, I hope it’s relevant here.

trying to wrap my head around using scenes vs. nodes in something simple like a 2d platformer.

Platforms:

My thinking: I'm gonna be using a ton of platforms, so it'd make sense to abstract the nodes that make up a platform to a scene, so I can easily instance in a bunch.

Maybe I'm already jumping the gun here? Maybe having a ton of an object (set of nodes) doesn't instantly mean it'd be better off as a scene?

Still, scenes seem instinctually like a good idea because it lets me easily instance in copies, but it becomes obvious fast that you lose flexibility.

So I make a scene, add a staticbody, sprite, and collision shape. I adjust the collision shape to match the image. Ideally at this point, I could just easily resize the parent static body object to make the platform whatever size I want. This would in theory properly resize the sprite and collision shape.

But I am aware it's not a good/supported idea to scale a collision shape indirectly, but to instead directly change its extents or size. So you have to do stuff based on the fact that this thing is not actually just a thing, but several things.

This seems like a bad idea, but maybe one way I could use scenes for platforms is to add them to my level scene and make each one have editable children. Problem with this is I'd need to make every shape resource unique, and I have to do it every time I add a platform. This same problem will occur if I try duplicating sets of nodes (not scenes) that represent platforms, too. Need to make each shape unique. That said, this is easier than using scenes + editable children.

Ultimately the ‘right’ way forward seems to be tilemaps, but I wanted to understand this from a principles perspective. The simple, intuitive thing (to me) does not seem possible.

When I ask questions about this kind of stuff, 9/10 times the suggestion is to do it in a paradigmatic way that one might only learn after spending a lot of time with an engine or asking the specific question, rather than what I would think is a way that makes dumb sense.

Reply View 10 replies
  • Tanoc 10 days ago

    I'm used to the old old school way of doing things, meaning you write shit in a text editor and then run it. There's no parenting system, no hierarchies, no inheritances, no massive trees of various classes/subclasses that you have to manage. Godot goes beyond friction and actively pisses me off because what should just be ten seconds of writing in a new text document turns into up to sometimes two or three minutes of interacting with the GUI because you have to create a new project, save it, make a scene node, create an object node, create a sub-object node, create an action node, create a container node, then you can start editing code, but only once you link whatever it is to that specific object instead of it being a general script you can re-use, because re-using it means making copies of the parent object and-- It's too complicated.

    A lot of 2D game engines are near frictionless because they're just "write and save" style simple, and Blender Game Engine was actually great about translating this to a UI, and more importantly a UI dealing with 3D since every object in the viewport could just have it's own little code block attached to it just by clicking it. It was no different in function than saving the .py file in a new folder, really. This method Unity "pioneered" of everything having to be part of a giant tree in the asset manager is such a slog and makes keeping track of anything during iteration a nightmare. I still prototype in BGE sometimes because every other 3D engine sprawls too quickly and has so many unnecessary steps.

    If somebody could just write a text-only "write and save" style editor like LOVE2D but for 3D (and support it for longer than two months) that would be amazing.

    Reply View 0 replies
  • 392 9 days ago

    I think you and I are at the same point in Godot progress. I have chosen to do everything in one scene and leave the code where I first put it when experimenting. It's my project, I'll find the code when I need to change it. Lots of crazy overabstraction on YouTube tutorials by people who are not software engineers but who think obfuscating working code makes them so. Let's sadly look away from why our industry gives them the impression that that's a good idea. I will finally have to learn separate Scenes when I give up on one level with teleports and shift to loading, which may be never.

    I watch clickbait Godot tutorials on YouTube on 2x speed in my spare time. When I stumble into a problem that I suspect has been solved before, like your resizeable platform problem, I go to YouTube and see if I can find a reference. For your case, I think you're looking to create a Tool, maybe. You'd need to define your platform as a programmaticly sized node using either tile maps or that texture thing that lets you define the corners, the fill texture, and size from there.

    But if it were me I'd lift the code for the platform out of the node that sizes it. Then you can just hand edit each platform, and link the platform to the controlling node (or whatever relation you see fit to use).

    It's important to focus on the game over the infinite ways you could structure code in an environment of such high flexibility. At least coding your game with bitmaps in C you can't get lost in trifles, you'll just spend more time reimplementing and understanding the basics. See raylib.

    Reply View 0 replies
  • bowsamic 11 days ago

    Honestly this is the kinda stuff that put me off Godot. A million ways to do things and they all seem bad or feel like they’re going to shoot me in the foot later. Somehow I never had these issues in Unity

    Reply View 7 replies
    • danbolt 11 days ago

      I think every developer finds footgun issues with various tools for their aims. Or, I know developers that express similar sentiments towards Unity (or Unreal, proprietary engines, etc.).

      When a game team is successful, it can often stem from having picked tooling and workflows that enabled them to be productive enough and avoid enough pitfalls. That’s going to change from project to project and team to team.

      Reply View 0 replies
    • notnaut 10 days ago

      Man maybe I should have started with unity but I’m such a fucking hipster I just never go with the popular thing. Ultimately happy I don’t have to worry about the licensing BS and I still get to claim hipsterdom, but it’s clashing with my desire to work in ways that make sense to my poo brain.

      Reply View 2 replies
      • hnuser123456 10 days ago

        I feel your frustration about spending years trying to understand the right way to use an arcane system. I don't know if this is the kind of response you were hoping for, but I urge you to just pick one method and try to develop past it, see how far you can get, see if it holds you back, if you needed to generalize better. Just brute force a couple approaches at random until you find one that lets you get shit done, so you can get to a working demo that has 1 semi-complete level/stage, no matter how hacky. Working on other things besides the difficult abstract one might lead you to useful answers or better ways of (re-)implementing features, and nothing will motivate you to find a system that works more than having a working demo that you know proves your concept, but also knowing the code is shit and ripe for refactoring.

        Reply View 1 reply
        • notnaut 9 days ago

          I appreciate your response! This is basically how I have managed to finish small games in the past. Only issue is much of my intention on finishing those small projects was to find the 'right' way forward, when that clearly isn't an effective way of thinking about it.

          I think my best bet is to apply the same mentality you're describing to larger projects, like you're saying. As long as I don't get too sloppy, refactoring will be a necessary effort when I actually hit issues that stall my progress.

          Reply View 0 replies
    • dingdingdang 10 days ago

      Are there any Godot FAQs or documentation with "blessed" paths for the various mainstay gamedev needs?!

      Reply View 2 replies
      • notnaut 8 days ago

        This conversation got me looking into the Godoy asset library, where I found a number of examples that wound up being very helpful. There are a few 2d platformer examples made by the Godoy team that emphasize just how many options there are (and for good reason). The ‘thing is a thing’ mentality that comes with learning OOP (or at least the way I have been learning) is probably a good one to get past, because indeed there is are many reasons to do one thing different ways based on the little differences between implementations of said thing.

        So the project I just looked at had 3 types of platforms that I could tell:

        The level was made up primarily of a tile map. It had its own collision set in the resource per tile and represents the most copy-cut type platforms you’re likely to see

        Then there was a static body tile, which had a polygon2d shape, used to create an irregular platform that would have been more painful (maybe near impossible) to make in the tile map.

        Finally, there were two moving platforms that were instances in as scenes.

        So the big revelation for me today is that I need to not get hung up on doing any one conceptual thing anyone one way. Any (seemingly minor) difference in fundamentals about what that thing is or does may lead to another basic node type being the best thing to use. I need to not be afraid of making use of more varied tools, even if things feel like they should be all just be the same simple thing in the head.

        Reply View 0 replies
      • danbolt 8 days ago

        Parent’s call methods on their children, while children use signals to communicate with parent nodes.

        Reply View 0 replies
whoknowsidont 11 days ago

The problem is "a thing is a thing" only gets you those exact things with those exact thing-behaviors.

Sharing behaviors or making things look or act like a little bit like this other thing becomes an absolute nightmare, if not out right impossible, with "a thing is a thing."

There's a reason graph based systems or ECS is basically the corner stone of every modern engine. Because it works and is necessary.

Reply View 0 replies