mirror of
https://gitlab.bixilon.de/bixilon/minosoft.git
synced 2025-08-12 16:36:27 -04:00
58 lines
2.7 KiB
Markdown
58 lines
2.7 KiB
Markdown
# Architecture
|
|
|
|
## Modules
|
|
|
|
Basically minosoft consists of 3 models:
|
|
|
|
- Core
|
|
- Eros
|
|
- Rendering
|
|
|
|
To only start the core, you can start the jar with the `--headless` parameter.
|
|
|
|
### Core
|
|
|
|
The core should not depend on other modules (currently not true, but reduced to a minimum). It contains all the network code,
|
|
account management, entity logic, physics and a lot more.
|
|
|
|
### Eros
|
|
|
|
Eros is the main gui, you can refer to it as launcher or server list. It is mostly using the [mvc design pattern](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller).
|
|
The model is not part of the package, mostly util classes or code from the core.
|
|
|
|
### Rendering
|
|
|
|
Rendering does not depend on Eros, it only depends on the core. It is written pretty much abstract and even/watcher driven.
|
|
This module contains most of the part. It does everything rendering (aka. what you actually see from the game).
|
|
|
|
It is also pretty dynamic, you could say that it also exists ot of modules. It also handles a lot of the logic.
|
|
You can find more about it [here](/doc/rendering/ReadMe.md).
|
|
|
|
## Networking
|
|
|
|
Networking is sitting on top of [Netty](https://netty.io/).
|
|
Every packet has its own class, all data is (due to compatibility and multi versioning) read manually from the buffer.
|
|
Every packet needs to include all version checks (e.g. `if(versionId >= V_1_19)`). If a packet changed fundamentally in a version,
|
|
there might be a legacy packet. Not all (but pretty much all) packets are implemented.
|
|
|
|
Every packet has a handle function, the use of it is pretty much straight forward. Most of those handle functions trigger events,
|
|
that might get handled by mods or other modules.
|
|
|
|
## Version data
|
|
|
|
Minosoft has a lot of properties of blocks, items, ... hardcoded into it. If the data is not present (i.e. not implemented or new version),
|
|
the data is generated by [PixLyzer](https://gitlab.bixilon.de/bixilon/pixlyzer) that gets downloaded and loaded on demand.
|
|
|
|
Personally I really like that design, it allows design decisions far away from vanilla and does not break multi versioning and the adaption of new versions is really quick.
|
|
|
|
## Assets
|
|
|
|
Assets are downloaded directly from mojang. Those assets are then hashed (to prevent duplicated saving) and compressed with
|
|
[zstd](https://en.wikipedia.org/wiki/Zstd). There are assets functions (e.g. sound). You can disable downloading of those assets
|
|
if you don't need them. The textures and models are stored in the original minecraft jar, this file is getting downloaded,
|
|
uncompressed and striped down. Original minecraft code never gets executed.
|
|
|
|
Assets are getting manged by assets managers. There are a few of them. Because of that design, you can easily load resource packs.
|
|
|
|
You can find more about assets [here](/doc/Assets.md)
|