GOG and Epic Games Store Launch Checklist for Indie Developers

Most indie developers spend months optimizing their Steam launch and then treat GOG and the Epic Games Store as a quick copy-paste job. It isn’t. Both platforms have unique technical requirements that can catch you off guard days before launch — and both have review processes that will reject your build if you don’t meet them. This checklist covers everything you need to verify before hitting submit.

Understanding What Makes GOG Different

GOG’s defining characteristic is its DRM-free commitment. Every game on GOG must work in full — install, run, save, and complete — without the GOG Galaxy client present on the system. This is not a soft recommendation. GOG reviewers will test your game specifically by removing Galaxy and verifying it still runs. If your game calls Galaxy SDK functions on the main code path and crashes when the library isn’t present, your build will be rejected.

The practical implication is that all GOG Galaxy integrations must be wrapped in optional, gracefully-degrading code. Achievement unlocks, friend list queries, and cloud save calls should be guarded so that when the Galaxy DLL is absent, the call silently skips rather than throwing a null reference or access violation. Test this yourself: uninstall Galaxy from your test machine, copy your game build to that machine, and play through a complete session. Pay particular attention to startup code, save triggers, and any point where an achievement would fire.

GOG also requires you to submit offline installers for each platform you support. These are standalone executables that do not require a network connection to install the game. If your game has large DLC or updates, each needs its own installer package. Plan time for building and verifying these packages separately from your main build pipeline.

GOG Galaxy SDK Integration Testing

If you choose to support GOG Galaxy features (achievements, leaderboards, cloud saves, multiplayer), the GOG Galaxy SDK has its own initialization and callback model distinct from Steamworks. Common integration mistakes include:

• Calling GalaxyInstance::Init() without checking the return value, then continuing to call Galaxy functions on a failed init
• Not calling ProcessData() in your game loop, which prevents callbacks from firing
• Triggering achievement unlocks before the SDK confirms the listener is ready
• Assuming cloud save slots are identical to Steam cloud save structures
• Not testing the “Galaxy signed out mid-session” scenario

Your test matrix should explicitly cover: game launched with Galaxy running, game launched without Galaxy installed, game launched with Galaxy installed but the player signed out, and Galaxy signing out after a session has already started. All four scenarios must produce graceful behavior — ideally the game continues normally, with Galaxy-backed features simply unavailable.

Epic Online Services Integration Testing

The Epic Games Store requires integration with Epic Online Services (EOS) for certain features. At minimum, most EGS releases need EOS for achievements. Cloud saves and the social overlay are optional but frequently expected by EGS players.

EOS initialization has a product ID, sandbox ID, and deployment ID that differ between your development and production environments. A build submitted to EGS must use production credentials. Accidentally shipping a build with development credentials means your achievements won’t actually unlock on player accounts — which generates support tickets and bad reviews.

Test your EOS integration with a fresh Epic account that has never played your game before, to verify that first-time initialization, entitlement checks, and achievement state work correctly. Then test with an account that has played your game during Early Access, to verify that existing progress is handled correctly. The EOS achievement system specifically requires you to handle the case where an achievement was already unlocked in a previous session — attempting to unlock it again should fail silently, not crash.

Epic’s entitlement check — verifying that the logged-in player actually owns the game — is important to test in both directions. What happens when the entitlement check passes? What happens when it fails, either because the player is on a shared machine or because the EOS service is temporarily unavailable? Your game should handle a failed entitlement gracefully, not hang on a black screen.

Testing the Game Without Any Store Client Installed

Both GOG and EGS players frequently run your game outside the store client. They may launch via a desktop shortcut, a third-party launcher, or directly from the executable. Your game must be stable in all these scenarios. Set up a clean virtual machine — a fresh Windows install with no Steam, no GOG Galaxy, and no Epic Games Launcher — and run your full QA pass on that machine.

Common failures in this scenario include:

