I liked the first example better than the last example.
One neat way of modeling gamedev problems like this might be to use AI. I’ve been thinking about training StyleGAN on geometry by slicing it up into 2D textures (voxels?) and training StyleGAN on that, or maybe extending StyleGAN into 3D space.
Realistically, to solve the “fun factor” problem, “just” get a legion of testers to playtest whatever you’ve made, and then iterate on feedback. Repeat 10,000 times and you’ll have a fun thing, every time. I can think of zero cases where this process failed to produce something fun.
I think this article is less about “identifying un fun” and more about “getting to fun”. This is a decent set of tools for the toolbox that you can use
Ultimately this kind of vocabulary and thought process let’s you go beyond basic design and into more structured design. Being able to theorize nicely about why something isn’t fun lets you go pretty far
As far as I understand, one role of skirmish modes in strategy games is also to pit 2 AIs against each other to test balancing changes.
That still doesn’t guarantee fun. “fun” comes when I wipe an enemy because I’ve seen them make a stupid move and have the tools to make them suffer for it. That’s hard to simulate.
Realistically, to solve the “fun factor” problem, “just” get a legion of testers to playtest whatever you’ve made, and then iterate on feedback. Repeat 10,000 times and you’ll have a fun thing, every time. I can think of zero cases where this process failed to produce something fun.
Sure, you could try to brute force some machine learning to find fun. Or, you could study game design and game patterns and start with something that won’t take infinite iterations to produce.
If memory serves, I remember reading a criticism of Edison from Tesla, that he could have discovered his lightbulb with far less effort if he had used mathematics. Of course, Edison was using mathematics and it’s likely that Tesla was simply more practiced at it. In the end you either need to get the theory right and test it, or you need to test it very well. There is more in life than is in our theories so we still do need some testing, but the amount can be drastically reduced with a sensible application of theory. If your theories aren’t getting you a solution, because they’re wrong, incomplete, or you aren’t talented enough at applying them then you should still be able to get there through adequate testing and exponentially more labor.
I don’t disagree with this, just with the somewhat glib notion above that, instead of learning theory, one should instead hire an army of testers and iterate thousands of times.
I think the “just” is in quotes for a reason. I suspect he doesn’t actually think someone “should” hire an army of testers and brute force the problem.
Yep, but it was also presented in a “I have this problem, and this solution” format. The problem was real, and the solution rang (to me) of “ha ha, only serious”.
To me it looked like a galaxy brain approach of automating perceptions of fun using a neural net. A sufficiently silly solution is the same as a good joke.
Also, wouldn’t it make sense to use a stylization network to just finetune a human designed greybox level? Then the designer could focus on fun and the machine on visual detail. For example if adding detail meshes such as bushes and garbage piles was fully automated you could iterate on high-level gameplay flow even pretty late in production.
I liked the first example better than the last example.
One neat way of modeling gamedev problems like this might be to use AI. I’ve been thinking about training StyleGAN on geometry by slicing it up into 2D textures (voxels?) and training StyleGAN on that, or maybe extending StyleGAN into 3D space.
Realistically, to solve the “fun factor” problem, “just” get a legion of testers to playtest whatever you’ve made, and then iterate on feedback. Repeat 10,000 times and you’ll have a fun thing, every time. I can think of zero cases where this process failed to produce something fun.
Now if only it could be automated…
I think this article is less about “identifying un fun” and more about “getting to fun”. This is a decent set of tools for the toolbox that you can use
Ultimately this kind of vocabulary and thought process let’s you go beyond basic design and into more structured design. Being able to theorize nicely about why something isn’t fun lets you go pretty far
As far as I understand, one role of skirmish modes in strategy games is also to pit 2 AIs against each other to test balancing changes.
That still doesn’t guarantee fun. “fun” comes when I wipe an enemy because I’ve seen them make a stupid move and have the tools to make them suffer for it. That’s hard to simulate.
Sure, you could try to brute force some machine learning to find fun. Or, you could study game design and game patterns and start with something that won’t take infinite iterations to produce.
If memory serves, I remember reading a criticism of Edison from Tesla, that he could have discovered his lightbulb with far less effort if he had used mathematics. Of course, Edison was using mathematics and it’s likely that Tesla was simply more practiced at it. In the end you either need to get the theory right and test it, or you need to test it very well. There is more in life than is in our theories so we still do need some testing, but the amount can be drastically reduced with a sensible application of theory. If your theories aren’t getting you a solution, because they’re wrong, incomplete, or you aren’t talented enough at applying them then you should still be able to get there through adequate testing and exponentially more labor.
I don’t disagree with this, just with the somewhat glib notion above that, instead of learning theory, one should instead hire an army of testers and iterate thousands of times.
I think the “just” is in quotes for a reason. I suspect he doesn’t actually think someone “should” hire an army of testers and brute force the problem.
Yep, but it was also presented in a “I have this problem, and this solution” format. The problem was real, and the solution rang (to me) of “ha ha, only serious”.
To me it looked like a galaxy brain approach of automating perceptions of fun using a neural net. A sufficiently silly solution is the same as a good joke.
It might be a better idea to automate the menial game testing phase as described in Making of The Talos Principle GDC talk at 26:36.
Also, wouldn’t it make sense to use a stylization network to just finetune a human designed greybox level? Then the designer could focus on fun and the machine on visual detail. For example if adding detail meshes such as bushes and garbage piles was fully automated you could iterate on high-level gameplay flow even pretty late in production.