In brief
There is no reliable “three-star button.” Aim for an original, polished game with defensible math, clear communication and robust device behavior. A reviewer—not an AI assistant or a local test score—determines acceptance and ranking.
- Distinguish official requirements from your studio's internal quality target.
- Resolve conflicting documentation through the current team review process.
- Test the weakest device and the least convenient state, not only the best screenshot.
What the published star guidance says
The Game Quality Rankings page associates three stars with exceptional originality and studio-level execution. It emphasizes device testing, efficient loading, consistent art, clean animation and substantive concepts. It identifies shallow gameplay, generic AI-heavy visuals and inconsistent presentation as common weaknesses. Three stars confer eligibility and priority for some positioning—not a guarantee of traffic, player demand or commercial return.
There is an important documentation discrepancy. That ranking page says one-star games are returned for improvement, while the public Submission Checklist describes three reviewers and approval at an average of at least one star. It also says team requirements can differ and places detailed approval requirements behind login. These public descriptions were consulted on 6 September 2026; do not combine them into a universal acceptance threshold. Use the checklist shown for your team and obtain clarification from Engine when needed.
A studio-quality target you can act on
Instead of asking “Will this get three stars?”, ask whether a reviewer can understand and trust the game without explaining away rough edges. Our internal target has five dimensions: coherent identity, meaningful mechanics, correct outcome presentation, reliable operation and clear documentation.
For Harbor Signals, the theme should connect the symbols, transitions, sound and feature explanation. The distinguishing mechanic should be understandable and tested, not a collection of unrelated buttons. A screenshot may establish visual direction; only repeated play reveals pacing, state leaks and confusing rules.
Avoid designing interactions simply to prolong play or obscure losses. Clear costs, accurate result labels and accessible rules are quality features, not obstacles to engagement.
A device matrix, not one mobile screenshot
Use this as a starting matrix, then adapt it to the actual supported devices:
| Environment | Inspect |
|---|---|
| Narrow portrait phone | Labels, touch targets, help panel, mode confirmation |
| Larger portrait phone | Board proportions, safe areas, long amounts |
| Landscape phone | Vertical space, controls, dialogs and keyboard focus |
| Tablet and desktop | Scaling, pointer/keyboard operation, audio |
| Small embedded player | Board visibility and access to essential information |
| Slower real device | Cold loading, animation timing, memory, repeated rounds |
Resizing a desktop browser is useful but does not reproduce a phone's GPU, touch behavior or memory limits. Capture device/browser/version alongside each result. Re-run the matrix after important art, layout or runtime changes.
Inspect information as carefully as artwork
The frontend communication requirements cover rules, paytables, per-mode RTP and maximum win, mode costs, balance and result display, audio controls and input behavior. They also require assets to load from Engine's CDN. Review the current jurisdiction settings alongside these general expectations.
In practical terms, try to answer the following without external instructions: What does this action cost? What changes in this mode? Why did this combination pay? How do I turn sound off? What happened when the connection failed? If the answers are hidden by a tiny icon or clipped panel, the interface needs work.
Do not bake prices, multipliers or translations into artwork that cannot be updated consistently. Prefer accessible text for information that changes by mode, currency or language.
Performance needs a repeatable measurement
Record cold-load behavior, transferred asset size, largest decoded textures and animation stability during the busiest feature. Compare the same build on the same device before and after an optimization. A fast second load from cache is not the cold-load result.
Choose internal budgets based on the devices you support; do not publish invented universal limits as Stake rules. Resolve missing assets, avoid shipping unused source material and inspect font loading. A smaller bundle that omits required content is not an improvement.
Turn feedback into a fix list
Each issue should include a reproduction, expected behavior, actual behavior, affected build and a retest result. Group findings into blockers, clarity problems and polish. Fix one root cause instead of making different compensating adjustments on each screen size.
When resubmitting, provide a short, traceable response to reviewer feedback. Do not replace it with “AI optimized everything.” Reviewers need to know what changed and which version contains the fix.
Finish this part
Keep a completed device matrix, unresolved-issue list and a short gameplay recording. Label your internal assessment as internal. You can be ready to request a review without claiming a rating you have not received.