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 emulator 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.

Splitting that number with tabs

The concurrency setting is one number, but it does not have to be one queue. Tabs across the top of the Accounts screen let you carve your accounts into groups that each get a slice of it and run at the same time, under the same Start button.

This matters as soon as your accounts stop being alike. A handful of accounts running long rallies and fifty small farms in one queue means the rally accounts hold workers for a long time and the farms wait behind them. Put the rally accounts in their own tab with two workers and the farms in another with six, and neither can crowd the other out. Each tab also laps on its own schedule, so short accounts come around quickly instead of waiting for a long account's cycle to end.

Three things worth knowing before you split anything up:

• Main is the master tab. It holds every account you have not moved, it takes whatever workers your other tabs do not use, and it is served first — so it can never be left with nothing, whatever numbers you type elsewhere.
• You never set Main's number. Set the total in Settings, give each tab you create a ceiling, and Main gets the remainder. The strip shows the live split.
• A tab has an on/off switch. Switch one off and it takes no workers and does not run at all, while remembering its worker count for when you switch it back on. That is the tidy way to park a set of instances you use for something else, rather than disabling accounts one by one.

Moving a group with its header button takes every member together. Moving a single account out of a group moves only that account — it keeps its membership, so the group is then drawn in both tabs, each showing the accounts it has there. The header count still says the total, so "1 of 4" tells you where the rest are.

Worker changes apply on the next Start, not mid-run.

If your accounts are all much the same, you do not need tabs. The moment one kind of account is starving another, that is what they are for. Full detail in account tabs.

One instance per account

Each account binds to one instance of your emulator, LDPlayer or MuMu Player. The binding is to the instance itself rather than its name, so renaming instances in the emulator later won't break anything. An account remembers one instance per emulator, so switching between LDPlayer and MuMu Player in Settings keeps both sets of bindings — see MuMu Player setup.

Make new instances rather than cloning one. A clone carries its original's identity across, which can cause login problems. Instead, create the instances you need, select their accounts, and use Update / Install Game with Copy game files from pointed at one instance that has already logged in. Every new instance gets the game and its first-login files in one go, so nothing downloads the game's extra 2 GB forty times over. The Rebuild Instances guide explains the copy, and Rename Selected there names every instance after its account.

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.

Put it at the top of that account's action list. The bot works down the list in order, so anything above Account Switch runs as whoever the emulator was already on — the other account's character. Nothing errors; the work simply lands on the wrong person. Full detail in account switching.

This is the exception to one-instance-per-account: the instance is shared, the characters take turns.

Configuring a farm without going mad

Three features exist specifically so you don't configure forty accounts one at a time:

• Apply to selected copies an action setup onto every selected account in one go. Set one account up exactly as you want it, then push that configuration across the rest. See copying actions.
• Saved profiles in the Profiles library 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.
• Account profiles let each account keep several setups, such as War and Farm, and switch a whole selection or group between them at once. See account profiles.

Configure on the same toolbar is a different thing: it writes the recommended settings into the selected accounts' instances, and it waits for the bot to be stopped.

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. What you can change is who waits behind whom — that is what tabs are for.

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.