Spatial partitioning for Pooling

After spending many hours debugging my old spatial partitioning scheme, I decided it was too clever for its own good. I had been attempting to keep objects sorted in x order, so as to decide when to activate / deactivate pooled objects. However the problem is that objects have varying widths, which makes things more complex, I was needing a sorted x list for both minimum and maximum x values, which was difficult to debug in gdscript.

So I decided to try out the old faithful grid partitioning scheme, although simply in 1 dimension for this game. As objects are activated and deactivated they are removed and inserted into the grid. Searching for new ones to activate then becomes simply iterating through a small range of the grid.

There is still a little bit of tweaking to be done, especially for wide objects like platforms. These might be 'missed' for activation as their centre may be in a grid square off the screen. There are two obvious workarounds for this - I can extend the range checked further (which will entail a little unneeded extra processing for the narrow objects), or I can place the wide static objects into more than one gridsquare. But this is quite easy to fix.

Monsters

There are now 4 different monsters (might be enemy spaceships, don't know yet). They will have their own behaviour. I'm just reusing some models from my frogger game for now. They tend to more get in the way of your progress at the moment rather than attack you!

Tractor Beam

My first step to allowing you to interact with the environment is the tractor beam, which you can activate by pressing space. It was actually really simple to implement.

In Godot I made an 'Area' underneath the player, and in the area you can give it modified physics when switched on. So I simply changed gravity inside the tractor beam.

There are various other improvements too, to the UI and sound etc.

Physics

Almost by accident the physics features have turned out very cool. You can pick up boxes etc and unblock / block routes, which I might use as part of the gameplay. The enemies do tend to get in the way physics wise too, which I'm not sure yet whether is good or bad.

There are a couple of snags with the physics too. One is that sometimes you can get stuck. This is a common problem with physics. I'll probably do something like leave a trail of breadcrumbs behind you, and if it detects you getting stuck, reverts to one of the previous positions.

The other problem is more a game / level design issue. It is quite possible to get into situations where boxes are blocking off your way through the level. I can either have some complicated logic in the level generator (I'm planning on auto generating levels), or I can have some way to remove them, such as shooting them or have the tractor beam work sideways.