The problem is neither composition nor inheritance. Is in the number of classes. The more classes you add the more complex the communication graph between them becomes. Whereas with adding more code into the same file/class - you just add more code, without increasing architectural complexity. And that complexity is where the nasty oo version of spaghettization happens, not in long linear passages of code.
3 Likes
IsGoingUp is set in HandleJump, but who calls that and when? You see how due to entangled architecture we needed to jump around the calls, wasting mental effort, but still don’t have the complete picture of the execution flow.
3 Likes
The problem is neither composition nor inheritance. Is in the number of classes. The more classes you add the more complex the communication graph between them becomes. Whereas with adding more code into the same file/class - you just add more code, without increasing architectural complexity. And that complexity is where the nasty oo version of spaghettization happens, not in long linear passages of code.
You are right, but every type of architecture is going to have advantages and drawbacks. I don’t want to sound like I’m completely rejecting your ideas, but I just feel like you are portraying components as worse than they are.
But I have to admit I don’t really know how would I use it in context of much more advanced game. In the thing I’m working on right now the combat is extremely basic and almost non-existent to be honest. If I would want to add real combat, some special attacks, it could become really messy. Assuming it couldn’t be handled by 2-3 big components.
IsGoingUp is set in HandleJump, but who calls that and when? You see how due to entangled architecture we needed to jump around the calls, wasting mental effort, but still don’t have the complete picture of the execution flow.
IsGoingUp exists for the sake of communicating with other components. For example for the corner correction mechanic I need to know if player is going up. It will also be useful in context of animations.
And the entire issue seems to be related to the fact that the player going upwards time is so short, that this variable has no time to be set. Which as I said probably won’t actually happen in reality, but I’m curious if it can be bypassed.
Yeah, simply changing the order of operations won’t solve this. When jumping, before MoveAndSlide() !body.IsOnFloor results in false, and afterwards the ceiling got already hit and Velocity.Y will be 0 (so, even if CorrectCorner() would change the position, the character would still drop down).
It would require at least two MoveAndSlide() calls before hitting the ceiling. Then there would be a moment where IsGoingUp would be true.
1 Like
Are we tracing the bug or discussing the finer points of architectures?
I don’t really care about paradigms or ideas. I only care about simplicity, performance and resistance to bugs. I’ll pick any approach that I estimate will cause least friction, given the problem. I’m telling you that you’ve broken your program into too many too small fragments. This makes it hard to mentally follow what is happening. And mentally following is the main thing we need to do when chasing bugs.
1 Like
Yeah this is what I’ve been thinking. There is probably some way to fix it, but if it requires some trickery, it’s probably not worth it. Since when you design a level I don’t see the reason why would you place any tiles basically at the head of the player (I did that during randomly placing tiles in the dev room). Meaning that this is a problem, but this problem will never appear in reality.
Or just calling test_move()
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.