# BDFramework.Core: a Unity3d workflow for hotfixing and automated builds

> BDFramework.Core is an Apache-2.0 Unity3d pipeline that bundles hotfix support, asset management and automated building behind an editor-driven workflow. The README is thin on specifics, so here is what the repository actually shows and what you should verify before adopting it.

**yimengfan/BDFramework.Core** — Simple and powerful Unity3d game workflow!  简单、高效、高度工业化的商业级unity3d 工作流。

- Repository: https://github.com/yimengfan/BDFramework.Core
- Stars: 2,708 · Forks: 464
- Language: C++
- License: Apache-2.0
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/yimengfan-bdframework-core

## The problem BDFramework.Core targets: a Unity3d pipeline rather than a library

Most Unity projects accumulate the same three problems: code that has already shipped needs a fix without a store resubmission, assets grow past what a naive Resources folder can carry, and the build step lives in a developer's head. BDFramework.Core positions itself against all three at once. The README describes it as "a comprehensive and efficient pipeline for game development in Unity" providing "a complete workflow from development to deployment, including features like hot-fixing, asset management, and automated building." The stated design focus is automation and editor enhancements. That framing matters for who this is for. It is aimed at teams running a commercial Unity3d title with a live client, not at someone prototyping a jam game. A solo developer who never ships a patch has no use for a hotfix path. A team that already ships weekly patches and maintains its own asset bundle tooling is the audience. The repository topics reinforce the scope: unity3d-hotfix, hotupdate, unity3d-game-workflow, csharpgame. Note also that the primary language listed for the repository is C++, which is unusual for a Unity framework and suggests native components sit alongside the C# layer, most likely related to the HybridCLRData directory at the top level.

## How the workflow is put together: editor tooling, runtime code and a hotfix data directory

The repository layout is the clearest statement of the architecture. Assets/, Packages/ and ProjectSettings/ make this a Unity project in its own right, so the framework ships as a working project you open rather than a bare package you drop in. DevOps/ holds the build and deployment side that the README calls automated building. HybridCLRData/ is the hotfix side: HybridCLR is a Unity hot-update solution, and the directory name indicates the framework integrates it rather than inventing its own IL patching. 工具包/ (toolkit) is where the editor-facing utilities live. Doc/ carries the documentation, split into README.cn.md and README.en.md. A separate README table links both. The data flow implied by that layout is: C# game code built through the standard Unity pipeline, with hot-updatable assemblies routed through HybridCLR, assets managed by the framework's own asset layer, and the whole thing driven from editor tooling under 工具包/ with build output produced by DevOps/. The README does not document the asset management format, the hotfix packaging format, or the build configuration keys, so treat that flow as inferred from directory names rather than confirmed from prose. The README also states that the next version, V-4.0, will evolve into an ai workflow, which tells you the current architecture is expected to change.

## Installing BDFramework.Core from OpenUPM and opening the project

The README advertises an OpenUPM badge for the package com.popo.bdframework, which is the distribution channel it points at. OpenUPM packages are consumed through the Unity Package Manager by adding the OpenUPM scoped registry. The README does not print the registry snippet itself, so the block below is the standard OpenUPM registry form with the package name taken from the badge URL.

```json
{
  "scopedRegistries": [
    {
      "name": "package.openupm.com",
      "url": "https://package.openupm.com",
      "scopes": ["com.popo.bdframework"]
    }
  ]
}
```

Add that to the project manifest, then install the package by name from the Package Manager window or by adding it to the dependencies block. The README gives no version number, so let the registry resolve the latest.

```bash
openupm add com.popo.bdframework
```

The openupm CLI command above is the documented way to add an OpenUPM package to a Unity project. After it resolves, the package appears under Packages in the Unity Editor and the framework's editor tooling should show up in the menu bar. Because the repository is itself a Unity project, the alternative path is cloning it and opening the folder in the Unity version recorded in ProjectSettings/. The README does not state which Unity version that is, so check ProjectVersion.txt under ProjectSettings/ before opening. Once the editor loads, the first real use is the editor tooling under 工具包/, which the README identifies as the automation surface. The README does not walk through a first build, so expect to read the Chinese documentation in Doc/README.cn.md for the concrete steps.

## Where BDFramework.Core is the wrong choice

