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.

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?

Development Log

I am keeping this post as a public version of the build log, not as a full internal changelog. The internal notes are more granular. This version keeps the useful development steps visible without listing every Blueprint adjustment.

June 3 - Core Data And Debug Contract Flow

The first real work was getting the data shape into place.

I created the base enums and structs for board mode, contract type, scope, state, assignment, participation, board data, contract data, and player progress. I also started Singleton_TribeContracts as the saved data owner with saved board and contract arrays, ID counters, board registration, contract creation, and contract acceptance.

The useful part was proving that a contract could exist as saved data and move through the first state changes:

• register a test board
• create a test contract
• accept that contract
• store accepted player progress
• submit Resource Delivery progress
• cap delivery progress at the required amount
• complete the contract when the required amount is reached
• reject extra delivery after completion
• persist contract data after save/load

At this point everything was still driven through admin/debug actions. That was intentional. Before building UI, I wanted to know that the saved contract shape and state transitions were usable.

June 4 - Inventory-Facing Resource Delivery

The next step was moving Resource Delivery closer to real gameplay.

Resource Delivery stopped being only a number change in saved contract data. I added an inventory-facing test path where Wood can be removed from a real player inventory before progress is applied to the contract.

That still ran through admin/debug actions, not through the real Contract Board UI yet, but it proved the handoff that delivery contracts need: inventory content gets consumed first, then accepted delivery progress is applied.

I also added the first query and cancellation paths:

• board contracts can be requested with an optional state filter
• player contracts can be requested with an optional state filter
• available and accepted contracts can be cancelled
• completed contracts reject cancellation
• cancellation currently uses a simple creator-only check

This was still not player-facing, but it gave the future board UI something useful to ask for.

June 5 - Contract Actions And UI-Ready Queries

After the inventory delivery path, I worked on the contract actions and query data that the first board UI would need.

I added the first leave-contract path so an accepted player can leave a contract without refunding already submitted progress. If other players are still participating, the contract stays accepted. If the leaving player was the last participant, the contract returns to available.

I also added player participation queries and board/player view entries. That let the UI-facing path ask more useful questions than “does this contract exist?”:

• is this player already participating?
• what progress data belongs to this player?
• should accept, leave, cancel, or complete actions be available?

The important part was centralizing rules before the widget started sending real action requests. I did not want the UI to decide one thing while the server-side accept action enforced another, so the accept checks started moving into a shared rule path.

June 6 - First Placed Board And UI Shell

This was the point where the mod started moving from debug helpers into the actual Contract Board flow.

I created the first placed ContractBoard structure path, connected the board interaction event to the contract system, and made the board register with a stable BoardId. I also started resolving player identity from the interacting player controller instead of relying on the old debug player string.

The board can now capture the placing player, keep early tribe/team ownership context, and query contracts attached to that board.

I also added the first board UI buff path. The board interaction can now move through a buff-owned UI flow instead of letting the widget own gameplay requests directly. That matters because the widget should mostly display data and emit button requests; the buff/server path should own real contract actions and refresh behavior.

The first board UI shell is in place:

• contract list
• detail panel
• entry selection
• progress display
• participants/rewards rows
• close behavior moving toward the buff owning widget lifecycle
• create-contract button reaching the server and adding a contract to the board

It is still rough. The board UI can show early board contract data, but accept and leave from the UI are not working yet, and the list/detail refresh still needs more work. The useful part is that the project has crossed from “the contract system works in debug” into “the contract system can start being used from the actual board.”

Current Next Steps

The next work is to make the first board flow usable instead of only reachable.

My current priority is:

• finish the board list/detail refresh flow
• connect accept, leave, and cancel buttons through the widget, UI buff, server requests, singleton actions, and board refresh
• fix board cleanup by collecting matching contract indices first and removing them in reverse
• keep the widget display-focused and let the buff own server requests and refresh behavior
• separate tribe board behavior from personal board behavior after the basic UI flow is stable
• add tribe/team permission checks once the board action path is reliable

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.