You're welcome here and it looks like a good submission and a great game! but this post also got a ton of bogus upvotes and quite a few bogus comments. Those things are quite against HN's rules - this is in both the site guidelines (https://news.ycombinator.com/newsguidelines.html) and FAQ (https://news.ycombinator.com/newsfaq.html), and we ban accounts that do it (I've banned 5 of them so far.)

Please make sure that you and/or your friends don't do this on HN in the future! The community here is hypervigilant about this kind of thing and will use unkind words like 'astroturfing' and 'spamming' and email us complaints when they see it.

Thank you so much for bringing this up! Still new to the community (long time lurker, first time commenter). I'm very thankful for your input and I'm glad you're enjoying the submission and the game :)

From my understanding, the earlier comments on this post were all existing players - but I may be mistaken. In any case, all duly noted for us new posters. Thank you for your help in keeping the HN community so awesome!

By the way, how does the software calculate solicited votes? Does it omit upvotes from a user on the same IP as the story creator?

Alas I can't answer that because it falls in the bucket of things that would stop working if they were public.

This is one of the (fortunately somewhat rare) cases where the principle of "optimize for curiosity" is at odds with itself!

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...

Sorry to hear that, but thanks anyway.

Are you aware of Solitaire Chess?

https://www.thinkfun.com/products/brain-fitness-solitaire-ch...

I was not! Just checked it out, great to see other chess variants out there. This looks like a simple but fun ‘clear the board’ puzzle. Here are the main differences with echo chess as far as I can tell:

1) No echoing mechanism. In echo chess, if you capture a pawn, you become that pawn. That means the maze effectively changes at every capture. The post linked above has a thorough analysis (and visual examples) of the strategic implications and limitations of this simple twist, so I highly recommend checking it out.

2)Forced to capture at every move. Solitaire chess seems to require a capture at every move. While that may appear to be a more difficult setting at first sight, it can actually lead to a much lower search space complexity by heavily restraining the degrees of freedom. In small enough puzzle boards, backtracking can become trivial.

3) No white pieces, so no squads, and no sacrifices. In echo chess, it’s white against the world. In future levels (starting 9), you get a squad of white pieces to use. This quickly becomes a double-edged sword: your ally is also a blocker on your quest. Higher levels even require you to sacrifice an ally piece in your squad to solve the maze. This adds a whole new level of strategy and complexity to the game.

4) Endless mode with ML. The ‘endless’ mode of echo chess continuously serves procedurally generated chess mazes in real time that are guaranteed to be solvable (with 99%+ accuracy) every time you solve a prior one. You carry over your white piece and ending square as a starting position for the next level. This adds a tremendous amount of replayability, variability, and continuity for the game. It essentially becomes a strategic Tetris variant.

There are lots of other differences and nuances but I really think the post linked above does a better job analyzing them. If you’re an experienced solitaire chess player, I’d love to hear your thoughts on echo chess once you try it out!

Thanks for sharing this cool variant too. I’ll make sure to give it a try :)

*oh and obviously echo chess has obstacles. The mazes would be significantly easier if you just removed every obstacle from the board, like Solitaire chess seems to do it

