Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Well he does say:

> Perhaps I missed something, but most of my friends have been on the lookout and I have had a number of games referred to me; none of them came close to Balance of Power in algorithmic sophistication.

So it's not like he missed the simulation genre evolution, he just disagrees with the direction that evolution took. And he suggests it's because the time has not yet come for his ideas.

An obvious retort is: maybe people don't (and won't) want to play games with sophisticated algorithmic simulation because they are boring. He doesn't seem to offer any good argument about why his ideas are "good but too early" as opposed to merely "bad". As such, I find his post not very persuasive.



>Well he does say:

>> Perhaps I missed something, but most of my friends have been on the lookout and I have had a number of games referred to me; none of them came close to Balance of Power in algorithmic sophistication.

Isn't that indicative of his problem. For all his talk about caring about a particular game design philosophy so much so that he devoted decades to talking about it, he's not even aware of what's out there. Why are his friends suggesting games to him? Why isn't he referencing games like EU4 or Victoria II and breaking them apart and pointing out in which way they differ from his design philosophy? But he's not excited about the field or ideas that come from others because he figured out the right answer in the 1980s ... and it's on everyone else to acknowledge this.


There are plenty of commercially successful strategy games with sophisticated algorithmic simulation, like Europa Universalis for example.

I wonder if there is perhaps a bias here in that it is easy to overestimate the algorithmic complexity of the code you wrote, whereas it's easy to underestimate the complexity of code you can't see.


I could be wrong but I think he's saying the opposite: people are missing that his code is about processes happening over time, whereas the focus of most games nowadays is on the objects. Or, what you can see in his static code isn't important, it's what happens during the running of the code that is.

Now I know almost nothing about game development so have no dataset myself or ability to understand the arguments either way.

I think we're seeing an increasing short term move to more complex, black box, DL trained models that will get behavior similar to the processes he seems to emphasize, and then we'll see a swing back to taking those gains but converting them into the type of readable algorithms like in his old games.

But I have no idea. Just complete 2 second conjecturing on my part.

Regardless, thoroughly enjoying reading his site and find his Object <=> Process gradient cycle to be crystal clear and fascinating and important idea.


Games like EU4 are more process oriented than object oriented, actually. There is no black-box DL model, just a great many low-medium complexity processes that chain into a large story.

These processes can almost always be reverse engineered, and they are actually quite understandable and readable.

Unless there is something I'm missing with his process/object distinction, admittedly I don't think I've parsed it with a great deal of clarity.


Well then I think the only thing for me to do is to get myself EU4 and do some "research" to figure this out. :)


Look at Victoria II if you want a game that is mainly about processes not objects.


This is kinda where I fall on this too. Lacking a lot of background on this and going off the post alone, it doesn’t sound like the author was “ahead of his time” so much as he was in the wrong field.

The point of a game is not algorithmic sophistication, it’s fun (to simplify in the extreme). If the game isn’t fun it doesn’t matter how fancy or impressive the logic powering it is. If you want to blaze new trails in modeling and computation, games are the wrong field to do it in as any advancement will tend to be overshadowed by whether or not the game itself is a good game. Sure there are enthusiasts that will be interested in internals, but fame in the realm of games comes with great game design, not algorithmic sophistication.

It’s like an artist inventing a new shade of green and using it in his work in combination with other colors and complaining that no one acknowledges the sophisticated formulas he had to use to produce his special shade of green.


The worst critic of your game is yourself. Even if your game is insanely boring, if you spend enough time toiling away on it, tweaking it, playing testing, critically thinking about the complexities of it, etc, you'll grow extremely attached to it very quickly.

I am automatically skeptical of anyone that tries to defend their art by referencing science, but in this case, as an indie developer with my own fair share of failures and lots of experience in development, I'm not just skeptical; I'm pretty confident that I know why this person failed, and why they'll continue to fail unless they change their thinking.

Although I will say, in fairness to the author, that I have not read any of his books, seen his lectures, or played his games. So maybe he really is a genius game designer with ideas too advanced for any of us to appreciate.

EDIT: okay now after reading another comment with more background information about the author, I feel like a dick for the tone I used here. But I'll leave the comment up anyways because, well, I feel like it's still useful advice (at least the first paragraph)


> So it's not like he missed the simulation genre evolution, he just disagrees with the direction that evolution took

The problem is that his examples from his own work, his references to subsequent work and it shortcomings, and, well, everything else is either isolated atomic details (like the two formula references) or sweeping generalities with no specifics that it's hard to tell really what specifically he sees as missing, and whether or not it is actually missing, or he's overlooking something or judging unfairly.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: