ChessPlay real, full games of Chess against the computer , live on your chart. The first playable chess on PulseWire.
🟩 HIGHLIGHTS
⭐ Genuine independent gameplay - infinite different games possible.
⭐ The computer ranked over 1200 at Blitz across 100+ rated games on a popular online chess website.
⭐ Optional trash talk from the computer.
⭐ Play as White or Black, with the board flipped so your pieces sit at the bottom.
⭐ The computer thinks and responds fast.
⭐ Only legal moves are allowed.
⭐ The computer knows all the rules of chess including en passant, castling, check, checkmate, and the threefold repetition draw.
⭐ The to and from squares of the most recent move from both sides are highlighted on the board.
⭐ Captured pieces are displayed; just-captured pieces are highlighted.
⭐ The colour scheme adjusts to light or dark chart backgrounds.
⭐ The computer sometimes resigns if it's about to lose, and sometimes lets you complete the win 🎉
🟩 SET UP THE FIRST GAME
Add the script to a chart with some history (it warns you if there's not enough); any timeframe, doesn't matter if the market is open or not.
The script opens on a separate pane below the main chart, appearing cut-off.
1. Don't panic.
2. Double-click the chart background to maximise the Chess pane and hide your chart (double-click again to get your chart back).
3. As an alternative, you can click the three dots next to the Chess script name and choose Move to > Existing pane above and then Hide the chart symbol.
4. The default settings should be good to get you started playing, although you might need to adjust the square height and width so that the chess board looks nicely square on your particular chart.
🟩 PLAY THE GAME
Let's play.
1. Open the indicator Settings dialog and move it to the side so you can see the board.
2. Type your move into the Moves text field. Use coordinate notation: `e2e4`, `g1f3`, `e7e8q`, etc.
3. Don't click OK , 'cos then you'll have to re-open the Settings. Instead, hit Enter . This makes the script pick up the changed text input.
4. The computer thinks a little (on my system, almost instantly) and then announces its move. It will say something like `Add my move d7d5 to the Moves input field`. The table cell goes orange.
5. Type that move into the Moves input field and hit Enter . The cell's orange colour disappears, and it tells you that it's your move. If you have trash talk on, it might comment about your move or its move.
If you enter an illegal move, the computer will tell you. It will try to help you if it recognises what you might have meant.
If you enter a move wrong, you can just delete it and press Enter and the game resumes from that point.
To save a game or show it to someone else with the same Chess script loaded, just copy the text out of the Moves input field (you'll need Replies: Deterministic set to ensure it makes the same next move).
Have fun! The computer will joke around with you even as it beats you (or you beat it).
🟩 RELOAD THE CHART TO PLAY THE NEXT GAME
To ensure that the computer can (if it wants) play different moves against the same position next game, leave Replies set on Random, and save and reload the board in between games.
Note that moves that are already entered are not changed. Only a pending move - one that the computer announced but you haven't yet typed in - can change if you reload the chart or change input values, and only if Replies: Random is selected in the settings.
🟩 ALL THE SETTINGS
Here are all the settings and what they do.
Moves : Holds your moves and the computer's moves. You can separate moves with a comma or a space or a new line. Only a new line, or some other change to the settings, triggers a script refresh and another move.
Play as : Choose who you want to play as. The board flips so that your pieces are always closest to you.
Thinking : Choose Deep so that the computer uses all of its tiny brain against you. Or Quick if you feel that it's responding too slowly or you run into timeout errors.
Replies : Choose Random so that the computer can play different moves against the same position next game (requires a chart reload to clear cache). It often still plays its favourite move but if it has two favourites, it can also choose between them. Choose Deterministic so that the computer always plays the same move given the same position (move sequence), even on a different chart, tab, or after a reload. This is useful for saving games or playing through saved games. For casual play, choose Random . Note : If you change any inputs to a new combination, the computer might choose a different reply if Random is selected.
Trash Talk : Enable this setting so the computer can misquote pop culture references at you.
Board : Move the board to the left, right, or centre.
Piece size : Make the pieces more bigger or smallerer.
Square width, height : Adjust the percentage sizes so that the squares look, well, square. The right ratio depends on your monitor.
Calculated Bars : This setting is precautionary to prevent any slowdown on long charts. Leave this at the default.
🟩 CREDITS
Thanks to @The_Peaceful_Lizard for discussions all that time ago about whether gameplay is possible in Pine.
Thanks to my beta testers for valuable usability feedback.
🟩 HOW TO CODE GAMEPLAY IN PINE
Turn-based gameplay as we know it is almost impossible. To play a game you need to make a move. So you need to tell the script something. All the possible ways to interact with a script are:
- Changing an input value (including interactive `input.time()` and `input.price()` lines).
- A value output from another script changing, if the consuming script reads it using `input.source()`.
- Scrolling or zooming the chart, if the script uses `chart.left_visible_bar_time()` or `chart.right_visible_bar_time()`.
- Changing the chart symbol or timeframe.
The latter two are not informative enough to build a game move from. And in any case, any change from this list reloads the script.
What happens when the script reloads? It forgets everything . This is actually a good thing, and by design, because a chart indicator needs to read from bar zero again if any of its inputs change, so that it can do all its calculations again and make sure they are accurate with the new settings. However, it means that there is nowhere to keep the game state :
- All variables reset, even `var` and `varip` ones.
- All drawings, plots, shapes, etc disappear.
- Pine cannot write to any external data source.
- Logs start from zero.
The only thing that persists is the most recent input values.
This means that the entire game state must be deterministically derivable from the values of inputs. Practically speaking, you must enter both your move and the computer's reply into inputs. That's the trick: the board is not stored between edits, it is re-derived from the move record (the computer checks ALL moves again, every move, that they are legal).
This pattern is actually already demonstrated in the only example of true gameplay in Pine that I was able to find: "Tic Tac Toe (For Fun)" by the Wizard @LonesomeTheBlue
🟩 HOW TO MAKE CHESS POSSIBLE IN PINE
The problem with chess is that there are so many possible moves that trying to foresee the responses to your move and the responses to that move and so on quickly becomes computationally impossible. Especially in a lightweight scripting language like Pine, which has limits on how long a script can take to run a loop or perform all its calculations.
The main thing you need to do is narrow it all down . So in building this thing from scratch, I started with some heuristics. What are some patterns when you play chess? If you're in check, you have to get out. If you're attacked, you defend. If you still have minor pieces on the back rank, you should probly get them out. And so on.
I quickly realised that not only did these rules hugely narrow down the number of things you need to calculate, but they stack in order of importance . The number one rule, for example, is: if you can win the game this move, you should. Nothing else can go before that. Developing your pieces, by contrast, comes somewhere at the back of the queue. And the others fall in line in between.
Another thing that comes fairly cheap is knowing the openings . I was always too lazy to memorise chess openings, but that's not a problem for a computer. I also figured that nailing the opening would put my engine in a good place for the midgame, and maybe cover up some weaknesses. Many of the rules are pitched slightly aggressive for the same reason 😆
🟩 MY LADDER
When you put a bunch of rules in priority order, you get a ladder .
SPOILER: If you want to enjoy a fresh game against the script, stop reading and play. Going further will give you insight into how it thinks (or avoids thinking) and allow you to beat it more easily.
Here's my chess ladder:
1. Mate in one .
2. Opening book .
3. Avoid checkmate .
4. Defence .
5. Win material .
6. Safe check .
7. Exchange when ahead .
8. Endgame .
9. Develop .
10. Any other safe move .
When you follow this ladder in order, it turns out, it looks quite a lot like you're playing chess. After I'd finished the script I found out that some very early chess engines did something similar (they likely had far weaker performance than mine), but modern ones function mainly by crunching predictions and even the most handicapped Stockfish engine is still stronger than this script.
On top of the ladder, you do need to layer in a little bit of actual looking ahead, or the engine makes terrible blunders. And you need to constrain that lookahead in turn with its own heuristics, so that you only map out a few moves and not an exponential number.
And there is a lot, lot more after that, like how we value pieces (we will deliberately lose material in an exchange when we're up big, because it hurts our opponent more), how we avoid forks, how we avoid repeating the same moves, and so on.
Still this is all smoke and mirrors - the engine doesn't really understand what makes a good position, or a good attack, or an elegant defence. It just does stuff.
🟩 HOW THIS SCRIPT WORKS END TO END
Here's what happens when you type a move and hit Enter:
Parse (bar zero). The input move text becomes board coordinates (via the ChessCore library). The tidied-up record also produces the random seed (via ChessAI), and the opening book (ChessBook) and the trash-talk banks (ChessTalk) get built.
Replay (one bar per move). For each move in the record, in order: generate every legal move in the current position, check that the next typed move is one of them, and if so apply it to the board. Along the way it collects captured pieces, watches for Game Over, and takes a fingerprint of each position so it can spot a threefold repetition. All ChessCore.
Prepare (one bar). If it's now the computer's turn: generate ALL its legal moves (ChessCore), note how well defended each move's landing square is, and flag moves that weaken the king's cover or just undo the previous move (ChessAI).
Foresee (up to three bars per candidate move). Score every potential move by how its story ends, in material: the opponent's best captures played all the way down the exchange, his checks, his quiet threats. The ChessAI library plays the stories out on ChessCore scratch boards.
The ladder (one rule per bar). Try the ten rules top down. The first that fires chooses the move. The scores from the foresee veto the doomed candidates in every rule, and break ties in some. ChessAI does all this, and rule 2 reads the ChessBook openings.
Done. The live bar draws the board and the status row announces the computer's move for you to type in. The live bar computes nothing - it only reads what the historical bars decided. The main Chess script draws, and any one-liners came from ChessTalk's banks.
Then you add its move to yours, hit Enter, and the entire thing runs again from bar zero: approves every past move, rebuilds the whole board, and chooses the next reply.
🟩 ARCHITECTURAL LESSONS
There are some things we did here that apply also to non-chess Pine scripts.
✨ "Library-first" design
Every large chunk was designed from the beginning to be its own library:
- Chess is the user-facing script that imports all the libraries.
- ChessAI decides the next move.
- ChessBook holds the openings.
- ChessCore does rules, the board, and what's legal.
- ChessTalk stores the trash talk.
Some libraries only hold data, and this split of calculations and data allows us to, for example, add more talk lines without republishing other libraries.
The main script and libraries together total ~5,000 lines, far too much to be manageable for a single script. Using libraries keeps everything organised and makes such a complex script possible.
Library-first design keeps you in control, as opposed to being forced to refactor functions into libraries when a script gets too big.
✨ Split work across bars
We do the work across historical bars, one small step per bar, so the live bar only has to draw the finished board. This prevents any one bar exceeding any timeouts. The ladder architecture makes this quite natural. For robustness, each stage declares its own completion, rather than using a hardcoded number of bars. We predict how many bars we'll need and warn if there's not enough. This pattern can help scripts with heavy calculations stay within budget.
✨ Draw once
We do all the calculations during historical bars and draw the board only on the last bar. In general, separating calculations from drawing is a good idea.
✨ Seeded randomness
If you want a random result (technically, pseudorandom) in Pine you can use `math.random()`. This returns a different number each time. We use random numbers to choose between equally promising options for the computer's moves.
However, sometimes you want a reproducible random result. You want the same random number each time the script runs. Fortunately, `math.random()` can take a `seed` parameter, and if this seed is the same, then the sequence of random numbers is the same.
For chess, the computer's choice of move must remain stable and not change to something else on the next tick of a realtime bar (seeing this happen in testing was quite a surprise). So we derive a seed from the move record . This means that for any given game, the computer's move is both random and repeatable. This helps a lot with testing.
For real games though, we want the user to be able to play the same moves next game and get a different reply from the computer (potentially; remember the computer can't remember what it did in any previous game). So for this reason, if Replies is set to Random, we also mix the script's loading time into the random seed (and each new move loads the script again). Reloading the chart now gives a new stable random sequence even for the same moves.
Understanding seeded randomness can be necessary for some scripts to use variety properly.
✨ Objects and library hierarchy
Libraries can import each other, but not in a circular way. Our lowest-level library declares object types, for example, for moves, but doesn't put data in them; the higher libraries do that.
When a more foundational library needs data that a higher-level library creates, a good pattern is for the lower library to create an object with fields that the higher library fills in. This avoids having to maintain parallel arrays so they don't get out of synch. Indicator
Public_Library_ChessTalkThis is where the Chess script keeps its trash talk. The library stores every line the computer can say, and decides when it speaks and which line it picks. It imports nothing, knows nothing about chess, and never calls `math.random()`.
There are eight kinds of occasion: the computer won material, it lost material, it promoted, it's still in its opening book, the game just started, it wins, it loses, or the game ends in a draw. Each occasion fires at its own rate, so the computer needles you now and then rather than commenting on every move. Every decision comes from arithmetic on a seed boiled down from the moves played so far, which means the same game always says the same lines, however many times you reload, and a chosen line can't flicker between ticks.
We pass the {piece} token in so that a line can name its victim ("Mmm... free {piece}." becomes "Mmm... free knight."), and per-line filters keep the puns honest - the "good knight" gag only fires when a knight actually dies. A no-repeat rule stops a category saying the same line twice in a row. The banks run to 97 lines of misquoted pop culture.
The `buildTalkState()` function packs the banks, the rates, the no-repeat memory and the wounded detection into one object, so the consumer holds one variable instead of fifteen. The consumer spots the occasion while it replays the game, asks this library for a line, and stores what it gets. The live bar only reads.
See the Chess script for the backchat in action:
Library
Public_Library_ChessBookThis library holds the opening book for the Chess script. It lives apart from the brain (ChessAI) so the openings can grow without republishing the logic. It imports nothing and contains no logic of its own beyond building the map.
Each entry pairs the moves played so far (both sides' moves, lowercase, one space between) with our reply, written the same way - so the key "e2e4 e7e5" answers with "g1f3". Some entries offer several replies separated by "|", and the consumer picks between them with its game seed, so back-to-back games can open differently. The empty-string key holds White's very first move.
We use a map because the book question is exactly a lookup: given the moves played so far, what do we reply? Simply query the canonical move string as the map key and if we get a reply that's our move in response.
Pine maps can't hold arrays as values, which is why several replies pack into one "|"-separated string. Of course we could define a UDT that contains an array, but it's overhead. The trade-off of keying by move sequence rather than by position is that an unusual move order into a known position misses the book - the cost is an early exit to the ladder, never a wrong move, and in exchange every entry in the source reads as a real game you can play through.
The book holds enough entries for every common defence and sideline on both sides, deeper main lines, and wider choices in some of them.
This split of data from calculation is worth using for non-chess scripts: when a big lookup table and the logic that reads it live in separate libraries, the table can grow on its own release schedule.
See the Chess script to play the book in a real game: Library
Public_Library_ChessAIThis library is the brain of the Chess script: a small chess opponent built on the ChessCore rules engine.
It is not a search engine. It is a ladder of ten rules that looks at one position, tries the rules in order, and plays the first that fires:
1. Mate in one
2. Opening book
3. Avoid checkmate
4. Defence
5. Win material
6. Safe check
7. Exchange when ahead
8. Endgame
9. Develop
10. Any other safe move
🟩 THE FORESEE
Before the ladder runs, a foresee stage takes every legal move and adds to its object its most likely material outcome. This score comes from the opponent's best replies to our move, and a few captures after that. We look at the opponent's best captures, his checks, his most menacing quiet threats, and what happens if we don't take. We also look briefly whether two checks in a row force mate. Deep thinking follows more replies and reads six half-moves.
The score works mostly as a veto. From the list of possible moves for a ladder stage, we reject the ones that end in us being checkmated. When every legal move walks into one, we toss a coin to decide between playing the least-bad move and resigning.
🟩 KEEPING A WON GAME WON
If we are winning we want to win, not draw. While ahead on material, the quiet rules refuse any move that recreates a position the game has already seen, so it can't shuffle a rook between two good squares forever. And the foresee prices a stalemate at minus the lead it would throw away, so the winning side sidesteps the trap while the losing side, correctly, steers toward it. The endgame rule gives the ladder actual technique (push passers, rook to the seventh, king up to escort) to try to win.
🟩 DETERMINISM
No `math.random()` call decides anything on its own. The first five rules always give the same answer for a position. The last five pick from their pools with a seed the consumer supplies, derived from the game record. Variety between games comes from the consumer script mixing a clock reading into the seed, not from the library.
🟩 PROCESS FLOW
The exported functions are called in a certian order for each position:
ChessCore generates the legal moves.
`annotateMoves()` counts the attackers and defenders on every move's landing square, and notes the cheapest attacker. Every safety test the rules make reads these three numbers.
`filterPromotions()` and `classifyMoves()` trim pointless pawn promotions and flag moves that make the king's cover worse or that just undo the previous move.
The foresee adds a score to each candidate move: `foreseePrepare()` starts the story, `foreseeFinishCaptures()` follows the capture lines, and `foreseeFinishRest()` follows the checks and quiet threats. The consuming script spreads these calls across chart bars so no single bar works too hard.
The ladder rules run in order, `ruleMateInOne()` down to `ruleFallback()`, and the first one that returns a move wins.
See the Chess script to play against this AI: Library
Public_Library_ChessCoreThe rules of chess as a reusable Pine engine. It doesn't display anything or think of any moves. It just defines what is legal. This is the foundation library of the Chess script, and it's built so that any Pine project needing real chess - a different engine, a puzzle board, a game replayer - can build on it without rewriting the rules.
🟩 WHAT IT DOES
Keeps the whole position in one object: the board, whose turn it is, castling rights, the en-passant target, the move clocks, and a cached king square for each side.
Generates every fully legal move for the side to move, including castling, en passant, and promotions. It checks first based on how the pieces can move, and then creates a copy board to test which moves keeps the king out of check - so pins, discovered checks and the en-passant edge cases all just work.
Applies a move to a position and does all the admin.
Detects checkmate, stalemate, and the automatic draws. For threefold repetition it provides position keys and a counting helper. The consumer keeps the key history, because that's the one draw that needs to remember earlier positions, and these functions deliberately hold no history of their own.
Parses a typed move record like "e2e4 e7e5" - junk-tolerant and case-insensitive, so "e2-e4, E7e5" parses the same - and rebuilds it as one tidy canonical string. The Chess consumer uses that canonical record as its opening-book key and its random seed.
🟩 DESIGN NOTES
The big thing here is the scan that answers "who attacks this square?", with variants that count the attackers and price the cheapest one.
Another important part is the test of whether a move is legal on a COPY board. One definition of "attacked" is shared by the move generator, the game-status detection and castling's transit-square tests, so they can never disagree about what check means.
Each generated move is an object whose scoring fields are declared here but filled in from outside - `foreseeScore` for an AI's look-ahead, plus two endgame scores. ChessCore itself never touches them. This declare-then-fill pattern is how a foundational library can carry data that a higher library computes, without circular imports and without parallel arrays.
Internally everything thinks in (row, column), where row 0 is rank 8 (Black's back rank) and column 0 is file "a". Square names like "e4" appear only at the edges.
🟩 WHAT TRUSTS WHAT
The exports look independent, but they lean on each other in ways worth knowing before you build on them:
`applyMove()` trusts its move and changes the position in place. It doesn't re-check legality, so feed it moves from `generateLegalMoves()` - or from `matchLegalMove()`, which picks the move matching typed coordinates out of that list and brings the filled-in castling and en-passant details with it. A move object you build by hand would miss those.
To ask "what if?" without committing, `copyPosition()` first and apply the move to the copy. The generator's own self-check filter runs on such scratch boards, and so does the whole ChessAI look-ahead.
`gameStatusOf()` spots mate, stalemate and the automatic draws, but not threefold repetition, which needs history this library deliberately doesn't keep. Push each new `positionKey()` onto your own array, then ask `isThreefoldRepetition()`. Push first, then ask.
The position caches each king's square so check tests don't scan the board, and `applyMove()` maintains that cache. If you build a custom position by writing to the board matrix yourself, set the king fields to match, or every check test will look at the wrong square.
See the Chess script for the whole thing playing human vs computer: Library
Indicator
Chess_Data_5This library supplies a randomized list of 1-Move Chess Puzzles, this is 5/5 in my collection of puzzles on Tradingview.
This library contains 730 chess puzzles, this is enough for 1 unique chess puzzle for 2 years (730/365 = 2)
The Puzzles are sourced from Lichess's open-source database found here -> | database.lichess.org
This data has been reduced to only included 1-Move chess puzzles with a popularity rating of > 70, and condensed for ease of formatting and less characters.
The reduced format of the data in this library reads:
"Puzzle Code, Modified FEN, Moves, Puzzle Rating, Popularity Rating"
Puzzle Code: Lichess Codes Identifying each puzzle, this allows them to be retrieved from their website based on this Code.
Modified FEN: Forsyth-Edwards Notation is the standard notation to describe positions of a chess game. This includes the active move tacked onto the end after the last '/', this simplifies the process to retrieve the active move in PineScript.
Moves: This holds the first move seen by the player in the puzzle (opposite color), and then the correct next move which is Puzzle Solution, that the player is trying to determine.
Puzzle Rating: Difficulty Rating of the Puzzle, Generally speaking | Under 1500 = Beginner | 1500 to 1800 Casual | 1800 to 2100 Intermediate | 2100+ Advanced
Popularity Ranking: This is the popularity ranking calculated by lichess based on their own data of user feedback.
Note: After Reducing the amount of data down to only 1-Move puzzles with a popularity rating of > 70%, there is still around 340k puzzles. (Enough for over 900 Years!)
> Functions [/b
get()
Returns the list of chess puzzle data. Library
Chess_Data_4This library supplies a randomized list of 1-Move Chess Puzzles, this is 4/5 in my collection of puzzles on Tradingview.
This library contains 730 chess puzzles, this is enough for 1 unique chess puzzle for 2 years (730/365 = 2)
The Puzzles are sourced from Lichess's open-source database found here -> | database.lichess.org
This data has been reduced to only included 1-Move chess puzzles with a popularity rating of > 70, and condensed for ease of formatting and less characters.
The reduced format of the data in this library reads:
"Puzzle Code, Modified FEN, Moves, Puzzle Rating, Popularity Rating"
Puzzle Code: Lichess Codes Identifying each puzzle, this allows them to be retrieved from their website based on this Code.
Modified FEN: Forsyth-Edwards Notation is the standard notation to describe positions of a chess game. This includes the active move tacked onto the end after the last '/', this simplifies the process to retrieve the active move in PineScript.
Moves: This holds the first move seen by the player in the puzzle (opposite color), and then the correct next move which is Puzzle Solution, that the player is trying to determine.
Puzzle Rating: Difficulty Rating of the Puzzle, Generally speaking | Under 1500 = Beginner | 1500 to 1800 Casual | 1800 to 2100 Intermediate | 2100+ Advanced
Popularity Ranking: This is the popularity ranking calculated by lichess based on their own data of user feedback.
Note: After Reducing the amount of data down to only 1-Move puzzles with a popularity rating of > 70%, there is still around 340k puzzles. (Enough for over 900 Years!)
> Functions [/b
get()
Returns the list of chess puzzle data. Library
Chess_Data_3This library supplies a randomized list of 1-Move Chess Puzzles, this is 3/5 in my collection of puzzles on Tradingview.
This library contains 730 chess puzzles, this is enough for 1 unique chess puzzle for 2 years (730/365 = 2)
The Puzzles are sourced from Lichess's open-source database found here -> | database.lichess.org
This data has been reduced to only included 1-Move chess puzzles with a popularity rating of > 70, and condensed for ease of formatting and less characters.
The reduced format of the data in this library reads:
"Puzzle Code, Modified FEN, Moves, Puzzle Rating, Popularity Rating"
Puzzle Code: Lichess Codes Identifying each puzzle, this allows them to be retrieved from their website based on this Code.
Modified FEN: Forsyth-Edwards Notation is the standard notation to describe positions of a chess game. This includes the active move tacked onto the end after the last '/', this simplifies the process to retrieve the active move in PineScript.
Moves: This holds the first move seen by the player in the puzzle (opposite color), and then the correct next move which is Puzzle Solution, that the player is trying to determine.
Puzzle Rating: Difficulty Rating of the Puzzle, Generally speaking | Under 1500 = Beginner | 1500 to 1800 Casual | 1800 to 2100 Intermediate | 2100+ Advanced
Popularity Ranking: This is the popularity ranking calculated by lichess based on their own data of user feedback.
Note: After Reducing the amount of data down to only 1-Move puzzles with a popularity rating of > 70%, there is still around 340k puzzles. (Enough for over 900 Years!)
> Functions [/b
get()
Returns the list of chess puzzle data. Library
Chess_Data_2This library supplies a randomized list of 1-Move Chess Puzzles, this is 2/5 in my collection of puzzles on Tradingview.
This library contains 730 chess puzzles, this is enough for 1 unique chess puzzle for 2 years (730/365 = 2)
The Puzzles are sourced from Lichess's open-source database found here -> | database.lichess.org
This data has been reduced to only included 1-Move chess puzzles with a popularity rating of > 70, and condensed for ease of formatting and less characters.
The reduced format of the data in this library reads:
"Puzzle Code, Modified FEN, Moves, Puzzle Rating, Popularity Rating"
Puzzle Code: Lichess Codes Identifying each puzzle, this allows them to be retrieved from their website based on this Code.
Modified FEN: Forsyth-Edwards Notation is the standard notation to describe positions of a chess game. This includes the active move tacked onto the end after the last '/', this simplifies the process to retrieve the active move in PineScript.
Moves: This holds the first move seen by the player in the puzzle (opposite color), and then the correct next move which is Puzzle Solution, that the player is trying to determine.
Puzzle Rating: Difficulty Rating of the Puzzle, Generally speaking | Under 1500 = Beginner | 1500 to 1800 Casual | 1800 to 2100 Intermediate | 2100+ Advanced
Popularity Ranking: This is the popularity ranking calculated by lichess based on their own data of user feedback.
Note: After Reducing the amount of data down to only 1-Move puzzles with a popularity rating of > 70%, there is still around 340k puzzles. (Enough for over 900 Years!)
> Functions [/b
get()
Returns the list of chess puzzle data. Library
Chess_Data_1This library supplies a randomized list of 1-Move Chess Puzzles, this is 1/5 in my collection of puzzles on Tradingview.
This library contains 730 chess puzzles, this is enough for 1 unique chess puzzle for 2 years (730/365 = 2)
The Puzzles are sourced from Lichess's open-source database found here -> | database.lichess.org
This data has been reduced to only included 1-Move chess puzzles with a popularity rating of > 70, and condensed for ease of formatting and less characters.
The reduced format of the data in this library reads:
"Puzzle Code, Modified FEN, Moves, Puzzle Rating, Popularity Rating"
Puzzle Code: Lichess Codes Identifying each puzzle, this allows them to be retrieved from their website based on this Code.
Modified FEN: Forsyth-Edwards Notation is the standard notation to describe positions of a chess game. This includes the active move tacked onto the end after the last '/', this simplifies the process to retrieve the active move in PineScript.
Moves: This holds the first move seen by the player in the puzzle (opposite color), and then the correct next move which is Puzzle Solution, that the player is trying to determine.
Puzzle Rating: Difficulty Rating of the Puzzle, Generally speaking | Under 1500 = Beginner | 1500 to 1800 Casual | 1800 to 2100 Intermediate | 2100+ Advanced
Popularity Ranking: This is the popularity ranking calculated by lichess based on their own data of user feedback.
Note: After Reducing the amount of data down to only 1-Move puzzles with a popularity rating of > 70%, there is still around 340k puzzles. (Enough for over 900 Years!)
> Functions [/b
get()
Returns the list of chess puzzle data. Library
