Comment by notnaut
Comment by 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.
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.