Automating Family Farm: Reverse Engineering a Facebook Game's Daily Rewards

My best friend plays Family Farm—a casual farming game on Facebook. Like most modern games, it has daily login rewards, time-gated bonuses, and a bunch of things you need to manually click every single day to claim. Miss a day? You break your streak. Traveling? Too bad. Have a life? The game doesn't care.

He mentioned how annoying it was to log in every single day just to click buttons. So I did what any reasonable developer friend would do: I reverse-engineered the game's JavaScript and built a bot that claims everything automatically. Because that's what friends are for, right?

P.S. I might be abusing my new custom emoji system a bit in this post. No regrets.

The Problem

Family Farm has several daily tasks that require manual interaction:

• Daily sign-in rewards — click to claim your daily bonus
• Online time rewards — claim rewards after being online for X minutes
• Monthly login calendar — click each day's reward
• Various spawners and timers — all requiring manual interaction

Missing even one day resets progress. Playing on vacation means logging in just to click buttons. It's not engaging gameplay—it's a chore disguised as a game mechanic.

The Plan

I needed a bot that could:

1. Navigate to the game automatically
2. Handle Facebook authentication
3. Wait for the game to fully load
4. Execute JavaScript to claim all available rewards
5. Run continuously, claiming rewards at the exact moment the day resets (5:00 AM)
6. Recover gracefully from errors and network issues

The tech stack:

• Puppeteer — headless Chrome automation
• Node.js — runtime environment
• Facebook cookies — persistent authentication

Diving Into the Game's Code

The first challenge was understanding how the game actually works. Family Farm loads a massive minified JavaScript file that contains all the game logic—over 50,000 lines of obfuscated code with no source maps or documentation.

I opened Chrome DevTools and started exploring. The game exposes a global object called GF (presumably "Game Framework") that contains all the models, controllers, and methods. After setting a few breakpoints and poking around with some guessing work, I found what I needed.

Here's an example of what the game's reward system looks like:

// Online time reward structure
GF.webOfficialEntranceModel.isOnlineCanClaim()  // Check if available
GF.webOfficialEntranceModel.claimReward(id)     // Claim it

The pattern was clear: standard model-view-controller architecture, just heavily minified and scrambled. Once I mapped out the structure, I could call these methods directly through Puppeteer's page.evaluate() function—essentially running my own code in the game's browser context as if I were the player clicking buttons.

Building the Bot

The core logic is straightforward: inject JavaScript into the page that checks for available rewards and claims them. Puppeteer's page.evaluate() runs code directly in the browser, giving me full access to the game's internal methods.

Here's a condensed example of the bot's loop:

async function executeClaim(page) {
    const result = await page.evaluate(() => {
        const logs = [];
        
        // Check and claim online time reward
        if (GF.webOfficialEntranceModel?.isOnlineCanClaim?.()) {
            logs.push('Claiming online time reward');
            GF.webOfficialEntranceModel.claimReward(rewardId);
        }
        // Check and claim daily sign-in
        if (!GF.webOfficialEntranceModel.isSigned(currentDay)) {
            logs.push(`Signing in for day: ${currentDay}`);
            GF.webOfficialEntranceModel.callServerCalendarSignIn(currentDay);
        }
        
        return logs;
    });
    
    result.forEach(log => console.log('  ✓ ' + log));
}

The bot loops through each reward type—online time bonuses, daily sign-ins, monthly calendars—checking availability and claiming them. It logs everything so I can verify it's working correctly.

Handling Authentication: The Cookie Evolution

Initially, I tried the simple approach: extract the game's session cookies from my browser and load them in Puppeteer. This worked great—for about a day... Then the session expired, and I was back to square one with no way to programmatically renew it.

The game's authentication flow goes through Facebook OAuth, which creates a chicken-and-egg problem: I need to be logged into Facebook to get game cookies, but I can't automate Facebook login without... well, automating Facebook login.

So I pivoted: instead of using game cookies, I'd use Facebook cookies and let the bot handle the entire login flow automatically.

The bot now:

