What I Am Building

Tribe Contracts is an in-game contract board system for ARK: Survival Ascended.

The basic idea is simple: instead of keeping tribe jobs, solo goals, boss preparation, crafting orders, and resource runs in Discord messages or memory, players can turn that work into contracts inside the game world.

The loop I want to prove first is:

• place or use a Contract Board
• create a contract
• accept it
• deliver the required resource or item
• complete the contract
• claim a reward if one was attached

That is the part that matters most. The long-term design has more contract types and more tribe tooling, but the first version has to make this core loop feel dependable.

Why The Scope Changed

The original concept is intentionally broad. It includes personal boards, tribe boards, delivery contracts, fresh harvest and craft validation, hunt contracts, reward bundles, contribution tracking, pinned contracts, history, stats, and recovery behavior.

That is useful as a full design direction, but it is too much to treat as equal priority during a jam build.

The feedback after the concept phase pushed me toward the safer version of the plan: build a smaller, reliable MVP first, then only add riskier systems when the base loop is stable.

So I am treating the current MVP as:

• Contract Board
• simple contract creation
• Resource Delivery contracts
• Item Delivery contracts
• basic QuestVault reward bundles
• secure reward claiming
• save/load reliability
• multiplayer reliability
• clear UI with minimal steps

Fresh Harvest, Fresh Craft, Hunt contracts, cooperative contribution tracking, reward split policies, leaderboards, and recovery behavior are still part of the larger idea, but they are not allowed to distract from the delivery loop right now.

Current Implementation Direction

The first technical pass is centered around a saved singleton that owns the contract data.

That gives me one authoritative place to handle:

• board registration
• contract creation
• contract IDs
• accepted player progress
• contract state changes
• saved board and contract arrays
• basic validation

I do not want the placed board structure to become a separate copy of the whole system. The board should be the interaction point and UI surface. The singleton should own the state that needs to persist and stay consistent.

That matters because this mod will eventually have to survive save/load, multiplayer requests, reward state, and board UI actions without desynchronizing.

What Works So Far

The early debug flow already proves a small but important slice of the system.

Right now I have:

• base enums for board mode, contract type, scope, state, assignment, and participation
• base structs for board data, contract data, and player progress
• saved arrays and ID counters in the singleton
• board registration
• contract creation
• contract acceptance
• accepted player progress stored on the contract
• Resource Delivery progress
• delivery progress capped at the required amount
• contract completion when the required amount is reached
• extra submissions rejected after completion
• basic validation and debug messages
• contract data persisting after save/load

Most of this is still debug-path work. It is not connected to a real board UI or inventory-facing delivery path yet. But it is enough to validate that the data shape is usable before I start putting UI on top of it.

Why Delivery Contracts Come First

Delivery contracts are the safest first target because they are easy to reason about:

• the player delivers physical resources or items
• the contract checks the amount
• progress increases
• the contract completes at the target amount

Fresh Harvest and Fresh Craft are more complicated because they need to know whether progress happened after the contract was accepted. Hunt contracts also need careful kill or assist attribution.

Those are interesting systems, but they are not where I want the first playable build to get stuck.

If Resource Delivery and Item Delivery are stable, the mod already has a useful contract loop. Everything after that can be judged against the question: does this make the core loop stronger, or does it add risk?

Next

The next work is to move from debug data flow toward player-facing use.

My current priority is:

• finish Item Delivery progress
• connect delivery to a safer inventory-facing path
• create the basic Contract Board structure and item flow
• add minimal board interaction
• start the board UI with the smallest useful contract list

After that, I can move toward the QuestVault and reward claim flow.

The important thing is keeping the project honest. A smaller contract system that saves correctly, works in multiplayer, and handles rewards safely is a better jam submission than a larger one where the advanced contract types are fragile.