Running multiple Viking Rise accounts
Going from one account to twenty is mostly a question of two numbers that people routinely conflate, plus not configuring twenty accounts by hand.
The two numbers
How many instances you can keep is a disk-space question. Each LDPlayer instance is a full Android VM with its own copy of the game. Nothing but storage stops you having fifty.
How many can run at once is the Runtime concurrency setting, and it's bounded by CPU, RAM and disk speed. This is the number that decides whether your farm is stable.
They're independent. A machine with a big disk and a modest CPU can hold forty accounts and run six of them at a time — and that's a perfectly good setup, it just means each account comes around less often.
There's no concurrency number anyone can give you. Raise it a step at a time, watch a full cycle complete at each step, and stop when boots start timing out. See Viking Rise bot setup for the method.
One instance per account
Each account binds to one LDPlayer instance. The binding is to the instance itself rather than its name, so renaming instances in LDPlayer later won't break anything.
Build one instance properly — game installed, logged in, settings the way you want them — then use Clone player in LDMultiPlayer to copy it as many times as you need. Cloning carries the installed game across, so you're only logging into a different account on each copy rather than downloading the game forty times.
Two characters on one instance
If you play two characters on the same account, the Account Switch action moves between them without needing a second instance.
Set the Mode to match how you identify the character — by character or by IGG ID — then give it the ID and the Position in the game's account list. Add the actions you want run, and the switch action moves the instance onto that character before they run.
This is the exception to one-instance-per-account: the instance is shared, the characters take turns.
Configuring a farm without going mad
Two features exist specifically so you don't configure forty accounts one at a time:
- Bulk Configure applies an action setup to every selected account in one go. Set one account up exactly as you want it, then push that configuration across the rest.
- Saved action configs let you name a setup and reuse it later — a "farm account" preset and a "main account" preset, say, applied to whichever accounts should get each.
Bulk Configure is disabled while the bot is running. Stop it first.
Scheduling across a farm
Each action carries its own optional schedule: which days, and either all day, once per day, or a time window.
On a farm, the schedule that earns its keep is once per day for things that genuinely only need doing once — dailies, mail — so an account that cycles eight times doesn't attempt them eight times. Leave throughput actions like gathering ungated.
Time windows are worth it when your accounts should behave differently at different times, and cost you throughput otherwise. Don't reach for them by default.
What to expect as you scale
Cycles get longer as accounts share a fixed concurrency budget. That's arithmetic, not a fault: twenty accounts at concurrency six means each one waits while others work.
Restarts are normal. An account that hits a state the bot doesn't recognise gets its instance restarted rather than pushed through, and carries on from there. A few restarts across a long run is healthy behaviour, not a problem to chase.
Boots are the expensive part of the cycle. If your accounts run few actions each, most of the day goes into starting and stopping emulators — give each account more to do per visit rather than visiting more often.