• The game silently expects a Steam API DLL and crashes on startup without it
• Overlay calls that crash when no overlay is present
• Crash reporter SDKs that were designed for Steam builds and attempt to submit reports through Steam, failing silently when Steam is absent
• Save paths that default to a Steam userdata folder that doesn’t exist
• Auto-update mechanisms that check for updates via the store client and hang when the client isn’t running

Use a tool like Process Monitor to watch your game’s file and registry access on startup. You’ll often spot unexpected dependencies this way — a DLL lookup that fails silently on Steam but causes a noticeable hitch on GOG, for example.

Crash Reporting on GOG and Epic — Why Your Steam Setup Doesn’t Cover It

This is the most commonly overlooked item on multi-platform launch checklists. Steam has a crash reporting mechanism for games that opt in via Steamworks. But that mechanism only works for players running the game through Steam. GOG and EGS players are entirely outside that system. If your game crashes for a GOG player, you get no automatic report, no stack trace, and no data unless you have integrated your own crash reporting SDK.

Bugnet operates at the application level and captures crash reports regardless of which platform the player bought from. Because you initialize Bugnet in your game code — not through a store-provided hook — it works identically on Steam, GOG, EGS, and even copies shared outside any storefront. This is exactly why setting up crash reporting before platform review submission matters: you want reports flowing from day one of launch, not after you realize two weeks later that you’ve been flying blind on a third of your player base.

Configure Bugnet to capture the platform context. You can tag sessions with the detected platform (check for the presence of Galaxy SDK, EOS SDK, or Steam API to determine which store the player is using) so that you can filter crash reports by platform in the dashboard. A crash that only appears on GOG builds is often a Galaxy SDK integration issue; a crash specific to EGS builds is often an EOS initialization problem. Platform tagging makes these patterns visible immediately.

“We had a crash affecting 12% of our GOG players on day one. We only found out because Bugnet was already integrated and showed us a spike in session crashes. Steam numbers looked fine. Without cross-platform crash reporting, we would have seen the GOG reviews roll in and had no idea what was wrong.”

Store Asset Checklist

Both GOG and EGS have specific asset requirements that differ from Steam. Plan to produce these assets separately rather than assuming your Steam assets will work as-is.

For GOG, prepare:

• Background image (1600×655 px) for the store page header
• Logo image (184×184 px, transparent background)
• Screenshots at 1920×1080 px minimum (GOG requires at least 4)
• Trailer hosted on YouTube or as a direct video upload (GOG prefers trailers under 3 minutes)
• A written description with no platform-specific branding references (do not mention Steam features in your GOG description)

For the Epic Games Store, prepare:

• Offer image (2560×1440 px)
• Landscape thumbnail (1920×1080 px)
• Portrait thumbnail (1200×1600 px)
• Screenshots at 1920×1080 px minimum (EGS requires at least 5)
• Trailer in MP4 format (EGS hosts trailers directly — do not submit a YouTube link as your primary trailer)

Both platforms will reject assets with incorrect dimensions. Build your asset exports into your release pipeline as a checklist item, not an afterthought.

Timing: Set Up Crash Reporting Before Submitting for Review

Platform review takes time — GOG reviews typically run 14 business days, and EGS can take 10–30 days depending on your game’s scope and whether you need assistance from Epic partner support. You should submit a build with crash reporting already integrated, not plan to add it after the game ships.

Here’s why: the review build is often very close to the shipping build. If you add Bugnet after review, you’re shipping a different binary than was reviewed, which may require a re-review. More importantly, review is a stress test. Reviewers run your game on a variety of hardware configurations to verify it runs correctly. If the game crashes during review, a crash report already in your Bugnet dashboard tells you exactly what happened — without that, you’re debugging blind based on a vague rejection note.

The recommended sequence is: integrate Bugnet → run your full QA pass → verify crash reports are flowing in the dashboard → submit to platform review. By the time the platform returns feedback, you have days or weeks of crash data from your own QA runs and can address any issues quickly.

Multi-platform launches reward preparation. The developers who treat GOG and Epic as separate products — not Steam ports — have the smoothest launches.