Discussion: Big client refactor about open-builder HOT 2 OPEN

Hey @Unarelith

Apologies I did not reply sooner, I been looking into many ways I can do this and I realise now that you are absolutely right!

Organizing game code into a game state system is something I typically did before, but throwing Lua into the mix really confused me here, and instead I went with this weird route that game states don't exist, and the game is always there but inactive. This was pretty horrible way to do things.

Looking back at your comment here now, I now understand that's exactly what I want,, as it enables the organisation of different stages of the game, while also being more flexible with what can be done.

For example, before if I wanted to have an animated GUI (eg, Minecraft the main menu sort of rotates around a world), then I would have to awkwardly fit it in between the game logic code, which is bad for obvious reasons.

The reasons I didn't do it before is because I was way too inclined on making as much as possible done from the Lua, which led to a code spagetti soup. Instead, I should be sticking with what I know, and delegate only very specific things to the Lua code, as after all this is a game and not a game engine.

What I am thinking is having the GUIs still defined in the Lua, but don't allow to have an ability to change the game state (or whatever I was doing before). Instead, I could have a GUI defined as a root menu, and make the game switch to that from the "C++ side" when switching to a game state etc etc

But yeah thanks so much for making me realise good ways to do things! 😄

from open-builder.

Ok, I see your issue here. I'll try to explain how it works in OpenMiner to give you ideas.

Basically, your Client class is divided among multiple things.

First, the state stack:

• gk::ApplicationStateStack handles the game states (Title screen, game, pause menu, chat, etc..)
• gk::ApplicationState, main class for all the game states, it's an abstract class that has:
  • A constructor to init the parent
  • A virtual function onEvent() for OS events (mouse moved, key press, etc..)
  • A pure virtual function update()
  • A virtual function draw()

This allows to split the code for the different states of the game.

Next, you're interested about what is in GameState.

Basically, three main classes:

• Client which handles the socket
• ClientCommandHandler which handles the packets received and is also able to send packet
• ClientWorld, which contains the chunks and is responsible for rendering them.

GameState also handles the shader used for 3D rendering, the camera and the HUD class (which will render the hotbar, fps counter and debug info).

It's also responsible for PlayerBox drawing (basically the other players model).

If you have any questions, just ask. :)

EDIT: Just noticed about the chest opening.

Basically in OpenMiner it works like this:

• User right-click on a block
• Client send BlockActivated packet to server
• Server execute the Lua function associated to this block
• In the Lua function (for a workbench or a furnace), a GUI is created and sent to the client
• The client receives the GUI info and display it

from open-builder.