Build update: local care before shared care

The short version

Little Together is still a virtual pet game in development. The current prototype explores local feeding, play, grooming, rest, movement through a garden, and titled memories that a person chooses to keep. It also shows two partner perspectives so we can examine how shared care might feel.

Those partner perspectives are simulated. Two people cannot yet sign in from separate devices, accept an invitation, or care for the same live pet world. Remote shared care, accounts, invitations, and production services are planned. App, download, and play access remain coming soon, with no announced release date or price.

Why begin with a local care loop

A virtual pet needs a coherent ordinary visit before it needs a large online system. Our current loop asks a small set of practical questions: Can a person understand what the pet needs? Does feeding feel different from play? Is rest a valid choice rather than a penalty? Does moving from home to garden give the visit a useful change of pace?

Working locally lets us refine those interactions and the information they change without implying that multiplayer infrastructure already exists. It also makes the boundary visible: a local prototype can help test a sequence on one device, but it does not prove that two devices will stay in sync.

What the prototype is testing today

The care set currently covers feeding, play, grooming, and rest. The world adds a home, garden movement, and intentional memories with titles. These are prototype interactions, not promises about final timing, progression, species behavior, rewards, or reminders.

We are looking for a visit that has a clear beginning and an easy stopping point: say hello, choose a care action, wander if you want, and save a moment only when it feels worth keeping. The design direction favors a small familiar world over an endless feed of new items.

What “saves locally” does and does not mean

In the prototype, progress is local rather than attached to a production account. That means people should not interpret a prototype save as a durable cloud backup, a cross-device transfer, or shared household data. We will document the actual storage, retention, deletion, and recovery behavior before any public app access.

For web technology generally, browsers can store site data on a person’s device through tools such as Web Storage and IndexedDB. MDN explains that browser storage is commonly managed per site origin and is best-effort by default; users can delete it, private-browsing sessions usually remove it when the session ends, and browser rules differ. That is why “it saved on this device” is not the same claim as “it is safely backed up everywhere.”

Why intentional memories are separate from automatic history

A care log and a keepsake answer different questions. A log can record that feeding happened; a memory should capture something a person actively wants to remember, with a title that gives it context. The prototype keeps that choice explicit rather than turning every tap into a permanent scrapbook entry.

This distinction also shapes future product work. Before cloud memories exist, we need clear answers about who can see a saved moment, whether both partners can edit or remove it, what happens when someone leaves a household, and whether a person can export what they want to keep.

How simulated partner perspectives help

The prototype can present the same situation from two named viewpoints. That lets us test wording and turn-taking ideas: who chose the care action, what the other person sees, and how a shared memory might name both contributions. It is a design simulation, not a network connection.

The simulation is useful precisely because it exposes decisions before account code hides them. We can identify ambiguous ownership, simultaneous-action conflicts, and awkward notification language on paper and in local interactions. It cannot test latency, offline reconciliation, invitation security, or real-world access control.

What remote shared care still requires

Real shared care needs more than putting two avatars on a screen. At minimum, the product needs production accounts, a way to invite and remove a partner, authorization for each shared household, a source of truth for pet state, and rules for actions that arrive at nearly the same time. It also needs visible recovery behavior when a device is offline or a request fails.

Memories add further questions about uploads, privacy, retention, deletion, and exports. We will not label these systems complete merely because a concept screen looks convincing. The public status will change only when the underlying behavior can be used and checked.

A reader’s checklist for any shared virtual pet game

When you evaluate a virtual pet game, ask five concrete questions: Can two people change the same pet, or only send pictures? Does each person need an account? What happens if both act at once? Can either person leave and remove access? Can you recover or export progress after changing devices?

Also separate current features from roadmap language. Words such as “planned,” “prototype,” and “coming soon” mean the feature is not available today. A clear product should state that boundary close to the relevant button or description.

What comes next for Little Together

The next product boundary is moving from simulated partner views toward real identity and shared-state work, while keeping the local care loop understandable. That includes defining household roles, invitation states, action conflicts, and what each person can do with shared memories. This is a direction, not a release commitment.

For now, Little Together remains an upcoming experience. The website and journal will continue to distinguish working prototype behavior from planned remote features. App, download, and play links will stay marked coming soon until there is something people can actually use.