B3DV Information

Each world is saved as a folder with a `chunks` folder, the actual chunk data; and a world.txt file, containing data like last played timestamp and player position

The world isn't just an array/grid of blocks, but it is divided into manageable chunks.
It is an infinite 3D grid, but split into small boxes, that are loaded and unloaded dynamically.
Only the chunk that the player is in, and the adjacent ones are 'loaded' (meaning loaded into memory, so effectively, actually relevant) and are unloaded once the player is far enough from them.
This is crucial and is what allows infinite worlds in finite systems, just like in Minecraft for instance.

The player has several properties:
- Physics:
Position relative to player's head's X Y Z coords;
Velocity how fast the player is moving;
Gravity: 35 m/s^2;
Jumping: apply upward force
Collision: The player is actually a cilinder, (radius 0.35, height 1.9mts) so they interact (collide) with blocks
- Features:
Flight mode: can fly (no gravity) (enabled with `/fly enable`)
No-clip (no collision) mode: stops interacting with blocks, enabled with `/noclip enable` (especially useful when combined with flight)
Block selection: The player struct has a selected block field, as of now it can only be changed with /select
Sneaking: the player can "sneak" or move slowly and not go down blocks
Sprinting: the player can sprint or move faster than normal walking

The whole shtick:
I've use many optimization techniques to bring the FPS above 30:
Distance culling, a.k.a. a limited render distance
Frustum culling: Only render blocks that are in front of the player, based on FOV; at the block level and chunk level (entire chunks can get skipped before individual blocks)
Back-pane culling: Don't draw back faces of blocks (back face meaning faces that the player can't see anyways)
Occlusion culling, a.k.a. don't draw blocks that are obscured from view anyways
and raycasing is used to see which block the player is going to break/place

Think of the menu system as a state machine with different screens:
- Main menu: the start screen, buttons for entering a world, creating a new one, quit, and credits. Displays a backround picture (ranomized from .png files inside ./assets/mainmenubackground/*.png) and a randomized splash text
- World select screen
- World create screen
- Settings: set FPS limit and render distance, modifying options.txt
And the gameplay, (when there's no menu) and credits screen which is merely text display
The 'menu' is localized (translated to 11*) and the settings are persistent.

The game uses direct input for gameplay, Raylib takes care of that. Yeah that's it.

The main loop which runs every frame, goes from line 200 to 1480, contains the game logic, as the following sequence, roughly:
- Handle input:
└─ Read keyboard & mouse -> update camera angle and process block placement/destruction
- Update player physics
└─ Apply gravity to player, handle jumping/flying, check collisions with blocks, update the player's position
- Update world
└─ Load chunks near the player, unload chunks far from the player, generate terrain for new chunks if needed
- Render
└─ Calculate which chunks to render,
     └─ Calculate which blocks to render
          └─ Calculate which faces to render
               └─ render those, with their respective texture; if the player is pointing at it, highlight it with a wireframe
& draw hud and crosshair on top