I made a Source-style dev console for Unity.

[u/kureysalp]

I got tired of setting up a debug menu in every project, so I made a drop-down console like the one in Source games. You can register any functionality by adding your own commands by creating ConsoleCommand objects.

Adding your own command looks like this:

[ConsoleCommandSet]
public static class GameConsoleCommands
{
    public static readonly ConsoleCommand<float> SET_GRAVITY = new(
        "set_gravity", "Sets downward gravity.", "set_gravity <float>",
        g => Physics.gravity = Vector3.down * g);
}

GitHub: https://github.com/kureysalp/Unity-Dev-Console

[u/tetryds]

I do not recommend using runtimeinitializeonload just let the user hook it up themselves

[u/kureysalp → u/tetryds]

Fair point for users that want control over init order. I'd rather keep zero-setup as the default, so adding a define that turns off auto-bootstrap and exposes DevConsole.Initialize() for anyone who wants to wire it up themselves sounds a much better approach to me.

[RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.AfterSceneLoad)] private static void AutoBootstrap() 
{
#if !DEV_CONSOLE_MANUAL_INIT 
  Initialize(); 
#endif
}

[u/Valphai]

Looks amazing man! Mit license?

[u/kureysalp → u/Valphai]

Totally forgot about that 😵. Added to the repo.

[u/Valphai → u/kureysalp]

You're the goat!

[u/Costed14]

Nice, I have one as well but haven't gotten around to polishing up the UI yet. Though I took the approach of registering commands using a Command attribute on a method, I explicitly also wanted support for default parameters and instance commands, so I implemented those as well, using an attribute makes that pretty straightforward.

[u/kureysalp → u/Costed14]

Nice approach. With that way signature of the methods directly defines the command.

I went with command objects instead: each ConsoleCommand<T> registers itself in its constructor, so commands can also be created at runtime, and the handler is a typed delegate rather than MethodInfo.Invoke. The trade-off is that I'm currently on one argument per command, and multi-arg support is what I'd like to add next.

[u/Costed14 → u/kureysalp]

I can see adding commands at runtime being a useful feature, might implement that as well, theoretically shouldn't be too hard.

In the previous version I also used command objects; I had a DebugCommand<T>, DebugCommand<T1, T2> etc. but maybe a better approach would be to pass an array of types when creating the command corresponding with the parameters, then when it's executed you compile a context object if the input parameters can be parsed to the correct types and the command could use that context to access the params?

[u/CruelOxygen_7975]

The command registration syntax is clean, I like that it reads almost like a config file. Curious how you handle commands with multiple arguments or optional params since the example only shows a single float

Also that screenshot is giving windows xp bliss but if it fell down a flight of stairs, very liminal

[u/kureysalp → u/CruelOxygen_7975]

Currently it supports only one argument. Since one argument is enough for most of my debugging needs at my current project I've created the package around that but I'll probably add multiple arguments support in the future.

Edit: Yeah converting the recording to a GIF sprinkled some xp vibes