I was playing PK Echoes — a browser-based geo-location MMO, the kind of game that probably shouldn't have held my attention past day two — and I opened DevTools out of habit. Just to see. What I found was a clean REST API with Bearer token auth and structured JSON responses. No obfuscation, no compiled client to decompile, no challenge to speak of. The whole game was just HTTP calls.
I could have closed the tab. Instead, I opened a Python file and started taking notes.
The Game
PK Echoes is a location-based MMO that runs entirely in the browser. Players are dropped onto a real-world map, where they harvest resources (wood, ore, leather, herbs), fight mobs ranging from squirrels to dragons, claim and defend territories, and trade on a player-driven marketplace. The mechanics are simple. The depth comes from the economy and the territory control.
The important thing for this story: every game action is an HTTP request. Move to a new location: PUT /api/character/position. Chop a tree: POST /api/world/interact/start, then POST /api/world/interact/complete. Buy something on the market: POST /api/player-marketplace/orders. The client is thin. The server does the work. And once you see that, you can't unsee it.
Mapping the API
There were no docs. No community wiki with endpoint tables. No desktop client to throw into a decompiler. The only tool available was the browser's network tab, a Python environment, and time.
The methodology was simple: do a game action, find the corresponding request, copy it into a Python requests call, fire it manually, see what happens. Change one parameter. Fire it again. Build up a mental model of what the server actually cares about.
Within a few sessions I had the core surface mapped:
POST /api/auth/login
GET /api/auth/character # position, stats, active inventory
GET /api/world/data # ~1.5MB: every visible object on the map
POST /api/world/interact/start # begin an interaction with an object
POST /api/world/interact/complete # resolve the interaction, collect rewards
PUT /api/character/position # move the character to new coordinates
POST /api/territory/{id}/travel # fast-travel to a placed flag
GET /api/player-marketplace/orders # current market listings
POST /api/player-marketplace/orders # place a buy or sell orderThe one that unlocked everything was GET /api/world/data. It returns roughly 1.5 megabytes of JSON on every call — every nearby resource node, every mob, every territory polygon, every player-placed flag in range. Fully structured, consistently shaped. That single endpoint became the backbone of almost everything built afterward.
One other thing worth noting: the position endpoint accepted arbitrary GPS coordinates. There was no server-side check on how far you'd moved between calls. You could teleport anywhere on the map instantaneously. That detail mattered later.
What I Built First
The first tool was theguibuild.py — 294 lines, plain dark tkinter, three buttons: Chop, Mine, Gather. Press a button, it calls /api/world/data to find nearby nodes of that type, then loops through interact/start and interact/complete for each one. Functional. Ugly. Did exactly the thing.
The second pass was automagic.py: instead of harvesting one territory and stopping, it looped. Travel to a flag, clear every node nearby, travel to the next flag, repeat. The teleportation quirk meant this ran in seconds instead of minutes — the bot covered ground the game never expected a player to cover.
From there: market tools. market_intel.py scraped current prices and tracked them over time. A separate analysis file calculated, commodity by commodity, exactly how many units you'd need to buy off the market to push prices to a given target. Purely analytical. I wanted to understand the shape of the economy.
And then the mapper. The /api/world/data response included territory polygon coordinates — the actual geographic boundaries of every claimed zone on the map. I piped those through Shapely for geometry operations, color-coded them by owner, and exported to KML. The output file, Bay_Area_detailed.kml, was 93.7 megabytes. The entire game map of the Bay Area, rendered in Google Earth, with every territory boundary drawn to scale.
That was the solo phase. It lasted about three weeks.
Teaching Someone to See It
My brother has no technical background. He plays games. He doesn't write code.
I showed him what I'd built — not by handing him the scripts, but by sitting down and walking him through the network tab. We opened the game, did a harvest action, and I pointed at the request. "See that? That's the game. Not the graphics, not the interface — that request is what's actually happening." I showed him the response. I asked him what he thought each field meant.
That framing — the game is just HTTP calls — is the thing I wanted him to internalize before anything else. Not Python syntax. Not API concepts. Just: this thing you interact with through a screen is actually a structured conversation between your browser and a server, and you can participate in that conversation directly.
Some parts clicked immediately. JSON is readable. Bearer auth is a single header. The pattern of request-response is intuitive once you see it a few times. Other parts took longer — the interaction loop (start before complete, always), what a 404 actually means mid-loop, why you'd need a session object instead of individual requests.
I could get him through the concepts in a session. What I couldn't do was be there at midnight when his loop was failing and he couldn't figure out why.
That's where AI came in. He could ask it to explain what requests.Session does. He could paste in a stack trace and ask what went wrong. He could describe what he wanted — "I want to attack the nearest mob, wait for it to die, pick up the loot, then find the next one" — and get back working code to study and modify. The gap between "I understand this in theory" and "I can build something" used to require either a lot of time or a more experienced person on call. AI compressed that gap dramatically.
I opened the door. AI kept it open while he walked through.
What He Built
Two weeks after that first session, he had shipped u-kombat.py.
I want to put the scale of this in concrete terms. My original tool, theguibuild.py: 294 lines, three buttons, no combat system. His tool: 2,288 lines, a custom Theme dataclass with neon green styling (#39FF14), and a multi-window interface with dedicated panes for Radar, Inventory, Scanner, Recipes, and Travel. I had never written a single line of combat logic. He had written an entire combat bot.
The combat system alone was a substantial piece of engineering. It targeted mobs by type — a configurable list of 14 targets, from squirrels and rabbits up through wolves, orcs, trolls, golems, and Giant Spiders. It polled character health continuously, switching between passive and active polling rates depending on whether combat was in progress. It had an emergency healing threshold: if health dropped below a configurable percentage, it would use a quick-slot healing item before continuing. After a kill, it looped back through the loot pickup cycle before finding the next target.
He kept going. By September 27 — roughly two weeks after the first teaching session — he had merged everything into Ai Alientech v2.5.2 MAIN.py: 151 kilobytes, over 3,000 lines, combining gathering, combat, crafting, market integration, inventory management, and the radar display into a single tool. A complete gameplay automation suite.
I had built a gathering script. He built the whole game.
What This Is Actually About
The PK Echoes bot is not the interesting part of this story.
The interesting part is that my brother — who had no technical background, had never written a line of Python, had no reason to believe he could build something like this — now builds his own games. Not modifications of my scripts. His own projects, from scratch, using AI as his collaborator. The PK Echoes bot was the first thing he made. It won't be the last.
What made the difference wasn't raw ability or prior exposure. It was a combination of three things: a concrete project worth caring about, someone to explain the underlying model rather than just hand over code, and a tool that could answer questions at any hour without getting impatient.
The barrier to building hasn't disappeared. You still need to understand what you're trying to do. You still need to learn to read error messages, to think in loops, to model state. But the time it takes to go from "I understand this in theory" to "I shipped something that works" has collapsed in a way that wasn't true five years ago.
I've thought a lot about what I actually gave him in that first session. It wasn't the harvesting script. It wasn't even the API knowledge. It was a way of seeing: the things you interact with are made of parts you can understand and manipulate, if you look at them the right way.
Once you see that, you can't unsee it. That's the part I'm proud of.