Getting Started

• Client flow
  • Game states
  • Network
  • HUD and GUI
• Server flow

The goal of this page is to quickly explain what is the global structure of the engine.

Client flow

The main class for the client is ClientApplication.

It inherits from gk::CoreApplication which will handle the game loop. This class initializes SDL and the gk::ArgumentParser and handles the gk::ApplicationStateStack.

Game states

Everything is handled by gk::ApplicationStateStack and gk::CoreApplication.

gk::ApplicationStateStack will hold a stack of gk::ApplicationState. For example, the main state, GameState, inherits from gk::ApplicationState.

gk::CoreApplication will handle the gk::ApplicationStateStack, and run gk::ApplicationState::update() and gk::ApplicationState::draw() from the top state each main loop turn. Also, it will send all the SDL events to gk::ApplicationState::onEvent().

Therefore, the top gk::ApplicationState in the stack will be the only one able to receive input from the player and to be displayed.

The current states:

• GameState: main state of the client, where all game-related stuff happens
• InterfaceState: base class for every 2D state
• PauseMenuState: pause (esc key) menu
• SettingsMenuState: "Options..." menu
• TitleScreenState: title screen
• ServerConnectState: where you enter the server address
• ServerLoadingState: displays a loading screen until Registry is received from server and TextureAtlas is initialized with it
• ChatState: chat history and input box
• LuaGUIState: where the magic happens for the GUI received from server (inventory, creative menu, workbench, furnace)

Network

The two main classes for the network in the client are Client and ClientCommandHandler.

Client is the class that will hold the sockets, retrieve all packets, and be able to connect to/disconnect from a server. It has a Client::setCommandCallback function, which allows setting a callback for a specific type of packet.

ClientCommandHandler will register a callback in Client for most types of packets, and will also provide helper functions to send packets.

Both of those classes are handled by GameState.

HUD and GUI

The HUD has basically its own class HUD, which is handled by GameState. This class manages:

• Hotbar: current player's hotbar
• BlockCursor: box displayed on the currently selected block
• Crosshair: cross in the middle of the screen
• DebugOverlay: debug infos that appear when you press F3
• BlockInfoWidget: Waila-like box that displays the name and the icon of the item you're currently looking at
• Chat: chat history
• and the FPS counter, which will probably get added to DebugOverlay soon

The GUI client-side is handled by their related state (see Game states). The server-sent GUIs are handled by LuaGUIState, which will turn the received data into actual GUI elements. Most of those GUI elements inherits from Widget.

For example, all those classes inherit from Widget:

• TextButton: clickable text button
• ProgressBarWidget: progress bar that is currently used for the furnace
• ItemWidget: item icon (uses either gk::Image or InventoryCube)
• InventoryWidget: inventory from a player/block/temporary inventory
• CraftingWidget: arbitrary-sized crafting table, can use the inventory from a block or from a temporary inventory

Server flow

The main class for the server is ServerApplication. This class manages the Registry, the Server, the ServerWorld and the ScriptEngine.

Registry is the class that manages blocks/items/biomes data. It is sent to the clients on connection.

Server (and ServerCommandHandler) are the classes that handles packets and clients. (See Network for more information, client architecture is really similar on that point)

ServerWorld is, obviously, the world. This class is responsible for storing chunks and generating them.

ScriptEngine is the class the manages Lua and binds C++ classes for usage in mods. Note that three other classes also handles Lua: LuaCore, LuaGUI and LuaMod.