I've build 10+ games which I am ashamed to show :)
Straight JS/html/css front-end with zero dependencies works well.
Ask for a node.js backend and can be instantly deployed as client/server or straight to html - multiplayer feels trivial.
C# Monogame works well for something heavier.
You can actually edit Unity scenes directly using the LLM as they're a readable text file which works ok, but Unity is bloatware when you can code it all yourself (it's an absolute nightmare of inexplicable bugs, do not use it. After updating to 0.62f from 0.48f my clang compiler now segfaults while building Webgl - luckily my team mate can do the builds)
The key is building exactly and only what you want and need. Make your design lean, suit the game as you are actually building it not a theoretical overengineered masterpiece - refactors are cheap later, but bloat will kill your project.
I've had my own rollercoaster relationship with Unity over the past decade, but telling people to roll their own game engine so that they can finally make a game is almost universally terrible advice.
People who want to build game engines should build game engines; people who want to build games should absolutely use Unity, Unreal or Godot in no particular order.
It's no different than needing to build a web framework so that you can make a website. The people who do it are often not even aware that they are procrastinating.
People who are making a simple 2D web game don't need an engine, with rare exceptions. Chrome's 30 million lines is plenty of bloat to build on ;)
Besides, in this context you're already outsourcing all the code to Claude or Codex or whatever. i.e. a "programmer" who has no problem handling the engine side of things.
That being said, most enginedev is creative procrastination. Randy's recent video on this is very illuminating — "I thought if I made a really good engine, making the game would be the easy part!" So he avoided actually making a game for like ten years...
Most 2D games don't even need an engine: you can just make the game "directly", on top of SDL or Canvas or what have you. (That being said, noob friendly stuff like Processing and Kaboom is great and highly recommended!)
--
Source: made lots of 2D games and a few engines. The engines were a complete waste of time. (Even ready made engines often did more harm than good!)
If I was making 3D games, then I would probably need an engine (but js13k begs to differ!), and it would probably not be a great to roll your own (unless you're going for something 90s themed :)
--
Edit: Most of my games are very "programmer art", or very retro. If I were an artist or working with artists, then an engine would be useful for that, for the visual side of things. Flash was probably unmatched in that regard
That being said, it's not that hard to roll your own level editor, so... ;) even that argument is questionable.
Edit 2: Also the web APIs are unfortunately kind of ass, so using a library (or engine) has the advantage of letting you avoid dealing with them directly for the most part.
Problems I've had with unity in my last 3 installs. All LTS default installations on windows. (I have delivered professional projects in Unity in the past):
1. Inspector for lists/arrays works once, crashes editor, must be restarted each time.
2. Race conditions in the basic animator functionality making animation events useless, killed a project because we couldn't edit the underlying code, didn't have time to redo animator-based functionality which should have worked in theory.
3. Segfaults in compiler -> 6 hours of debugging, gave up, still can't build reliably.
Each of these killed the workflow and therefore the ability to deliver the project dead, and were completely out of my control.
Vibe code your engine, at least you'll die on your own terms.
Unity is also just a fundamentally hostile organization waiting to pull the rug, as evidenced by their past behaviour.
Big plus for html/css/js, mostly Pixi 8 or around (I also have a couple threejs). Vanilla JS. I did this by hand before, but having the LLM tweak around the code and styling while I handle more gameplay related things makes this doable (otherwise I just would not have enough free time)
Im using UE5 which is arguably GUI heavier than Unity.
You can get around a lot of the GUI-heavy stuff by using C++ in preference to Blueprint, and/or developing some tools to help you decompile/recompile Blueprints.
It has a pretty cool remote control plugin you can install which can be used to simplify a lot of test cases through automation.
I have a relatively large amount of experience with UE4/UE5 and C++ though, so it's probably not for the absolute beginner or the faint of heart.
I wish that people would just stop with the "vibe coding" thing.
If you want to get quality results from an LLM use a quality frontier model (I recommend Opus 4.5 thinking) in an agentic Plan -> Agent -> Debug loop inside of Cursor. Roughly 90% of the hate that gets assigned to AI anything is a direct result of the absurd notion that taking the human completely out of the loop is a valuable goal. In reality, it's expensive and almost guaranteed to produce crap.
If you treat LLMs as pair programmers and split your implementation into a set of sequential tasks of a reasonable scope, you can use Unity or Unreal or any number of JS engines built on ThreeJS to produce things that are worth playing.
I would strongly argue that pairing with Opus to write your controller code while you take primary responsibility for interacting with the UI sounds exactly like how you should proceed if you care about the end result.
