> The Steam label, maybe it means something now, but longer I think it fades.
It might fade, but it will take a while. You need a generation of gamers to grow up in a world where AI-generated content is normalized and then become old enough to start driving these trends. It could actually happen in as little as ten years or so, but it also might never become fully normalized, which I think is more likely.
Yeah, using generative AI to boost productivity (i.e., with coding assistants), and using it to literally generate artistic assets for the the game, are very different propositions. Steam's AI tag also very clearly distinguishes between the two.
I 100% recommend that you avoid AI-generated assets in your game. The stigma around AI-generated assets is very real, and not going away soon. Although people might enjoy using AI for their own purposes, by and large they don't want to be subjected to other people's use of it. Moreover, while I don't have the data to back this up, I would have to think that among the segment of the population that plays indie games, the stigma around generative AI is even greater.
In the second part of the question you asked if you should just learn all of the skills...buddy, does that question not answer itself? Of course you should learn all of the skills. Obviously that's much easier said than done, but TBH I think the quality bar to producing something viable is not super high, so as long as you're not a perfectionist, you can probably do it.
Since I could be labeled as an "AI hater" based on those comments, I want to be clear that I'm saying all this to keep you from falling into a trap and not to further my own agenda. The generative AI route is not a magic shortcut to success, although it is being aggressively marketed as such. The shortcut only seems to lead to success if you ignore the fact that people don't want to be subjected to other people's AI content.
> In the second part of the question you asked if you should just learn all of the skills...buddy, does that question not answer itself?
Yes I agree, I don't think I worded my post well. I want to learn all the skills and such, because I enjoy learning. My post was more centered around if I was behind the times and thinking in the past by not using it.
> Since I could be labeled as an "AI hater" based on those comments, I want to be clear that I'm saying all this to keep you from falling into a trap and not to further my own agenda
I don't think AI hater label would be fair, you're making a similar point that I was trying to make which is that specifically for art in video games, it might be to someone's detriment.
First, who is saying "termination implies safety"? There need to be a citations for that, so we can know what specific claim is supposedly being refuted here.
Second, Rice's theorem states that no nontrivial property on the set of partial recursive functions is decidable. However, there are subsets of the set of all recursive functions that do have decidable properties, and it's pretty trivial to cook some of them up. Since some of these sub-languages also consist only of total functions, there are "total languages" for which the analogous statement of Rice's theorem is false. To fix this we would need to choose a specific total language. There could be some interesting ones for which the analogous statement of Rice's theorem still holds, but I'm not an expert on that.
You're correct on the citations though that will probably be very easy as we have many people claiming exactly that.
As to your second point, yes, and the safety claims being made are not restricted to those decidable subsets. The moment you claim general safety guarantees for systems operating beyond those constrained subsets you're back in full Rice territory. If you can name a total language with an early termination guarantee, I'm all ears. You asked for my citations, now show me yours.
Not only is this just a random article from the internet, as opposed to something peer-reviewed, but more importantly, nowhere does it even attempt to claim that the mere fact of a program terminating implies its suitability in a safety context.
Here's your citation — ARIA's Safeguarded AI program, £59M in UK government funding, explicitly claiming mathematical safety guarantees through restricted verifiable models — total languages by another name. The claim exists. It has a budget. Now, do you have a substantive response to the proof, or are we done here?"
@techreport{ARIA2024,
author = {{Advanced Research and Invention Agency}},
title = {Safeguarded AI: Constructing Guaranteed Safety},
institution = {ARIA},
year = {2024},
url = {https://www.aria.org.uk/programs/safeguarded-ai/},
abstract = {Outlines a 'Safeguarded AI' program that seeks to build AI systems with 'mathematical guarantees.' It argues that by using restricted, verifiable models—effectively total languages—one can avoid the 'impossible' task of verifying general AI and instead produce 'quantitative safety guarantees.'}
}
It looked to me like it was just due to recurring build issues. Lots of "swift can't import these conflicting C++ versioned libraries concurrently" and "can't use some operator due to versioning or build conflicts". Basically it sounds like trying to add swift to the project was breaking too many things, and they decided it wasn't worth it.
It's a shame, I think swift is an underappreciated language, however I understand their reasoning. I think if they tried to just use swift from the beginning it would have been too ambitious, and trying to add swift to a fragile, massive project was probably too complex.
How are you getting the 170,000 number? I did a quick search and found this quote from merriam-webster.com [1]:
> Webster's Third New International Dictionary, Unabridged, together with its 1993 Addenda Section, includes some 470,000 entries. The Oxford English Dictionary, Second Edition, reports that it includes a similar number.
I do kind of like the idea of automatically reformatting the code based on the media size, but the devil seems to be in the details. In my experience, code formatters can sometimes backfire and make the code harder to read. There's usually an escape hatch via special comments in the code, but those would appear in the final rendering and add noise to the presentation, which is unacceptable. Thus, I didn't pursue that idea, and instead I ended up manually breaking my code samples at 64 columns or so. There can still be some horizontal scrolling on very small screens, but hopefully it's tolerable. I also made sure each individual code block gets its own scroll bar and not the whole page, so you wouldn't need to constantly scroll the whole page back and forth to check for overflowed content.
I have other thoughts on this, but I don't want to go too far afield. Anyway, I think it's an interesting problem and one that's worth solving.
I totally agree with both this and the comment you replied to. The common thread is that you can architect the application in such a way that dry vs. wet running can be handled transparently, and in general these are just good designs.
There's some truth to this, since some design patterns can simply be implemented "for good" in a sufficiently powerful language, but I don't find it's true in general. Unfortunately, it has become something of a thought-terminating cliché. Some common design patterns are so flexible that if you really implemented them in full generality as, say, some library function, its interface would be so complex that it likely wouldn't be a net win.
> Some common design patterns are so flexible that if you really implemented them in full generality as, say, some library function, its interface would be so complex that it likely wouldn't be a net win
Then I would say you have not arrived at the optimal solution. Keep looking.
It might fade, but it will take a while. You need a generation of gamers to grow up in a world where AI-generated content is normalized and then become old enough to start driving these trends. It could actually happen in as little as ten years or so, but it also might never become fully normalized, which I think is more likely.
reply