BitCraft Server Documentation

repository·master·Indexed 20 days ago

https://github.com/clockworklabs/bitcraftpublic

Server-side logic and state management for BitCraft, a community sandbox MMORPG. Built using SpacetimeDB, the repository includes game logic, state management, and custom Rust macros for shared tables, event-driven timers, and feature gating. It provides detailed implementations for claim systems, dropped inventory lifecycles, and server-side systems.

Tokens
15.8K
Snippets
56
Records
69
Agent score
69%

What's inside bitcraftpublic

  1. Overview of BitCraft Server Repository

    master

    This repository contains the server-side code for BitCraft, a community sandbox MMORPG. It includes game logic, state management, and server-side systems.

    Note: This repository does not include the game client or the tools required to connect to the official BitCraft game servers. It is intended for public inspection, experimentation, and contribution.

  2. Usage rights and restrictions for BitCraft code

    master

    The BitCraft source code is licensed under the Apache 2.0 license.

    Permitted Actions

    • Read and study the code.
    • Modify and experiment with the code locally.
    • Run your own servers for experimentation.
    • Use the code as a reference for building your own projects.
    • Create a game similar to BitCraft using your own IP (art and themes) using this code as a basis.

    Prohibited Actions

    • Use BitCraft’s art, game content, music, or other protected assets.
    • Use BitCraft’s IP or present forks as official.
    • Share information about discovered exploits with anyone other than the developers.
    • Operate official, unofficial, private, or competing BitCraft servers.
    • Violate the open source license.
  3. Requirements for Claim Resupply

    master

    To successfully execute a claim resupply, the following conditions must be met within the reduce logic:

    1. Permissions: The actor must have Permission::Usage and ClaimPermission::Usage for the target building.
    2. Proximity: The distance between the actor's coordinates and the building's coordinates must be $\le 3$.
    3. Claim Association: The building must be located on a valid claim tile.
    4. Ownership: The building being supplied must be the owner_building_entity_id of the claim.
    5. Supply Capacity: The claim's current supplies must be less than its max_supplies.
    6. Inventory Validity:
      • The provided inventory_entity_id must exist.
      • The pocket_index must be within the valid range of the inventory's pockets.
      • The item at the specified pocket must be of ItemType::Cargo.
      • The item must be recognized in building_repairs_desc as having a valid repair_value.

    If any of these conditions fail, the reducer returns an error (e.g., "Too far", "Building is not under a claim", or "Claims can only be charged with supplies.").

  4. How dropped inventory ownership and despawn timers work

    master

    The system uses a state machine driven by scheduled reducers to manage item persistence:

    1. Ownership Phase: When an item is dropped, a DroppedInventoryOwnershipTimer is scheduled. While this timer is active, the items are considered private to the owner.
    2. Ownership Loss: When dropped_inventory_lose_ownership triggers:
      • If the inventory is still private, it converts into a Despawn Timer.
      • If the inventory is at a location where a public inventory already exists, it merges the items into the public inventory and deletes the private one.
    3. Despawn Phase: When dropped_inventory_despawn triggers, the DroppedInventoryState and its associated InventoryState and LocationState entries are deleted from the database.
  5. How deconstruction time is calculated

    master

    The duration required to deconstruct a building is determined by the event_delay_recipe_id function. The calculation follows this logic:

    1. Base Time: Starts with the time_requirement from the building's DeconstructionRecipeDesc.
    2. Skill Reduction: The time is divided by the player's skill speed for the specific skill required by the recipe (recipe.get_skill_type()).
    3. Tool Factor: If the recipe requires a tool, the time is multiplied by a time_factor derived from the tool's power relative to the desired_tool_power required by the recipe.
    4. Fallback: If no recipe is found, the system uses deconstruct_default_time from the global parameters_desc.

    If the player does not possess the required tool, the action is invalidated.

  6. Deconstruction permissions and restrictions

    master

    Deconstructing buildings is subject to several permission and state checks:

    Restriction TypeCondition
    PermissionMust have Permission::Build or ClaimPermission::Build on the tile/building.
    Premium BuildingsMust be the owner or a co-owner of the claim.
    WatchtowersCannot be deconstructed.
    Player HousingCannot be deconstructed if there are active residents (locked_until <= ctx.timestamp).
    ElevatorsCannot be deconstructed if they are currently in use (checked via player_use_elevator_timer).
    DimensionsCannot deconstruct portal buildings in interiors, or any buildings in AncientRuin or Dungeon dimensions.
    ProximityActor must be within a distance of 2 from the building.
  7. Initialize world region information

    master

    The init_region_info reducer allows an Admin to set up the initial parameters for a world region.

    Parameters:

    • world_width: Width in chunks.
    • world_height: Height in chunks.
    • region_index: The index of the current region.
    • region_count: Total number of regions (must be a square number).

    Requirements:

    • The caller must have Role::Admin.
    • region_count must be a perfect square.
    • region_index cannot exceed region_count.

    This function populates WorldRegionState and WorldRegionNameState and updates the Globals table with the current region_index.

    #[spacetimedb::reducer]
    pub fn init_region_info(
        ctx: &ReducerContext,
        world_width: i32,
        world_height: i32,
        region_index: u8,
        region_count: u8,
    ) -> Result<(), String>
  8. Initialize the BitCraft database

    master

    The initialize reducer is an init reducer that sets up the initial state of the database. It performs the following actions:

    • Assigns Admin roles to the database owner and the database identity.
    • Sets up the ServerIdentity.
    • Initializes AdminBroadcast, Globals, and Config tables.
    • By default, the Config table is set to env: "dev" and agents_enabled: false.

    Note: If the environment is not dev, the reducer enforces that the caller must be the owner of the database.

    #[spacetimedb::reducer(init)]
    pub fn initialize(ctx: &ReducerContext) -> Result<(), String>
  9. Handle client connections and authentication

    master

    The identity_connected reducer is triggered via the client_connected event. It manages access control for connecting identities:

    • Developers: If the identity is found in the developer table, they are logged and allowed to connect.
    • Queue Skipping: Identities with the Role::SkipQueue are allowed to connect.
    • Authentication & Blocking: If an identity is in the blocked_identity table or fails is_authenticated checks, the connection is rejected with "Unauthorized".
    • Session Management: If a user is already signed in via a different identity, they are signed out internally before proceeding.

    If an identity has no valid user or permission, the connection is rejected with "Identity with no user or permission is disallowed from connecting".

    #[spacetimedb::reducer(client_connected)]
    #[shared_table_reducer]
    pub fn identity_connected(ctx: &ReducerContext) -> Result<(), String>
  10. Reset player onboarding to specific Alpha 3 milestones

    master

    The following reducers allow administrators to reset a player's onboarding state to specific predefined milestones within the Alpha 3 version of the game. These are useful for testing or correcting player progression.

    Note: These reducers are specific to Alpha 3 and may become invalid as onboarding logic changes.

    Requirements:

    • Caller must have Role::Admin permissions.
    • Requires a valid entity_id (u64) of the player.

    Available Milestones:

    • admin_alpha3_reset_onboarding_to_first_temple_quest: Resets to the first temple quest.
    • admin_alpha3_reset_onboarding_to_second_temple_quest: Resets to the second temple quest.
    • admin_alpha3_reset_onboarding_to_third_temple_quest: Resets to the third temple quest.
    • admin_alpha3_reset_onboarding_to_fourth_temple_quest: Resets to the fourth temple quest.
    • admin_alpha3_reset_onboarding_to_fifth_temple_quest: Resets to the fifth temple quest.
    • admin_alpha3_reset_onboarding_to_first_expand_quest: Resets to the first expand quest.
    • admin_alpha3_reset_onboarding_to_second_expand_quest: Resets to the second expand quest.
    • admin_alpha3_reset_onboarding_to_third_expand_quest: Resets to the third expand quest.
    • admin_alpha3_reset_onboarding_to_fourth_expand_quest: Resets to the fourth expand quest.