Rendered at 17:21:36 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
am-gm 6 hours ago [-]
Wow, my post suddenly went viral! Just opened GitHub a few minutes ago, and saw +17 stars on my project from the last few hours... Anyway, i see a lot of people asking WHY making ky own engine or language. So the main answer is: for fun. it's clearly not going to be even close to a professional engine like godot/unity/modern gamemaker, but this is mine, and the others aren't :)
But i wrote more about it here: https://www.reddit.com/r/csharp/comments/1tmcg6j/my_biggest_...
WillAdams 4 hours ago [-]
Two thoughts/questions:
- 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?
Notably, that would then allow publishing the project as a PDF for didactive purposes.
3 hours ago [-]
am-gm 4 hours ago [-]
1. Not in the current state of the engine, but in the future - after implementing all the graphics functions that i plan to add - yes, absolutly.
2. Hmm no, first time i hear about it
spacechild1 6 hours ago [-]
Thanks for sharing! Great attitude!
h2aichat 10 hours ago [-]
This 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?
am-gm 6 hours ago [-]
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 than a year, one day i just tried and unlike a few previous times, this time it started clicking, and this what bringed me back to the abandoned game engine
unfinished_thum 3 hours ago [-]
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.
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.
vunderba 2 hours ago [-]
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.
As somebody else with a game engine that has its own scripting language:
AI 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)
am-gm 6 hours ago [-]
I really don't want to use AI for my project. I love writting code by myself, and except for very few specific things, I didn't use it in this project. But for the language i actually didn't use ANY external sources, including google, tutorials, books. wanted to figure it out by myself. so maybe i'm kind of weird in this stuff
6 hours ago [-]
ivm 4 hours ago [-]
I'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 UI and run thousands of simulations of the gameplay.
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.
whizzter 2 hours ago [-]
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).
ivm 2 hours ago [-]
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.
FLeXMurphy 36 minutes ago [-]
We are reaching levels of based that shouldn't even be possible.
Altern4tiveAcc 7 hours ago [-]
The inspiration on GameMaker is clear and very much appreciated.
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).
am-gm 6 hours ago [-]
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.
dadoum 5 hours ago [-]
Windows.Forms is becoming less of a problem with projects like LibreWinForms [0] progressing quickly. I just tried to build your project and there are only a few classes that are not implemented when it comes to the GUI.
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.
vunderba 2 hours ago [-]
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.
gwbas1c 4 hours ago [-]
> 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.
am-gm 3 hours ago [-]
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:
There is already a relection-based way to call C# functions from my language, i call it "extern classes":
extern class File = "System.IO.File"
println(File.readAllText(filePath))
it can also be used with non-static classes, and you can use new(...) expressions on them, and "is" tests and access properties and so on... it SHOULD feel like a normal Exp class. The only exception is that it does not fit to performance-critical contexts, because it uses the slow reflection APIs of C#. but it's already working, unlike the assembly manager feature that is not implemented yet but will allow fast invocations.
gwbas1c 2 hours ago [-]
(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.
ux266478 3 hours ago [-]
Seems rather trivial, just extend the codebase.
kiops 3 hours ago [-]
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.
wingardium 3 hours ago [-]
looking for open source game engines lately, this is soooo cool :)
am-gm 3 hours ago [-]
Thanks
BSTRhino 7 hours ago [-]
I think if you're looking for other people to use your game engine, it helps to have one killer feature. I'm not clear what yours is at this point. Even if your killer feature is not something you have yet completely implemented, but it is simply a long-term goal, I think it is worth listing that front and center.
am-gm 6 hours ago [-]
If I'll have an idea for such a "killer-feature", I'll do my best to implement it... :)
theyliesoeasily 7 hours ago [-]
To 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'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.
semyonsh 6 hours ago [-]
As mentioned there are plenty of engines mature and worthy to develop with, like Godot.
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.
spacechild1 6 hours ago [-]
Thank you! That's exactly what I was about to write.
xgulfie 3 hours ago [-]
Just write your own SDL how hard could it be
TulliusCicero 7 hours ago [-]
Eh, what's wrong with using Unity or Godot or GameMaker?
4 hours ago [-]
gauntr 9 hours ago [-]
Apart from "I have fun working on this", which is always legit, what's the point and who's supposed to use it? What'd be the benefit using with or working on it over e.g. Godot, which is, imo, pretty much the open source way to go if you want more than an IDE and libs/code you'd use to make a game. It's also written in C# and offers GDScript as a more lightweight programming language with C# being ready to be used for when it's necessary.
bob1029 9 hours ago [-]
The benefit of engaging with a project like this is that you gain a very plausible set of excuses that can be leveraged when you find out that making the game is the actual hard part.
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.
whstl 8 hours ago [-]
Do you make it a habit of shitting on other people hobbies? Maybe I should try doing the same! Lets go:
Your post assumes everyone wants to make a game in 2026, the year where a half a trillion games are launched per milisecond on Steam (numbers outdated, probably more now), and every "gamedev" community has become 50% about marketing and 50% about self-help. But that still adds up to 100% toxic and 100% being a lottery.
Or maybe they don't want to join a large game studio and make a fraction of the money they make on their cushy web job, where they're home at 6PM. Or worse: risk joining an indie team, where there's a 99% chance people are either lying or are plain talentless.
Seriously now: Game engines are a way to escape the hell that is making games in 2026 while still engaging with the fun parts of the hobby. Will it produce anything worthwhile? Probably not. But chances of it doing so are 100x higher than when making games.
The toxicity of the game community of constantly shitting in something they can't do and can't understand needs to fucking stop.
andsoitis 7 hours ago [-]
> Do you make it a habit of shitting on other people hobbies? Maybe I should try doing the same! Lets go:
> The toxicity of the game community of constantly shitting in something they can't do and can't understand needs to fucking stop.
In your rage, I think you replied to the wrong person maybe?
whstl 7 hours ago [-]
Definitely not.
Replying to the trope that exists in gamedev that "making the game is the only valuable thing, people who make engines are just making excuses".
> Firing up godot/unity/unreal eliminates an entire universe of reasons for why you haven't shipped more content today
Not everyone wants to "ship content".
> brutal exposure when you don't have a creative vision to follow
Also assumes everyone must have or follow a creative vision.
EDIT: And yeah, I'm tired of people collectively shitting on other people's project in HN without even looking at it, or without considering why not having monocultures is good.
andsoitis 7 hours ago [-]
> EDIT: And yeah, I'm tired of people collectively shitting on other people's project in HN without even looking at it, or without considering why not having monocultures is good.
The person you replied to simply wrote the following, which seems like the opposite of shitting on the project this post is about:
"The benefit of engaging with a project like this is that you gain a very plausible set of excuses that can be leveraged when you find out that making the game is the actual hard part. 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."
Not meaning to argue; maybe we're just getting our lines crossed.
Archer6621 6 hours ago [-]
It does not read like a compliment to me. What the person seems to be saying in a rather patronizing and opaque manner is that building a game engine gives you an excuse to avoid building a game, thus framing it as an exercise in avoiding hard work or needing to be creative.
In reality however, many people whom I know who built a game engine did it for a plethora of different additional reasons:
- Learning C++, OpenGL, and other tech
- Similarly, learning a new language
- Learning how a game engine works, by building one, and perhaps a better one afterwards, or for developing skills to work on existing engines
- Just because it is fun and you get a high from it
- Building an environment tailored to how they would like to build a game, e.g. because existing engines don't cut it in that regard. Basically building your own tool(s).
- Building tools for others, so that they can build cool things, because you get satisfaction from that.
- Building a new engine because existing large engines have gone stale for some reason (an attempt at becoming the next big engine that structurally solves the tech debt problems that the status quo ones developed over time)
- Similarly, building an engine that has a new paradigm as first-class citizen, e.g. ECS
- A combination of any of these.
I had a similar mindset in the past, not understanding why anyone would like to build their own engine and not a game, because it happened very often and I was the one who liked to build games. Now I do see that there's more to it than just the product it is supposed to create. I learned that when I got into tool development, and noticing that I got a lot of satisfaction from building tools that other people can use well.
whstl 6 hours ago [-]
Reducing it to a "plausible set of excuses", among other things, is what I mean by shitting on other people's passion project. Saying that the "firing unity/unreal/godot" is what I mean by preferring monocultures.
EDIT: Writing an engine is difficult and time consuming, but also rewarding in several ways, and requires a completely different skill set from writing a game. It's incredibly patronizing to call it "an excuse".
This is similar to asking someone making an image editor to "just open photoshop, you're making excuses for not working on art".
virgildotcodes 8 hours ago [-]
I'm sold.
Razengan 8 hours ago [-]
> when you find out that making the game is the actual hard part.
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.
No, Godot is written in C++. You can use C# to code games, as well as GDScript or other languages.
gauntr 6 hours ago [-]
Oh ok, my bad. Thought it was C# and therefore C# was the reason it's advertised for more complex coding in Godot. False friend I guess, should've checked, thx.
__m 8 hours ago [-]
No successcull game engine is written in c#
dude250711 6 hours ago [-]
Correct, as there is no need. Use frameworks instead: Terraria, Stardew Valley, Celeste.
- 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
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.
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.
https://www.youtube.com/watch?v=a-OyoVcbwWE
AI 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)
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.
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).
[0] https://github.com/wieslawsoltes/LibreWinForms
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.
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.
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.
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.
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.
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.
Your post assumes everyone wants to make a game in 2026, the year where a half a trillion games are launched per milisecond on Steam (numbers outdated, probably more now), and every "gamedev" community has become 50% about marketing and 50% about self-help. But that still adds up to 100% toxic and 100% being a lottery.
Or maybe they don't want to join a large game studio and make a fraction of the money they make on their cushy web job, where they're home at 6PM. Or worse: risk joining an indie team, where there's a 99% chance people are either lying or are plain talentless.
Seriously now: Game engines are a way to escape the hell that is making games in 2026 while still engaging with the fun parts of the hobby. Will it produce anything worthwhile? Probably not. But chances of it doing so are 100x higher than when making games.
The toxicity of the game community of constantly shitting in something they can't do and can't understand needs to fucking stop.
> The toxicity of the game community of constantly shitting in something they can't do and can't understand needs to fucking stop.
In your rage, I think you replied to the wrong person maybe?
Replying to the trope that exists in gamedev that "making the game is the only valuable thing, people who make engines are just making excuses".
> Firing up godot/unity/unreal eliminates an entire universe of reasons for why you haven't shipped more content today
Not everyone wants to "ship content".
> brutal exposure when you don't have a creative vision to follow
Also assumes everyone must have or follow a creative vision.
EDIT: And yeah, I'm tired of people collectively shitting on other people's project in HN without even looking at it, or without considering why not having monocultures is good.
The person you replied to simply wrote the following, which seems like the opposite of shitting on the project this post is about:
"The benefit of engaging with a project like this is that you gain a very plausible set of excuses that can be leveraged when you find out that making the game is the actual hard part. 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."
Not meaning to argue; maybe we're just getting our lines crossed.
In reality however, many people whom I know who built a game engine did it for a plethora of different additional reasons:
- Learning C++, OpenGL, and other tech
- Similarly, learning a new language
- Learning how a game engine works, by building one, and perhaps a better one afterwards, or for developing skills to work on existing engines
- Just because it is fun and you get a high from it
- Building an environment tailored to how they would like to build a game, e.g. because existing engines don't cut it in that regard. Basically building your own tool(s).
- Building tools for others, so that they can build cool things, because you get satisfaction from that.
- Building a new engine because existing large engines have gone stale for some reason (an attempt at becoming the next big engine that structurally solves the tech debt problems that the status quo ones developed over time)
- Similarly, building an engine that has a new paradigm as first-class citizen, e.g. ECS
- A combination of any of these.
I had a similar mindset in the past, not understanding why anyone would like to build their own engine and not a game, because it happened very often and I was the one who liked to build games. Now I do see that there's more to it than just the product it is supposed to create. I learned that when I got into tool development, and noticing that I got a lot of satisfaction from building tools that other people can use well.
EDIT: Writing an engine is difficult and time consuming, but also rewarding in several ways, and requires a completely different skill set from writing a game. It's incredibly patronizing to call it "an excuse".
This is similar to asking someone making an image editor to "just open photoshop, you're making excuses for not working on art".
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.