ποΈ Differences from the classic version
Compared with the classic version, the current version greatly simplifies the code implementation and is more convenient for customization. So the code adjustment is huge, but the usage difference is not huge.
ποΈ design philosophy
In most people's minds, the implementation of configuration tools should be very simple. In fact, you can implement a simple configuration tool with a few hundred lines of code, but it is only usable and far from meeting the various requirements of the configuration workflow in actual game projects.
ποΈ Features
Luban has a wealth of built-in features.
ποΈ luban.conf
Defines the global configuration required by luban.
ποΈ schema logical structure
As introduced in the Design Philosophy document, the core of Luban is a complete type system, and the DPP pipeline is the basis for powerful expansion capabilities.
ποΈ configuration definition
Luban has a set of Schema logical structure implementation independent of the specific implementation. There is no requirement on how to define the configuration, as long as the final definition can be loaded and parsed into a schema logical structure, it can be processed uniformly. The Luban.Schema.Builtin module provides a default SchemaCollector implementation. If the requirements cannot be met, developers can implement a custom SchemaCollector to suit their own project needs.
ποΈ Automatic table import
Each new table is added to tables.xlsx, which is a tedious task. In most cases, each excel corresponds to a table, and it is possible to let the tool automatically add the table definition.
ποΈ Command line tools
Cross-platform
ποΈ Hierarchical parameter mechanism
Most of Luban's built-in templates use the Cascading Option mechanism, which reduces the module name step by step until the option is found.
ποΈ type system
Luban has a complete type system, especially bean supports type inheritance and polymorphism, so that Luban can easily express any complex data structure.
ποΈ type mapping
Sometimes you want to use ready-made struct types directly in the generated code instead of using the generated type code. For example, vector3 is a very common type. After you define vector3 in the configuration, you may want to use UnityEngine.Vector3 instead of the generated vector3 class where the vector3 type is involved in the generated C# code. Luban supports this external type mapping mechanism, which can map configuration classes to external ready-made enum or class types.
ποΈ excel format (primary)
Basic rules
ποΈ excel format (advanced)
The structure used in the example
ποΈ Non-excel data format
Most of the data format filling methods are intuitive, and the data definitions are exactly the same.
ποΈ Code and Data Generation
Support mainstream game engines and platforms
ποΈ Code Style
Luban generates code for a language that conforms to the recommended style of the language by default, but sometimes developers want to control the generated code style. Luban
ποΈ Load configuration
Install Luban.Runtime
ποΈ data validator
A variety of common data validators are implemented in the Luban.DataValidtor.Builtin module.
ποΈ custom template
Luban uses the scriban template engine to generate code, and also uses this template to generate custom text data files.
ποΈ data tag
Luban supports record-level tag marking, and each data can have 0 or more tags. tag can be used to identify a record as a comment, either to filter the export, or to instruct the validator not to check this record.
ποΈ Field Variants
Sometimes the same field may have multiple configurations. A very common scenario is that when making localized data, different regions have different values ββfor a certain initial path.
ποΈ localization
Multiple localization mechanisms are supported and they can be used simultaneously.
ποΈ Best Practices
Naming Conventions
ποΈ Extended Luban implementation
After weighing flexibility and simplicity, luban does not use the plug-in mechanism, but adds some extension projects to the source code project to achieve extension.