Identify the reading problem first
| Symptom | Check first |
|---|---|
| Complete but hard to read | Actual size, spacing, viewing distance and viewport. |
| Boxes or missing strokes | Target-language font coverage and actual loading. |
| Large but lost in the background | Text surface, contrast, background and occlusion. |
| Enlargement pushes choices away | Panel layout, long-option wrapping and information order. |
The art method includes font coverage, reading order and line width, judging actual interaction screens. A concept poster’s large heading does not establish readable game prose, and a large hit area does not prove legible text.
One size looks different across fonts, devices and reading habits. Values are prototype candidates to try through reading and operation, not a universal solution.
Enlarge text without removing decision evidence
Separate prose, current conditions, choices and feedback, asking who needs to read what and when. Condense repeated explanation while retaining unique current limits. An explicitly opened archive can contain longer reading; essential choices cannot disappear offscreen without guidance.
Do not keep a rigid box then shrink type again to fit it. If one screen carries several beats, change layout or split semantically while providing nearby review and return to the current choice. See interface overload for hierarchy; this page focuses on reading and display adjustments.
A text preference is presentation, not a submission of waiting or returning an item, a replay of completed events or a disclosure to characters. For an existing real-time clock, follow its established pause-or-continue rule rather than changing it during a text revision. The route below uses this example’s explicit no-time-advance setting rule.
Complete example: reading a loan record without returning the book
In an original library game, the player sorts a cupboard at 14:00. The red volume is inside; Tang He borrowed the blue one and promised to return in ten minutes, but has not returned it. The player can check the loan record or wait. This example’s reading settings and record inspection do not advance time; waiting enters later events under established rules.
The phone draft packs conditions into tiny text, making “blue volume borrowed” easy to miss. Try a 390×844 viewport, 18px body text and 1.6 line height for this example. These are author candidates, not native defaults or a tested game.
Current prose: The red volume is in the cupboard. Tang He has the blue one; she promised to return in ten minutes and has not returned it yet.
Choices: Check the loan record; wait for Tang He.
On demand: Reading settings; read history.
Give prose and choices a clear reading area, wrap long choices completely and place full history on another page. Check this paper route:
| Step | Expected result |
|---|---|
| Enlarge text in settings | Return at 14:00 with the blue volume still borrowed, without automatic waiting or return. |
| Inspect loan record | Show the established loan entry for the player to read without triggering Tang’s arrival. |
| Return to choices | Prose and both choices remain readable; waiting has not been submitted. |
After implementation, use actual fonts in the target viewport to read the route and check prose, choices and required feedback at the larger size. Check narrower supported views and longer translations within the project’s actual scope. This page does not build the game; the article’s mobile layout cannot prove that the example interface passes.
Implement the reading change and replay the route
Brief the implementer:
Change only reading presentation for prose, choices and feedback. Preserve textual facts, option meanings, time rules, possessions and current state. Check target fonts, size, spacing, wrapping and occlusion. Enlargement must return to the current choice without submitting an action or resetting the game. Replay the unreadable route, then an adjacent route with longer text. Report actual tested viewports and remaining issues; a large screenshot heading is not a prose-reading check.
game-art-direction sets presentation, game-build implements it and game-qa checks the actual runtime. This does not require rebuilding the game or extensive new logging. Readability includes experience; no automated overflow error does not mean effortless reading for every player.
FAQ
Is doubling every text size enough?
Check fonts, spacing, contrast, wrapping and displaced choices as well. Read and operate in the viewport rather than checking a size property alone.
Can I remove long conditions to clean the screen?
Keep conditions required for the decision. Remove repetition, provide nearby inspection or split beats; changing rules is a separate task.
Do it with the skill
Use $game-art-direction to revise this reading direction with the current screen, target viewport and established rules. Implement it and verify actual reading and operation; a size candidate is not a passed result.
Read the method: Fonts, line width and reading boundaries · Implement presentation without independent state changes · Target viewport, actual overflow and route replay