The Game

No, Kovarust isn't dead yet!

I'm spending a lot of time overthinking the design of Kovarust - how to organize things, how plugins would interact with each other & the world, etc. - and by the time I looked at it again, all the libraries changed their APIs and I need to rewrite a big chunk of the graphics stuff...
Well, at least it'd push me to design it better, but it's still annoying.

I'm also working on a few other small projects (my excuse is to get more experience with Rust before tackling something more important, like Kovarust), so all I can say is that I'll get there when I get there.
Don't rush me.

Design

Essentially, everything is going to be a plugin (or "mod") - taken to the most extreme extents. Everything beyond loading plugins, initializing the world, and ticking chunks will be left to said plugins.

That includes implementing all blocks and entity types, the entire "base game" content, networking (multiplayer), and even the graphical client front-end. I'm forcing myself to write it this way so that no mods should need to modify the core source code to be able to do anything more than my implemention could. That would be unfair to the mods.

The best design is as little design as possible.
- Some dude

This is kind of the reason Kovarust is taking so long to get up & running. Before I implement anything, I overthink how much I can strip away to make it as generic as possible while also being reasonably efficient. My excuse is even if I do a cheap job now just to make it work temporarily, it'll cause me pain later since I'll need to rewrite it and everything else that interfaces with it, so I might as well do it as right as I can now.

Plans

Anyway, here's a list of selling-point features I'm considering, grouped by their likelihood of making it into the base game (excluding the obvious, like, uh, rendering).

Literally the main selling-points

• Server-side LoD generation (far enough to render your mother)
• Plugins support (in case you missed it, everything is a plugin in one way or another)
• Gamepad input & split-screen multiplayer (I mean, this just depends on the front-end plugin - create as many player entities as you want and bind them to a GUI socket)
• Fleshed-out content & progression even without 20 modpacks (only 200 individual mods to get equivalent of Minecraft base game)
• Expansive Tinkerable™ tools, weapons, & armour system
• Redstone & heaps of other technical blocks, all inter-compatible with Flux™
• Massive modular dungeons & strongholds, dynamic structure generation
• Programmer-oriented player customizability taken to the extremes ("programmer-oriented" == json, write your own player model)
• Still somehow capture the Classic Minecraft feel (most difficult point on this list)

Definitely most likely

• Cryptographic multiplayer accounts (this just depends on the networking plugin)
• Proximity voice chat (again, plugin)
• Shadows, coloured lights, & other "fancy" graphics (but not too fancy)
• Simple server-side anticheat (if the player can't see a block, don't send it, duh)
• Multi-threaded worlds depending how far players are
• API-controlled bot entities (maybe with simple server-side scripting as fallback?)

Within possibility

• Native VR support
• GMod-style auto-mod-downloading from servers, if it's secure enough
• Compatability with Minecraft/Minetest/OpenMiner servers (vanilla only tho, I ain't porting every mod in existence, nor am I writing a Java transcompiler)

Nah yeah nah

• Eating dirt
• Attack cooldowns
• Definitely no backdoors to hack git4rker back
• Herobrine
• microsoft spyware
• Cringe gay mobs, useless redundant blocks, & 1.19.84 anti-features