However combining some of the flexibility and workflows of git with the ability to deal more efficiently and effectively with large asset files is something that a hell of a lot game engineers would be interested in. And having the virtual checkout as a feature out of the box for folks used to half terabyte repo sizes is definitely a huge plus.

This announcement is definitely a big deal, and if the promises for lore actually measure up, we could be seeing the beginning of a switch over to open source version control for larger asset heavy games where git was still not a great fit.

Will be interesting to see what the public code hosting platforms do (github), and whether there will be any major structural changes to git (I'm thinking not likely). I wonder if Epic will make a play to take business away from github or gitlabs.

- Various particle types with different densities, properties (gas, water, rock, etc.) - Highly optimized webgpu simulation (could be optimized even more but pretty decent). - Not exactly physically accurate but pretty cool glowy molten lava. - Fun relativistic impactor that turns earth into a gooey glowing donut.

This was written as a one shot, and it did partially work, but the various refinements and especially the optimization was done afterwards.

Running on github pages. MIT licensed and code is at https://github.com/benjcooley/doomsday_simulator

Have fun.

Comments URL: https://news.ycombinator.com/item?id=48509775

Points: 4

# Comments: 1

I've found that there are a couple of things you need to do to be very efficient.

- Maintain an architecture.md file (with AI assistance) that answers many of the questions and clarifies a lot of the ambiguity in the design and structure of the code.

- A bootstrap.md file(s) is also useful for a lot of tasks.. having the AI read it and start with a correct idea about the subject is useful and a time saver for a variety of kinds of tasks.

- Regularly asking the AI to refactor code, simplify it, modularize it - this is what the experienced dev is for. VIBE coding generally doesn't work as AI's tend to write messy non-modular code unless you tell them otherwise. But if you review code, ask for specific changes.. they happily comply.

- Read the code produced, and carefully review it. And notice and address areas where there are issues, have the AI fix all of these.

- Take over when there are editing tasks you can do more efficiently.

- Structure the solution/architecture in ways that you know the AI will work well with.. things it knows about.. it's general sweet spots.

- Know when to stop using the AI and code it yourself.. particuarly when the AI has entered the confusion doom loop. Wasting time trying to get the AI to figure out what it's never going to is best used just fixing it yourself.

- Know when to just not ever try to use AI. Intuitively you know there's just certain code you can't trust the AI to safely work on. Don't be a fool and break your software.

----

I've found there's no guarantee that AI assistance will speed up any one project (and in some cases slow it down).. but measured cross all tasks and projects, the benefits are pretty substantial. That's probably others experience at this point too.