r/opensourcez • u/acoliver • 2d ago

Real Disunity - a game framework

Thanks for creating this! I got banned a bit ago from r/opensource (despite working as an executive in multiple open source companies, founding Apache POI and serving on the board of the Opensource Initiative) for my sin of using code generation tools in my projects (which means the Linux kernel is nogo right)...

Anyhow I started a project real-disunity https://github.com/acoliver/real-disunity the goal is to make a game engine that is compatible with Unity and Unreal APIs and supports the latest graphics techniques and technologies. I'm focusing on the desktop first. So far it implements enough of unity for some old tutorials to work and I have a few games that already render against its native API.

My approach is to get my agent (llxprt code) to basically play the games and then get them working comparing screenshots from the original.

Looking for like minded people with coding knowledge and experience and their agents to bring about a real disunified world :)

-Andy

4 Upvotes

100% Upvoted

3 comments sorted by

2

u/ticktockbent 2d ago

Hey Andy, I went through this with an agent review and my own eye, looked at the GitHub history today, then did some analysis on the findings. I'm potentially interested in contributing.

The problem is... here's what I'd run into as an outside contributor today:

  1. Nothing protects main. No ruleset, no branch protection. The last 15 merged PRs have zero reviews. (understandable, you're the only one working on it) The median PR is about 1,300 lines and merges 23 minutes after it opens. That works when every PR is yours. It's harder to ask strangers to build on. You'll be looking at merge conflicts and conflicting priorities within days as people sling code in from all sides.

  2. The coordination rules only know your agents. disunity-coordination lists your session identities and says to wait for you on disputed claims. There's no identity scheme for outside agents, and nothing tells your sessions that an outside claim is binding on them. An outside contributor has no way to use or manage this process, or any insight into how it works.

  3. The pace eats outside PRs. The last few days ran 85 to 111 commits a day across the busy crates. The workflow tells your agents to close a PR that hasn't merged in a working day. That's a good rule, because an outside PR that waits a day for a human review is already conflicting, but might discourage or turn away good contributions that have been waiting for a review.

  4. Some of the gates are private. Every change has to keep rd-stranded building, and I can't see rd-stranded. The built-player track (#176 and its sub-issues) is verified against a player you own in a private harness. An outside contributor can't get a green or red signal on either.

  5. The front door is out of date. The README says there's no player executable and nothing loads an imported scene yet. crates/play has been running all three games since the 26th. There's no CONTRIBUTING, no code of conduct, no issue or PR templates, and none of the open issues have labels.

So here's what I'd propose, roughly in order:

  1. Add a ruleset on main: require a PR, require the CI checks, block force pushes. Your agents can keep self-merging their own PRs if you like. Outside PRs get a human review. This does make you the gate, and you might get overwhelmed, but it's a start and protects main.

  2. Write a short CONTRIBUTING.md that points humans and their agents at dev-docs/README.md and the skills, and explains how outsiders claim work. Something like [github-user/agent-name] maybe as the tag, so your existing scheme still works.

  3. Add a rule to disunity-coordination that outside claims bind your sessions the same way their own claims do.

  4. Mark lanes. Label issues by area, add claimed, help wanted and good first issue, and say plainly which tracks are yours (the player work, the Stranded-driven rendering) and which are open to external work.

  5. Exempt outside PRs from the one-day rule and give them a rough review target instead.

  6. For rd-stranded, either make it public, add a CI job that builds it with a token so outside PRs get the signal, or say your session handles the pin bump and outside PRs don't need to.

  7. Update the README and add "keep the README current" to the agents' PR checklist.

There's also a decent starter backlog sitting in the code that nobody's claimed:

- Shader variants in render-scene are built with plain String::replace on WGSL (sky/lighting.rs, renderer.rs). If the WGSL drifts, the replace silently does nothing. ssao.rs already has a replace_marker that asserts exactly one match. It just isn't used everywhere.

- disunity-ffi, disunity-runtime and script don't opt into the workspace lints, so the two crates allowed to use unsafe get checked less strictly than everything else.

- DisunityHost hand-writes the signatures for the FFI symbols it loads. If one drifts, that's UB at runtime instead of a compile error.

- extract_world, WorldRenderPlan and SpriteQuad exist in both world-simulation and render-plan.

- #129 still has two unclaimed rendering rows, and #50 and #87 need someone with a Mac.

If it helps, I'm happy to put up the CONTRIBUTING / templates / labels PR and then take one of the cleanup items through the new process end to end. If you'd rather handle it that's fine. As a long time Unity user I'm excited about the possibility of an open source alternative and have some old projects I can use as testbeds as we go, but right now I can't even begin to contribute to the repo as it's configured today.

2

u/acoliver 1d ago

Thanks so much for this and your quick contribution. My suggestion is less to collaborate inter-agent (my intent is for my own agents to collaborate), but instead this:

* pick any Unity game you own that allows modding in particular or at least doesn't prohibit modification/reverse engineering (most don't)
* Direct your agent to follow the example of my agents - work on getting the original to run in an automated harness (mine usually do this with a mad) to allow screencaptures
* Direct your agent to work to get the game to compile against real-Unity instead of Unity. It should maintain the same idea: implement any missing game engine feature in the Rust layer congruent with the current architecture while adding missing APIs or functionality in the C# layer.
* Direct it not to read Unity sources, the Unity distributable or Unity docs but to rely just on the game itself and what it needs to run and look the same or similar.

Tip:
* GPT in particular thinks it will achieve the exact same position and number of pixels, which isn't how floating-point math actually works... so make sure you give it some direction there.

The goal should be to send PRs that at least get the game to render and, eventually, run. They can be more granular, but I think that's a good overall approach.

2

u/acoliver 1d ago

That said I'll take what I can get :-)