game-engine-2d VS lc64

I don't think it's unpopular. We need more and better game software, what exists today is unsatisfactory for a plethora of reasons. I'm personally interested in this because I ship Planimeter Game Engine 2D, which comes with client-side prediction standard, and it's the largest pure-Lua game engine on GitHub.[1]

[1]: https://github.com/Planimeter/game-engine-2d

> Another benefit of speculative collision is that I can elminate[sic] the polygon skin/radius on collision shapes. That was necessary to keep shapes separated for the time of impact algorithm. This should no longer be necessary in version 3.0. I never liked this artificial separation of shapes.

Hah! In Planimeter Game Engine 2D, we shrink physics objects by approximating the polygon skin so that we can achieve "pixel approximate" physics.[1]

[1]: https://github.com/Planimeter/game-engine-2d/blob/master/eng...

From what I've found maintaining https://github.com/Planimeter/game-engine-2d is that you should be explicitly checking for nil, separately from checking for false-evaluating values.

We found that this had the added benefit of semantically checking for something that did not exist, versus some contextual "false" value.

I suspect this is a good practice in other languages as well.

Maybe consider https://github.com/Planimeter/game-engine-2d? We have multiplayer with client-side prediction out of the box. Example code is included to demonstrate the ease of networking entity fields, and there is an included payload abstraction for creating networked events.

You can set the tick rate for your game based on your needs as well. And prediction is robust, supporting exceptional packet loss and smoothing over latency concerns for player movement.

Examples in Lua/LOVE:

https://github.com/Planimeter/grid-sdk/blob/master/engine/sh...

https://github.com/Planimeter/grid-sdk/blob/master/engine/sh...

https://github.com/Planimeter/grid-sdk/blob/master/engine/sh...

https://github.com/Planimeter/grid-sdk/blob/master/engine/se...

I remember having to write something similar for Lua, because there was no math.approximately() function and I was dealing with networking floats and comparing values over the wire to predicted movement in 2D space.

https://github.com/Planimeter/grid-sdk/blob/master/engine/sh...

What’s so great about ASN.1 and it’s encoding rules is that anyone writing type-length-value serialization for networking purposes, for example[1], is basically independently reinventing ASN.1 because it’s so fundamentally optimal.

It truly will make you wonder why Protobufs and others exist.

[1]: https://github.com/Planimeter/grid-sdk/blob/master/engine/sh...

I did it the other way around. I made one in MoonScript for LuaJIT, with about the same (lack of) features, but then got bored and a bit overwhelmed and used the code to make an NES emulator instead. NES was much more fun to implement.