Spile Design Information

[zorbyte]

NOTE: This issue is messy, I simply dumped my thoughts into words as fast as I could.
Some of the things mentioned here do not reflect what is currently happening in the repository as this was written prior to the Deno rewrite.
I will rewrite it and split it into separate issues for readability.

Spile is gonna be a lot of stuff to do... So, I need to figure out a lot of details before it is too late, these are some of those ideas just dumped into an issue.

Easy to use file layout, I hate hyper-focusing on this but when I get it right it makes life so much easier.

Prioritise power over ease of setup. Don't get me wrong, a good user setup experience is nice but this is intended for people who want something fast. Thus I'm going to make redis extensively.

Use FFI with rust... At first I was just considering this, but now I know I should definitely learn rust and use it here.

Other random considerations I thought of: Using elixir for TCP related stuff, its high concurrency is great for handling a lot of players at one time... Or maybe balerina, since it is great for micro-services and supports Java (great for compatibility with existing solutions).

Quick Note: Spile uses SemVer. Anything pre-1.0.0 is volatile and is subject to change at any time, thus the public API can change at any time.

Something worth mentioning: We are using Deno now.

Stuff:

• Make Spile an importable module, and make the the end user executable another
  project.
• Try and use more functional programming which utilises objects instead of using
  them for functionality.
• A nice packet parsing pipeline that makes use of es6 proxies, type safety
  maybe event emitters.
• An error API which forwards errors to a GUI, where maintainers may select errors
  to send to this repo or something.
  • Sentry for maintainers might be cool.
• rcon client, I'm not integrating a console into this, the less I/O work, the
  better.
• CLI to bundle the server, rcon client and error GUI into.
  • Commands called like spile server [opts] [config]
• A neat monorepo setup.
• A worker thread thing setup.
• Usage of cluster.
• Plugins, cross platform using gRPC or something... Also allow first class JS
  plugins (recommended)
  • Support for Spigot API through a Java Lib written using the plugin API.
  • Dedicated plugin worker_thread or cluster worker, with fast communication.
• Terrain generation (WASM only, in this project through rust)
  • With support for custom ones that fit a spec.
• Github Actions
• i18n
• Pretty much everything Notchian
• Plugins with that.
• Probably a lot more than this.

Game:

• Terrain Generation (See above)
• Redstone
• Physics
  • Explosions
  • Fluid dynamics
• Anvil Storage
• Lighting
• Mobs
  • Path finding

Worry about this later:

• Bungeecord like thing
  • spile occy [server_ips...] [config file (probs with that)
  • Also support env vars in that cmd (and security keys???).
  • Probably call this project occystrap or occy, because it's slang for
    bungee cord in Australia.
  • Probably where elixir might be useful.
  • IDK about this, but k8s???
• Docker Configs
• Logo