How is AI supposed to simulate a player, and why should it be able to determine what real people would find engaging?
I don't think it's much of a stretch to take this data over multiple games, versions, and genres, and train a model to take in a set of mechanics, stats, or even video and audio to rate the different aspects of a game prototype.
I wouldn't even be surprised if I heard this is already being done somewhere.
Whether that set is actually useful is a separate issue but someone is trying this over there for sure.
Yes, that's how games like Concord get made. Very successful approach to create art based on data about what's popular and focus groups.
I think what the previous comment meant was that there is data on how player play, and that tends to be varied but more predictable.
AI/fuzzers can't get far enough in games, yet, without a lot of help. But I think that's because we don't have models really well suited for them.
Edit: yup, it shut down nearly a year ago
Compare that to Helldivers 2 (online-only live service game, same platforms and publisher) which had a lot of personality (the heavy Starship Troopers movie vibe) and some unique gameplay elements like the strategems.
And sometimes it works; Apex Legends came out of nowhere and became one of the big live service titles. Fortnite did a battle royale mode out of nowhere and became huge.
Everything is measured and analysed and optimised for engagement and monetisation.
When you have 200 people making a game, "luck" or "art" doesn't factor in at all. You test, get data, and make decisions based on the data, not feelings.
Solo devs can still make artsy games and stumble upon success.
Where we used AI (machine learning, not LLM) was in terms trying to figure out what kind of human you would want to play with. We also used machine learning to try figure out what cohort of players you were in so we could tweak engagement.
Where LLMs could really shine, in my opinion: Gamers love to play people, not AI (now). People are unpredictable, they communicate, they play well but in ways a human could (like they don't have superhuman reflexes or speed). You can play all kinds of games against AI (StarCraft, Civilization, training of all kinds of FPS) but it isn't fun for long because you see the robotic patterns. However, an LLM might be able to mix it up like humans, talk to you, and you could probably make it have imperfect reaction time, coordination, etc. That would really help a lot of games that have lulls in human player activity, or too much toxicity.
I would be shocked if some games aren't doing this now. It seems like it still be hard to make a bot seem human, and it probably only works if you sprinkle it in.
Edit : oh yeah. A quick google search proved it : https://marvelsnapzone.com/bots/
I'm sure you could conjure up any number of ways to do that, but they won't be trivial, and maintaining those tests while you iterate will only slow you down. And what's the point? Even if the unit-move-and-attack test passes, it's not going to tell you if it looks good, or if it's fun.
Ultimately you just have to play the game, constantly, to make sure the interactions are fun and working as you expect.
You use a second enemy that spawns, moves towards the "enemy", and attacks.
You can easily write a 'simulation' version of your event loop and dependency inject that. Once time can be simulated, any deterministic interaction can be unit tested.
You're right that "unit test" has taken on another, rather bizarre definition in the intervening years that doesn't reflect any kind of tests anyone actually writes in the real world, save where they are trying to write "unit tests" specifically to please the bizarre definition, but anyone concerned about definitional purity enough to quibble about it will use the original definition anyway...
Like letting speed runners skip half your game. :)
The real reason? It's because writing tests is a different skill and they don't actually know how to do it.
Sounds very much like the description of a big ball of mud.
An interesting gamedev video I saw recently basically boiled down to: "Build systems, not games." It was aimed at indie devs to help with the issue of always chasing new projects and making code that's modular enough to be able to reuse it.
But taking a step back, that very much feels like it should apply to entire games, where you should have boundaries between the components and so that the scope of any such pivot is managed well enough not to tank your velocity.
Other than that, it'd be just the regular growing pains of TDD or even just needing to manage good test coverage - saying that tests will eventually need changes isn't the best argument against them in webdev, nor should it be anywhere else.
I mean, yeah, kinda.
For any given object in the game world, it's funnest for that object to be able to interact with as many other objects as possible in as many ways as possible. A game object's handles for interaction need to be globally available and can't impose many invariants—especially if you don't want level designers to have to be constantly re-architecting the engine code to punch new holes for themselves in the API. Thus, a lot of the logic in a given level tends to live inside the callback hooks of level objects, and tends to depend on the state of the rest of the level for correctness.
Modularity is a property of high cohesion and low coupling, which are themselves only possible when you can pin down your design and hide information behind abstraction boundaries. But games are a flexible and dynamic enough field that engines have to basically let designers do whatever they want, whenever they want in order for the engine to be able to build arbitrary games. So game design is naturally a highly-coupled, incohesive problem space that is poorly suited to unit testing.
Poorly suited? Perhaps, but so are certain web system architectures as well, neither is impossible to test.
I think Factorio is an example that it can be done if you care about it... it's just that most studios shipping games don't.
https://www.factorio.com/blog/post/fff-438
https://www.factorio.com/blog/post/fff-366
Of course, in their case it can actually be justified, because the game itself is very dependent on the logic working correctly, rather than your typical FPS game slop that just needs to look good.
https://www.youtube.com/watch?v=AmliviVGX8Q (kovarex - Factorio lets fix video #1)
Games have goals, and players are prone to 'optimising the fun out of games', by doing some save strategy over and over again to reach that goal, even if it's not fun. Think eg grinding in an RPG, instead of facing tough battles with strategy and wits and the risk of failure.
Even if AIs are terrible at determining what's engaging, you can probably at least use them to relatively quickly find ways that you accidentally opened that let players get in the way of their own fun.
And note, this is not AI as in asking an LLM what to do, this is more classical machine learning and deep learning.