How we review games
This is the checklist we run before a title is treated as a high-priority page on ragdollhit.info. We are not scoring “fun” in the abstract—we are checking whether the embed works, whether controls match what we publish, and whether the session is fair on desktop and mobile.
Who runs the review
Reviews are done by the Ragdoll Hit editorial team—the same people who maintain game pages, category hubs, and site policies. We are an independent browser catalog focused on ragdoll, stickman, and physics games. We do not claim to be the original developers of third-party embeds; when a build is hosted elsewhere, we say so on the game page.
Questions about a review outcome: info@ragdollhit.info.
Review checklist
1. Does it actually load?
We open the same embed players get on the game page. If the frame stays blank, throws a host error, or needs a login wall, the title fails review until the embed is fixed or replaced. We do not publish “play now” for builds we cannot launch ourselves.
2. Load time
We note first interactive time on a normal laptop connection. Titles that sit on a spinner for a long time without progress get a warning note on the page or stay off the featured / high-priority lists until the host improves. Instant black screens count as load failures, not “slow.”
3. Desktop play
We test keyboard (and mouse when required) in Chrome or Edge: focus inside the frame, movement, jump/kick/grab or title-specific actions, pause/restart if available, and fullscreen. Broken key maps or focus-stealing ads that block input fail desktop review.
4. Mobile play
We check phones in landscape and portrait when the build offers touch pads. We record whether on-screen controls appear, whether they overlap critical UI, and whether the session is usable without a keyboard. Local two-player titles are marked keyboard-first when touch cannot support fair rematches.
5. Controls
We document the real bindings from the live build—not a generic WASD blurb. Missing grab, reversed axes, or undocumented weapon keys get written into the controls section after we verify them in-session.
6. Difficulty
We play enough rounds or stages to judge early difficulty: unfair instant deaths, soft gear gates, or fair learning curves. Boss or ladder walls that need shop upgrades are called out so players know when a wall is a gear check, not a skill check.
7. Gameplay quality
For this site, quality means readable physics, rematch value, and topical fit (ragdoll, stickman, physics fighting/sandbox). We prefer titles where knockback, timing, or sandbox tools teach something after a few runs—not empty clicker shells with a stickman skin.
8. Ads experience
We note whether the host shows interstitial or overlay ads that steal clicks, mute audio unexpectedly, or break input after a reward video. Heavy ad friction does not always remove a game, but it lowers recommendation priority and may appear in editorial notes.
9. Bugs
Soft-locks, invisible walls, save wipes, and consistent crash loops are logged. Critical bugs block index-ready status until retested. Minor visual glitches may ship with a short note if play remains fair.
10. Game session length
We estimate a typical session: one duel, one stage, or one sandbox experiment. Browser players need honest expectations—five-minute rematch loops vs. long ladders—so we write session length into guides when it is clear from play.
What happens after the checklist
- Pass: we write or refresh controls, mechanics, FAQ, and strategy notes from what we observed in the live build.
- Partial pass: the game stays playable, but we lower sitemap priority, leave a known-issue note, or hold off featuring it until a retest.
- Fail: we fix the embed, replace the host URL, or keep the page out of the high-priority index until load and controls work.
Related pages
Ownership, corrections, updates, and copyright handling are documented in Editorial standards. Legal requests go through Copyright and Contact.