Sometimes it helps to step back and step away for a while. It can be tempting to keep at it, to just keep pushing. Work ethic… Just push through… But sometimes, giving yourself a break, even for a while, can give your brain a chance to work in the background.

I started out this morning playing around with Godot areas, looking to see how I could determine the bounds for a collision. The player can move items around, but it’s important they not be able to move them just anywhere. In particular, we don’t want the pieces to leave whatever is the main area for a level. I also want to have a puzzle mechanic where components can be limited to certain parts of the level or forced to move along certain paths. It’s not something I have worried about so far (apart from overlapping components) because I just don’t do goofy things. But ultimately, players will probably be trying just about anything, and it won’t be considered goofy at all.

My plan was to check for overlapping areas as the component moves. If the component being dragged impacts a boundary or otherwise solid area, it should not be allowed to pass through. This something that is normally handled in Godot with physics, but I’m not using physics. I would need to determine how a component can move and keep it from moving where it’s not supposed to. I even set up a new unit test to begin working it through.

Then I went out in the garden and did some other work, including building a planter box (really a planter “U” since it butts up against a brick wall).

Later, when pondering things a bit more, I realized that my approach has some issues. It would only really work if the player doesn’t move a component too quickly. If they do, they could – in theory – manage to get a component through a wall and to the other side without having a collision be detected. Not likely, but possible. And if you get enough people hitting something, the possible happens.

What came to me instead is the thought that as I’m moving a component, I have its old position and new one. If I can do a raycast, I can see if there is anything between those two positions. And then go from there to force the component to not pass through if there is. It’s more about travel than instantaneous position.

This caused me to shift gears, especially since the raycast functions are supposed to happen during the “process physics” phase. This means I’ll probably need to capture the mouse position, remember it for the next physics phase, and then have that code update the component as it can. At least that’s the theory.

Unless some more ideas occur to me between now and then. Maybe I’ll run into a wall. Then I’d have to see the best way to proceed, to get around it. Maybe I can just go over.

Day 25: Avoiding acting too soon.