Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Big Rewrite #208

Open
Hopson97 opened this issue Oct 8, 2020 · 1 comment
Open

Big Rewrite #208

Hopson97 opened this issue Oct 8, 2020 · 1 comment

Comments

@Hopson97
Copy link
Owner

Hopson97 commented Oct 8, 2020

It has been a very long time since I have touched this project. At some point in the future, I will likely be scraping a lot of the code (As I am not happy with it, and it's generally pretty bloated).

Just making an issue for the sake of discussion.

Changes I would like to make in the future rewrite:

  • Being more open to using libraries (Eg, rather than writing my own GUI system I can use something else eg ImGui), This should be within reasons though, eg I would rather use OpenGL than an existing render engine as IMO its just more fun that way, plus the code can generally tailor to a "voxel" world rather than having a more general renderer.

  • Don't make classes for the sake of classes, eg having a separate class for the window was pretty pointless

  • Don't preoptimize, quite a lot of my decisions were dictated by the fact that there may be some impact on performance, but I doubt they would've now that I actually think about it.

  • Integrate Lua from the start if possible, I think I added Lua scripting about 2 months into development which meant it felt like an afterthought rather than a primary part of the project.

  • Don't use Sol2 but stick to raw Lua, as it unfortunately really harmed compile times due the amount of template metaprogramming present in the library.

  • Make building easier. Eg, rather than having extra steps to link to the client/server/common directories, just have relative paths and a single compile target

  • Use CLion (This is mostly for me). This way I can ensure it works from the start, as CLion support was very common problem.

@untodesu
Copy link

untodesu commented Oct 11, 2020

I would like to recommend you to use Source Engine styled network architecture for some better multiplayer gameplay experience because I haven't seen this split so client was sending actual commands to the server. In Source Engine style client will just send input commands to the server, and the server will compute everything, then send the snapshot of the world state to the client. Client also can predict server behaviour to reduce lag feelings...
EDIT: However it would be inefficient to send chunk deltas, so I suggest to use delta compression only for entities (eg. players, mobs, etc.) and send chunk updates as usual...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants