|
1 |
| -nyan |
2 |
| -==== |
| 1 | +# nyan |
| 2 | + |
| 3 | +## WTF? |
| 4 | + |
| 5 | +**nyan** is a strongly typed hierarchical key-value database with patch |
| 6 | +functionality and inheritance. |
| 7 | + |
| 8 | + |
| 9 | +## Design idea |
| 10 | + |
| 11 | +[openage](https://github.com/SFTtech/openage) requires a very complex data |
| 12 | +storage to represent the hierarchy of its objects. Research and technology |
| 13 | +affects numerous units, civilization bonuses, monk conversions and all that |
| 14 | +with the goal to be ultimatively moddable by the community: |
| 15 | + |
| 16 | +Current data representation formats make this nearly impossible to |
| 17 | +accomplish. Readability problems or huge lexical overhead led us to |
| 18 | +design a language crafted for our needs. |
| 19 | + |
| 20 | +Enter **nyan**, which is our approach to store data in a new way™. |
| 21 | + |
| 22 | + |
| 23 | +## Core Principles |
| 24 | + |
| 25 | +* Human-readable language |
| 26 | +* More or less compact (readability > memory) |
| 27 | +* General-purpose data definition + database features |
| 28 | +* Changing data with patches at runtime |
| 29 | +* Moddability of defined data |
| 30 | +* Portable |
| 31 | +* Object-oriented |
| 32 | +* Typesafe |
| 33 | + |
| 34 | + |
| 35 | +## Srsly? |
| 36 | + |
| 37 | +Let's create a new unit with a mod: a japanese tentacle monster. |
| 38 | + |
| 39 | +``` python |
| 40 | +TentacleMonster(Unit): |
| 41 | + name = "Splortsch" |
| 42 | + hp = 2000 |
| 43 | + |
| 44 | +Creation<TownCenter>(): |
| 45 | + creates += {TentacleMonster} |
| 46 | + |
| 47 | +TentacleMod(Mod): |
| 48 | + name = "Add the allmighty tentacle monster to your holy army" |
| 49 | + patches = {Creation} |
| 50 | +``` |
| 51 | + |
| 52 | +Things like `Unit` and `Mod` are provided by the game engine, |
| 53 | +`TownCenter` is provided by the base game data. |
| 54 | + |
| 55 | +When the engine activates the mod, your town center can create the new unit. |
| 56 | + |
| 57 | + |
| 58 | +## Why nyan? |
| 59 | + |
| 60 | +* nyan allows easy modding |
| 61 | + * Data packs ship configuration data and game content as `.nyan` files |
| 62 | + * Modpacks can change and extend existing information easily, by applying data "patches" |
| 63 | + * Patches are applied whenever the `libnyan` user decides when or where to do so |
| 64 | +* nyan is typesafe |
| 65 | + * The type of a member is stored when declaring it |
| 66 | + * The only things nyan can do: Hierarchical data declaration and patches |
| 67 | + * No member type casts |
| 68 | + * Only allowed operators for a member type can be called |
| 69 | +* nyan is invented here™ |
| 70 | + * we can change the specification to our needs whenever we want |
| 71 | + |
| 72 | +## Specification |
| 73 | + |
| 74 | +A full specification is provided [here](nyan_specification.md). |
| 75 | + |
| 76 | +## Integration into a Game Engine |
| 77 | + |
| 78 | +* Some `.nyan` files are shipped with the game engine |
| 79 | + * They describe things the engine is capable of, basically the mod API |
| 80 | + * That way, the engine can be sure that things exist |
| 81 | + * The engine can access all nyan file contents with type safety |
| 82 | + * The data files of the game then extend and change the API `nyan::Object`s |
| 83 | + |
| 84 | +* The nyan database provides a C++ API used by the game engine |
| 85 | + * Can parse `.nyan` files and add all information to the database |
| 86 | + * Provides hooks so the engine can react on internal changes |
| 87 | + |
| 88 | +* Data does not contain any executable code but can specify function names |
| 89 | + and parameters. The game engine is responsible for calling those |
| 90 | + functions or redirecting to custom scripts |
3 | 91 |
|
4 |
| -[language specification](./nyan.md) |
|
0 commit comments