Code Monkey home page Code Monkey logo

spile's Introduction

Spile

Discord Shield

Spile is a Minecraft Java edition game server and library written in Typescript and (soon) Rust using Deno.

About

Spile is a Minecraft Java Edition server that will in future sport all the features of other Minecraft servers such as Spigot. To make this possible in Deno, Rust plugins and Workers will be used for resource heavy operations and TypeScript will be used for game logic.

Spile will also be able to be used as a library to make minecraft bots in Deno. The server component is a long term project, and the Spile as library features will be developed in a "second-class" manner until the server is finished.

Check out issue #1 for a checklist of ideas planned for Spile.

Running Spile

There are two ways of running Spile, the first is by installing the Velociraptor CLI and then running vr start.

The other is to use the following command through the Deno CLI:

deno run --allow-net --allow-read --allow-write allow-env --config ./etc/tsconfig.json --importmap ./etc/import_map.json --lock ./etc/lock.json --unstable ./src/main.ts

It is recommended to use the VelociraptorCLI to avoid typing this long command or creating your own shell script. If you are contributing to Spile, do not commit any files for starting the server, you should instead be using the Velociraptor CLI. Please see the Contributing section below in the latter case.

Contributing

Follow the Deno Style Guide where appropriate. It can be inferred which rules do not apply from a cursory glance at the Spile code.

To use the scripts, install the Velociraptor CLI.

To configure the development environment, run vr setup_dev (this requires the aforementioned CLI).

To run Spile (in development mode), run vr dev.

Ensure that you lint everything with prettier (using an editor plugin is the easiest way to achieve this) and then vr lint prior to committing.

Do not use a deps.ts file. Instead use the import map, take a look at how previous imports are done and replicate the format.

If you use the Code Spell Checker VSCode plugin, you can create a custom_dictionary.json file in the root directory to use custom words. To update it, make your changes to the custom_dictionary.json file and run vr setup_dev again.

A note about the current state of the packet parser: The parser is currently written in TypeScript, this will change. The parser will be written in rust to take advantage of features such as macros and Rust's performance

Credits

This project would be impossible without these amazing people, resources, communities and projects:

  • Deno Standard Library - Useful guide on how I should go about writing stuff in Deno, especially the packet parser.
  • wiki.vg - Documentation on the Minecraft protocol.
  • Mojang - Mojang for such a cool game.
  • GlowstoneMC - For countless inspirations on how I should go about creating certain aspects on this project.
  • Feather - For ideas for the rust side of Spile.
  • PrismarineJS - Existing JS code to help me gain insight on how things are done through JS in the MC protocol.

License

This project is licensed under the MIT license. Please consider its existence... See LICENSE for more information.

spile's People

Contributors

zorbyte avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

Forkers

massimiliano76

spile's Issues

Consider Versioning for Packet IDs

Use a file that maps packet name and direction to an ID instead of hard coding it, this will make updating packets way easier when adapting to future Minecraft versions.

Another idea:

Use a bot that crawls wiki.vg, then creates a PR and replaces the ids in their respective files.

Config files

Todo:

  • Parse yml, find something fast
  • Use ow validation.
  • Create typescript type.

Investigate buffer producer speeds

I need to see if the buffer producer could be optimised by some means, creating buffers and concatenating them is a bit slow and I would hope to maybe just write to one buffer instead. Probably need to see about buffers that can grow in size too though, otherwise if such a thing does not exist, maybe just keep the current system?

Spile Design Information

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

Input prompt.

Get an input prompt working, however my main concern is the extra usage of IO, as well as the interference with the sonic boom module, which allows logging to be less costly. If this has impact on throughput, I will not include it as a v1 feature and instead just create a CLI rcon client which relays logs. If such a thing is enabled, the default recommendation for logs will be for it to be stored in a file instead, however both stdout and a file can be used but the config will have a comment warning against such a thing.

Ideas for it:
Whenever something gets logged, it freezes the input prompt, buffers what was in the middle of being typed (if any), moves the cursor before the prompt (\r), logs, moves the cursor back to where it was and then puts the stdin text there.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.