What Pet Society Exposed Actually Is

Pet Society Exposed refers to a community-driven project that reverse-engineered the server-side mechanics of Pet Society, the Facebook/Bejeweled social game that shut down back in 2013. When Zynga pulled the plug, there was no official way to run the game anymore. What emerged over the next several years was a set of open-source servers, client patches, and community documentation that let people run their own private instances of the game. The "exposed" part comes from the fact that researchers had to dig into the original packet structure, cookie systems, and authentication flow to figure out how the game talked to its servers before everything went offline.

Understanding Pet Society Exposed

The core of the project is a PHP/Node-based server emulator that replicates the original game's HTTP endpoints. Players connect to it using a modified version of the original Flash client or a HTML5 reimplementation, depending on which fork of the project you're using. The most widely used versions include Pet Society Reborn and the various forks hosted on GitHub under the "pet-society" namespace. Getting this running requires a few things. You need a web server with PHP support, a MySQL or MariaDB database, and Node.js if you're using the WebSocket-based components. Most people spin this up on a VPS from providers like DigitalOcean or Linode, since you need a public IP address for the game client to reach your server. Running it locally on your home machine is possible but requires port forwarding, which introduces complications with ISP CGNAT and dynamic IPs. I spent about two weeks trying to get a clean install working on a fresh Ubuntu 22.04 VPS because the documentation across different forks is inconsistent. The README files tend to be written for slightly different OS setups, and dependency versions matter more than you'd expect. The original project was built around older PHP versions, and some of the older query patterns don't play nicely with PHP 8. The workaround I ended up using was running the database layer through an older PHP-FPM pool while keeping the rest of the stack modern. It's not elegant, but it works. The specific issue was that the auth handshake queries were using a MySQL function that got deprecated and removed in later versions. Switching the SQL mode to include `NO_AUTO_CREATE_USER` and `NO_ENGINE_SUBSTITUTION` in the mariadb config resolved it without touching the application code.

Setting Up Your Own Instance

Download the source code from the relevant repository, typically pulled via git clone from the project's GitHub page. The repository structure is fairly standard — there's usually a docs folder with setup instructions, a server directory with the emulator code, a client folder with the patched game files, and a sql directory containing the database schema. Before installing anything, check your PHP extensions. You need at minimum PDO MySQL, mbstring, json, curl, and xml. If the version you're using has WebSocket support, you'll also need the openssl extension enabled. Run `php -m` and verify these are all loaded. Missing one of these will cause a cryptic failure later that makes debugging take twice as long as it should. Install and configure the database. Create a new database, then import the SQL schema file from the repo. Most forks provide an initial data dump that seeds the item tables, pet templates, and default shop inventory. Skipping this step means you start with an empty catalog, which makes the game unplayable until you manually populate it. Configure the server settings. There's usually a config.php or .env file where you specify the database credentials, the server URL, and optional settings like coin starting balance and XP multipliers. Set the server_url to the public IP or domain of your VPS. If you forget this, the game client will try to connect to the old Zynga endpoints and everything will silently fail with connection timeouts. Deploy the client files. These are the modified SWF or HTML5 assets that point to your server instead of the old ones. Upload them to your web server's document root. Some forks use a CDN or external hosting for the client files, which complicates things if you want everything self-hosted. The cleanest setup puts both server and client on the same domain. Point the game at your server. This is where it varies by fork. Some versions auto-detect the server from the SWF's configuration. Others require you to modify the client's config XML or set a custom header. If the game launches but doesn't load any pets or items, you're almost certainly still hitting the wrong endpoint.

Common Pitfalls and What They Look Like in Practice

One issue that catches everyone out is the timestamp handling. The original game used server-side timestamps in a specific format, and some emulators have been slow to update when switching between Unix timestamps and PHP's DateTime objects. I ran into a case where players could log in but any action that involved a time-based reward — daily bonuses, cooldown timers — was returning null values. The fix was updating the date formatting in the reward calculation functions to use `time()` consistently instead of mixing it with `strtotime` calls that were parsing the old format incorrectly. This affected roughly three to five functions in the payment handler file. Another frequent problem is the cross-origin resource sharing setup. The Flash client makes HTTP requests that cross domains if your client and server aren't on the same host. You need a proper crossdomain.xml file at the root of your web server, and it needs to allow the domain your server emulator runs on. Without it, the game fails to load assets silently. I found this one the hard way after spending four hours troubleshooting why the pet inventory wouldn't render, only to realize the SWF was being blocked by CORS before it even made the API call. Session management is another area where things can go wrong. The original game relied on a specific cookie format for authentication. Some emulator versions generate these cookies differently, causing players to get logged out randomly or unable to maintain a session across tab refreshes. The workaround here is usually adjusting the session lifetime in your PHP config and making sure the cookie domain is set correctly — it needs to match whatever domain the client is loading from, not just the server API domain.

Limitations You Should Know About

Pet Society Exposed won't give you the full original experience. A lot of the social features — gift sending, visiting other players' homes in real-time, the party system — are either partially implemented or not implemented at all, depending on the fork. The item database is also incomplete. Certain limited-edition items, event rewards, and premium-only goods simply don't exist in the source data because nobody reverse-engineered those specific packets. If you're expecting to recreate every item from the original game, you'll be disappointed. Performance degrades noticeably when you get past a few dozen concurrent players on a basic VPS. The emulator isn't optimized for high concurrency. If you plan to run a larger community, you'll need to upgrade your server specs and possibly look into caching layers for the database queries. A 2GB RAM instance handles maybe 20 to 30 active players reasonably well. Beyond that, you start seeing lag in item loading and home rendering. There's also the legal gray area. Running a private server for a discontinued game sits in a questionable space depending on your jurisdiction. Zynga hasn't actively pursued enforcement against small community servers, but that could change. The project is open source, but distributing modified client files carries its own risks. Most people involved keep their instances small and private for exactly this reason.

Who This Is Actually For

This is mainly useful for people who want to run a small private server with friends, or for researchers interested in how these social games were structured technically. It's not going to replace the original game for the general public. The community is fragmented across different forks, and there's no central hub for finding active servers. If you want to play, your best bet is joining a Discord server associated with one of the major forks and asking for an invite link. The public signup pages are mostly dead or have very restricted capacity. For developers, the codebase is worth studying even if you don't plan to run a server. The packet structure analysis, the way the original game handled economy balancing, and the client-server communication patterns are all there if you know where to look. The authentication flow alone is a decent case study in how mid-2000s social games handled session management without modern OAuth standards.