Reimplement Minecraft Java and implement Minecraft PE protocol with luaJIT

[yangm97]

Today I was chatting with @Mathias on Matrix/IRC about the current Minecraft situation and I had the following idea: what if protocol code used lua? 
I have been playing with GroupButler, a lua telegram bot, and learning about openresty and non-blocking i/o libraries, like pgmoon.

The funny thing its, most of these libraries are written in lua, and since openresty uses luaJIT, there are situations where lua code outperforms C code: https://www.cryptobells.com/resty-core-t...the-jit-y/

Ok, so that could work on cuberite too, right? right??? ?

Reimplementing Minecraft Java protocol in lua should make it straight forward to support multiple (all?) protocol versions without problems that sometimes occur currently when cuberite is updated to support a newer protocol. Although this issue is not related to C++, decoupling game logic from protocol is what would fix that. Bonus: making forge mods or other protocol changing plugins would be as easy as building a Cuberite plugin. ? 
For Java, LuaSocket TCP should be enough.

Minecraft PE on the other hand can be implemented in a number of ways: using this guy’s lua code https://github.com/pabloko/Lua-JIT-RakNet, using actual C++ raknet code and creating lua bindings, reimplementing raknet purely in luaJIT, etc.
For the protocol, our friends at MiNET have us covered: “As part of the project, I also deliver an up-to-date automatically generated MCPE Protocol Specification.” 

Bonus: Cuberite would become a “generic voxel game server”, meaning it could allow for crossplaying not only minecraft java and pe but also minetest and whatever comes next.

Yeah, I know. Currently protocol and logic and tightly coupled so I would suggest doing this in the following order:

• Implement Pocket Edition protocol, by creating lua bindings and de-coupling protocol code as needed;
  
• Reimplement Java Edition protocol, probably more difficult to do than PE, since Java has more features et al.
  

Both may be done on master, just need to have the option to turn on/off these features somewhere.

So, what do you guys think? Doable or suicidal?

[ShadowCone]

There is just one thing: what remains, if you split everything minecraft related to lua? And: the problem about different protocols at the same time. How do you handle them? How do you handle server side computation? Etc etc etc

[yangm97]

The goal would be to do the least modification possible. For instance, cuberite continues to generate worlds and calculate projectiles the way it does now, the difference would be it now exposes those events to luaJIT, which would then “translate” and send these events.
This way, multiple luaJIT vms, light threads or whatever can run simultaneously, serving different protocols, without affecting each other.

Another example: Protocol1_8.lua has a table whitelisting which blocks it “knows” about, any other block_id gets converted to, let’s say 1, before sending the update to the client that is connected to this protocol.

Yeah, there needs to be some kind of routing code so each client gets the right treatment. I think ProtocolSupport (spigot) has implemented something like that.

[xoft]

I think this is suicidal at least

In my opinion it's easier and a lot less work to implement protocol support directly in C++. The networking stuff is already relatively standalone in Cuberite - just look how easily the new protocols were added - usually within days of the Vanilla release (remember 1.1, which took us more than a month?). I can see no advantage in having yet another layer exported into plugins, not to mention that it would need proper isolation from regular plugin logic, we'd basically have two kinds of plugins - protocol and regular ones. The maintenance cost would be huge, and the protocol implementation would be much more difficult in Lua, because of the Lua-to-C++ layer having some limitations (mainly threading).

[yangm97]

So, loading raknet C++ library and listening on the PE UDP port should be the way to go?

[xoft]

I have a feeling that reimplementing the protocol parsing would be easier than including raknet, it seems like a library that is rather difficult to set up on many architectures.

[yangm97]

Kind unfortunate the main raknet project is “dead”. There seem to be a number of open PR regarding building etc, some forks are said to have merged them but nothing “official”.

Besides the building issue, is there anything else wrong with raknet? And how do you determine which is the best way?

[xoft]

Looking at the unmerged PRs in their main repo, I'd say it's quite "undercooked" - there are PRs that fix basic stability issues (buffer overflows, resource leaks).