The documentation gap is the first real limitation. The root README is a landing page: a logo, a badge row, a two-sentence description, and links to the two language versions. It does not document the asset management API, the hotfix packaging format, the build configuration, or a migration path. The English file at Doc/README.en.md exists, but the project's own emphasis and the Chinese-first framing of the README suggest the Chinese documentation is the authoritative one. If your team cannot read Chinese and will not read source, you are adopting a framework whose primary documentation you cannot use. Second, the hotfix capability depends on HybridCLR, given the HybridCLRData directory. That is a dependency with its own platform constraints and its own build requirements; the README does not discuss them, so any claim about which platforms the hotfix path supports has to be verified against HybridCLR itself, not against BDFramework. Third, the README announces that V-4.0 will become an ai workflow. A framework whose next major version changes direction is a framework where the current API may not be the long-term one. If you need a stable interface for the next two years, that announcement is a reason to wait for 4.0 rather than adopt 3.x. Finally, the repository publishes no releases, so versioning is whatever the OpenUPM package publishes. The last push was on 2026-09-20, which is recent, but a recent push is not a release and not a compatibility guarantee.

## Alternatives and how their approach differs

The closest comparison in approach is to assemble the same three capabilities from separate, single-purpose projects. For hotfix specifically, HybridCLR is itself the underlying technology, and BDFramework's contribution is integration and editor tooling around it rather than a replacement for it. If you only need code hot-updating and already have asset and build tooling you like, pulling in HybridCLR directly gives you a smaller surface and documentation that belongs to that project rather than to a wrapper. For asset management, Unity's Addressables system is the first-party option: it is maintained by Unity, documented in English, and integrated with the editor's own build pipeline. The trade-off is that Addressables does not attempt to be a full workflow, so you still own the build automation and the hotfix path. BDFramework's pitch is exactly that it does not leave those to you. The honest framing is that BDFramework.Core is a bundling decision: you accept a broader, Chinese-first, editor-heavy framework in exchange for not wiring HybridCLR, asset management and DevOps/ together yourself. If you would rather own each piece, the unbundled route is more work up front and less to learn about someone else's conventions.

## Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-20, so there is current activity. That is the only maintenance signal available here; the repository publishes no releases, so there is no changelog to read and no version cadence to plan around. Upgrading means tracking the OpenUPM package com.popo.bdframework, and the announced V-4.0 direction toward an ai workflow is the upgrade event to plan for. A major version that changes the workflow model is a migration, not a patch, so budget for it. On licensing: the repository ships an Apache-2.0 LICENSE file and the README's badge row also links an Anti 996 licence badge and the 996.ICU site. Apache-2.0 is a permissive licence with an explicit patent grant and a requirement to preserve notices. The badge pointing at a second licence is worth resolving before you ship, because two licence references in one README is exactly the kind of ambiguity a legal review will flag. Read the LICENSE file in the repository root, not the badges, and confirm which terms apply to the code you redistribute. This is not legal advice; the point is that the README alone does not settle it.

## Conclusion

Adopt BDFramework.Core if you are building a Unity3d title and want hotfix, asset management and automated building handled by one Apache-2.0 framework rather than assembled from separate packages. Do not adopt it if you need the English documentation to be as complete as the Chinese one, or if you cannot read C# and C++ source to answer questions the README leaves open. Before committing, check the OpenUPM package page for the current com.popo.bdframework version and Unity compatibility, read Doc/README.cn.md and Doc/README.en.md side by side, and confirm that the HybridCLRData and DevOps directories match the hotfix and build pipeline you actually run.

## FAQ

### What Unity version does BDFramework.Core require?

The README does not state a Unity version. Because the repository is itself a Unity project with a ProjectSettings directory, the version is recorded in ProjectVersion.txt there, so check that file before opening the project.

### How do I install BDFramework.Core?

The README points at OpenUPM with the package name com.popo.bdframework, so it installs through the Unity Package Manager by adding the OpenUPM scoped registry, or with the openupm CLI. The README does not print the registry snippet or a version number.

### Does BDFramework.Core support hot updates?

Yes. The README lists hot-fixing as one of the workflow's features, and the repository contains a HybridCLRData directory, which indicates the hot-update path is built on HybridCLR. The README does not describe the packaging format or platform constraints.

### Is BDFramework.Core free to use in a commercial game?

The repository ships an Apache-2.0 LICENSE file, which is permissive and includes a patent grant. The README badge row also links an Anti 996 licence, so read the LICENSE file in the repository root to confirm which terms apply.

## Sources

- [Issues](https://github.com/yimengfan/BDFramework.Core/issues)
- [License: Apache-2.0](https://github.com/yimengfan/BDFramework.Core/blob/master/LICENSE)
- [README](https://github.com/yimengfan/BDFramework.Core/blob/master/README.md)
- [yimengfan/BDFramework.Core on GitHub](https://github.com/yimengfan/BDFramework.Core)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/yimengfan-bdframework-core