Hello, @zenith391!
Right now I develop plugins for (real) Minecraft servers, and your project could be a huge source of knowledge about the architecture of server cores and their internals. However, don't take it personally, your code is an unreadable spaghetti mess.
Fixing this should not be very hard, since you've only just started working, but it will make your open-source project much simpler for others to understand and participate in, not mentioning that it will make it much simpler for you in the first place.
If you want to do it, here is a shortlist of what, in my opinion, would be cool to accomplish:
-
Well-organized code, divided into modules with specific tasks
Proper organization is what your code lacks in the first place. For example, implementing chunk generation in the main launcher (mc.lua) was not a bright idea for sure - and this not the only example! Think of dividing code into 3-4 modules (Noise generator, chunks handlers, etc.) with a single purpose - it will make code easier to maintain and understand
-
Code comments
The title explains itself - provide comments for "delicate" places, where you use not-so-straightforward hacks or utilize some complex syntax, that can't be understood at the first glance.
-
Documentation
Documentation should explain your design choices - why have you decided to use bridge software? What concerns have you encountered and how you have dealt with them or plan to deal with?
Optionally, it would be very cool to explain the basics of the system you are working at - how packets are formed, how a world is loaded, how NBT data is formatted, etc. But if you are too lazy or busy to do it, at least provide links to your information sources - sites, other projects, wikis - just anything that helps you and could help others to understand your project as well
-
Milestones
If would be nice for everyone visiting your repo to see how much have you done and how much you are planning to do in the future.
Just collect all that you have done so far, make sure it works relatively stable and call it "Alpha v0.1", for example. And before starting working on v0.2, make a shortlist of features you are aiming to implement and issues to resolve.
It will not only show everyone what you've implemented and help you structure your work, but also show potential contributors where you'd be glad to use their help
Hello, @zenith391!
Right now I develop plugins for (real) Minecraft servers, and your project could be a huge source of knowledge about the architecture of server cores and their internals. However, don't take it personally, your code is an unreadable spaghetti mess.
Fixing this should not be very hard, since you've only just started working, but it will make your open-source project much simpler for others to understand and participate in, not mentioning that it will make it much simpler for you in the first place.
If you want to do it, here is a shortlist of what, in my opinion, would be cool to accomplish:
Well-organized code, divided into modules with specific tasks
Proper organization is what your code lacks in the first place. For example, implementing chunk generation in the main launcher (mc.lua) was not a bright idea for sure - and this not the only example! Think of dividing code into 3-4 modules (Noise generator, chunks handlers, etc.) with a single purpose - it will make code easier to maintain and understand
Code comments
The title explains itself - provide comments for "delicate" places, where you use not-so-straightforward hacks or utilize some complex syntax, that can't be understood at the first glance.
Documentation
Documentation should explain your design choices - why have you decided to use bridge software? What concerns have you encountered and how you have dealt with them or plan to deal with?
Optionally, it would be very cool to explain the basics of the system you are working at - how packets are formed, how a world is loaded, how NBT data is formatted, etc. But if you are too lazy or busy to do it, at least provide links to your information sources - sites, other projects, wikis - just anything that helps you and could help others to understand your project as well
Milestones
If would be nice for everyone visiting your repo to see how much have you done and how much you are planning to do in the future.
Just collect all that you have done so far, make sure it works relatively stable and call it "Alpha v0.1", for example. And before starting working on v0.2, make a shortlist of features you are aiming to implement and issues to resolve.
It will not only show everyone what you've implemented and help you structure your work, but also show potential contributors where you'd be glad to use their help