Ask HN: What game engine would you recommend for vibe coding?
I feel like things like Unity and Unreal have a lot of UI-centric workflows that wouldn’t be great for vibing.
10 comments
Just a heads up, it's highly unlikely you're going to be able to get away with pure vibe coding (as defined by Karpathy) for game dev.
There's just no way around the fact that games need a lot of play-testing and visualization, all of which is difficult to capture discrete unit tests.
Many of the games I've released using an agentic CLI (OpenCode) would have been absolutely impossible to vibe code.
That being the case, any library that’s been around long enough to be well represented in the training data of the larger LLMs will work perfectly fine. Love2D, Phaser, etc., would all be solid options.
There's just no way around the fact that games need a lot of play-testing and visualization, all of which is difficult to capture discrete unit tests.
Many of the games I've released using an agentic CLI (OpenCode) would have been absolutely impossible to vibe code.
That being the case, any library that’s been around long enough to be well represented in the training data of the larger LLMs will work perfectly fine. Love2D, Phaser, etc., would all be solid options.
# I think it's possible to architecture around this. For example, here is one idea:
- make the game as functional as possible: as in the game state is stored in a serializable format. New game states are generated by combining the current game state with events (like player input, clock ticks, etc)
- the serialized game state is much more accessible to the AI because it is in the same language AI speaks: text. AI can also simulate the game by sending synthetic events (player inputs, clock ticks, etc)
- the functional serialized game architecture is also great for unit testing: a text-based game state + text-based synthetic events results in another text-based game state. Exactly what you want for unit tests. (Don't even need any mocks or harnesses!)
- the final step is rendering this game state. The part that AI has trouble with is saved for the very end. You probably want to verify the rendering and play-testing manually, but AI has been getting pretty decent at analyzing images (screenshots/renders).
# Here is an example of a simple game developed with functional architecture: https://github.com/Leftium/tictactoe/blob/main/src/index.ts
- Yes, it's very simple but the same concepts will apply to more complex games
- Right now, there is only rendering to the terminal, but you could imagine other renders for the browser and game engines
- make the game as functional as possible: as in the game state is stored in a serializable format. New game states are generated by combining the current game state with events (like player input, clock ticks, etc)
- the serialized game state is much more accessible to the AI because it is in the same language AI speaks: text. AI can also simulate the game by sending synthetic events (player inputs, clock ticks, etc)
- the functional serialized game architecture is also great for unit testing: a text-based game state + text-based synthetic events results in another text-based game state. Exactly what you want for unit tests. (Don't even need any mocks or harnesses!)
- the final step is rendering this game state. The part that AI has trouble with is saved for the very end. You probably want to verify the rendering and play-testing manually, but AI has been getting pretty decent at analyzing images (screenshots/renders).
# Here is an example of a simple game developed with functional architecture: https://github.com/Leftium/tictactoe/blob/main/src/index.ts
- Yes, it's very simple but the same concepts will apply to more complex games
- Right now, there is only rendering to the terminal, but you could imagine other renders for the browser and game engines
That's true - state serialization can definitely help.
> AI has been getting pretty decent at analyzing images (screenshots/renders).
I've found AI to be hit or miss on this - especially if the image is busy with lots of elements. They're really good at ad-hoc OCR but struggle more with 3d visualizations in a game that might be using WebGL.
For example, setting up the light sources (directional, lightmaps, etc) in my 3D chess game to ensure everything looked well-lit while also minimizing harsh specular reflections was something VLMs (tested with Claude and Gemini) failed pretty miserably at.
https://shahkur.specr.net
> AI has been getting pretty decent at analyzing images (screenshots/renders).
I've found AI to be hit or miss on this - especially if the image is busy with lots of elements. They're really good at ad-hoc OCR but struggle more with 3d visualizations in a game that might be using WebGL.
For example, setting up the light sources (directional, lightmaps, etc) in my 3D chess game to ensure everything looked well-lit while also minimizing harsh specular reflections was something VLMs (tested with Claude and Gemini) failed pretty miserably at.
https://shahkur.specr.net
I hadn't thought about how to write tests for games before.
Wow, something I can answer!
I've been working on Ziva[0], an AI plugin for Godot that's explicitly for game development. Game development is hard and a different paradigm than regular coding, so there may be a learning curve, but we're working to flatten that out.
Happy to answer any questions!
[0] https://ziva.sh
I've been working on Ziva[0], an AI plugin for Godot that's explicitly for game development. Game development is hard and a different paradigm than regular coding, so there may be a learning curve, but we're working to flatten that out.
Happy to answer any questions!
[0] https://ziva.sh
To be fair, Unity is already building a suite for exactly this. "Unity AI" is aimed at letting you prompt your way through development instead of menu-diving
Why not just vibe code an engine?
I’m not interested in the output that is “engine”. I’m interested in the output that is “game”. Why not just start at my own programming language, right?