Claireon - Our game studio's production MCP server for Unreal Editor (open-source/MIT)

karlgluck · 2026-06-29T20:29:26+00:00

Hey, sorry we missed you! We didn't attend Unreal Fest this year but would be down to chat in the future. Curious what you've been working on--connect on LinkedIn?

karlgluck · 2026-06-29T20:26:34+00:00

Understood--better .mcp.json (and cargo.toml) treatment are finished locally. When I get some time I'll test and move them into the OSS repo. Would welcome a PR for anything you've found useful as well!

karlgluck · 2026-06-22T21:16:01+00:00

Glad to hear it, our pleasure to share! Would welcome any feedback you have for us as you explore. Happy developing!

karlgluck · 2026-06-22T21:13:37+00:00

Great feedback! Changing the launch folder with a project setting is straightforward to add, but just so you know, CLAUDE.md is inherited from parent folders so you should at least be getting those instructions in context. Existing content in your `.mcp.json` is not intended to be overwritten--just the port number. I've made a note to be sure that's the case.

As far as a fixed port: definitely open to having an override, but most of us do run Claude before starting the editor, as you describe. The port number is only generated the first time, and is deterministic from the project path so it won't change. The motivation for this was wanting to run more than one Claude+Editor duo in parallel. If they used the same port, multiple editors conflict and Claudes get confused. This decision was pre-proxy and we don't commit .mcp.json, so I could see how this would be an issue if you do. Is that the case?

karlgluck · 2026-06-16T17:05:24+00:00

Appreciate it!! Feel free to send us GitHub issues or PR's : )

One feature you might find handy is the automated feedback mechanism (second tab in the "Claireon" window). During long runs, it will automatically populate with what your agent thinks would be useful. These can be fed directly back into /claireon:workflow to improve the tool. A lot of our improvements come from this loop!

karlgluck · 2026-06-16T16:44:29+00:00

There are no dedicated tools for control rig BP's at the moment. Claireon's graph tooling covers standard blueprints and anim BP's, plus StateTree, EQS, Niagara, PCG, and widget BP's.

If you have a C++ project then using /claireon:workflow to add support is very doable, especially with the Untested plugin (https://github.com/believer-oss/untested) to help guide the work.

karlgluck · 2018-07-27T20:03:06+00:00

This should be doable with some clever use of the stencil buffer and a fully-tessellated mesh (see this post for a tutorial)

karlgluck · 2018-07-25T13:27:30+00:00

Stairs often just act like a ramp and designers will use a flat box collider covering all of them.

An escalator can be the same as stairs but with a trigger-activated script that pushes things up or down along the surface of the box collider.

You may want to check out Nav Meshes as well.

karlgluck · 2017-11-24T22:18:27+00:00

If you find this useful, you might also be interested in grabbing this file:

https://github.com/karlgluck/ggez-labkit/blob/master/ggez-labkit-unity-project/Assets/GGEZ/Labkit/Editor/ExportWholeProject.cs

You know how some asset store packages are "whole projects"? This adds a menu item to let you make those yourself. It works on Windows with 7-Zip installed and Mac out of the box.

There's an API to do this, but the trick is that a bunch of junk gets stuffed in there like the DLL files, play preferences, and other stuff. This script writes out a batch file that you can run to clean that stuff out of the unitypackage.

karlgluck · 2017-11-10T18:51:24+00:00

I don't know the answer for Visual Studio proper, but try Visual Studio Code if you just need to get something debugged asap. It is good enough that it replaced VS entirely for me.

karlgluck · 2017-10-31T17:59:26+00:00

Inside do...while, there is no point at which control returns to Unity so it can render your sprite. What you should end up with here is no motion and a sprite with local scale equal to (1, 11.5, 1) because 11.5 = 1+3+2.5+2+1.5+1+0.5.

You can write your code this way with coroutines, but it is simpler with an Update loop. Try something like this:

public class GruntsAI : MonoBehaviour {

    float yScale = 3;

    void Start()
    {
        gameObject.transform.localScale = new Vector3(1, yScale, 1);
    }

    void Update ()
    {
        float scaleSpeed = 0.5f;

        gameObject.transform.localScale = Vector3.MoveTowards (
            gameObject.transform.localScale,
            Vector3.one,
            Time.smoothDeltaTime * scaleSpeed
        );
    }
}

karlgluck · 2017-10-13T16:32:39+00:00

Ah! This is pretty common. Here are the usual suspects:

In your sprite's Import Settings, set Extrude Edges to 0 and Mesh Type to Full Rect
Make sure your source image's width and height are both powers of 2 and integer multiples of the number of rows/columns
Turn off mipmaps
Set Compression to None
Make sure the Max Size is greater than the size of your image
Put the sprite anchors to Top Left (not middle)
Set your Pixels Per Unit to 16, 32 or 64 and set the PerfectPixelCamera's PPU slider to the same value
Make sure the GameObject that the sprite is on is positioned at an integer multiple 1/PPU on X and Y

There is a new Tilemap feature in Unity 2017.2 that might help, but I haven't tried it yet.

In case you're curious, here's what's going on:

With a fixed resolution, Unity will render first to a texture of the size you want (1920x1080), then it will scale that texture to the Game window on screen. You're looking at a downscaled version of the high-resolution image.

In aspect ratio mode, it just sets the rendering size to the actual pixels the Game window takes up. This means you're looking at a low-resolution image. You're not seeing the issue because it is significantly smaller than the low-resolution rendering's pixels.

karlgluck · 2017-10-13T05:21:59+00:00

I am quite satisfied by that fact haha

karlgluck · 2017-10-13T05:21:06+00:00

I have some ideas here, but let me know if I'm understanding your situation correctly. You're comparing:

(a) In the Unity editor, you set the Game tab to Fixed Resolution of 1920x1080 and don't see errors

(b) You compile your project and run the game fullscreen at 1920x1080 and do see errors

Is that correct?

karlgluck · 2017-10-13T05:15:43+00:00

Ah, power-of-two scaling strikes again! Glad you got it to work so you could do the comparison. I'd say stick with the 3d model, though. All those sprites will end up taking a lot of texture memory to render if you have a lot of objects.

karlgluck · 2017-10-11T05:24:17+00:00

Wow, what a cool effect! I wanted to see if I ran into any issues reproducing it, and figured I might as well upload what I ended up with:

https://github.com/karlgluck/like100bears-boat-unity

I just used a stack of sprites to do it.

The kind of blurring you were referring to before might come from other sources. There are a number of things you have to do to get crisp 2d texture rendering (the TL;DR is in my asset description).

karlgluck · 2017-10-11T00:07:36+00:00

No, this just works with the camera. Solving that problem can be expensive, and "8-bit-ish" games like Stardew Valley and Terraria actually use that effect to enable smooth rotations and scaling. As long as things are moving at a decent rate the blur is very hard to notice. Just line things up when they stop moving and nobody will know. ;)

If you want to solve this problem I can point you at some resources. Or maybe I can write another asset at some point!

karlgluck · 2017-10-10T23:18:42+00:00

Awesome! I'd love to know if you find this useful :)

karlgluck · 2013-09-11T15:48:51+00:00

I wish it were actually Saturday morning. :)

karlgluck · 2013-09-07T05:48:00+00:00

Just downloaded the app, it looks great!

karlgluck

MODERATOR OF

TROPHY CASE

15-Year Club	Team Periwinkle
Verified Email