A 65-second video went around X this week. A narrator says he reverse engineered Block Blast, the most downloaded mobile game of 2025, and found that how well you do has "less to do with your skill" than with how much you are worth in ads. Code flashes by: a machine-learning model, rules with names like Boost Then Kill, a "Death Algorithm", a secret high-score bump after you watch a revive ad.
Those are big claims, and the video gives you about a second and a half per code screen to judge them. So I did the boring thing. I pulled every frame that shows code, read them at full size, ran text recognition over the unique ones so I could search them, and then checked each claim against two things: what the frames actually show, and what is known about the game and the tools from the outside. This post is the result.
Why I believe the frames are real
The engine matches. This is not the first time someone has opened Block Blast. In January 2025 the YouTube channel Technically Unsure published a teardown of the Android build and showed it is a Cocos2d app whose game logic ships as embedded JavaScript, encrypted with XXTEA plus a custom twist, and they published the decrypt scripts. The frames in the new video show minified JavaScript with Cocos-style prefab calls (R.PrefabConfig.Revive, m.UI.hideUI), !1 for false, 1e3 for 1000, and single-letter module aliases. That is exactly what a decrypted Cocos bundle looks like.
The model code uses the real file format. The tree walker on screen reads left_children, right_children, split_conditions and base_weights. Those are the required per-tree arrays in XGBoost's official JSON model schema. A faker would have to know that. It also ends with Math.expm1(m), which is what you do when the model was trained on the log of revenue, the normal way to regress a target as skewed as ad income. The model file is fetched from a remote config path and is named xgboost_regression_model111.json, so it can be retrained and swapped without an app update.
The numbers are real. The chart in the video (Block Blast $127M, Vita Mahjong $89.8M, Candy Crush Saga $81.1M) is Sensor Tower's published ad-revenue ranking for January to May 2026, covering 19 countries rather than the whole world.
The naming fits the studio. Hungry Studio is a Beijing company with roughly a thousand people by the end of 2025 and a Hong Kong publishing entity, which is why some reports call it a Hong Kong studio. The code mixes English with pinyin: the offer type that ends your run is ZHI_SI_TI, which reads as 致死题, roughly "lethal puzzle". That is how a Chinese team names an internal feature, and not how an English-speaking creator would fake one.
The signals it feeds the model exist. The per-user features on screen are ad_revenue_recent, ad_revenue_max and ad_revenue_avg_reward. Both AdMob and AppLovin MAX hand the app the dollar value of every impression as it happens, with a precision flag. Keeping a recent, a maximum and an average per player is a few lines. Hungry Studio is a published AdMob partner.
The feature-flag wall fits. The video scrolls through hundreds of classes ending in Trait. Industry reporting puts the game at around 25,000 A/B tests in 2025. Hundreds of named switches is what that looks like in code.
What is not established: nobody has independently published these specific identifiers yet, the original narrator is unknown (the clip I saw was a repost), and the code is abridged on screen with plenty of ellipses. The definitive check is to decrypt the bundle from the Android package with the published tooling and search it for MultiClearBoostThenKillTrait, xgboost_regression_model or ZHI_SI_TI. That is a one-evening job for anyone who wants certainty.
Claim by claim
Three verdicts: shown means the frames show it, implied means the frames support it but the narration adds an interpretation, not shown means the frames do not contain it.
| Claim in the video | What the frames show | Verdict |
|---|---|---|
| Over $100M in ads, more than Candy Crush | Sensor Tower's January–May 2026 chart, matching the published figures. | shown |
| It takes your phone model and country | EcpmFeatureConfig: a phone map ("iPad16,6": 1, "iPhone17,2": 12, "iPhone16,2": 23, "iPhone9,4": 120) and a country map (ST: 1, US: 2, DZ: 238). Those are Apple's device identifiers for the 13-inch iPad Pro, iPhone 16 Pro Max, iPhone 15 Pro Max and iPhone 7 Plus. Low numbers for premium devices and the US, 238 for Algeria: a rank by ad value, encoded for the model. | shown |
| How much your past ads made them, and whether you turned off vibration | packageData() collects country, device model, the music toggle, the vibration toggle (read from the game's shake setting), and the three ad-revenue features. | shown |
| An XGBoost model runs on your phone and predicts your ad worth | Remote config points at the model JSON; runModel() walks the trees and sums the leaf weights. | shown |
| Depending on your value, the game gets easier or harder | Not shown directly. Implied by the trait system and the thresholds below. | implied |
| "Boost Then Kill" makes it easier until you hit your average game length | MultiClearBoostThenKillTrait records the round of a multi-clear success, a time check against killDelaySeconds, and setDeathAlgorithm selecting the lethal offer type. The "average game length" part is not on screen; the delay is just a config value. | implied |
| If it detects a really expensive ad is ready, that's when it turns on you | RewardHighValueAdHarvestTrait: HIGH_PRICE_MULTIPLIER = 3.5, MIN_HISTORY_AD_WATCH_COUNT = 3. A loaded reward ad is classed "high" when its value is at least 3.5 times a baseline; the rule only arms for players who have watched at least three. The death check requires isTargetAdReady(). | shown |
| It helps you beat your high score, then triggers the Death Algorithm | currentScoreThreshold is your previous high score plus a step; shouldTriggerDeath fires once you are no longer below it and the target ad is ready; onBottomOfferAlgo swaps the piece-tray algorithm for deathAlgorithm. | shown |
| …which rigs your next turn so there is no way to survive | Only the names deathAlgorithm and ZHI_SI_TI. The piece-selection logic itself is not on screen. Plausible, because handing out three pieces that cannot fit a nearly full board is a trivial search, but not shown. | implied |
| The first thing you see is an offer to revive if you watch that ad | Revive_Proxy with show, close, reward-over and success events; the reward-over handler hides the revive panel. | shown |
| If you revive they secretly add 10% to your high score | onAdd1ReviveSuccess computes a random integer between 0 and 10% of the high score and writes it, added to something, under a key called classScore. Whether that is the score you see or a "class" score used to bucket players is not on screen. The narration overstates this one. | implied |
| They run experiments on the exact minute to make you lose and measure which gets you to watch the revive ad | MABXiBaiTrait: a table of 240, 360, 600, 1000 and 1800 seconds, a flag for "within 15 minutes of game over", a reward equal to revives divided by revive offers, and reportArm(i, r). MAB is multi-armed bandit, and that call is bandit vocabulary. | shown |
| Hundreds of rules | Walls of trait names: EndlessDeathBoardTrait, DifferentStrategyDieTrait, HighValueInterstitialReliefTrait, NoBannerAdNewUserByDaysTrait, PlaytimeNoInterstitialTrait, LevelReviveCondiTrait and many more. The names alone are a map of their experiments. | shown |
The loop, drawn out
Put the shown pieces together and this is the machine the code describes. Read it as a loop: it runs every game.
Could a small studio build this?
Technically, yes, and faster than you would think. Nothing on screen needs a research lab.
- Per-impression value. AdMob's paid-event callback and MAX's revenue callback give you value, currency and precision for every ad. Store recent, maximum and average per player. Free.
- "Is an expensive ad loaded?" MAX says revenue is available in all ad lifecycle callbacks, so you can read a loaded reward ad's value before showing it. The other common trick is two or three reward ad units with different eCPM floors, and checking which one filled.
- The value model. XGBoost trained offline on device, country, revenue history and engagement flags, exported to JSON, evaluated by a thirty-line tree walker in the client, served from remote config so you can retrain weekly.
- Experiments. Firebase Remote Config A/B testing, and its personalization feature is literally a contextual multi-armed bandit. Or your own
reportArmendpoint. - The difficulty lever. In a block puzzle, everything is the piece generator. Board-aware piece selection, in either direction, is a small amount of code.
The hard parts are not technical.
Data scale. The model and the 25,000 experiments only work because the game has tens of millions of daily players (the studio claims 70 million daily and 300 million monthly). A per-user value model trained on five thousand players is noise. Below roughly a million installs, the honest version of all this is a couple of eCPM floors and a handful of A/B tests.
The money per player is small. Third-party estimates put Block Blast between $600,000 and $1 million a day on 55 to 70 million daily players: about one to three cents per player per day. A simple puzzle game with ten thousand daily players makes on the order of a few hundred dollars a day from ads. The fortune comes from the install machine (368 million downloads in 2025, the most of any game, bought with relentless TikTok and Instagram advertising) and from retention that stayed near 50 percent a year in. The kill switch is the garnish, not the meal.
The two pieces I would not copy
Of the thirteen mechanisms in the table, eleven are things every ad-funded game does or could do openly: value-aware ad pacing, eCPM floors, a rewarded revive, adaptive difficulty for retention, bandits over offer timing. Two are different in kind, and they are also the two the narration is least sure about.
- Covertly rigging an outcome to force an ad view. Apple's review guidelines ban "hidden, dormant, or undocumented features" and the Developer Code of Conduct names "manipulative practices" as grounds for termination. Google Play's deceptive-behavior policy bans apps that are "functionally deceptive in any way" and demands behavior transparency. In the US the FTC treats manipulative design as an unfair or deceptive practice; Epic paid $245 million in 2022 for dark patterns in Fortnite. EA was sued, and the case later dropped, merely over the suspicion that its dynamic difficulty pushed loot-box spending, and EA's patent on that difficulty system is public (US 10,286,323).
- Writing an inflated score. Apple lists "false information and features" as a rejection reason; Google's policy covers misleading users about functionality.
Nobody has sued or sanctioned Hungry Studio over any of this as of today, and Apple put an ad-free Block Blast on Apple Arcade this autumn, so the enforcement risk is theoretical right now. It is still the part of the design that a motivated journalist, regulator or class-action firm could turn into a case overnight, and this video is exactly the evidence they would use.
What I would build instead
A clean version of the same engine keeps almost all of the revenue logic and drops the two deceptive pieces:
- Predict per-player value and use it to decide which ad to show and when: interstitial frequency, reward placements, eCPM floors, ad-free windows for new players. That is what the
HighValueInterstitialReliefTraitandNoBannerAdNewUserByDaysTraitfamily of flags does, and it is standard. - Use difficulty adjustment for retention, say so in the store listing, and never couple a specific loss to a specific loaded ad.
- Offer the rewarded revive on every loss. Rewarded ads convert when the player wants the revive; the forced-loss version mostly buys one-star reviews and refund tickets, which Apple now counts against you.
- Run bandits over offer timing and ad pacing, not over when to end the player's run.
I like the genre and I like the engineering, so a colorful puzzle game built on the clean version is next on the bench. More on that when there is something to show.
Sources
- Sensor Tower's ad-revenue ranking for January–May 2026, as reported by Game World Observer and WN Hub.
- Android Reverse Engineering, Part 2: Cocos2D Analysis by Technically Unsure (Block Blast is Cocos2d with XXTEA-encrypted JavaScript; scripts in the linked gist).
- XGBoost JSON model schema and the model parser example.
- 36Kr on Hungry Studio (Beijing headquarters, founder, headcount, revenue), AppLixir's Block Blast playbook, Felix Braberg's Black Friday estimate, and the AdMob case study.
- Apple device identifiers.
- AdMob impression-level ad revenue, AppLovin MAX impression-level user revenue API, Firebase Remote Config personalization.
- EA's dynamic difficulty patent, the class action and its dismissal; the FTC order against Epic Games.
- Apple App Review Guidelines (1.1.6, 2.3.1, 2.5.18, 5.1.2, 5.6) and Google Play's Deceptive Behavior policy.
- TechCrunch on Block Blast joining Apple Arcade.