Regarding organisation of blueprints

[kerguestenen]

Hi everyone, first question in this forum, I hope I’m not making a too much dumb question!

So, I’m making a puzzle game, where I’ll have to create a path with the help of cubes for a cat to climb and reach a paper-box, to be able to go to the next level.

Those coloured cubes have weight, resistance to fall and a max load weight.
There will be teleport, platforms and doors to open with triggers (triggers on the floor, also coloured, activated when putting a same-coloured cube on them)

For now I’m having all the behaviours running well for moves, fall, stack/parenting and teleportation.

My doubt is about organising it all.

For now I have all my logic in the cubes BP.
For example, when leaving a place, I check from where the cube is going, and if it goes out of another cube, I update all the stack that it’s leaving. If it goes out of a teleport, I check if the next move (using ASTAR pathfinding here) is also a paired teleport and teleport, etc.
Same for arriving to a new tile: is it a cube? Am I falling? etc.

Now that it’s all done and working is a good time to stop, think, and decide if I shouldn’t redo everything to split the mechanisms (being ironic here, I was dumb enough to not think about that sooner…)
If the cube arrives on a teleport and will be teleported, I could send a message to the teleport and leave it makes the teleportation process).

(Note: everything is child of a parent class for my astar system.)

I was thinking I could implement interface perhaps, and send message from my active cube to the places it leaves and arrives, that kind of things…

Sorry, enough for now as it’s getting long and I am conscious it’s not the most appealing subject!

Could I get some opinions about this? As it is working, should I just continue, or perhaps not because it is working but because there is no advantages splitting the mechanisms in different places, or all the way around, should I stop now and take care of splitting each “thing” in it’s relative BP?

Sorry, my English as it appears clearly is not good, I hope it was understandable…!
thanks for whoever read all that, and thanks twice for whoever find time to answer my doubts!

Cheers,
François.

[Hyaniner]

With things that you said, I think there are limits to what other people can know about the state of your code. I think we need more sharing of information, for example, screenshots of your Blueprint.

If you are asking about the proper timing for refactoring, at first, search about it. Maybe there is something like “if the same thing repeats three times…” Blueprint is also programming. So there is some proper timing, but it would be difficult to say when it is proper, with high precision.

[Sebastianaff (Sebastianâff)]

With things that you said, I think there are limits to what other people can know about the state of your code. I think we need more sharing of information, for example, screenshots of your Blueprint.

[kerguestenen]

Thanks for you answer!

Here is a simple example of one of my functions inside my BP_BaseMovingCube, which do specific things depending on which type of tile my cube arrives on.

I’m doing all the logic afterwards in this function, calling other function if needed (like, will the cube under this one will be destroyed? Then I call another function to destroy, then in that one I send the top cube to fall after the below one being destroyed).

But I’m also doing stuff here if the cube arrives on a teleporter or a static tile, and I was wondering if I shouldn’t just send a message to the teleporter BP and leave him do its logic there. etc.

Sorry if this didn’t help

[Hyaniner]

In my case, my criteria for deciding whether to refactor or clean up my code are:

• Will my future self look at this code and get angry because of the irrationality of the logic or the difficulty of reading it?

My future self tends to get angry at my past self very easily(I have some difficulty working with him by this reason. Sigh…) , so I worry about the same things as you quite often. Sometimes that worry is very helpful, but other times it doesn’t help at all or can actually make additional problem. There is also a saying that says fast optimization is bad. Yes. it is really bad, and In many cases, it is not necessary.

The problem is that who I am now is not who I will be in the future. So I tend to leave the code alone for very short periods of time. After that, I look at it again and decide whether I want to clean it up or not.

I think your code is pretty clean.

I hope this helps.

[kerguestenen]

Thanks a lot, that seems a good advice!

[Hyaniner]

If you think the thing I wrote is a good answer enough, you can select what I wrote as an answer and make this thread solved