What to Include in a Game Press Kit

A game press kit should let someone understand your game, check its facts and download usable media without waiting for a reply. Prepare a short public factsheet, a deliberate selection of assets and one clear contact route. Then test the kit as someone who has never opened your studio’s shared drive.
Give the kit an obvious place on the game website
Use a plainly named Press Kit link that opens the game’s current resources. It can lead to a dedicated page or a well-organized download location. Keep that route available alongside the immersive presentation, so a journalist does not have to complete an introduction or discover a hidden object to reach it.
Team Cherry’s games page places a Press Kit link beside each game’s store and website links. That is a useful example of discoverability, not evidence of a particular coverage result. Our recommendation is to give your kit a stable address and preserve that address when the files change.
Write a factsheet someone can check quickly
Start with the exact game title, a one-sentence explanation of what players do, developer and publisher names, confirmed platforms, announced release status, official website and store links, and a press contact. Add a short description that explains the central activity and what makes it interesting. Keep unannounced details out; do not turn a target date into a confirmed release date.
Give each fact one clear home. A visitor should not need to compare a biography, trailer description and old announcement to work out which date applies. Where platform releases differ, label them separately. If something is still unannounced, say so rather than leaving ambiguous placeholder text.
Treat the factsheet as working reference material. Clear sentences are more useful here than a second atmospheric introduction. Your game website’s broader presentation can carry the mood; the kit gives someone accurate material to work with.
Choose assets for different editorial jobs
Include approved game and studio logos, representative gameplay screenshots, key art and links to relevant trailers. Choose screenshots that explain different parts of play: an encounter, a readable environment or a meaningful interaction. Several nearly identical beauty shots give an editor less choice than a smaller selection with distinct subjects.
Supply original approved images rather than screenshots taken from your website. Keep the game logo available without a background where you have that version. Identify gameplay, cinematic stills and concept art accurately, and include relevant creator credits. Check that the assets are approved for the intended public use before adding them to the kit.
Supergiant’s Hades page describes a downloadable ZIP of media, wallpapers and logos and labels its trailers separately. The useful lesson is to explain what a download contains. A button called Download assets tells a visitor less than a named collection with a brief description.
Make the downloads easy to identify and reuse
Show lightweight previews on the page, then provide clearly labeled downloads of the approved files. Offer individual files for quick use and a combined package when that is helpful. State the package size so someone on a phone can decide whether to download it now. Choose filenames that identify the game, subject and relevant version without relying on a private folder structure.
For a hypothetical game called Tidepost, tidepost_gameplay_harbour_pc_01.jpg is easier to identify later than screenshot_final_7.jpg. A short asset list can explain the pictured activity, build or capture context when relevant, and any required credit. Keep outdated material outside the current public package instead of leaving an editor to guess which version to use.
Check the downloaded files themselves. An image that looks sharp as a small preview may be unsuitable for a larger placement. A working download button does not establish that the logo has the intended transparency or that the archive contains the promised files.
Separate public resources from review access
Our recommendation is to keep the public facts and approved media accessible without an account request. Review builds, keys and embargoed material need a separate, deliberate route. Do not put private access details in a public archive simply because the same people may eventually need both.
Finji’s TUNIC page provides image downloads and game facts while presenting a separate game-key request. That separation makes the two jobs clear: public information is available now; access to the game follows its own process. For your kit, name the contact responsible for unanswered press questions and agree internally who handles access requests.
Run a first-visit check before sharing
Ask someone outside the kit’s preparation to open its link while signed out. Have them find the current release information, download one logo and screenshot, open the combined package if offered, play the relevant trailer and locate the press contact. Repeat the essential route on a phone. Note anything that requires explanation, a permission request or a missing application.
Compare the page and downloads against each other. In the hypothetical Tidepost kit, an old date in the factsheet would still conflict with a newly updated trailer. Correct both the public reference and the package; uploading a fresh ZIP alone would leave the contradiction in place. Assign an owner to repeat this check after announcements and substantive asset changes.
Planning the website around these resources? Discuss your game launch site with Twined. We can agree how the press page, approved downloads and future updates fit into the website scope.

