Start here: use AI as a coding assistant
You do not need to be a professional programmer to begin. A practical first step is the TurningLine Coding Studio, which helps you describe a game idea in plain English and turn it into a structured coding prompt for AI coding tools.
Use it to plan a small game, generate starter code, ask for debugging help, improve controls, add scoring, or learn what the code is doing. Treat AI-generated code as a draft, not as finished software.
What kind of game should you build?
Start with a game that can be understood in ten seconds and played in one browser tab. Simple games are easier to review, easier to debug, and more likely to be played.
Good first projects
- Arcade shooter
- Puzzle game
- Quiz or trivia game
- Memory card game
- Solitaire or simple card game
- Chess/checkers variant
- Endless runner
- Word game
- Clicker or timing game
- Educational challenge
Core features to include
- Clear start screen
- Simple controls
- Score or progress tracking
- Restart button
- Pause/help screen if needed
- Readable text on mobile and desktop
- No broken assets
- No external login requirement
- No surprise redirects
- Short instructions inside the game
The preferred technical format
GoodVideoGames is designed around browser-playable games. The easiest submission is a static web build that runs from an index.html file.
| Item | Preferred | Why it matters |
|---|---|---|
| Main file | index.html | Gives the reviewer and hosting system a clear entry point. |
| Code | HTML, CSS, JavaScript | Works in the browser without server execution. |
| Assets | Images, audio, JSON, fonts | Local assets are easier to review and host. |
| Package | One ZIP file | Keeps the upload organized. |
| Cover image | PNG/JPG/WebP | Used as the game card and social preview image. |
| External services | Avoid when possible | Outside network calls slow review and can create privacy/security risk. |
How to package your ZIP
Your ZIP should open cleanly and should not require a build step from the reviewer unless you are specifically submitting a source project for build review.
my-game.zip
├── index.html
├── styles.css
├── game.js
├── assets/
│ ├── cover.png
│ ├── player.png
│ ├── enemy.png
│ └── click.wav
└── README.txtThe README.txt should briefly explain the controls, goal, scoring, and whether any special browser feature is used. It does not need to be long.
What is allowed
The site is intended for playable, non-malicious, creator-made browser games that can be reviewed and hosted responsibly.
Allowed and encouraged
- Original browser games.
- AI-assisted games where you reviewed and tested the code.
- Educational games and brain teasers.
- Retro-inspired arcade games with original names/assets.
- Simple card, board, puzzle, sports, quiz, and strategy games.
- Games with local save data for scores/settings.
- Optional sound/music that can be muted.
- Games with imaginary points, coins, credits, or demo balances when clearly labeled.
- Clean cover images and screenshots that accurately represent the game.
Allowed only with care
- Casino-style or slot-style mechanics must clearly state that all money/credits are imaginary, have no real value, cost nothing, and cannot be redeemed.
- Public-domain or open-license assets must follow their licenses.
- Inspired-by mechanics are usually fine; copied names, art, music, characters, or logos are not.
- AI-generated art/audio should be checked so it does not copy or impersonate a real brand or protected character.
- Network features must be disclosed and may be rejected if they are not needed.
What is not allowed
Submissions may be rejected or removed if they create security, legal, privacy, or user-safety problems.
- Malware, spyware, miners, credential theft, or harmful scripts. Anything designed to damage, track, steal, exploit, or deceive users is prohibited.
- Real-money gambling or redemption. No wagers, deposits, cash-out, prizes of real-world value, or paid chance-based rewards.
- Forced payments or paywalls. Players must be able to start playing for free.
- Unapproved redirects. Games should not push players to outside sites, app stores, downloads, ads, or sign-up pages.
- Hidden network calls. Do not send data to outside servers without a clear need and disclosure.
- Copyright infringement. Do not upload games using protected characters, music, art, names, logos, or copied code unless you have rights.
- Adult sexual content or explicit nudity. Keep games appropriate for a broad public arcade.
- Hate, harassment, or targeted abuse. Do not attack protected groups or encourage harassment.
- Extreme graphic violence or shock content. Arcade action is fine; graphic gore or torture content is not.
- Illegal instructions or dangerous real-world behavior. Games should not teach or enable crime, weapon construction, self-harm, or abuse.
- Credential/API-key exposure. Never include private API keys, passwords, admin tokens, database credentials, or private URLs in a public game ZIP.
- Server-side code in normal game uploads. PHP, Python, Node backends, executable files, and database dumps should not be included in a static game submission.
Security and privacy expectations
Games should run as self-contained browser experiences. The safer the game is to inspect and host, the faster it can move through review.
Quality checklist before you submit
A game does not need to be perfect, but it should be playable. Test the simple things before uploading.
Gameplay
- Clear objective
- Responsive controls
- Working restart
- No dead-end screens
- No impossible first move
- Score makes sense
Presentation
- Readable title
- Good cover image
- Legible instructions
- Mobile/tablet check
- Sound can be muted
- No broken image/audio files
Submission
- ZIP includes index.html
- Game name is final
- Description is honest
- Controls are explained
- Category is accurate
- Special warnings disclosed
How review works
Submissions go through a review queue before being listed. Review may include file checks, source inspection, sandbox testing, and basic gameplay validation. A game can be approved, rejected, or sent back for changes.
Improving your game after launch
Use ratings and reviews as practical feedback. Most games improve through small iterations: clearer instructions, better controls, cleaner difficulty, stronger cover art, shorter loading time, and better mobile layout.
When updating a game, keep version notes. Explain what changed, what bugs were fixed, and whether the scoring or controls changed.