Comment by danbolt
11 days ago
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.
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.
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.
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
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.
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.
2 replies →
Are there any Godot FAQs or documentation with "blessed" paths for the various mainstay gamedev needs?!
2 replies →
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.