[furyofantares]

Very cool.

For the small casual games I've been vibe coding, I always start from a place where the application has a CLI where it can run headless, rendering to offscreen texture, with a a screenshot command as well as performance instrumentation. It takes no time to include all this, and gives the agent a way to automate the ui and inspect important things. It also lets me trivially have the agent update screenshots.

Not as neat as being part of the build process, but I will now add that.

[sho_hn]

I do the same :-)

I have an offscreen screenshot path, as well as a CLI arg for world pos/camera view vector, and scripted benchmark runs with a simple text-based input format that has rows of named segments of n game ticks length with control inputs per segment. Use that extensively for A/B testing of visuals and performance while working on the game code.

[vidarh]

I was toying with a DragonRuby game a while back, and did something like that. But DR also comes with recording reproducible playbacks, screenshotting etc. built in, couple hot reloading and easily being able to inject code into the running game, and it was great putting in place instructions so the agent could run the game fully and show off things for me in addition to allowing it to test things. I think we'll see more and more frameworks built to enable this - it's nice for human development, but it really pays off when you're working with an agent to have everything nicely runnable from a CLI and fully introspectible.

[caspar]

This is also what I've done for my multiplayer falling sand game: it's very much not vibe coded (too performance-sensitive), but coding agents can launch the game on my steamdeck and run benchmarks, take captures & verify rendering is bit-for-bit identical on a given machine, etc.

Agent can't _play_ the game yet, but that's on my list to experiment with.

[_fzslm]

Would you mind sharing a link to some of these casual games? I ask cuz I'm also interested in how vibe coding can make game development easier.

We had such a vibrant indie game scene when Adobe flash was about and since then nothing's really touched that level of ease of development. I think vibe coding is the first tool that actually exceeds it.

[furyofantares]

Unfortunately I can't right now, I'm going to release a few things simultaneously but they aren't public yet. They will eventually show up on https://kellydornhaus.com

[ryanjshaw]

Search for #vibejam on X, there’s a contest running right now with lots of people sharing their dev experiences.

[crefiz]

Since you cannot seem to be able to share the url: https://x.com/search?q=%23vibejam&src=typed_query

And for those of you: https://XCancel.com/search?q=%23vibejam&src=typed_query

[avaer]

> It takes no time to include all this

In some cases it does. Which engine?

[furyofantares]

I don't use an engine for vibing, they tend to be built around managing content and using their editors. You can drive engines from code but they are more built for invoking code from content usually. So I just use frameworks like SDL, Raylib C# and ebitengine. Most stuff I've done recently was ebitengine because I felt golang was the best thing to have LLMs writing when I started them.

Right now I have my own framework which has a host written in Rust but game code is written in AssemblyScript - too early to tell how well this will work out but it is very promising to me right now.

If I were just getting started I would probably pick some framework in Rust, or maybe Bevy which I believe is considered an engine but is code-centered.

[furyofantares]

Actually, if I were just getting started I might pick an engine at this point. It's probably great at Godot now, and maybe with MCP servers can work on any other engine fine by having access to the editor.