Why Make an English Lesson Feed an OC?
yczz/oc-english is a local desktop application that asks an unusual product question: what happens when a correct English answer does not end as a score, but changes a small character and the room they inhabit? This opening focuses on the application’s actual learning-to-customization relationship, not on its visual charm alone. It gives readers a working picture of the product, the reason that picture matters, and the boundary between the code that exists and the larger world described in the project’s design notes.
An OC is an “original character”: a person-like avatar whose appearance belongs to the player. In this project, the OC is not merely a mascot placed beside a quiz. The learner creates a local profile, creates one or more characters, changes their faces and clothes, arranges furniture, studies vocabulary and grammar, and spends study-earned points on further changes. The character and the room are therefore the visible end of a chain that begins with a learning action.
That chain is the subject worth examining. A language lesson normally produces an internal result—perhaps a remembered word—or a thin external result such as a percentage. oc-english adds an intermediate, inspectable state: a unit becomes practiced, an exam becomes available, points accumulate, and the learner can turn those points into something they chose. This does not prove that the learner has retained the language. It does make the application’s theory of motivation concrete: effort should leave a trace in a world the learner recognizes as their own.
A learning app whose output is a place
The repository presents “Learn English with an OC” as a Tauri 2 desktop application. Tauri supplies the desktop shell; Rust handles the durable profile and learning rules; the interface is written in framework-free JavaScript; SVG draws the characters; and PixiJS renders the room. The application is designed to work locally. Profiles are stored as JSON in the operating system’s application-data area, and the project describes registration as local and passwordless rather than as an account-based service.
This combination matters because it puts the project between two familiar categories. It is not only an educational worksheet with decoration added afterward, and it is not yet a networked social game whose learning feature happens to be present. Its current surface is a compact local loop with five connected areas: a profile, an OC, a personal room, a learning center, and a point-funded shop. The assistant Doudou adds another entry point, but even that assistant is tied to the same content and customization system.
The loop can be stated without technical vocabulary:
The important arrow is not simply “quiz leads to reward.” It is the relationship between an abstract activity and an owned object. A correct practice answer can award points. Completing the words in a unit can unlock its exam. Passing that exam can provide a larger reward. The reward can buy an item, and the item can alter the avatar or the room. Each step is small, but together they give study effort a visible destination.
That design also changes what the application must remember. A score shown briefly on a page would be enough for a conventional quiz demo. Here, the product must preserve which profile is active, which characters belong to it, what each character is wearing, which furniture is placed, which words have been practiced, and the best result for each unit. The room and the wardrobe are meaningful only if they survive the next session. Personalization is therefore not an illustration around the learning system; it is one reason for having a durable learning state at all.
The project’s scope makes the same point in negative form. The current interface exposes profile switching, character creation, face editing, outfit selection, furniture placement, study, exams, and grammar cards. It does not expose the full emotional life described in the design document. A learner can create and decorate a character in the current code path, but the current profile model does not contain the design document’s hunger, mood, resentment, player-level, or redemption state. Those distinctions are not minor wording choices. They determine what kind of product a reader is evaluating.
Follow the smallest complete journey
Consider the shortest journey that still reveals the application’s idea. A learner registers a local profile and starts with 200 points plus a few basic items. They create a character, whose initial room includes a small bed. The face can be changed without spending points. The learner then opens the study center, chooses one of the embedded textbook units, and begins practice.
Practice is not a single “mark complete” button. The current engine creates a meaning-selection card and a listening card for each word, with additional grammar cards when the unit supports them. The learner chooses among four options. A correct answer awards two points; a wrong answer gives feedback but no practice reward. The result is also tied to the unit’s progress, so the application can tell whether every word has been successfully practiced.
When that condition is met, the exam button changes from unavailable to available. The learner takes a 15-question paper containing word, listening, and grammar questions. A score of at least 12 passes. The first pass awards 100 points; a later pass can award points only when it improves the stored best score. This arrangement gives the learner two kinds of feedback: small, immediate progress from practice and a larger milestone from demonstrating performance under a fixed exam format.
Now the points leave the learning screen. The shop contains wardrobe and furniture catalogs. Buying an item is not supposed to be a purely visual page action: the backend checks that the item exists, that it has not already been bought, and that the profile can afford it. Equipping an item also checks ownership and whether the selected slot matches the item. The learner can then see the change on the character rather than only in an inventory number.
The room makes the same transition spatial. Furniture belongs to a character’s room, not just to a global list of purchased objects. The room has a 12-by-8 grid. Placement must stay within the boundary and must not overlap another item; moving an existing item is allowed, and removing it returns it to storage. Those constraints seem like ordinary implementation details until the room is understood as feedback. If every object could occupy any impossible position, the space would be less like a home and more like a collage. A bounded room gives the learner a place to arrange and revisit.
The character renderer reinforces ownership through construction. It does not use one opaque picture for every avatar. It combines skin, hair, eyes, mouth, blush, and outfit parts into layers, then uses the resulting SVG both for previews and for the room. A change to the face or clothing is consequently a change to a structured character state, not merely a screenshot swap. The visual result is the final, human-readable form of several earlier decisions.
This is why the OC relationship is more informative than the project’s cute surface. Cuteness explains why a learner might want to look at the screen. The state transition explains why a learning action has consequences beyond the moment of answering. The character is a destination for earned choice; the room is a persistent record of those choices. Without the learning loop, the application would be a small avatar-and-room editor. Without the character and room, the points would be another abstract score. The product’s identity lies in the connection.
The connection is also deliberately incomplete. Nothing in the repository shows that buying a new outfit improves vocabulary retention, that decorating a room produces durable motivation, or that an exam pass transfers to conversation. The project makes effort visible; it does not establish what the learner can do away from the application. That restraint is essential. A visible trace of activity is useful evidence about what the application recorded, not conclusive evidence about what the learner now knows.
The working prototype and the larger promise
The design document invites a much more dramatic reading. It imagines daily feeding, hunger states, mood differences among personalities, permanent resentment when an OC dies, player levels, redemption trials, generated worlds, social sharing, visits between friends, and a monthly “best parent” ranking. These ideas deepen the metaphor of care: learning would not merely buy accessories; it would keep a dependent character healthy. They also introduce stronger emotional pressure and more serious ethical questions about failure and loss.
The current repository does not implement that larger lifecycle. Its profile structure centers on points, characters, inventory, custom items, progress, and creation time. Its registered commands cover the current local interactions rather than daily settlement, hunger, resurrection, or social networking. The design document is still valuable because it reveals the project’s direction and the intended meaning of the OC relationship. But it must be read as a proposal, not used to attribute unshipped behavior to the application.
That distinction gives the project a useful tension. The implemented loop is legible precisely because it is limited. A learner can understand what was practiced, what was earned, and what was changed. The future design seeks stronger continuity and emotional stakes, but each added state would create more obligations: missed days would need reliable settlement, failure would need to be recoverable or deliberately permanent, and social features would need account and privacy boundaries. More drama would not automatically produce better learning.
The right question, then, is not whether an OC can make English study fun in the abstract. It is whether this particular application creates a coherent chain from practice to consequence, and whether readers can tell where that chain ends. The answer supported by the repository is yes to the first question. The application has a recognizable path from content to question, from question to progress, from progress to points, and from points to a customized character and room. The answer to the second question is equally important: the path ends short of evidence for mastery, transfer, emotional attachment, or the future systems in the design notes.
That is a strong starting point for understanding the project. The next question is what happens inside the path when a learner selects one answer: which part validates it, which state changes, which reward is calculated, and what condition decides whether the next gate opens. Once those transitions are visible, the application can be evaluated as a system rather than as a collection of charming screens.