Hello and thank you for the neat article. I have not finished it yet (I'm still partway through the ML bit), so ignore me if this is explained somewhere, but as far as I can see you only considered "generate and test for solvability" approaches. But isn't there a direct way to generate puzzles by solving the board "backwards"? Start with a single white piece on the board. Then, pick a random predecessor of that state; either the piece moved there normally or it was a capture. In the first case just move the white piece back, in the second replace it with a matching black piece and place a new white piece in a spot that could have captured it. Do this a few times until you are satisfied with the number of black pieces.

The biggest issue I can see right now is matching up the starting piece with the previous puzzle's ending piece, but I feel that should be manageable with some heuristics and brute force. And one would have to test whether the puzzles generated like this are actually "random-looking" enough.

100% exactly. This is a very smart observation and is actually one of the main approaches I attempted first when tackling the creation of 'endless' mode. There are a few nuances and adjustments that would actually turn what you're suggesting into a somewhat viable approach, but I think in general you're on the right track with both the hypothesis and its limitations.

A lot of the early playtesting I did for 'endless' kept indicating, much to my initial dismay, that the continuity of the carryover white piece is pretty much essential. In hindsight, it kinda makes sense. Imagine playing Tetris or Temple Run but where every 30 sec you essentially start from scratch. I guess maybe that's why people are more likely to binge-watch a whole season of Breaking Bad back-to-back than a full season of Black Mirror?

If we didn't have that constraint for echo chess, we could've easily just saved the crowdsourced pre-labeled solvable levels into a big 'test bank' db, and randomly served one of them any time a player needs a new level to play. Think SAT/GRE questions that are all pre-curated beforehand but that get 'generated' at random for every participant.

Thankfully the ML classification approach I ended up going with completely sidesteps the carryover piece dilemma. It's like you said: you simply "generate [incl. carryover] and test for solvability". Plus it works, with 99%+ accuracy, and in real time. So I think we're good for a bit :)

you don't need to run the puzzle backwards to generate solvable positions, you run it forwards and generate the pieces from the solution moves.

Starting with the piece and square from the previous board, mark all squares but this one as unknown. Make a random move. Any unknown squares passed through get marked blank in the current board and in the puzzle. Randomly choose to keep the same piece (making this square blank in the puzzle) or switch (marking the chosen piece in the puzzle, but now blank in the current board). Continue making random moves (biasing slightly towards choosing unknown squares), eventually stop and randomly assign the remaining unknowns as obstactles or blanks. Because you've said you don't care if there's only one solution, this gives you solvable puzzles trivially.

This isn't a new idea, eg https://www.snellman.net/blog/archive/2019-05-14-procedural-... talks about generating solvable puzzles using the forward moves, you'd generally pair it with a filter that weeds out puzzles that are not fun for some reason (eg, solutions that random walk blank squares; these can be avoided at generation time by having a budget for move-to-blank)

That's a brilliantly simple approach. You could even have an estimated difficulty score that updates based on number of moves, switches, etc. and ramp up target difficulty as the random run progresses.

Yep. Even the boring, topology-agnostic 'macro' variables can be good proxies for difficulty: obstacles count, empty squares count, counts per piece type, etc. I don't have a direct source for this but the original echo chess post has a good EDA section (+ feature importance plots) covering the impact of such variables on solvability. At scale, average solvability of random levels might be a half-decent proxy for how the difficulty of individual ones would fluctuate.

It's weird that I almost immediately had the thought for essentially exactly the same approach while reading the article. Not that this reflects on OP; flashes of solutions like that I think are often mostly random.

But I wonder if this is a sign of things to come - rather than needing to find explicit deterministic solutions to many problems that might actually have one, because ML is getting much more powerful and accessible instead we'll just use ML models and get 99.9% accurate solutions, but say, well that's good enough.

> I wonder if this is a sign of things to come - rather than needing to find explicit deterministic solutions to many problems that might actually have one, because ML is getting much more powerful and accessible instead we'll just use ML models and get 99.9% accurate solutions, but say, well that's good enough.

You're not alone: http://www.incompleteideas.net/IncIdeas/BitterLesson.html

For a more echo chess specific answer, see my answer above to @bazzargh

Very valid take - few thoughts to share on this. And thanks for linking the writeup about Linjat's procedural generation. That was a great read. Many interesting insights on the approach the author used for finding solutions to the puzzles in his logic game. The solver method with its conceptual layers seems particularly interesting. I think the challenge with this type of 'forward' puzzle generation, however, is that it tends to lead to more trivial levels by default. The Linjat author actually admits this limitation in the same post, shortly after introducing the neat solver:

