Difference between revisions of "Engine/NMPR"

From Minetest Developer Wiki
Jump to navigation Jump to search
Line 1: Line 1:
 
[[Category:Core]]
 
[[Category:Core]]
−
[[File:minetest-0.3-dfd-visio.png|500px|thumb|right|0.3 data flow diagram - still mostly accurate.]]
+
== The base (NMPR) ==
−
== General architecture ==
+
Everything is built on a small core, that was the original network multiplayer release of Minetest (call it NMPR; the 2010-10-24 version). Being around 10000 lines of code, it contains:
 +
* The '''Map''': Voxel storage + lighting + rendering
 +
* The '''Client''' + '''Server''' logic
 +
* The '''Environment''': Contains the map and the players, handles the simulation of the world
 +
* The '''main loop''': Invokes the client, the server, the environment and the rendering.
 +
* A bunch of wrappers for OS-dependent things, and utilities.
  
−
Minetest always runs as a server and zero or more clients connected to it.
+
As the current code still largely bases on the NMPR, it is useful to look at how it works.
  
−
== Functions ==
+
=== Map (the voxels) ===
 +
[[File:minetest_voxel_storage.png|400px|thumb|right|Minetest Voxel Storage]]
 +
* The main content of the Map is a <code>map<v2s16, MapSector*></code> container.
 +
* The main content of a MapSector is <code>map<s16, MapBlock*></code>.
 +
* The main content of a MapBlock is a linear array of 16x16x16 MapNodes.
  
−
=== main() ===
+
These form a relatively performant storage of voxel data. In addition to these containers, the latest fetched MapBlock is cached in each MapSector, and the last fetched MapSector is cached in Map, resulting in very useful sequential access speed through the whole abstraction layer.
−
main.cpp
 
  
−
When Minetest starts, main() comes up from main.cpp. It handles all the command-line arguments (server and client) and launches and processes the results of the main menu (client).
+
=== Network protocol ===
 +
The high-level network protocol of NMPR is delightfully simple. There are four commands for the server, and four commands for the client. Since this, a lot has been added and changed, but the basic idea stays the same.
  
−
=== dedicated_server_loop() ===
+
==== Client -> Server ====
−
server.{h,cpp}
+
{| class="wikitable"
 +
|TOSERVER_GETBLOCK
 +
|v3s16 p
 +
|Ask the server to send the data of a block
 +
|-
 +
|TOSERVER_ADDNODE
 +
|v3s16 p, MapNode node
 +
|Inform the server of a placed node
 +
|-
 +
|TOSERVER_REMOVENODE
 +
|v3s16 p, MapNode node
 +
|Inform the server of a removed node
 +
|-
 +
|TOSERVER_PLAYERPOS
 +
|v3s32 p*100, v3s32 speed*100
 +
|Inform the server of the positon of the local player
 +
|}
  
−
When the dedicated server is run, main() ends up running this and when it returns, Minetest quits.
+
==== Server -> Client ====
 +
{| class="wikitable"
 +
|TOCLIENT_BLOCKDATA
 +
|v3s16 p, MapBlock data
 +
|Send the content of a block (16x16x16 nodes)
 +
|-
 +
|TOCLIENT_ADDNODE
 +
|v3s16 p, MapNode node
 +
|Add a node
 +
|-
 +
|TOCLIENT_REMOVENODE
 +
|v3s16 p, MapNode node
 +
|Remove a node
 +
|-
 +
|TOCLIENT_PLAYERPOS
 +
|foreach(player){
 +
:u16 player_id, v3s32 p*100, v3s32 speed*100}
 +
|Update players on client
 +
|}
  
−
It basically just feeds time to the server instance created by main() and reacts to SIGKILL etc.
+
Minetest uses it's own reliability layer on top of UDP. It isn't well documented at the moment, and thorough understanding of it isn't that important, so let's skip it as of now.
  
−
=== the_game() ===
+
=== Environment ===
−
game.{h,cpp}
+
-
  
−
Launched when you start the game from the main menu.
+
=== Rendering ===
 +
-
  
−
This creates the client (and the server, if needed), handles the waiting of loading stuff from the server, and runs the game in a somewhat badly structured main loop (which works well, though).
+
== Hmm... ==
−
 
 
−
== Threads ==
 
−
 
 
−
=== Stand-alone server ===
 
−
* main
 
−
:* Doesn't do much
 
−
* ServerThread (Server)
 
−
:* Runs the server
 
−
* EmergeThread (Server)
 
−
:* Fetches and generates world
 
−
 
 
−
=== Client-only ===
 
−
* main
 
−
:* Runs almost everything in main game loop
 
−
* MeshUpdateThread (Client)
 
−
:* Does mesh updates in the background
 
−
 
 
−
=== Singleplayer ===
 
−
* main
 
−
:* Runs almost everything except server in main game loop
 
−
* MeshUpdateThread (Client)
 
−
:* Does mesh updates in the background
 
−
* ServerThread (Server)
 
−
:* Runs the server
 
−
* EmergeThread (Server)
 
−
:* Fetches and generates world
 
−
 
 
−
== Classes ==
 
−
 
 
−
=== IGameDef ===
 
−
An interface for fetching pointers to the managers of things. It is passed to almost everything.
 
−
 
 
−
It is implemented by Client and Server. Neither implements all interfaces.
 
−
 
 
−
Generally these can be accessed by referring to IGameDef:
 
−
* TextureSource
 
−
* ItemDefManager
 
−
* NodeDefManager
 
−
* SoundManager
 
−
* MtEventManager
 
−
 
 
−
This is the main difference between 0.3 and 0.4. In 0.3 this does not exist, because all content is defined in static tables in source code.
 