1. Loads saved Facebook cookies from a JSON file
2. Navigates to the game
3. If login is required, clicks the Facebook button
4. Waits for the OAuth popup and clicks "Continue as [Name]"
5. Saves the updated cookies for next time

This means as long as Facebook stays logged in (which persists much longer than game sessions), the bot keeps working. And if Facebook logs out, I just need to manually log in once—the bot handles everything from there.

Scheduling: The 5 AM Problem

Family Farm resets daily rewards at 5:00 AM. The bot needs to wait until exactly that moment, then claim everything for the new day.

I wrote a simple loop that calculates the milliseconds until 5:00 AM, sleeps until then, refreshes the page, waits for the game to load, and claims all rewards. Then it calculates the next reset time and repeats.

It's been running for months, waking up at 5:00 AM every day like the world's most reliable alarm clock.

Error Handling & Resilience

Games crash. Networks drop. Servers hiccup. The bot wraps everything in a try-catch that waits a minute on errors and restarts itself. If anything goes wrong, it recovers automatically—no manual intervention needed.

Deploying to Production: PM2 on Linux

Once the bot was working on my local machine, I needed it to run 24/7. My best friend isn't going to SSH into a server to start a script every time it crashes—and even if he would, explaining Linux to a non-technical person is like teaching calculus to a cat.

Enter PM2—a production process manager for Node.js applications.

I set this up on my Linux server with a few commands:

npm install -g pm2
pm2 start farm-claimer.js --name "farm-bot"
pm2 startup && pm2 save

PM2 handles auto-restart on crashes, logging, monitoring, and startup on boot. The bot now runs silently in the background, claiming rewards every day at 5:00 AM like clockwork. My friend gets all his rewards without lifting a finger, and I get the satisfaction of solving a problem with code.

What It Looks Like Running

When you start the bot, it logs everything:

Starting Farm Claimer (Continuous Mode)...
Navigating to farm...
Game loaded successfully!

==================================================
Executing claim script at: 11/9/2025, 5:00:05 AM
==================================================

=== Claim Results ===
  ✓ Claiming online time reward
  ✓ Signing in for day: 9
  ✓ Claiming day 9 monthly reward
=====================

Next claim scheduled for: 11/10/2025, 5:00:00 AM
Time until next claim: 23h 59m

Simple, clear, and it just works.

What I Learned

1. This approach works on most web games
The techniques I used here aren't unique to Family Farm. Most browser-based games expose their internal APIs in some way, making them vulnerable to this kind of automation. If it runs in a browser, it can probably be automated.

2. Games are just state machines
Once you understand the state (models) and actions (methods), you can replicate any user interaction programmatically.

3. Browser automation tools are absurdly powerful
Whether it's Puppeteer, Selenium, Playwright, or any other framework—these tools let you control entire web applications programmatically. They're not just for testing; they're Swiss Army knives for web automation.

4. Error handling matters more than the happy path
The bot's been running for months because it gracefully handles failures and restarts itself. Production code is about recovery, not perfection.

Ethical Considerations

Is this "cheating"? Technically, yes. Practically, it's automation of tedious tasks that shouldn't exist in the first place. This isn't about gaining competitive advantage—it's just not missing daily rewards because someone has a job, hobbies, and a life outside clicking buttons.

Family Farm is a single-player game with optional multiplayer elements. The bot doesn't affect other players, doesn't exploit real money transactions, and doesn't break anything. It just clicks buttons on a schedule.

That said, this violates the game's Terms of Service. The game could patch the exploit, maybe ban us. Consider this a learning exercise, not a recommendation.

Final Thoughts

This project scratched a very specific itch: my best friend loved the game, but hated the dailies. Building the bot was more fun than the problem it solved—and honestly, that's the best kind of side project.

The code is rough, pragmatic, and purpose-built. It's not enterprise-grade—it's "help a friend out on Saturday morning" code. And that's fine. Not everything needs to be polished; sometimes "working" is good enough.

Now if you'll excuse me, my friend can enjoy his free daily fertilizer, and I can enjoy my weekends without him bugging me to make this script. Win-win.

---

As always my friends, stay magical.