Owning the language, IDE, and engine might actually be the interesting part here. The question is what workflow that lets you build that would be awkward or impossible in Godot/GameMaker. If you find that, you probably find the project's killer feature too.
Show HN: C# Game Engine with its own scripting language and IDE
51–60 of 73 posts
Re: Show HN: C# Game Engine with its own scripting language and IDE
#52This is a massive undertaking... building a whole language + IDE + engine from scratch is insane. I am curious: what made you go with a custom language instead of just embedding Lua or something? Was it a learning thing, or do you think Exp brings something Lua (or GML) doesn't?
Thanks! so, at first i really used C# for scripting language, so it was like GameMaker-8 but C# instead of GML... but after almost year of development, i was bored. it wasn't exciting anymore, and when i asked myself what would make it exciting again, the answer was "my own language". i don't know why, but it's something i always wanted to build by myself. i had absolutly 0% idea on HOW, but after a break of more tha…
The "i was bored" part is the most useful thing in this thread. I think
personal projects usually die not because the technical part is too
hard, but because the person does not want to open the project anymore.
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.
Re: Show HN: C# Game Engine with its own scripting language and IDE
#53To any aspiring game developers out there: If you need AAA-equivalent graphics and are willing to tank the overhead, use UE5. Otherwise, homebrew everything in the language you prefer (use an LLM, make sure you understand the architecture perfectly). 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'…
Just write your own SDL how hard could it be
Re: Show HN: C# Game Engine with its own scripting language and IDE
#54Earlier quoted context omitted.
What's time traveling debugging?
https://en.wikipedia.org/wiki/Time_travel_debugging Basically it’s rewinding a process so you can observe changes or twiddle the knobs.
Neat~ it kind of reminds me of Bret Victor who did a lot of research and design into experimental programming environments where changing code instantly updates the visual output.
Re: Show HN: C# Game Engine with its own scripting language and IDE
#55Earlier quoted context omitted.
Thanks. As you said, the IDE is built on winforms, so it's windows only. maybe it was a mistake to not to use a cross platform framework like avalonia, but i really like the winforms designer, and winforms is the only UI framework i ever used, except for MAUI which is not a good idea to build an IDE on.
I really miss working with WinForms. 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.
I completely agree with you. It definitely felt like function over form. It was utilitarian, but WinForms was probably the closest thing since Visual Basic (and Delphi) in terms of rapid prototyping of a GUI.
Re: Show HN: C# Game Engine with its own scripting language and IDE
#56I've also been making a game engine based on MonoGame (and prime31/Nez), and one thing I recommend looking into is headless mode for both the game and the editor. I started my engine in the first place because I want to get back into gamedev, but there's no way I'm going back to the convoluted editor-centered workflow of Unity/Godot. And with proper MVVM, you can get the game headless too, so agents can play without…
The thing is that doing a separation for editors necessitates that you create a "client-server" protocol and things needs to flow through it, and that adds quite a bit of complexity over a "plain" editor.
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).
Re: Show HN: C# Game Engine with its own scripting language and IDE
#57> The engine and IDE themselves are written in C#, but the language you use inside ArcadeMaker to program your games is my custom language, not C#. 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.
So I need to implement again the assembly manager in the IDE. which will allow you to add your own C# libraries (DLLs) and then the answer would be yes, but from within the engine's language, like this: C#: public void DoSomething(Exp.Instance? callingInst, Exp.IValue?[] args) { ... } Exp: doSomething("hello") There is already a relection-based way to call C# functions from my language, i call it "extern classes": ex…
(Lesson from experience here)
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.
Re: Show HN: C# Game Engine with its own scripting language and IDE
#58I've also been making a game engine based on MonoGame (and prime31/Nez), and one thing I recommend looking into is headless mode for both the game and the editor. I started my engine in the first place because I want to get back into gamedev, but there's no way I'm going back to the convoluted editor-centered workflow of Unity/Godot. And with proper MVVM, you can get the game headless too, so agents can play without…
The thing is that doing a separation for editors necessitates that you create a "client-server" protocol and things needs to flow through it, and that adds quite a bit of complexity over a "plain" editor. 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…
Yes, I guess a big part I skipped is that it may not be such a good fit for action games, where asset-dependent interactions, such as collisions, can affect the game model.
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.
Re: Show HN: C# Game Engine with its own scripting language and IDE
#59Re: Show HN: C# Game Engine with its own scripting language and IDE
#60We are reaching levels of based that shouldn't even be possible.