Skip to content
Bastard Games home

DRAFT — pending legal review

Content Policy

Version 2026-10-draft

This is placeholder text. It describes the rules we apply today; counsel will review the wording.

What is allowed

Anything legal and safe can be listed. We do not judge quality. Games made with AI are the point of the store, and every game must say how AI was used.

What is not allowed

  • Pornographic games and pornographic store images. Images that show sexual acts or exposed genitals are rejected.
  • Illegal content of any kind, including child sexual abuse material, which we report to the authorities.
  • Intimate images of a real person shared without their consent, including AI-generated ones.
  • Deepfakes of real people without their consent.
  • Malware, or anything built to harm the computer of the person running it. Real-money gambling is also not allowed.
  • Content that infringes someone's copyright or trademark. See the DMCA policy.
  • Games that use the name of a well-known game, film, TV show, anime or toy franchise or character in a way that suggests they come from, or are endorsed by, its owner.

Mature content

Games with graphic violence, nudity or loot boxes are marked mature. Developers declare this when they publish, and our image check also marks a game mature when its store images show nudity. A mature game's page shows only its title until the viewer is confirmed as an adult:

  • signed in, the date of birth on your account decides (18 or older);
  • signed out, you confirm you are 18 or older with one click, and we remember that in a cookie (see Cookies).

Accounts under 18 cannot view or buy mature games.

How we check

Before a release goes live, automated checks run on it:

  • a malware scan (ClamAV and custom rules) of every file, including inside archives;
  • for Mac builds, a check that everything in the build is signed by one team: every app must be signed and notarized, with its ticket stapled; every program outside an app must be signed with a Developer ID Application certificate; and a .pkg installer must be signed with a Developer ID Installer certificate and notarized. A .dmg is opened to check it, and one holding a folder the scan can't read (for example a locked .Trashes folder) is rejected;
  • for Windows builds, a check that the main programs are validly signed: the .exe or .msi you upload, or the .exe and .msi files at the top level of a zip (when its top level has none, every .exe in the zip). We remember the exact set of their signers when your first signed release goes live, and a later release whose main programs have another set of signers is rejected until we reset that at your request: adding or dropping a main program signed by someone else changes the set. The libraries and other programs in the build may be signed by anyone, but a broken signature fails; unsigned ones only get a warning, as do unsigned scripts at the top level;
  • a build uploaded as a shell script (a file starting with #!, or named .sh, .run, .bash or .command, that is not an ELF program) must be plain UTF-8 text. One with anything else in it, such as a self-extracting installer's packed data, can't be scanned and is rejected;
  • for games that can be remixed, a scan of the remix pack for secrets and for code that cannot be redistributed;
  • a check of the title, tags and game address against a list of well-known names. A match holds the release for review by a person and the game is not listed in the meantime. This is automated, and a person makes the decision.
  • an AI image classifier that labels the cover and screenshots for sexual content. The images are sent to an AI model through Vercel's AI Gateway for this. The model does not decide on its own: a high-confidence explicit label rejects the release, which the developer can fix and republish;
  • a check for the game engines and libraries each build uses. For open-source ones we show their license notices on the game's notices page (/games/<slug>/notices) and warn the developer when a build doesn't include them. These checks only warn; they never stop a release.

We do not review games for quality or approve each one in advance. We also rescan live games when the malware signatures update.

Removed files stay removed

When we remove a release after a valid notice, its files go on a blocklist. A later upload with any of those files, including a file inside an archive, is rejected. Identical copies already on the store are removed automatically, with a statement of reasons to their developer, when the file was part of a removed game build or remix pack, or is uploaded again to the same game. Other matches, such as a store image shared with a removed release, go to a person for review. Removing a copy does not add a copyright strike by itself.

Download monitoring

We watch how often each game is downloaded, to catch a game used as file hosting. When a game's downloads in an hour are more than 500 and more than 50 times its average hourly downloads over the previous 7 days (or twice both over two hours), our operators get an alert and review it. Nothing is removed automatically.

Reviews

Reviews follow this policy too. We can remove a review that breaks it: its author gets an email with the reason and can't post another review of that game, and can dispute the removal through Contacts. Authors can delete their own reviews at any time.

Reports and takedowns

Anyone can report content using the forms linked in the footer: copyright, trademark, intimate images shared without consent, and other illegal content (EU Digital Services Act, Article 16).

  • Copyright: we aim to act within 24 hours of a complete notice.
  • Trademark: we review within 72 hours.
  • Intimate images: we remove them within 48 hours of a valid request, and usually much sooner.
  • Other illegal content: we review within 72 hours and email you our decision, the reasons and how you can seek redress.

Every takedown is listed in the takedown log.

When we act on a game or an account

We can remove a release, quarantine it, remove a game, or terminate a developer account. When we do:

  • The developer gets a statement of reasons by email: what we did, the facts, whether automated means were used, the legal or contractual ground, and how to appeal.
  • The developer can appeal from their dashboard. A person who did not take the original decision considers the appeal where we can. We tell the developer our decision. [TBD by counsel: who decides appeals, and the time limit for the appeal]
  • A developer can also use out-of-court dispute settlement where available, or go to a court.
  • Copyright removals can be answered with a counter-notice. See the DMCA policy.

Contact

See Contacts.