Week 50: key-keyhole game mechanics

This week I started working on object collection and the key-keyhole game mechanics. I decided to go for an easy implementation, where the key is pulled towards a docking point that moves with the player. A more physically accurate implementation would involve the player sending out information about where the docking point is (at the speed of light) and the key receiving this information and reacting to it. Such an implementation would respect causality, meaning that the key would move based on the information that it can physically have. Instead, the current implementation doesn’t do this and is not invariant under Lorentz transformations. This may cause glitches if the same dynamics is observed from a moving reference frame.

Well, I’ll come back to this... if I have to. For now, I want to prototype some initial game levels and see how that goes. I am exploring things at this stage. There’s no point to make it all perfect.

I attach a video that gives an idea of what I currently have.

I also spent a considerable amount of time improving the game infrastructure, especially from Lua. You can call it “invisible work”, as it doesn’t yet have a visible impact now, but will allow the game development to scale and ultimately succeed. For example, I added an option to track how much memory Lua uses (by temporarily disabling its Garbage Collection) and get an idea of how much garbage it is creating. I also started making the Lua API more memory friendly. For example, I added functions that return the coordinates of a point rather than a new table of coordinates. These changes led to a 30% reduction in the rate of garbage creation in Lua. This is all useful, as I plan on using Lua to implement quite a bit of game logic.