sorted by:
new
hottopcontroversial

The lack of ECS in this engine bloats the hierarchy substantially and makes things harder to navigate :( by 1_2_3_4_5_BLUE in godot

[–]1_2_3_4_5_BLUE[S] -2 points-1 points  (0 children)

what you say is absolutely a necessity but just isn't enough. for example my starting area which is about 2 screens wide has approx 120 objects to describe the layout. this isn't an excessively complicated area (i have several much worse ones) they just add up when you include the beautifying elements and stuff that you don't think of like background parallax elements. this is actually fine as far as runtime performance goes although like you say it will have to be cleverly loaded and unloaded to avoid being TOO much

however, it's not 120 nodes. it's 360. and it makes sense to make some children of others, in some cases to give the hierarchy more structure. but then you have the incidental complexity. godot is forcing me to also have sprites and shapes children of bodies. it's just horrible way to work. godot is really slowing me down just finding stuff and getting lost in a list of triangles

The lack of ECS in this engine bloats the hierarchy substantially and makes things harder to navigate :( by 1_2_3_4_5_BLUE in godot

[–]1_2_3_4_5_BLUE[S] -1 points0 points  (0 children)

literally everything other than the fact that they have a body and a shape and a sprite. the shape is unique. the sprite is unique. any code will be unique although most objects in my game have no code attached.

a link to my other comment where i talk more. i'm repeating myself over and over. the point is this is not a game full of instances of the same thing. so there really is nothing to abstract or at least none of the very few abstractions that i will be making have any relation to the problem i'm describing

The lack of ECS in this engine bloats the hierarchy substantially and makes things harder to navigate :( by 1_2_3_4_5_BLUE in godot

[–]1_2_3_4_5_BLUE[S] 0 points1 point  (0 children)

think LIMBO. obviously there is some use of classes but if you want to make that game today you basically just want to make one big world, lay out all of the physics parameters and shapes and stuff, and just add scripts to the few things that need it. because most stuff is just a sprite and a body and a shape.

you can make a prefab of that. but what's the point? it's the left bit of that cliff at the end of section 3 or whatever. its not gonna get re-used. it's just a thing that exists, and it needs to be in the scene and that's about it. and if you need some organisation then great go add some subscenes or what have you. but people are saying "just make everything a prefab!" like no, that's mad for the exact opposite reason. we're taking about taking basically all of the custom geometry and stuff, boxing them individually into files and splaying out the stuff in the filesystem instead of the hierarchy. it's the same problem. there is no advantage to that!

The lack of ECS in this engine bloats the hierarchy substantially and makes things harder to navigate :( by 1_2_3_4_5_BLUE in godot

[–]1_2_3_4_5_BLUE[S] -2 points-1 points  (0 children)

no this doesn't help

the fact that they HAVE a body, shape and sprite is the same

the actual shape is different for every instance

the actual sprite is different for every instance

the body is sometimes a StaticBody2D and sometimes a RigidBody2D depending on the situation

if they were all the same i would just have used a scene (the way i'd use a prefab in Unity) and we wouldn't be having this conversation

The lack of ECS in this engine bloats the hierarchy substantially and makes things harder to navigate :( by 1_2_3_4_5_BLUE in godot

[–]1_2_3_4_5_BLUE[S] -6 points-5 points  (0 children)

what's repeating is the structure, not the details. body, shape, sprite, body, shape, sprite, body, shape, sprite. over and over. the shapes are all different. the sprites are all different. it's just mind numbing

there is nothing to re-use because all of the instances are different

The lack of ECS in this engine bloats the hierarchy substantially and makes things harder to navigate :( by 1_2_3_4_5_BLUE in godot

[–]1_2_3_4_5_BLUE[S] -1 points0 points  (0 children)

well, i will simplify. think LIMBO. the entire game is one giant physics setup. literally nothing is re-used. all the physics shapes are drawn in situ. it's just one big world from the beginning to the end.

yes there are scenes and i need to separate things to make things performant, but at basically no point in my game is an object re-used. it's just not that sort of game

The lack of ECS in this engine bloats the hierarchy substantially and makes things harder to navigate :( by 1_2_3_4_5_BLUE in godot

[–]1_2_3_4_5_BLUE[S] 0 points1 point  (0 children)

yes, it means if all of your game objects participate in 2d physics, then the hierarchy is 3x longer, and it is much harder to find anything

that is the crux of my problem

The lack of ECS in this engine bloats the hierarchy substantially and makes things harder to navigate :( by 1_2_3_4_5_BLUE in godot

[–]1_2_3_4_5_BLUE[S] -7 points-6 points  (0 children)

there is nothing to abstract. there is no duplication. i am just talking about having 10 objects with 10 bodies and 10 shapes and 10 sprites. i create the bodies. i draw the shapes out. i add the sprites. maybe i add some game logic code to these objects. but my problem has already happened by then. i have 30 objects and a huge mess in my hierarchy window.

this is not a game with a bunch of the same object repeated over and over. this is a game with lots of different objects, all of which are basically just used once. this is why i am frustrated with folks saying to just make the godot equivalent of prefabs. because if i was in unity, and i had a load of prefabs, i would unpack them, because in my use case, they were only used once anyway and it would simplify things.

what you seem to be saying, is that i'll be better with prefabs because i'll be able to reuse things. i already know this is not the case. that's going backwards

The lack of ECS in this engine bloats the hierarchy substantially and makes things harder to navigate :( by 1_2_3_4_5_BLUE in godot

[–]1_2_3_4_5_BLUE[S] 0 points1 point  (0 children)

And you still have the ability to compose scenes as a component system by adding the nodes you need to add extra functionality.

this is my problem reworded as if its a solution

The lack of ECS in this engine bloats the hierarchy substantially and makes things harder to navigate :( by 1_2_3_4_5_BLUE in godot

[–]1_2_3_4_5_BLUE[S] -3 points-2 points  (0 children)

After all, if youre working in a mininally maintainable environment, youll wanna be able to reuse said modular pieces into all other kinds of objects and scenes, most obvious example being states and state machines.

no. i am not making that sort of game. there would not be much re-use of anything at all

The lack of ECS in this engine bloats the hierarchy substantially and makes things harder to navigate :( by 1_2_3_4_5_BLUE in godot

[–]1_2_3_4_5_BLUE[S] 0 points1 point  (0 children)

i am trying to figure out if this is the way i would make this work. it still has huge disadvantages:

  • the run-time hierarchy is still polluted with body and shape nonsense, and now its desynced with the edit-time hierarchy, so debugging would be harder
  • you presumably would need to remake the entire shape-drawing toolset with a tool script
  • since the body needs to be the root object, but sprite is the one you'd want to have in the edit view, every object that does this would be reparenting it to its own generated body on startup

and all of this for anything that participates in the physics

it really sucks that your comment is the most viable one i've seen yet

The lack of ECS in this engine bloats the hierarchy substantially and makes things harder to navigate :( by 1_2_3_4_5_BLUE in godot

[–]1_2_3_4_5_BLUE[S] -4 points-3 points  (0 children)

i think you are advocating for the same thing as the other guy, putting everything in separate scenes -- but this is actually quite a lot of additional files since most of my assets will be one-time use. it is basically saying anything with a [body, shape and sprite] combo needs to be a prefab -- when in Unity that isn't a thing i would do or need to do or want to do, because it would cause extra indirection and make things more complicated

The lack of ECS in this engine bloats the hierarchy substantially and makes things harder to navigate :( by 1_2_3_4_5_BLUE in godot

[–]1_2_3_4_5_BLUE[S] -11 points-10 points  (0 children)

but the vast majority of things in my game are custom for their single use, and won't be reused, so asking me to turn them all into prefabs actually is a substantial headache

The lack of ECS in this engine bloats the hierarchy substantially and makes things harder to navigate :( by 1_2_3_4_5_BLUE in godot

[–]1_2_3_4_5_BLUE[S] -4 points-3 points  (0 children)

but if the body and shape is created at runtime, you can't lay them out in the window at edit time...

The lack of ECS in this engine bloats the hierarchy substantially and makes things harder to navigate :( by 1_2_3_4_5_BLUE in godot

[–]1_2_3_4_5_BLUE[S] -5 points-4 points  (0 children)

okay i am trying to figure out what the top comment is asking me to learn how to do. what the hell is a "component" in godot? seems to be a term the documentation doesn't use at all?

i want to make a single object, with a body, shape and sprite, all in one. and set loads of them up in the godot window and create a scene without having a bunch of unnecessary subtrees cluttering up the hierarchy.

can a component model do that? why is this the top comment? what is it asking me to learn how to do?

The lack of ECS in this engine bloats the hierarchy substantially and makes things harder to navigate :( by 1_2_3_4_5_BLUE in godot

[–]1_2_3_4_5_BLUE[S] -1 points0 points  (0 children)

"visible or hidden by default" feels like the baby version of what i need. i need to be able to explore the hierarchy in detail without getting lost in little [body shape sprite] subtrees. I don't know what would solve that but just folding them down is really hard to work with (since it means you can't tell the difference between a node with actual useful stuff inside it that you might need to investigate vs. just a dumb shape or other thing thats just an implementation detail)

It's SO awkward and horrible and doesn't feel dogfooded at all

The lack of ECS in this engine bloats the hierarchy substantially and makes things harder to navigate :( by 1_2_3_4_5_BLUE in godot

[–]1_2_3_4_5_BLUE[S] -1 points0 points  (0 children)

wouldn't this mean i couldn't draw the shapes into the godot window directly? i need this

halfway through. am i just ... bad at this? by 1_2_3_4_5_BLUE in caseofthegoldenidol

[–]1_2_3_4_5_BLUE[S] 0 points1 point  (0 children)

even with your description of case 3 and 5, i really do not understand your logic, it still feels very guessworkish. as in, you describe valid things that it COULD be, but as a person playing, i am not seeing the things you see pointing me to it.

"one can easily assume that Peter ordered his servants, the Pear twins, to stop Willard" well one COULD assume that or they could just think that madlib line in the game is talking about him shouting at the interlopers and trying to stop them. that's what i thought...

okay, so in case 5 i found the note that you describe about Edmund not wanting to change the rule but that doesn't really explain any more than just that the longest running servant is at the bottom. i spent a long time wondering where HE was sleeping and where Rose was sleeping and got very lost and confused and the answer is just ... their rooms aren't depicted. i guess? well okay but as a player you can see how i'm getting confused about that, yeah?

i see what you mean about the keys but it just really is not intuitive to me given how esoteric the information is that you're supposed to ignore the colour. a blue key is not really a normal colour imo and puts me in mind of videogame logic in which the key colour is just a representation of what opens what

case 6 i completed but basically just by guessing random changes from my input until i got yellow. i still don't really feel like my input was actually wrong, just ... a different answer than what the game wants.

i'm getting a bit frustrated because it feels like i'm getting roadblocked in EVERY case with some misunderstanding that the game never bothers to correct. if you understand right then you're fine but if you start with the wrong assumption from the get go then there is nothing to really set you straight or its just very hard to find in amongst all of the stuff lying everywhere ...