> "This process will not always produce a solution, but it's pretty fast (on the order of 50-100 microseconds) so it can just be repeated a bunch of times until it generates a level. Unfortunately it'll generally produce a mediocre puzzle. There are too many obvious moves right at the start, the board gets filled in very quickly and the solution tree is quite shallow."

This tracks well with my own earlier experiments and my intuition about the (in)consistency of generating interesting echo chess levels by solution-tracing one random walk at a time. That said, could this forward-pass procedural generation be improved upon by adding some discriminator/scoring system after it to make sure we're not falling for the most trivial of solutions? Absolutely. In fact, the author continues by explaining how Linjat does that as well.

> "The above process produced a mediocre puzzle. In the final stage, we use that level as a seed for an optimization process. The optimizer sets up a pool of up to 10 puzzle variants. The pool is initialized with the newly generated random puzzle. On each iteration, the optimizer selects one puzzle from the pool and mutates it. [...] We then run the solver in the special level-generation mode [...] to make it solvable again. After that, we run the solver again, this time in the normal mode. [...] The new puzzle is then added to the pool. If the pool ever contains more than 10 puzzles, the worst one is discarded. This process is repeated a number of times (anything from 10k to 50k iterations seemed to be fine). After that, the version of the puzzle with the highest score is saved into the puzzle's level database."

In other words, what we'd truly be doing is: (1) some iterative process to generate a (trivially) solvable walk, (2) add random mutations to make the (solvable) level interesting, (3) readjust to make the (interesting) solvable again, (4) rinse and repeat until we have a (hopefully) interesting and solvable level.

To be clear, there's nothing wrong with this approach - it could even give us more granular control of difficulty curving explicitly. Indeed, with the right tweaks, I bet some solid solver + optimizer process could be devised to generate non-trivially solvable echo chess levels starting from a forward random walk.

Philosophically, in fact, the last step of the Linjat optimizer sounds actually pretty similar to the way the current 'Endless' mode in echo chess selects a level to be served to the player. 50 random gens get evaluated by the ML ensemble, they get ranked by majority-voting of solvability first, and probability of being solvable second, and the level with the highest score is the one that gets committed to the game.

Granted, the current echo chess generator directly starts from a parametrized random pool of 'mutations' before running them through its solvability discriminator, as opposed to starting from a definitionally solvable forward walk kernel to be mutated. Mutations first, solvability second. But the result is the same. And given that the starting pool is parametrized, there is still ample control (implicitly at least) in adjusting the distribution of components like obstacles, piece types, topology, etc. to vary the expected difficulty of the seeds.

TL;DR: we can start from random weights or fine-tune promising ones. But we still need to do something to get non-trivial levels generated.

Fun write up and interesting game that repurposes known mechanics. I paused reading to solve your first fictional example and ended up using the exact strategy that you explain in the next few paragraphs. I don't play chess, but your write up and simple rules made the strategy part really intuitive (for the simple example). Excellent nerd sniping!

Yes! So happy to hear this. One thing I was really aiming for with the echo chess gameplay design is the ability for anyone to pick up the game without any prior familiarity with chess or other strategy games, while also offering a pretty exciting challenge for chess GMs and strategy veterans.

The fact that you directly got the solution to that fictional example kinda proves the point that 'type 2' folks (as described in that section of the post) can actually be at a disadvantage compared to the newcomers given their preexisting intuitions and heuristics. Curious to know if you ended up solving some of the main levels in 'classic' mode too.

> I paused reading to solve your first fictional example and ended up using the exact strategy that you explain in the next few paragraphs.

I did too, and really feel like it's the most natural strategy, even for regular chess players. I'm interested if OP has any anecdotal evidence that chess players would try to solve it by a "forward" algorithm rather than "backward." Even a natural chess player would get that this is a puzzle.

> anecdotal evidence that chess players would try to solve it by a "forward" algorithm rather than "backward"

