There's a lot to getting it right, and like all software, you have to built it for your target market. There's no easy AI solution to getting a fun and engaging core loop. Nor is there one for building the right level of complexity and balancing the learning curve.

I think a lot of people who can't/don't code see themselves as game designers and had thought that AI would let them make games, and are now finding it wasn't really about the code after all. That, and if you can't code, vibe coding alone isn't really good enough for much beyond flash-level games (yet).

4. Tell claude what to do instead, which will update the plan base on what you say.

5. Add comments to the plan directly - similar to 4 - but you can comment on specific parts.

Note: I use the VSCode extension, not sure if it differs in terminal mode.

Lots of people wanted (and Intel tried to sell, somewhat succesfully) something they could just plug-and-play and just run the parallel implementations they'd already written for supercomputes using x86. It seemed easier. Why invest all of this effort into CUDA when Intel are going to come and make your current code work just as fast as this strange CUDA stuff in a year or two.

Deep learning is quite different from the earlier uses of CUDA. Those use cases were often massive, often old, FORTRAN programs where to get things running well you had to write many separate kernels targeting each bit. And it all had to be on there to avoid expensive copies between GPU and CPU, and early CUDA was a lot less programmable than it is now, with huge performance penalties for relatively small "mistakes". Also many of your key contributers are scientists rather than profressional programmers who see programming as getting in the way of doing what they acutally want to do. They don't want to spend time completely rewriting their applications and optimizing CUDA kernels, they want to keep on with their incremental modifications to existing codebases.

Then deep learning came along and researchers were already using frameworks (Lua Torch, Caffe, Theano). The framework authors only had to support the few operations required to get Convnets working very fast on GPUs, and it was minimal effort for researchers to run. It grew a lot from there, but going from "nothing" to "most people can run their Convnet research" on GPUs was much eaiser for these frameworks than it was for any large traditional HPC scientific application.

[1] https://en.wikipedia.org/wiki/VGA_Planets

For board games this is mostly true. For turn based games in general, it is not. It's certainly not true to say "all good turn based game ai" works like this.

Turn based games where multiple "moves" are allowed per turn can very quickly have far too many branches to look ahead more than a very small number of turns. On board games you might have something like Warhammer, or Blood Bowl where there are many possible actions and order of actions within a turn matters.

For computer games you may Screeps [2] or the Lux multi-agent AI competitions [3] which both have multiple "units" per player, where each unit may have multiple possible actions. You can easily reach a combinatorial explosion where any attempt at modeling future states of the world fails and you have to fall back on pure heuristics.

[1]https://en.wikipedia.org/wiki/Blood_Bowl

[2]https://screeps.com/

[3]https://www.kaggle.com/competitions/lux-ai-season-2

If the amount of content to be produced remains constant, then from a purely financial point of view the company should be looking at cutting one of them. AI would have then taken their job.

For the amount of content to be produced to not remain constant either the studio would have to go for increased art quality, or scale up the rest of the business to keep up with the new art productivity. It's not clear they'd make that decision over cutting their art department spending in two. At the very least their job is at risk.

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

Points: 1

# Comments: 0