VPet-Simulator: A WPF Desktop Pet You Can Embed in Your Own App

What VPet-Simulator Actually Solves

The README describes VPet as a virtual desktop pet simulator, an open source desktop pet that can be embedded into any WPF application. Those are two products in one repository. The first is the Windows desktop app, distributed free on Steam, where a character sits on your desktop and reacts to being petted, picked up or made to climb the wall. The second is VPet-Simulator.Core, published on NuGet, which is the same engine packaged so another WPF program can host a pet inside its own window.

The second use case is the one worth paying attention to. Most desktop pet projects are end-user toys with no embedding story; you either run their executable or you do not use them. VPet separates the simulation core from the Windows shell, which is why the repository contains VPet-Simulator.Core, VPet-Simulator.Windows and VPet-Simulator.Tool as distinct projects. If you are writing a WPF application and want a persistent character that has needs, food, work timers and speech, the Core package is the piece you would reference.

The audience is therefore narrower than the Steam listing suggests. Casual users install the Steam build. C# developers building WPF software are the people who get value from the repository itself.

How the Core, Graph and Display Layers Fit Together

The README's software structure section lays out three layers inside VPet-Simulator.Core. Handle holds the interfaces and controls: IController for window control such as moving the pet to the side of the screen, GameCore for the data, GameSave for persistence, IFood for food and item definitions, and PetLoader for loading pet graphics. Graph handles rendering: IGraph as the base animation interface, GraphCore as the display core, plus concrete components for PNGAnimation (dynamic animation), Picture (static animation) and FoodAnimation, which supports a three-layer sandwich animation and, as the README notes, is not necessarily only for food.

Display sits on top: a basestyle/Theme system, Main.xaml with MainDisplay and MainLogic, a ToolBar shown when the character is clicked, a MessageBar for speech, and a WorkTimer. The Windows project then adds the shell around it: MainWindows hosts the Core, PetHelper is a small quick-switch icon, and there are separate windows for settings, mod management, a better-buy shop, ChatGPT settings, a developer console and a report centre.

The animation count is stated as 32 kinds times 4 states times 3 types, with the README's own caveat that some kinds have no sick state or no loop, so the real number is lower. That caveat is worth repeating because the headline figure is the kind of number that gets quoted without it.

Building the Desktop App from Source

The README gives a five-step desktop deployment procedure, and it contains a trap. You open VPet.sln in Visual Studio, set the build to x64 with VPet-Simulator.Windows as the startup project, and run it. The first run is expected to fail with a missing Core mod error. That is not a bug in your setup; the mod files live outside the build output, so the project expects you to link them.

Run the linking script as administrator, then start again:

mklink.bat

After that, launching from Visual Studio should bring up the pet normally. The reason the script needs elevation is that it creates directory links, which Windows restricts to elevated processes by default.

If you only want the pet in your own application rather than the full desktop shell, the README points at NuGet instead:

# package: VPet-Simulator.Core
# https://www.nuget.org/packages/VPet-Simulator.Core

The README does not document the Core package's public API surface, so expect to read the source in the VPet-Simulator.Core project for the exact types you need. That is a real gap: the package is offered as the embedding path, but the embedding instructions in the README stop at the package name.

Mods, Plugins and the Mod Maker Tool

The Workshop support is the most developed part of the project. According to the README, mods can add or modify pet animations, items, food and drink, custom pet work, speech text, themes, and code plugins. Code plugins are the broadest category: they can add new animation logic or display schemes such as Live2D or Spine, and add new features such as an alarm clock or a notepad. The README calls this almost omnipotent and points to VPet.Plugin.Demo as the example repository.

A separate repository, VPet.ModMaker, is listed as the mod creation tool, and VPet-Simulator.Tool in this repository provides utilities such as image frame generation for mod authors. The contribution guide adds a constraint that matters: for new features or gameplay, the README asks you to email or open an issue first to confirm the idea fits the simulator, otherwise a pull request may be rejected as unsuitable. Bug fixes do not need that prior contact.

