Something similar happened to the macOS chess game, which has always been bundled with OSX/macOS. Once upon a time it was easy to beat in easy mode, which restricted how long it could thing in advance.

When Big Sur rolled out around 2020, Apple introduced a bug which disabled the difficulty slider: no matter what it was set to, it was hard or impossible to beat. In macOS Sequoia, the Chess app got updated again, and supposedly they fixed the difficulty slider, but in the interval silicon improved so much that the old restraints (like think for only a second) mean little. The lowest levels play like a grand master.

▲

mh2266 6 hours ago | parent | next [-]

is there some reason to implement it as a time limit instead of iterations or something else deterministic? it being affected by CPU speed or machine load seems obvious.

or whatever makes sense if “iterations” isn’t a thing, I know nothing about chess algorithms

▲

twoodfin 6 hours ago | parent | next [-]

It’s simpler. Chess is a search through the space of possible moves, looking for a move that’s estimated to be better than the best move you’ve seen so far.

The search is by depth of further moves, and “better” is a function of heuristics (explicit or learned) on the resulting board positions, because most of the time you can’t be sure a move will inevitably result in a win or a loss.

So any particular move evaluation might take more or less time before the algorithm gives up on it—or chooses it as the new winner. To throw a consistent amount of compute at each move, the simple thing to do is give the engine consistent amounts of time per move.

▲

TheDong 2 hours ago | parent [-]

> To throw a consistent amount of compute at each move, the simple thing to do is give the engine consistent amounts of time per move.

The simple thing to do is give it a limit on the total number of states it can explore in its search.

If your goal is consistency, wall-clock time makes no sense. If I run 'make -j20', should the chess computer become vastly easier because the CPU is being used to compile, not search? Should 'nice -n 20 <chess app pid>' make the chess computer worse?

Should my computer thermal-throttling because it's a hot day make the chess computer worse, so chess is harder in winter?

If the goal is consistency, then wall-clock isn't the simple way to do it.

	▲	shadowpho 2 hours ago \| parent [-]
		>If the goal is consistency, then wall-clock isn't the simple way to do it. It’s simpler than doing a limit on number of states, and for some applications consistency isn’t super important. Doing a time limit also enforces bot moving in a reasonable time. It puts a nice limit to set up a compromise between speed and difficulty. Doing state limit with a time limit might be better way to do it, but is harder.

▲

microtherion 5 hours ago | parent | prev [-]

A time limit is also deterministic in some sense. Level settings used to be mainly time based, because computers at lower settings were no serious competition to decent players, but you don't necessarily want to wait for 30 seconds each move, so there were more casual and more serious levels.

Limiting the search depth is much more deterministic. At lower levels, it has hilarious results, and is pretty good at emulating beginning players (who know the rules, but have a limited skill of calculating moves ahead).

One problem with fixed search depth is that I think most good engines prefer to use dynamic search depth (where they sense that some positions need to be searched a bit deeper to reach a quiescent point), so they will be handicapped with a fix depth.

▲

microtherion 5 hours ago | parent | prev [-]

Heh, I was just discussing this some minutes ago: https://news.ycombinator.com/item?id=46595777