doc/concepts

   1 General
   2 =======
   3
   4 The World is made from 1m³ locks, divided into chunks of 16x16x16 for
   5 convenience. Players can place and remove block at will (currently).
   6
   7 There's no global light source. All lighting comes from light emitting blocks.
   8
   9 Equally, there's no global gravity, though some blocks can emit force fields.
  10
  11 The void is able transport sound for some reason.
  12
  13 It's also inhabited by yet unnamed entities which, for the moment, stand or
  14 float around. If they see a player, they start chasing it until they're near
  15 enough and run away again if they get too close.
  16
  17 World Generation
  18 ----------------
  19
  20 As of now, the world has at generation time the following properties
  21 distributed to make up "biomes": solidity, humidity, temperature, richness.
  22 Solidity determines how dense the material is at any given point. Below a
  23 certian solidity, there's no matter at all (or rather "air"). The exact point
  24 is given by the loaded block type definitions.
  25 Humidity, temperature and richness are intended to create some variety.
  26 There's also a random factor that decides which of the qualified block types
  27 is actually placed.
  28
  29
  30 Initialization
  31 ==============
  32
  33 Runtime::Initialize
  34  - arguments are interpreted
  35  - if asset or save paths are empty, they're set to defaults, which are
  36    SDL base path + assets/ and SDL pref path, repsectively (except when
  37    NDEBUG is undefined, in which case default save path is SDL base path
  38    + saves/)
  39  - if save path/prefs.conf exists, its values are read, otherwise it is
  40    created and populated with baked defaults
  41  - arguments are interpreted again so they can override pref values
  42
  43 Runtime::Execute
  44  - if mode is error, exit with failure
  45  - init headless part (basic SDL and net)
  46  - remaining steps depend on runtime mode
  47
  48 Standalone
  49 ----------
  50
  51 Runtime::RunStandalone
  52  - init the remaining components (video, image, TTF, GL)
  53  - create environment (loader, counter, controller, RNG, assets, audio, viewport, keymap)
  54  - load or create world save
  55  - create application and load up master state
  56
  57 standalone::MasterState
  58  - load world resources (shapes, block types, models, sounds, textures)
  59  - load player from world save if available
  60  - push preloader
  61
  62 standalone::PreloadState
  63  - load or generate a bunch of chunks every frame until all are in memory
  64  - generate VAOs for chunks in visible range (independent of view angle)
  65
  66 Server
  67 ------
  68
  69 Runtime::RunServer
  70  - create headless environment (loader, counter, controller, RNG)
  71  - load or create world save
  72  - create headless application and load up server state
  73
  74 server::ServerState
  75  - bind server socket
  76  - load world resources (shapes, block types, models)
  77
  78 Client
  79 ------
  80
  81 Runtime::RunClient
  82  - init the remaining components (video, image, TTF, GL)
  83  - create environment (loader, counter, controller, RNG, assets, audio, viewport, keymap)
  84  - create application and load up master state
  85
  86 client::MasterState
  87  - send login to server, wait for response
  88  - if anything other than a join comes back (or nothing at all), display message and exit
  89  - create interactive state and pass control
  90
  91 client::InteractiveState
  92  - create cache (which is just a stripped world save) if is doesn't exist already
  93  - load resources (shapes, block types, models, sounds, textures)
  94
  95
  96 Game Loop
  97 =========
  98
  99 This is roughly divided in server and client responsibilities both of which,
 100 except for network transmission, are also handled by the standalone state.
 101
 102 The general structure is like this:
 103  - handle input
 104  - update simulation (see World Update below)
 105  - load or generate chunks if any (servers only)
 106  - generate and push output
 107
 108 For interactive runtimes, input can come from devices like mouse, keyboards, etc.
 109 Networked runtimes can receive input from packets.
 110
 111 The simulation is updated based on the time that passed since the last update.
 112 Networked runtimes divide the physics part of the simulation in fixed steps of
 113 16ms so client prediction has a chance to make good estimates.
 114
 115 Output for interactive runtimes is usually audio+video. Networked runtimes also
 116 output packets to synchronize with connected remotes.
 117
 118 World update
 119 ------------
 120
 121  - spawner (servers only)
 122  - physics simulation
 123  - for each entity update:
 124   - transform caches
 125   - controller (input for players and AI for others)
 126   - model (animation state)
 127  - rebase player chunk indices
 128  - remove dead entities