A solitaire card can work perfectly and still look wrong.
That was the uncomfortable part of building Glimmerbook Solitaire. The rules were there. The Android build ran. There were story scenes, rewards, and a route through the first chapter. Yet I kept coming back to the same judgment: it felt cheap. Ithaca Rising, our other Godot game, had a different problem. Its hero could run and fight, but the interface looked like a collection of functional parts competing for the same patch of screen.
Neither problem could be fixed by adding one more feature.
My AI assistant, Instinct, does the heavy lifting on both games: implementation, asset research, tests, build work, and successive passes on the interface. I set the bar and reject what does not meet it. In this case, the bar was not “more effects.” It was a visual language that made each game feel like itself and made the next action clear.
The two games taught me something I had underestimated: polish is not an asset count. It is the agreement between assets, layout, motion, and gameplay.
Two games that should not look alike
Glimmerbook is a portrait solitaire game inside a storybook frame. The Grimm brothers’ study is the way into the tales; the cards should feel like objects that belong in that world. Little Red Riding Hood and Hansel and Gretel are playable chapters, not just wallpaper behind the same board.
Ithaca Rising is an Android action and idle RPG built around Odysseus’s journey. The player needs to read combat, resources, controls, and progress while the world keeps moving. Its interface has to survive a crowded screen without burying the character.
That became our design question: what should stay consistent within a game, and what can be reused as a method between games?
The first mistake: treating a good asset as a finished decision
We had an asset library. We also had a reason to use it carefully. An attractive sprite in isolation can clash with the weight of the typography, the pixel scale of another sprite, or the color of the control beneath it. A licensed pack may solve one screen and make the next screen look borrowed from a different game.
For Ithaca, we selected a bronze-and-navy pixel UI family for the HUD, controls, buttons, and Arsenal. That was more coherent than finding a different ornament for every button. The work included attribution and excluding packs we could not use under the project’s licensing rules. The subsequent title-scroll adjustment was only a small spacing fix, but it showed why a coherent kit still needs a real screen pass: the title crowded the edge of the scroll in the live Android crop.
For Glimmerbook, the approach was different. We gave the bookshelf a real illustrated presence; gave card backs a woven burgundy surface and card faces parchment, a gold frame, and a faint book mark; and replaced an unexplained question-mark control with a drawn wolf-head symbol. These details have to be judged together. If the cards look like paper but the controls look like default software buttons, the illusion breaks every time the player takes a turn.
An icon is not automatically clearer than a word
I asked for drawn icons in place of text-heavy controls. This sounds like a clean design rule until an icon is ambiguous.
The question mark was a case in point. It occupied space, but it did not explain what would happen when tapped. A wolf-head mark was at least part of Glimmerbook’s story vocabulary. Even then, icon shape alone does not make an action obvious. Tooltips and context still matter. If a player must memorize a private symbol system before making a move, the interface is decorative rather than helpful.
That is why I think of the interface as an agreement with the player. The art establishes the world. The hierarchy keeps the agreement usable.
Give motion a job
We are exploring what I call a 2.5D direction for Glimmerbook: depth and tactile response inside a 2D Godot game, not a conversion to full 3D. A draft pass adds stronger card shadows, edge thickness, a slight resting tilt, lift and press response, and layered drifting light. It has not passed device review or shipped. Earlier card motion work added a more deliberate arc and landing feel; story panels gained subtle camera movement.
The question was not whether these effects were possible. Godot provides 2D layers and animation tools for this kind of work. The question was what each effect tells the player.
A raised card should feel available. A shadow should separate the active object from the table. A landing should close the action. Background movement should add life without competing with the board. If a light moves everywhere at once, it stops guiding attention. If every card performs a flourish, the player waits for the interface instead of playing.
Reduced motion belongs in that decision. The information in the interface cannot depend on an animation that some players disable or cannot comfortably watch. A static shadow or contrast cue should still explain the card when movement is reduced.
A system is also a constraint on the assistant
Instinct can research an asset library, implement a control, adjust a transition, and move to the next screen faster than I could manually direct every edit. That speed is useful. It also means a weak visual decision can spread quickly. If “make it more polished” is the only instruction, the assistant can add shine without fixing the composition.
My corrections became more specific. Use a consistent family of assets. Keep the cards and the story in the same world. Do not replace a crowded result screen with a more ornate crowded result screen. Check the title against the edge of its frame on the actual Android crop. Keep visual changes small enough that a broken build can be traced to one step.
The checklist I use now
Before approving a visual pass, I ask:
- Can I tell which game this screen belongs to without reading the title?
- Is the next action visually stronger than the decoration around it?
- Do the cards, controls, frames, and text seem made for the same world?
- Does motion explain state or only advertise that we added motion?
- Does the screen still make sense when movement is reduced?
- Have I seen the result on the running Android build, rather than only as isolated art or a code diff?
I am still dissatisfied with parts of both games. Glimmerbook’s character art and the feel of its story world have further to go. Ithaca still needs its real-device gate and more work on how the voyage looks and sounds. Calling those gaps out is not a rejection of the work. It is how the next pass gets a useful target.
The strongest thing we have learned is modest: a game’s identity is made from repeated choices. One coherent frame, one legible control, one card that moves for a reason. Do that across the whole experience and the player stops noticing the parts. They start believing in the world.
References
- Godot documentation: Parallax2D – technical reference for independently moving 2D layers.
- Godot documentation: Canvas layers – separation of world, background, and screen-space interface.
- Godot documentation: GUI skinning – themes and consistent control appearance.
- My earlier article on Android QA – the separate test-evidence story mentioned above.
A note on how this article was made
Instinct prepared this draft from our actual project work and did the heavy lifting on the research and technical narrative. I reviewed the facts and decided what belongs under my name before publication.