−
 
 
−
gamedef.{h,cpp}
 
−
 
 
−
=== TextureSource ===
 
−
Fetches, generates and caches textures.
 
−
 
 
−
tile.{h,cpp}
 
−
 
 
−
=== ItemDefManager ===
 
−
Stores the definitions of items, by item name. Content is set up at server startup, and transferred from server to client at beginning of connection.
 
−
 
 
−
itemdef.{h,cpp}
 
−
 
 
−
=== NodeDefManager ===
 
−
Stores the definitions of nodes and the mapping between node ids and names. Content is set up at server startup, and transferred from server to client at beginning of connection.
 
−
 
 
−
nodedef.{h,cpp}
 
−
 
 
−
=== SoundManager ===
 
−
Stores and plays sounds on the client.
 
−
 
 
−
sound.{h,cpp}; sound_openal.{h,cpp}
 
−
 
 
−
=== MtEventManager ===
 
−
A minimal event manager currently only used for triggering sounds on the client.
 
−
 
 
−
event.{h,cpp}
 
−
 
 
−
=== Client ===
 
−
Contains a lot of stuff. Most considerable members are listed here.
 
−
* TextureSource
 
−
* ItemDefManager
 
−
* NodeDefManager
 
−
* SoundManager
 
−
* MtEventManager
 
−
* MeshUpdateThread
 
−
* ClientEnvironment
 
−
:* ClientMap
 
−
:* Players
 
−
:* ClientActiveObjects (CAOs)
 
−
* Connection
 
−
 
 
−
Implements IGameDef.
 
−
 
 
−
client.{h,cpp}
 
−
 
 
−
=== Server ===
 
−
Contains a lot of stuff. Most considerable members are listed here.
 
−
* ServerEnvironment
 
−
:* ServerMap
 
−
:* Players
 
−
:* ServerActiveObjects (SAOs)
 
−
* Connection
 
−
* BanManager
 
−
* Lua State
 
−
* ItemDefManager
 
−
* NodeDefManager
 
−
* CraftDefManager
 
−
* ServerThread
 
−
* EmergeThread
 
−
 
 
−
Implements IGameDef.
 
−
 
 
−
server.{h,cpp}
 
−
 
 
−
=== Lua State ===
 
−
The single Lua interpreter on the server. Built-in code and mods are loaded into it at startup.
 
−
 
 
−
=== Connection ===
 
−
Connection (client->server or server->clients)
 
−
 
 
−
=== ClientEnvironment (Environment) ===
 
−
Contains most of the actual game environment (players, objects, map...)
 
−
 
 
−
* ClientMap
 
−
* Players
 
−
* ClientActiveObjects (CAOs)
 
−
 
 
−
environment.{h,cpp}
 
−
 
 
−
=== ServerEnvironment (Environment) ===
 
−
Contains the actual game environment (players, objects, map, time of day, ...)
 
−
 
 
−
* ServerMap
 
−
* Players
 
−
* ServerActiveObjects (SAOs)
 
−
 
 
−
environment.{h,cpp}
 
−
 
 
−
=== ClientMap (Map) ===
 
−
 
 
−
map.{h,cpp}, clientmap.{h,cpp}
 
−
 
 
−
=== ServerMap (Map) ===
 
−
 
 
−
map.{h,cpp}
 

Revision as of 09:06, 20 January 2013

The base (NMPR)

Everything is built on a small core, that was the original network multiplayer release of Minetest (call it NMPR; the 2010-10-24 version). Being around 10000 lines of code, it contains:

  • The Map: Voxel storage + lighting + rendering
  • The Client + Server logic
  • The Environment: Contains the map and the players, handles the simulation of the world
  • The main loop: Invokes the client, the server, the environment and the rendering.
  • A bunch of wrappers for OS-dependent things, and utilities.

As the current code still largely bases on the NMPR, it is useful to look at how it works.

Map (the voxels)

Minetest Voxel Storage
  • The main content of the Map is a map<v2s16, MapSector*> container.
  • The main content of a MapSector is map<s16, MapBlock*>.
  • The main content of a MapBlock is a linear array of 16x16x16 MapNodes.

These form a relatively performant storage of voxel data. In addition to these containers, the latest fetched MapBlock is cached in each MapSector, and the last fetched MapSector is cached in Map, resulting in very useful sequential access speed through the whole abstraction layer.

Network protocol

The high-level network protocol of NMPR is delightfully simple. There are four commands for the server, and four commands for the client. Since this, a lot has been added and changed, but the basic idea stays the same.

Client -> Server

TOSERVER_GETBLOCK v3s16 p Ask the server to send the data of a block
TOSERVER_ADDNODE v3s16 p, MapNode node Inform the server of a placed node
TOSERVER_REMOVENODE v3s16 p, MapNode node Inform the server of a removed node
TOSERVER_PLAYERPOS v3s32 p*100, v3s32 speed*100 Inform the server of the positon of the local player

Server -> Client

TOCLIENT_BLOCKDATA v3s16 p, MapBlock data Send the content of a block (16x16x16 nodes)
TOCLIENT_ADDNODE v3s16 p, MapNode node Add a node
TOCLIENT_REMOVENODE v3s16 p, MapNode node Remove a node
TOCLIENT_PLAYERPOS foreach(player){
u16 player_id, v3s32 p*100, v3s32 speed*100}
 Update players on client

Minetest uses it's own reliability layer on top of UDP. It isn't well documented at the moment, and thorough understanding of it isn't that important, so let's skip it as of now.

Environment

-

Rendering

-

Hmm...

Retrieved from "http://dev.minetest.net/index.php?title=Engine/NMPR&oldid=612"