The previous devlog left us having just gained the ability to draw one isometric-sorted moving object - the player - in the game world, and some rudimentary test controls.

ENTITIES

Adding controller based movement was easy; adding further objects proved to be a bit of a can of worms. Having more than one entity active threw up a few problems with how the update loop was structured, but the biggest issue was clipping entity bobs that were partially off-screen.

CLIPPING

In previous games I had avoided bob clipping by various means, but none of those tricks would fly here, unfortunately.

Fortunately, though, this game doesn't need a full 4-directional pixel clip. Only one edge in the horizontal or vertical direction will ever need clipped, and pixels clipped at the right hand edge will be hidden by the scroll anyway. Vertical clipping is straightforward. Left-clipping, not so much.

Left-clipping usually requires running the blitter in descending/reverse mode so the clipped pixels are shifted off the left hand side, but the change in direction needs a recalculation of a number of values which I'd rather avoid. I pulled a trick though and kept the blitter running in it's normal ascending mode.

The blitter shift is set so the clipped pixels are all in the first 16px column, ie: the first visible pixel is the first pixel of the second column, and then the first word mask is set to mask off the clipped pixels. The blit is calculated as normal except the pointers are set to one word left of the visible screen. This setup writes to memory outside the target screen lines, but the masking means these out of bounds writes actually don't change any bits! It's a little hacky, but should be safe, and kept the clipping routines fairly simple.

There's a little optimisation to be done in these routines yet but they'll do for now.

PHYSICS

With multiple entities now drawing, it was time for interaction! The game will need some block pushing and stacking, moving platforms, lifts, conveyors and probably a few other bits and pieces, so a basic physics engine is required. This is not Chaos Physics, or even Box2D ... it may be a box of chaotic physics though.

Collisons with fixed blocks and the room boundaries were easily implemented.

For movable objects, the core idea is if an object hits another, we try to move the second one as well so it no longer collides, and then recursively check if the second's new position would impact further objects. So if the player pushes an object any number of other objects could be moved in the same direction. If any object cannot move to its new position, it pushes back and the movement back along the recursion chain is appropriately limited or blocked altogether.

Moving objects also check if they have another object on top of them and, if so, moves it by the same vector. This transferred movement naturally applies if a player jumps on top of a moving block giving us moving platforms for free. Again, this recurses so a stack of objects can move as one. Or an object can be dropped on a moving platform and then move along with it.

Gravity is applied to objects too, so one can be pushed off the top of another in a stack and it will fall to the ground. In fact, the player is constantly failing to fall through the fixed blocks that make up the floor.

The recursion depth and/or mass being moved could be tracked if I wanted to cap what the player was capable of moving, or scale the movement speed accordingly, but I'm not sure that's necessary.

This video shows some of the basic interactions, as well as the bob clipping in action.

Physics and Bob Clipping

It's not a bad start, and wasn't actually as complicated to implement as I expected it to be. I looked at some videos of Head Over Heels on the Spectrum Next and I think my physics implementation can do everything I saw there at least. I imagine a realistic physics engine is a bit more work though.

NEXT TIME

Platforms and lifts aren't fully implemented yet, and I haven't looked at conveyors at all. Conveyors are interactive objects that don't move or change shape, so they lie in between fixed blocks and entities as far as the engine is concerned. I'm not sure which approach is best for this class of object ... my spidey sense says to treat them as fixed blocks with special flags attached though. Ropes are down the line (ha!) for physics too, and that's a little scary. We don't talk about the water rooms. I'll need to figure out how to add all these objects via the editor too.

The video shows there's still some glitching in the isometric sorting to address. Sorting is not sorted yet.

Sorting is not sorted yetSorting is not sorted yet

There is a problem with how the floor is set up too. The floor blocks are solid from, say, Z=0 to Z=8, and the player walks on top of the Z=8 plane. However, given that blocks must fit into a fixed grid, this means that any blocks that should be at floor level will actually have the first 8 units of their height embedded in the floor, which will be awkward later.

In this image, the orange, green and cyan blocks are all the same height, but the lowest green and cyan blocks are embedded in the floor rather than sitting on it as the player and orange block are.

The Floor Is L...owerThe Floor Is L...ower

I will need to rework the room building so the floor is a layer of blocks all to itself, like the walls are, making the floor level Z=16 so blocks like the green and cyan ones can sit on top of it as intended.

And then, I'm sure there will be something else.

Related Links