Show HN: C# Game Engine with its own scripting language and IDE
github.comAI is incredibly good at making scripting languages with your ideal dream syntax/functionality. It's pretty fun to use it.
(No, neither my engine nor my language is worth using and never will be)
Their entire stack is custom (language, compiler, IDE, build system, engine). Has neat features like time-travelling debugging and instant hot-reloading for code and assets.
Basically it’s rewinding a process so you can observe changes or twiddle the knobs.
Your answer was to build the thing you always wanted to build. It worked, because you came back. I think that is more important than a killer feature.
Firing up godot/unity/unreal eliminates an entire universe of reasons for why you haven't shipped more content today. Tools that "just work" can feel like brutal exposure when you don't have a creative vision to follow.
Guilty as charged ^-^"
Spent over 3 years trying to make an engine built in Swift cause I loved Swift, before I had to admit that an engine without an editor is almost useless in actual game development, and even 10 years won't bring me close to the level of Godot's editor (though Miguel de Icaza the Mono/Xamarin/Gnome guy did port the Godot Editor to SwiftUI) [0]
so I spent the next 3 years trying to make a framework for Godot :') and still no actual game.
[0] https://blog.xogot.com/blissful-ui-development-with-swiftui-...
No, Godot is written in C++. You can use C# to code games, as well as GDScript or other languages.
Can the IDE run on other OSes besides Windows? You seem to be using WinForms.I tried building it and running through Wine, but it didn't work.
Congrats on the project, making an IDE is no easy task. I believe there's room for a game engine to offer what GameMaker 8.1 used to (near instant runs, extremely fast iteration time for 2D games).
Every other UI framework I worked before and after always left me with the impression that something was lacking, in speed of development, fast iteration, but also in the quality of the abstractions.
WinForms has had a major cleanup over the last few years. Issues with DPI, multiple windows are mostly gone.
You no longer need VS2. vscode on its own is excellent, and you can if you need to, still use VS2 for debugging
(Same applies to AvaloniaUI for cross platform.)
Codex, Claude need guidance if you want something maintainable, otherwise they generate a mess structure wise or reinventing functionality already available in standard controls 'out of the box'.
But people want python ...
Indeed. But I always found WinForms also better for "slow and polished".
Using a half-baked semi-supported game engine which you don't understand will destroy your project sooner or later. The cognitive overhead of understanding someone else's code is far, far higher than using your own. If you can't handle any of this, get a developer on board who can - you aren't equipped for this.
For example: race conditions in animation events (killed a game jam project), contact filters not being passed to 2d collisions in the API (added days of debugging to a simple prototype, has since been fixed), list/arrays causing the editor to bug out and require a restart after editing one (in the LTS version in 2026 - unforgivable).
Sure, don't roll your own SDL (but also if you can, do - you'll be a better game developer for it). Do for example roll your own animator - you don't need their features, clarify what you actually need and design for that. Do you want to trigger scripts with frames? Should those scripts be executed before the next frame, or with it? Do you need a bones/rigging system? How should those bones warp the mesh exactly for your visual style? A game isn't just a collection of scripts moving objects around, it's a pipeline of design intentions from bottom to top. Someone else's engine will be mediocre for your project at best, and inheriting their bugs and workflows is far more painful than designing and fixing your own.
Even with frameworks like monogame, you inherit their asset pipeline and rendering API decisions. Better to create exactly what you need, and understand it.
Even when you reach the deployment phase, you'll be hit with errors and incompatibilities you couldn't foresee. E.g. the Signalr .net library is incompatible with WebGL builds, so have fun maintaining an additional js signalr bridge for your WebGL build separate to your editor build.
Advising to homebrew everything with an LLM just sounds insane to me. Cognitive overhead of what? Using well thought out and standardized libraries that have proper documentation? Creating a new engine with an LLM is only going to achieve the opposite of fully understanding your codebase.
Let's say you're making a visual novel. Do you need a fully 3d editor? No, so having Z coordinates on all your objects is a liability: you'll have bugs with Z-fighting sprites or your designer will accidentally place gameobjects at depth and not understand why they're not rendering, because this is a 2d game and they set the rendering layer correctly not thinking about 3d space.
Specify exactly what you need and execute that, using libraries for the low level stuff, and taking responsibility for as many design decisions as you can. It will save you so much frustration. If I could go back and give one piece of advice to myself when I was learning, it would be ditch the engine - they are false promises. One size fits all means it truly fits no one.
You are right that you can often ditch the engine, but you should only do that as an experienced programmer who can assess the scope of the project. AI doesn't really change that IMO.
- do you feel that this could be used to make a (simple) drawing program?
- have you considered setting up your codebase as a Literate Program?
http://literateprogramming.com/
Notably, that would then allow publishing the project as a PDF for didactive purposes.
2. Hmm no, first time i hear about it
If you have occasion to try Literate Programming, or have any interest in the concept, I'd be glad to hear of it.
Overall, MVVM should be getting a renaissance because of how well it determines the layers and data flow for AI. I have multiple projects using it, and even in early 2025, models had almost no issues understanding my code and implementing new features. Now I set up MVVM-inspired headless architectures including for Swift or React Native projects and it works like a charm.
And for authoring tools, especially in gamedev that can really blow up in complexity, because you often want to create custom editors (imagine things like enemy paths, layered enemy paths, skin customization options, and so on) and every customized one risks adding more complexity to the protocol (unless ridiculously overspecified from start).
This is why "dear ImGui" is so popular (look at the example screenshots for the library.. tons of editors), the magic is that you can tie rendering of the editor to the editables quite easily so there is very little overhead in makin an editor (a task that normally can gobble up inordinate amounts of time).
But games closer to the tabletop end of the spectrum (think strategy, puzzles, etc.) are basically apps: they're not doing much in the world itself, but rather rendering it based on the existing state and accepting user input to modify that state.
Is there a plugin system that allows me to code in C#? (Or F#, or perhaps any of the other dotnet scripting languages?) I'd prefer to avoid a new language if possible.
C#:
public void DoSomething(Exp.Instance? callingInst, Exp.IValue?[] args)
{
...
}
Exp:
doSomething("hello")
extern class File = "System.IO.File"
println(File.readAllText(filePath))
Years ago I built a "bells and whistles included" webserver with a development environment. https://github.com/GWBasic/objectcloud. (I moved it over to Github after I abandoned it, which is why the repo doesn't follow Readme.md semantics.)
Anyway, a mistake that I made with Objectcloud was basically following my fancy everyday and making many parts custom. In the end, the function of the project was educational for me; but Objectcloud itself never was a useful tool for other people. In part, Objectcloud turned into me solving every problem at once, instead of carefully choosing the problems I needed to solve to have a useful product.
To make a long story short: In dotnet, it's very easy to build programmable extensibility by publishing an interface. By putting "scripting" first, and tightly coupling scripting into the tool, you introduced a lot of complexity into the tool and the learning curve. (I have to learn a new tool and a new language.)
In contrast, if you started with a more traditional dotnet-style "just build classes that implement these interfaces" extensibility, you end up reducing your problem scope. (IE, are you trying to build a game engine or a scripting environment? You only have so many hours in the day, and both are complicated projects to support.)
Furthermore, you can always add a scripting plugin built to the interface once the gaming engine is mature.
Out of personal interest, what role do you envision for Exp in the long term? Do you see it primarily as a scripting language for a game engine, similar to a Lua-like language embedded in a C# application, or as a standalone programming language in its own right?