I think the main point is less about the forward vs backward part, and more so about the assumed relative values of every piece, position, or configuration on the board. Anecdotally, playtesting did show that regular chess players tend to lean on preexisting heuristics that serve them really well in chess, but less so in echo chess.

Not sure how this data compares to other variants like Sovereign Chess. I bet there is a similar adjustment period required to unlearn some habits and learn new ones. Caveat to all this: after re-adjusting to the mechanics of a puzzle game and the specific implications entailed, I'm sure veteran strategy players would still outperform, on average. Even across broader genres like chess vs TBS vs 4X vs GS. There's likely some 'muscle memory' that the brain develops over time.

It would be great to include these links prominently in the article, fairly high up,

Great point, thanks. Will update.

I actually semi-appreciate being 'forced' to read through the great write-up.

Well done!

You, sir, are a gentleman and a scholar. Thank you for reviving the lost art of deep reading.

What a fun game and awesome write up! I've been considering building my own card game variation and this encouraged me to dive in and do it. I loved your balance of engineering/product/marketing/game theory throughout the article. Given the success, have you tried to monetize it at all?

Do it! If you build that game, I'd love to check it out. No plans for monetization. Just enjoying the quest atm. Glad you're enjoying it so far.

This was a lot of fun to read, really enjoyed the journey from game design to product design to ML. One thing I was hoping to ask was how come you felt the need to procedurally generate levels? I've often heard debates around whether content needs to be "hand-crafted" to be worth another human's time but curious to hear your take on this since it seems like you implemented both ends of the spectrum with endless and classic.

Also do you feel like you now have a general set of principles to procedurally generate levels that apply to games outside of echo chess? Puzzle games are great since they're well scoped for indie devs and I'd imagine a lot of would be puzzle designers would burn out before they create a few dozen-hundred levels.

> how come you felt the need to procedurally generate levels?

Three reasons: (1) demand for new levels was too high - game traction exceeded my laziness threshold as a designer; (2) puzzle lovers suffered from lack of replayability - game was effectively punishing core users who engage with it the most; (3) designing a 'good' difficulty curve required me to quantify a level's difficulty objectively - anytime I design a puzzle or strategy game, I also try to design an algorithm that can solve it to get a general sense of how the different levels compare in difficulty; (4) I tend to get obsessively curious about stuff - wasn't sure if it's feasible to have a 100% real-time procedural gen of chess mazes so I decided to do it to find out.

> I've often heard debates around whether content needs to be "hand-crafted" to be worth another human's time

LLM jokes aside, I think this is a great point and I'm not sure exactly what the right answer is here. I ended up keeping both Classic and Endless modes for this exact reason. If there's enough interest, I'll add a manual level generator for the community of 'humans' to submit their own hand-crafted creations for others to play.

> a general set of principles to procedurally generate levels that apply to games outside of echo chess?

Good question. I think it really comes down to this: (a) can you formalize the concept of a 'level' and its components for your game in a way as to encode/decode every game state (at a minimum) easily and efficiently? (b) can you parametrize this formalism in a way as to connect malleable randomizations to every meaningful component of a level to generate (hypothetical) infinite variability? (c) do you have a confident way to make sure whatever generation of a 'level' you're churning out is as playable, achievable, and as fun as the manually crafted one? The fun part is the hardest one to automate. That's where I think you need a very strong grasp of what actually make your puzzle game fun. All the rest can likely be generalizable to other games.

> puzzle designers would burn out before they create a few dozen-hundred levels

Tell me about it.

can you please implement click&click controls, like on lichess?

hold&drag is almost unusable on the phone

