Some ideas

[Pantyhose-X]

WebAssembly

From webassembly.org:

WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications.

WebAssembly describes a memory-safe, sandboxed execution environment [...]

WebAssembly also supports non-web embeddings.

Wasm VS D performance benchmark

WASM is already used/supported by other game engines as scripting platform.

Advantages:

would allow people to write mods whatever language they prefer
mods could be more performant by using low-level/high-performance languages

---

Add FFmpeg support

adds the FFmpeg support to voxelman. FFmpeg can virtually decode anything (including GIF files).
ffmpeg is a system library that can potentially do some of the following:

record video from a webcam
record audio
grab or record your entire screen, not just something inside the game
encode this
send the data out over a streaming protocol

Advantages:
Dynamic texture
Higher audio, bitrate and sample rate.

Use Git Repositories Storing Mods

This would offer several benefits:

1. Reduce server load:

   a. No need to deploy a separate database server.
   b. The entire Mods List project can even be made into a static website, with Git operations moved to the browser side using the isomorphic-git library.

2. Quick setup of mirror sites, which will accelerate site access speeds.

3. Simplify the development of various Mods List front-end sites, with the Git repository serving as the backend. This would make it easier to create sites with different scenes such as education-based, RPG game-based, puzzle-based, etc.

4. The proposed Git repository would also allow developers to choose from a variety of comment services, such as giscus, which is based on Github Discussions.

5. Users can submit new mods and subgames through pull request operations.

The proposed Git repository should have the following directory structure: games, mods, textures, and maps subdirectories.

\
|-- games
  |-- voxelman_game
    |-- README.md
    |-- screenshot.jpg
|-- mods
  |-- the_mod_or_modPack
    |-- README.md
    |-- screenshot.jpg
|-- textures
|-- maps

The configuration instructions should be included in the README.md file, and the configuration information should be placed in the front-matter section at the beginning of the README.md file. eg,

---
name: the_mod_name
title: human-readable title
description: a short description
type: mod
author:
  - the_author_name
tag:
  - tag1
url: https://the.mod.location.git
screenshot:
  - ./screenshot.jpg

---
## My voxelman Mod

here is the mod detail description

• url: the real mod/game/texture package location
  • git location: must end with .git
  • zip file location: must end with .zip
  • embed package location: must start with './'
• screenshot: the screenshot of the mod/game/texture package. It could be a screenshot or array of screenshots

The better design architecture is to completely decoupling:

1. Index of Contents: The Git repo I designed above is.
2. Content storage: The actual storage mods, subgame, texture packages can come from git, cloud storage, BT, ...
3. Review/Comment service: There are many clouds or local services to choose from. The Open Source GISCUS service mentioned earlier is one of them.

Multiplayer Server

Why libp2p?
There are several reasons to consider using libp2p as a networking layer to create a robust P2P application:

• Modularity: libp2p is designed to be modular, allowing developers to mix and match different components to meet the needs of their particular application. This makes it easy to customize the networking stack to fit the specific requirements of any P2P application.

• Extensive transport configurability: libp2p provides a set of specifications that can be adapted to support various transport protocols, allowing libp2p applications to operate in various runtime and networking environments as the wealth of transport protocol choices makes it possible to use libp2p in a variety of scenarios.

• Versatility: In addition to supporting a wide range of transports, libp2p offers a range of discovery mechanisms, data storage and retrieval patterns, and is also implemented in many programming languages, providing developers with great flexibility when building P2P applications.

• Security: libp2p includes several security features, such as peer identity verification using public key cryptography and encrypted communication between peers using modern cryptographic algorithms.

• Robustness: libp2p is a robust and reliable networking protocol that is designed to withstand stress, disturbance, and change. Its features and design choices ensure that it is able to function effectively and efficiently in a wide range of environments, and it is able to recover quickly from disruptions or failures. It also offers protection against network attacks through the use of mitigation techniques.

• Resiliency: P2P networks are often more resilient than traditional client-server networks, as there is no single point of failure. libp2p includes features such as peer discovery and content routing that help to ensure that the network remains available and accessible even if some peers are offline or unreachable.

• Efficiency: P2P networks can be more efficient in resource utilization, as data is distributed across multiple peers rather than stored on a central server. libp2p includes various storage and retrieval patterns that allow developers to distribute data efficiently across the network, making it possible to store and retrieve data in a cost-effective and scalable way.

• Piercing NAT Barriers: libp2p is equipped with capabilities for NAT traversal, which allows P2P communication between peers even when they are behind NAT devices or firewalls. This helps to maintain the connectivity of the network and ensure that it remains accessible despite the presence of these obstacles.

• Message Distribution and Dissemination: One such pattern libp2p uses is publish/subscribe (pubsub), which allows a sender (publisher) to send a message to multiple recipients (subscribers) without the publisher having to know who the subscribers are. libp2p implements pubsub through the use of protocols like gossipsub, providing developers with a flexible and efficient means of exchanging data and messages within their P2P applications.

• Interoperability: libp2p implementations in different programming languages and libp2p releases across versions are designed to be interoperable with one another. This enables applications /from different language ecosystems to communicate seamlessly. This helps to promote a healthy, interconnected ecosystem of P2P applications.

• Decentralization: One of the main advantages of P2P networks is their decentralized nature, allowing them to operate without a central authority. libp2p is designed to facilitate decentralized communication between peers, making it possible to build P2P applications resistant to censorship and more resilient in the face of network disruptions.

[MrSmith33]

Hi, thanks for your input.

I thought about having wasm mods, but atm Vox doesn't support wasm as an input, so that is something that may be added in future.

ffmpeg is pretty big (140MiB of dll files), so I wont include it in the base game. But people are free to add it with a library, once I add some convenience code to bind to dlls.

Mod management is a tough one. Using git for mod index sounds like a good idea. Having less centralized solution might be more desirable. Ideally user should be able to browse, rate, install mods directly from the client.

For networking I already added enet and GameNetworkingSockets (without Vox bindings). libp2p looks pretty new.