Ezhh
/
minetest_modding_book
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Creating Games: Fix paragraph order

master
rubenwardy 2018-09-14 15:50:34 +01:00
parent dd4d0ddbb1
commit b9a80a57c3
No known key found for this signature in database
GPG Key ID: A1E29D52FF81513C
1 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
_en/games/games.md
View File

@ -55,7 +55,14 @@ are recommended.
It's a good idea to try to keep as much API compatibility with Minetest Game as
convenient, as it'll make porting mods to another game much easier.
API compatibility is the sum of the following things:
The best way to keep compatibility with another game is to keep API compatibility
with any mods which have the same name.
That is, if a mod uses the same name as another mod even if third party,
then it should have a compatible API.
For example, if a game includes a mod called `doors` then it should have the
same API as `doors` in Minetest Game.
API compatibility for a mod is the sum of the following things:
* Lua API table - All documented/advertised functions in the global table which shares the same name.
For example, `mobs.register_mob`.
@ -65,13 +72,6 @@ It's probably fine to have partial breakages as long as 90% of dependency
usecases still works. For example, not having a random utility function that was
only actually used internally is ok, but not having `mobs.register_mobs` is bad.
The best way to keep compatibility with another game is to keep API compatibility
with any mods which have the same name.
That is, if a mod uses the same name as another mod even if third party,
then it should have a compatible API.
For example, if a game includes a mod called `doors` then it should have the
same API as `doors` in Minetest Game.
It's difficult to maintain API compatibility with a disgusting God mega-mod like
*default* in Minetest Game, in which case the game shouldn't include a mod named
default.