(and/or you need to resize the website, as it doesn't fit the screen neither in phone- nor in desktop-mode of the browser)

Click and click support is coming soon! Is the board itself not fitting on the screen? If you don't mind, can you please share what device/os/browser you're on. Resizing is disabled by default on mobile.

android, Opera

if I hold'n'drag up-down, it moves the viewpoint (together with the board)

might be because of URL bar appearing/hiding, never encountered this before...

edit: even with "toolbars - never hide", it still scrolls a tiny bit (tho the game becomes usable)

Hmm that's interesting. The screen is supposed to be non scrollable, non draggable and non zoomable on mobile to avoid this type of issues. Unfortunately it might be a bug for opera on android. I'll see what I can do. Just to make sure, this is happening in a fresh browser tab, not within a webview from another app - right? In the meantime, hopefully you'll able to play normally on other mobile or desktop browsers. Thanks for your patience and support!

> Just to make sure, this is happening in a fresh browser tab, not within a webview from another app - right?

yep

> Thanks for your patience and support!

thank _you_ for a great game

I implemented a partial generator based on the idea in my previous comment. It was quite a fun challenge.

At each step it determines the reachable squares for the given piece, that are not occupied or block past moves, and chooses one at random, then it computes the shortest path to that square. This procedure is repeated until there are no squares available.

Only pawns, knights and kings are supported so far.

https://gist.github.com/oessessnex/bc617095675da44f857216f98...

Great game btw :)

Glad you enjoyed the game - and the generator metagame. Thanks for pitching in and sharing your partial gen implementation!

> the reachable squares for the given piece, that are not occupied or block past moves

The last part is key. There's a similar discussion related to level generation here: https://news.ycombinator.com/item?id=37334186

If you do check it out, I'd be curious to hear your thoughts on the Linjat approach and the limitation around trivial solvability of gens without an optimizer step of some sort. Still unclear at this stage where the debate of ML vs deterministic solvers will land on this one, though there are already several insights discussed that can be meaningful for puzzle design in general.

Let me know if you end up expanding the code and/or going through the 'forward solver' tangent debate. Thankful for your efforts in taking a stab at this challenge!

I don't know if you still read this, but is there a chance to separate controls of sounds (piece selection, piece placement) and music (the score)?

I love the music, but a bit frustrated with the sounds

> I don’t know if you still read this

Certainly, feel free to drop a comment here any time.

> separate controls of sounds (piece selection, piece placement) and music (the score)

Not planned for the current minimalist version but I think that’s a good idea for a settings menu.

> I love the music, but a bit frustrated with the sounds

Sorry to hear that. Out of curiosity, is it the capturing sound in particular you’re referring to, or do you feel the same about the (less frequent) other SFX ones? Would be great to understand a bit more too what aspect in particular of these sounds you find suboptimal (genre, volume, frequency, specific audio, etc.)

> is it the capturing sound in particular you’re referring to, or do you feel the same about the (less frequent) other SFX ones?

Level end and level start are rare enough to not pay attention to, they're fine

Capturing the pieces is high enough note to not interfere with the music (and it sounds positive), but it gets boring(?) after a while

"Moving to an empty cell" on the other hand... I'd reserve it for errors, tbh. Something about that... sound of hitting a tin or glass, it feels unpleasant (and not neutral like simple maneuvering should be, imo)

Only now, after frantic replaying of sounds over and over, I understood that "wrong move" has different sfx from "move to an empty cell"... That's not obvious. | Also, I think that returning piece to its own place shouldn't sound like an error (especially since it is highlighted same green color as valid moves. I'd make this silent probably)

> Would be great to understand a bit more too what aspect in particular of these sounds you find suboptimal (genre, volume, frequency, specific audio, etc.)

Volume seem fine: my mouse is louder than sfx, but less loud than the song

And perhaps last nitpick, but does the song change bpm? I feel the urge to synchronize moves with the catchy beat, but I feel like I can't apply rhythm from the beginning of the song to its end (and vice versa)

Very helpful feedback. Thank you for that.

By the way, many have reached out asking about an echo chess community for future updates or feedback/discussions. I'm considering setting up a discord server for that.

Let me know if you're interested in future versions or levels of echo chess. I can add you to the early access list when the time comes.