That review gate is unusual and worth weighing. It keeps the core coherent, but it also means the fastest route for an experimental feature is a plugin mod rather than a patch. The README says as much: adding new features can generally be done through a code plugin mod.

The Animation Licence Is Not the Code Licence

The repository is Apache-2.0, but the bundled pet animations are not. The README states that the animation files under VPet-Simulator.Windows/mod/0000_core/pet/vup belong to the VUP-Simulator production team and are governed by a separate animation copyright statement. This distinction is easy to miss and expensive to miss.

For non-commercial use, the terms require you to tell users where the animation files came from and provide a link to the project page. For commercial use, the requirements are stricter: a prominent pop-up naming the source on first use, a link on a page users can reach easily, no selling of the animation files, and an email to the maintainer. Redistribution requires passing on all of that information and providing the link, and redistribution must not be charged for. Built-in images follow the same terms, and the zip photo library is stated as non-commercial only.

The README also notes that this statement covers only the animations shipped with the pet. If an artist or developer draws their own animations for the pet, those do not fall under it. So the practical path for a commercial product is to supply your own art, which the README explicitly says you may need to do. This is a description of the project's stated terms, not legal advice; if your distribution depends on it, have someone qualified read the full statement.

Where VPet-Simulator Is the Wrong Choice

The clearest limit is the platform. The core is written in C# against WPF, and the README frames the embedding use case as any WPF application. There is no stated support for Avalonia, MAUI, WinUI, Electron or the web, and no cross-platform claim anywhere in the README. If your application is not WPF, the Core package does not solve your problem, and porting the display layer would mean reimplementing the Graph and Display components yourself.

The second limit is documentation depth. The README covers the desktop build procedure in detail and the mod surface in detail, but the embedding path is one sentence and a NuGet link. A developer who wants to know how to instantiate GameCore, wire an IController, or load a save has to read the source. That is normal for a project of this size, but it means the embedding feature is advertised more confidently than it is documented.

The third is the maintenance expectation on contributions. If you plan to fork and push new gameplay upstream, the prior-approval process described in the contribution guide applies. If you want to move fast without that conversation, plan to keep your changes as a plugin mod or a private fork.

Alternatives and the Actual Difference

The obvious comparison is a general desktop pet framework rather than a specific pet. Projects in that space typically treat the pet as a sprite with a script attached: you define frames, a state machine and click handlers, and the framework draws them. VPet instead ships a simulation with persistent state. GameSave, IFood, GameCore and WorkTimer exist because the pet has hunger, items and tasks that survive between sessions, and the animation set is organised around states such as sick rather than around a generic idle-walk-sleep loop.

That difference cuts both ways. If you want a lightweight animated character on screen and nothing more, VPet's simulation layer is weight you did not ask for, and a simpler sprite framework will be less code to understand. If you want a character that accumulates state and can be extended by third parties without forking, VPet's split between Core, Graph, Display and plugin mods is the reason to pick it.

The other alternative is writing the pet yourself inside your WPF app. For a single static image with a click handler that is a reasonable choice. The moment you need layered animations, a save format, item definitions and a mod loader, you are rebuilding what VPet-Simulator.Core already contains.

Editorial conclusion

Adopt VPet-Simulator.Core if you are building a WPF desktop application and want a pet layer that already handles animation, saves, food items and a plugin surface, and if you can live with the animation licence conditions or supply your own art. Do not adopt it if you are not on WPF, if you need a cross-platform pet, or if you intend to sell the bundled animations. Before committing, verify three things: that mklink.bat runs with administrator rights on your machine, that the mod folder structure matches what the code expects, and that your distribution model satisfies the non-commercial or commercial animation terms, since the Apache-2.0 licence on the code does not cover the artwork.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. LorisYounger/VPet on GitHub
4. README