TBot2
Kingdoms · Coming soonPreview the new engine while final launch verification is completed.
Included with the same TBot2 key at launch
All Kingdoms features

Kingdoms operations

Coming soon

One account. Every village in view.

Fair scheduling, exact-village navigation and isolated runtime state for Kingdoms accounts that keep growing.

Operational brief

A growing Kingdoms account creates a scheduling problem: capital work is important, frontier villages still need service, and one broken page must not hold the entire account hostage. TBot’s Kingdoms engine keeps a durable position across configured villages and combines fairness with real deadlines.

The result is a command-center view rather than a stack of unrelated browser tabs. Each village has its own observed resources, live queue, planned work and enablement state. The browser still acts serially—one verified context at a time—while the scheduler decides where useful work is due next.

Scope
Per account
Browser control
Serialized
License
Shared
TBot2 Travian Kingdoms command center with multiple villages, resources, queues and next actions
One operational view keeps village readiness, storage pressure, live construction and planned work comparable without merging their state.
01

Fair by design

TBot does not keep returning to the first few villages. Its durable scheduler rotates service across configured villages while still respecting urgent deadlines and navigation affinity.

  • Rotating durable cursor
  • Deadline-aware ordering
  • Failed-village backoff
  • Bounded work per cycle
02

The right village at the last possible moment

URL state alone is not enough. TBot requires coherent Kingdoms routing and independent selected-village evidence before a mutation can proceed.

  • Strict HTTPS world origin
  • Exact selected-village evidence
  • Clean modal and window state
  • Fail-closed navigation
03

Legends remains isolated

Kingdoms configuration, scheduler state, receipts and logs are separated from Legends workspaces even though access comes from the same TBot license.

  • Separate game engine
  • Separate account state
  • Shared license boundary
  • Cross-game regression coverage

The operating loop

From live state to a proven result.

01

Build a current snapshot

The engine observes village identity, resources, queues and helper state without assuming that the last page is still valid.

02

Score useful work

Due times, readiness, failures and the rotating cursor determine the next eligible village instead of a fixed first-to-last loop.

03

Enter exact context

Kingdoms routing and selected-village evidence must agree before any mutation-capable workflow proceeds.

04

Leave a durable next step

Receipts, backoff and next-wake timing survive short cycles and restarts, preventing the account from starting from zero each time.

Isolation where it matters

A shared license unlocks both games, but it does not blend accounts, villages or engines. Each workspace remains understandable on its own.

  • Separate village plans and runtime observations
  • Per-village automation enablement
  • Bounded work so later villages still receive service
  • Backoff for a temporarily broken village
  • Separate Kingdoms and Legends configuration and receipts

Before you enable it

Questions worth answering.

Does one account with several villages use several paid sessions?

No. A session represents an open TBot automation workspace, not every village inside that Kingdoms account. Your plan’s session allowance is explained on the pricing page.

Will the first village always run first?

No. TBot keeps a rotating durable cursor and considers due work, so the order is not reset to the first village on every cycle.

Can Legends and Kingdoms run at the same time?

Yes, within the total concurrent-session allowance of your license. Each workspace selects its own game engine and keeps its data isolated.

Coming soon

One key. Legends now, Kingdoms soon.

The sessions in your existing TBot2 plan will cover Kingdoms at launch.