[Kpt-Ahab] Candles Slot MachineHow the Game Works
Candles Slot Machine** is an automated slot machine simulation that runs directly on the PulseWire chart.
Each new game starts with 100 credits:
1. Disable Autoplay to reset the game and change the settings.
2. Set the maximum number of spins under Autoplay bars.
3. Select the wager per spin under Bet per spin.
4. Enable Autoplay to start the game.
5. Exactly one spin is completed at each confirmed close of a real-time bar.
The wager is deducted from the available credits on every spin. Three symbols are then generated, and any applicable payout is calculated.
A game ends when:
* the selected maximum number of spins has been reached, or
* there are not enough credits remaining for the next wager.
The final result remains visible for three fully completed bars. The next game then starts automatically with another 100 credits. The cumulative session statistics remain active until Autoplay is disabled, which resets the entire session.
Symbols and Payouts
Each symbol has its own probability:
* **Cherry:** 30%
* **Lemon:** 25%
* **Bell:** 18%
* **Star:** 13%
* **Seven:** 9%
* **Diamond:** 5%
Two matching symbols pay x1. This only returns the original wager, resulting in a net outcome of zero for that spin.
Three matching symbols pay:
* **Cherry:** x6
* **Lemon:** x8
* **Bell:** x12
* **Star:** x20
* **Seven:** x40
* **Diamond:** x100
Three Diamonds form the jackpot.
The payout model has a theoretical RTP of 92.53%. This value represents the expected long-term payout relative to all credits wagered. It does not guarantee any particular outcome for an individual game or a short session.
Random Generation
The reel symbols are generated using a combined pseudo-random calculation. The script uses, among other inputs:
* runtime random values
* individual game and spin numbers
* confirmed OHLCV data from the current bar
* bar closing time and bar index
Market data is used exclusively as additional entropy for the random-generation process. It is not evaluated as a trading signal, and there is no intended relationship between price direction and game results.
The script is not designed to simulate historical spins retroactively. New spins are executed exclusively on confirmed real-time bars.
Game Speed
The speed of the game depends directly on the selected chart timeframe because one spin is completed per confirmed bar close.
Examples:
* On a 1-minute chart, approximately one spin is completed per minute.
* On a 15-minute chart, approximately one spin is completed every 15 minutes.
* On a 1-hour chart, approximately one spin is completed per hour.
Exchange closures, missing market updates, or unconfirmed bars delay the next spin accordingly.
Indicator
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
Texas Hold'em Engine [BOX Max Size Edition]Texas Hold'em
NOTICE / DISCLAIMER
This architecture is NOT a mere entertainment tool. It is a highly advanced algorithmic multi-state logic simulation engine disguised as a Texas Hold'em framework, specifically designed to test the computational overhead, state persistence, and localized rendering boundaries of Pine Script v6 under live tick conditions.
EXECUTIVE SUMMARY
This script is deployed as a Proof of Concept (PoC) to demonstrate the extreme limits of Pine Script v6's array processing, state evaluation capabilities, and localized UI rendering. It functions as a rigorous technical benchmark for developers building institutional-grade algorithmic dashboards directly on PulseWire charts. By leveraging box.new() structures, this script successfully bypasses PulseWire's native text scaling limits, allowing for massive UI components that seamlessly track price volatility.
SYSTEM USAGE (How-To / Interactive Execution Flow)
Initialization: Apply the script to a chart. The system automatically initializes a deterministic pseudo-random array shuffle based on the Game Seed.
Phase Progression: The script executes across 6 distinct phases based on the bar index: Dealing, Pre-Flop, Flop, Turn, River, and Showdown.
Player Action Inputs: Using the Settings menu, manually override your decisions (FOLD, CALL/CHECK, RAISE) during the Pre-Flop, Flop, Turn, and River phases.
CPU State Engine: The opposing CPU evaluates the market's volatility via the True Range (ATR). If ta.tr / ta.sma(ta.tr, 14) > 1.5, the CPU assumes an aggressive posture and executes a "RAISE".
Stateful Transaction Engine: As actions are selected, the system calculates blind deductions, raise accumulations, and pot sizes. The var driven memory engine perfectly retains chip stack data across chart ticks and resets seamlessly upon determining a winner via Fold or Showdown.
Evaluation: At the Showdown phase, a localized combinatorics engine processes a 7-card array for both entities, scoring the best 5-card combinations using mathematical rank arrays to determine the victor and award the accumulated pot.
ARCHITECTURE & QUANTITATIVE LOGIC (Technical Specifications)
Bounding Box Scaling Algorithm (Localized UI Vector Scaling)
Standard label.new() text strings are hard-capped at size.huge (approx. 36px), which fails to scale alongside chart zooming. To override this limitation, vector Unicode strings are injected into a box.new() container. The Y-axis boundaries are mathematically locked to the Average True Range (ATR).
Formula:
Top = Y_Position + (ATR / 2)
Bottom = Y_Position - (ATR / 2)
Calculation Example:
Given an asset trading at Y = 150.00 with an ATR = 2.0.
Top = 150.00 + (2.0 / 2) = 151.00
Bottom = 150.00 - (2.0 / 2) = 149.00
The resulting Y-axis width of the box is strictly 2.0. By enforcing a strict volatility-based bounding box, the text engine is overridden, forcing the Unicode vectors to dynamically scale in perfect proportion to market noise.
Persistent State Memory (Transaction Logic)
PulseWire charts inherently recalculate scripts on every new price tick. To prevent the chip stacks and pot sizes from resetting, the system employs Pine Script's var declaration alongside a custom last_calc_state tracker. This ensures that deductions and additions are mathematically locked only once per phase transition, proving that complex financial state machines can run cleanly alongside heavy visual rendering without consuming object limit quotas.
Deterministic Pseudo-Random Array Shuffling (LCG Implementation)
To eliminate chart repainting across continuous tick streaming, a Linear Congruential Generator (LCG) loop reorganizes the 52-element primary array via modulo arithmetic:
Swap_Index = (Seed + i * 7) % (i + 1)
This math guarantees identical randomizations across every chart tick refresh, achieving absolute visual stability.
INPUT PARAMETERS REFERENCE
Chip & Betting System: Configure initial starting stacks, blind amounts, and default raise sizes.
UI Mode: Toggles between a static Table grid and the dynamic Chart-Linked Box rendering.
Force Enlarge Cards with Box Text: Activates the bounding box algorithm mentioned above.
Y-Axis Reference Price: Anchors the floating UI to High, Low, or Close prices to prevent visual collision with candlestick series.
テキサスホールデム
免責事項
本アーキテクチャは単なる娯楽ツールではありません。これは、テキサスホールデムのフレームワークを模した、高度な多状態ロジックシミュレーションエンジンであり、Pine Script v6におけるライブティック更新下の計算オーバーヘッド、状態変数の永続性（メモリ保持）、および局所的レンダリングの限界を検証するために特別に設計されています。
エグゼクティブ・サマリー
本スクリプトは、Pine Script v6の配列処理、状態評価、およびUI描画の極限を実証するための概念実証（PoC）モデルです。PulseWire上でクォンツレベルのアルゴリズム・ダッシュボードを構築する開発者に向けた技術的ベンチマークとして機能します。box.new()構造体を応用することで、PulseWireネイティブのテキスト縮尺制限を突破し、ボラティリティに追従する巨大なUIコンポーネントの描画を実現しています。
システム実行手順（インタラクティブ実行フローの詳細）
初期化: スクリプトをチャートに適用すると、Game Seedに基づく決定論的疑似乱数アルゴリズムにより、配列のシャッフルが初期化されます。
フェーズ進行: バーインデックスに基づき、Dealing、Pre-Flop、Flop、Turn、River、Showdownの6つのフェーズが自動進行します。
プレイヤーアクション: 設定画面のプルダウンから、各フェーズ（Pre-Flop〜River）における自身のアクション（FOLD, CALL/CHECK, RAISE）を手動でオーバーライドします。
CPU状態エンジン: 対面（CPU）は、True Range (ATR)を用いて市場のボラティリティを評価します。ta.tr / ta.sma(ta.tr, 14) > 1.5の場合、CPUはアグレッシブな状態と判断し「RAISE」を実行します。
状態記憶トランザクションエンジン: アクションが選択されると、システムはブラインドの徴収、レイズによる資金移動、POTの合計を瞬時に計算します。var変数で構築されたメモリエンジンにより、ティックが更新されてもチップスタックは完璧に保持され、勝敗確定時に正確に清算されます。
役の評価: Showdownフェーズにて、ローカルの組み合わせ評価エンジンが双方の7要素配列を処理し、ランク配列を用いて最適な5枚の組み合わせをスコアリングし、勝敗の決定とPOTの分配を行います。
アーキテクチャおよび定量的ロジック（技術仕様）
Bounding Boxスケーリング・アルゴリズム（局所的UIベクタースケーリング）
標準の label.new() オブジェクトは最大フォントサイズが size.huge（約36px）に制限されており、チャートの拡大縮小に追従しません。この制限をオーバーライドするため、ベクターテキストを box.new() 構造体に注入し、Y軸の境界をAverage True Range (ATR)に同期させます。
計算式:
Top = Y座標 + (ATR / 2)
Bottom = Y座標 - (ATR / 2)
実際の計算例:
現在価格 Y = 150.00、ATR = 2.0 の資産の場合。
Top = 150.00 + (2.0 / 2) = 151.00
Bottom = 150.00 - (2.0 / 2) = 149.00
出力されるBoxのY軸幅は正確に 2.0 となります。価格変動（ボラティリティ）に基づく厳格な境界ボックスを強制することで内部レンダリングエンジンをハックし、市場のノイズに完全に比例したダイナミックなテキストスケーリングを実現しています。
永続的状態メモリ（トランザクションロジック）
PulseWireのチャートは、価格ティックが動くたびにスクリプト全体を再計算します。この挙動によってチップスタックやPOTがリセットされるのを防ぐため、Pine Scriptの var 宣言と独自の last_calc_state トラッカーを組み合わせています。これにより、各フェーズの移行時に一度だけ確実な資金移動計算がロックされます。これは、高度な描画処理と並行して、複雑な金融ステートマシンが制限オブジェクト（BoxやLabel）を消費することなくクリーンに動作することを証明しています。
]
決定論的疑似乱数による配列シャッフル（LCGの実装）
ティック更新におけるリペイントを防ぐため、剰余演算を用いた線形合同法（LCG）アルゴリズムが52要素のプライマリ配列を並び替えます。
Swap_Index = (Seed + i * 7) % (i + 1)
この数理モデルにより、すべてのティック再計算において完全に同一の配列並び順が維持されます。
主要入力パラメーター仕様
Chip & Betting System: 初期スタック量、ブラインド額、デフォルトのレイズ額を設定します。
UI Mode: 固定テーブル描画と、チャート連動型のBOX描画を切り替えます。
Force Enlarge Cards with Box Text: 上記のバウンディングボックス・アルゴリズムを有効化します。
Y-Axis Reference Price: ローソク足との視覚的な衝突を避けるため、フローティングUIの基準アンカーをHigh, Low, Closeのいずれかに固定します。
Indicator
Indicator
Auto Play Ping/Pong [UAlgo]Auto Play Ping/Pong is a fully self running arcade style mini game built entirely in Pine Script and rendered directly on the chart. Instead of analyzing price, this script turns the chart area into a compact game field where two AI controlled paddles rally a moving ball from one side to the other while the score updates in real time.
The script is designed as a visual and technical showcase of what Pine Script can do with custom objects such as boxes, lines, labels, arrays, and user defined types. It demonstrates persistent state handling, frame by frame physics updates, collision detection, automatic paddle control, scoring logic, and motion trail rendering, all inside a chart overlay.
The left and right paddles are both controlled by simple AI logic. Each paddle reacts to the vertical position of the ball and tries to align itself for the next return. The ball bounces off the top and bottom boundaries, changes direction when it touches a paddle, and resets to the center when one side misses. A trail effect is also added to make movement easier to follow and visually more dynamic.
What makes this script interesting is that it is not simply drawing static shapes. It maintains a persistent game state across updates, modifies that state on every bar, and redraws the field using live object coordinates. This makes it a playful but technically instructive example of animation and object control in Pine Script.
In practical terms, this script is a creative visual project rather than a trading tool. It is useful for demonstrating real time state management, chart object animation, and game style logic inside PulseWire.
🔹 Features
🔸 Fully Automated Gameplay
Both paddles are controlled automatically. The script continuously tracks the ball position and moves each paddle vertically to intercept the ball without user input.
🔸 Persistent Game State
The script uses a dedicated game state object to store ball position, paddle positions, scores, trail points, and drawing references. This allows the whole game to evolve smoothly over time.
🔸 Ball Physics and Collision Logic
The ball moves with its own horizontal and vertical velocity, bounces off the top and bottom walls, reacts to paddle contact, and changes its vertical angle depending on where it hits the paddle.
🔸 Score Tracking
If one paddle misses the ball, the opposing side scores a point. The ball then resets to the center and starts a fresh rally with directional variation.
🔸 Paddle AI With Speed Limits
Each paddle follows the ball using its own maximum movement speed. This gives the game a natural chase behavior and prevents instant teleport style motion.
🔸 Motion Trail Effect
The ball leaves a fading trail behind it using a sequence of stored points and prebuilt lines. This improves visual clarity and gives the movement a smoother arcade feel.
🔸 Custom Game Field Rendering
The play area is drawn with a background box, two paddle lines, a circular ball label, a score label, and trail segments. Everything is positioned relative to the current bar index.
🔸 Chart Overlay Animation
The game is drawn directly over the chart with overlay=true , which turns the chart into a moving visual canvas.
🔹 Calculations
1) Defining the Game Geometry and Core Constants
var int GAME_WIDTH = 80
var float GAME_HEIGHT = 100.0
var float PADDLE_H = 20.0
var float BALL_SPD_X = 1.8
var float BALL_SPD_Y = 1.2
var int TRAIL_LEN = 10
var float AI_SPEED_1 = 1.1
var float AI_SPEED_2 = 1.2
This block defines the full physical layout and motion parameters of the game.
GAME_WIDTH sets the horizontal size of the play area.
GAME_HEIGHT sets the vertical size.
PADDLE_H defines paddle height.
BALL_SPD_X and BALL_SPD_Y define the initial ball speed.
TRAIL_LEN defines how many trail segments are stored.
AI_SPEED_1 and AI_SPEED_2 define how quickly each paddle can move.
So before any gameplay starts, the script already establishes the dimensions and motion rules of the whole arena.
2) Defining the Point and Game State Objects
type Point
float x
float y
type GameState
float ball_x
float ball_y
float ball_vx
float ball_vy
float p1_y
float p2_y
int p1_score
int p2_score
box bg_box
line p1_line
line p2_line
label ball_lbl
label score_lbl
array trail_pts
array trail_lines
This is the structural foundation of the script.
The Point type stores one coordinate pair. It is used for the trail system.
The GameState type stores the full live state of the game:
the ball position,
the ball velocity,
the vertical positions of both paddles,
both scores,
the main drawing objects,
and the trail arrays.
This design is important because the script is not just drawing shapes independently. It is managing a complete game world through one persistent object.
3) Creating the Visual Objects on the First Bar
method init_drawings(GameState state) =>
state.bg_box := box.new(na, na, na, na, border_color=color.new(color.gray, 60), border_width=1, bgcolor=C_BG)
state.p1_line := line.new(na, na, na, na, color=C_P1, width=4)
state.p2_line := line.new(na, na, na, na, color=C_P2, width=4)
state.ball_lbl := label.new(na, na, "", color=C_BALL, style=label.style_circle, size=size.small)
state.score_lbl := label.new(na, na, "0 - 0", color=color.new(color.white, 100), textcolor=color.silver, style=label.style_none, size=size.large)
This method creates the core objects that will later be updated every frame.
The script builds:
a background box for the game field,
a line for the left paddle,
a line for the right paddle,
a circular label for the ball,
and a score label.
These are created only once, then reused and repositioned as the game evolves. This is much more efficient than deleting and recreating everything on every update.
4) Preparing the Ball Trail System
for i = 0 to TRAIL_LEN - 1
color fade_color = color.new(C_BALL, 100 - int((TRAIL_LEN - i) * 100 / TRAIL_LEN))
state.trail_lines.push(line.new(na, na, na, na, color=fade_color, width=2))
state.trail_pts.push(Point.new(state.ball_x, state.ball_y))
This loop initializes the trail effect.
For each trail slot, the script creates:
a line object with progressively changing transparency,
and a point initialized at the current ball position.
The idea is simple. The newest trail segments remain more visible, while older trail segments fade away. This creates the illusion of motion persistence behind the ball.
So the trail is not a single effect. It is a chain of stored points and lines that move along with the ball.
5) Updating Ball Position Each Frame
method update_physics(GameState state) =>
state.ball_x += state.ball_vx
state.ball_y += state.ball_vy
This is the first step of the physics engine.
On every update, the ball position is advanced by its horizontal and vertical velocity values. This is the basic motion rule of the game.
If nothing else happened, the ball would keep moving in a straight line forever. The rest of the physics method exists to modify that path through AI movement, wall bounces, paddle collisions, and scoring resets.
6) Left Paddle AI Logic
if state.ball_vx < 0
if state.p1_y + PADDLE_H/2 < state.ball_y
state.p1_y += math.min(AI_SPEED_1, state.ball_y - (state.p1_y + PADDLE_H/2))
else if state.p1_y - PADDLE_H/2 > state.ball_y
state.p1_y -= math.min(AI_SPEED_1, (state.p1_y - PADDLE_H/2) - state.ball_y)
This block controls the left paddle.
The paddle only reacts when the ball is moving toward the left side, which is why the script first checks:
state.ball_vx < 0
Then it compares the ball’s vertical position to the top and bottom edges of the paddle. If the ball is above the paddle center zone, the paddle moves upward. If the ball is below it, the paddle moves downward.
The amount of movement is limited by AI_SPEED_1 , which prevents the paddle from moving instantly.
So the left paddle behaves like a simple tracking AI that tries to align itself with incoming ball position.
7) Right Paddle AI Logic
if state.ball_vx > 0
if state.p2_y + PADDLE_H/2 < state.ball_y
state.p2_y += math.min(AI_SPEED_2, state.ball_y - (state.p2_y + PADDLE_H/2))
else if state.p2_y - PADDLE_H/2 > state.ball_y
state.p2_y -= math.min(AI_SPEED_2, (state.p2_y - PADDLE_H/2) - state.ball_y)
This is the mirror logic for the right paddle.
It only moves when the ball is traveling toward the right side. It uses the same tracking idea as the left paddle, but its maximum speed is set independently by AI_SPEED_2 .
That means each side can have slightly different behavior and difficulty characteristics.
8) Keeping Paddles Inside the Arena
state.p1_y := math.max(PADDLE_H/2, math.min(GAME_HEIGHT - PADDLE_H/2, state.p1_y))
state.p2_y := math.max(PADDLE_H/2, math.min(GAME_HEIGHT - PADDLE_H/2, state.p2_y))
After paddle movement is updated, the script clamps both paddles so they cannot leave the top or bottom of the field.
The center of each paddle must remain between:
PADDLE_H/2
and
GAME_HEIGHT - PADDLE_H/2
This ensures that the visible paddle body never extends outside the game frame.
9) Ball Bounce on Top and Bottom Walls
if state.ball_y >= GAME_HEIGHT
state.ball_y := GAME_HEIGHT
state.ball_vy := -state.ball_vy
else if state.ball_y <= 0
state.ball_y := 0
state.ball_vy := -state.ball_vy
This block handles vertical wall collisions.
If the ball reaches or exceeds the top boundary, its vertical position is snapped to the top edge and its vertical velocity is reversed.
If the ball reaches or drops below the bottom boundary, the same thing happens at the lower edge.
This creates a classic arcade bounce effect where the ball reflects off the horizontal walls and stays inside the arena.
10) Left Side Paddle Collision and Right Side Scoring
if state.ball_x <= 0
if math.abs(state.ball_y - state.p1_y) <= PADDLE_H/2 + 3
state.ball_x := 0
state.ball_vx := -state.ball_vx
state.ball_vy += (state.ball_y - state.p1_y) * 0.15
state.ball_vy := math.max(-4.0, math.min(4.0, state.ball_vy))
else
state.p2_score += 1
state.ball_x := GAME_WIDTH / 2
state.ball_y := GAME_HEIGHT / 2
state.ball_vx := BALL_SPD_X
state.ball_vy := BALL_SPD_Y * (state.p2_score % 2 == 0 ? 1 : -1)
This is one of the main gameplay blocks.
When the ball reaches the left boundary, the script checks whether the ball is close enough to the left paddle vertically. If yes, it counts as a successful return.
On a successful return:
the ball is snapped to the left edge,
its horizontal velocity is reversed,
and its vertical velocity is modified based on where it hit the paddle.
This extra adjustment is important because it creates angled returns rather than perfectly repetitive motion. The farther from the paddle center the hit occurs, the more the vertical speed is changed.
The vertical speed is then clamped between negative four and positive four to keep the game stable.
If the left paddle misses, the right side scores a point. The ball resets to the center, moves back toward the right, and gets a vertical direction that alternates based on score parity.
11) Right Side Paddle Collision and Left Side Scoring
else if state.ball_x >= GAME_WIDTH
if math.abs(state.ball_y - state.p2_y) <= PADDLE_H/2 + 3
state.ball_x := GAME_WIDTH
state.ball_vx := -state.ball_vx
state.ball_vy += (state.ball_y - state.p2_y) * 0.15
state.ball_vy := math.max(-4.0, math.min(4.0, state.ball_vy))
else
state.p1_score += 1
state.ball_x := GAME_WIDTH / 2
state.ball_y := GAME_HEIGHT / 2
state.ball_vx := -BALL_SPD_X
state.ball_vy := BALL_SPD_Y * (state.p1_score % 2 == 0 ? 1 : -1)
This is the mirror version of the left side logic.
When the ball reaches the right boundary, the script tests whether the right paddle is in position. If it is, the ball bounces back left and its vertical speed changes according to impact location. If not, the left player scores and the ball resets to center.
Together, the left and right boundary blocks define the full rally and scoring logic of the game.
12) Updating the Trail Memory
state.trail_pts.unshift(Point.new(state.ball_x, state.ball_y))
state.trail_pts.pop()
After the new ball position is resolved, the script stores it at the front of the trail point array. Then it removes the oldest stored point from the end.
This gives the script a rolling history of recent ball positions. Those points are later used to position each trail segment.
So the trail always follows the newest motion path while keeping a fixed length.
13) Converting Game Coordinates Into Chart Coordinates
method draw_frame(GameState state, int base_x) =>
int right_x = base_x + 5
int left_x = right_x - GAME_WIDTH
This method begins the rendering step.
The game is not drawn in a separate graphics window. It is projected directly onto chart coordinates. The current bar index acts as the base anchor, and the script defines a right edge slightly ahead of it. From that right edge, it subtracts the game width to get the left edge.
So the whole game field is mapped into a section of chart space that moves with the current bar position.
14) Drawing the Background and Paddles
state.bg_box.set_lefttop(left_x, GAME_HEIGHT)
state.bg_box.set_rightbottom(right_x, 0)
state.p1_line.set_xy1(left_x, state.p1_y + PADDLE_H/2)
state.p1_line.set_xy2(left_x, state.p1_y - PADDLE_H/2)
state.p2_line.set_xy1(right_x, state.p2_y + PADDLE_H/2)
state.p2_line.set_xy2(right_x, state.p2_y - PADDLE_H/2)
This block updates the main field and the paddle drawings.
The background box spans from the left edge to the right edge and from zero to the full game height.
The left paddle is drawn as a vertical line on the left boundary.
The right paddle is drawn as a vertical line on the right boundary.
Each paddle extends above and below its center position by half the paddle height. That makes the paddle length consistent and easy to manage mathematically.
15) Drawing the Ball and the Score
state.ball_lbl.set_xy(left_x + int(math.round(state.ball_x)), state.ball_y)
state.score_lbl.set_xy(left_x + GAME_WIDTH/2, GAME_HEIGHT - 10)
state.score_lbl.set_text(str.tostring(state.p1_score) + " - " + str.tostring(state.p2_score))
This block positions the moving ball and updates the scoreboard.
The ball label is placed by adding the ball’s internal game x coordinate to the left boundary of the field. Its y coordinate is the current ball height.
The score label is placed near the top center of the arena and updated with the current left and right scores.
So every frame, the game communicates both live motion and match progress.
16) Drawing the Motion Trail
for i = 0 to TRAIL_LEN - 1
Point p1 = state.trail_pts.get(i)
Point p2 = i + 1 < TRAIL_LEN ? state.trail_pts.get(i + 1) : p1
line l = state.trail_lines.get(i)
l.set_xy1(left_x + int(math.round(p1.x)), p1.y)
l.set_xy2(left_x + int(math.round(p2.x)), p2.y)
This loop converts stored trail points into visible trail segments.
For each trail slot, the script reads one point and the next point after it. Then it updates the corresponding trail line so it connects those two positions.
Because the trail lines were created with different transparency levels earlier, the newest segments appear stronger and older segments fade out.
This gives the ball a continuous motion streak that makes gameplay easier to follow visually.
17) Persistent State Initialization
varip GameState state = GameState.new(
ball_x = GAME_WIDTH / 2,
ball_y = GAME_HEIGHT / 2,
ball_vx = BALL_SPD_X,
ball_vy = BALL_SPD_Y,
p1_y = GAME_HEIGHT / 2,
p2_y = GAME_HEIGHT / 2,
p1_score = 0,
p2_score = 0,
trail_pts = array.new(),
trail_lines = array.new()
)
This block creates the persistent live game state.
The ball starts in the center of the arena.
Both paddles start in the vertical center.
Both scores start at zero.
Empty arrays are prepared for the trail points and trail lines.
The use of varip is important here because it keeps the game state persistent as the script updates, allowing the game to evolve continuously rather than resetting each time.
18) First Bar Initialization and Main Update Loop
if barstate.isfirst
state.init_drawings()
state.update_physics()
state.draw_frame(bar_index)
This is the main execution flow.
On the very first bar, the script creates all required drawings through init_drawings() .
After that, every update performs two steps:
first the game physics are advanced,
then the new state is rendered onto the chart.
This is the standard game loop pattern:
update state,
then draw state.
19) Invisible Plot Anchors
plot(100, color=color.new(color.white, 100))
plot(0, color=color.new(color.white, 100))
These invisible plots help stabilize the vertical scale for the game area.
Because the whole arena is designed between zero and one hundred on the y axis, plotting hidden values at those levels ensures the script keeps a consistent vertical drawing space.
This is a subtle but important implementation detail. Without it, the game objects could be compressed or mispositioned by automatic scaling behavior.
20) Practical Interpretation
Auto Play Ping/Pong is best understood as a Pine Script animation and state management demo rather than as a market analysis indicator. Its real value comes from showing how chart objects, arrays, persistent state, and update logic can be combined to create a living visual system inside PulseWire.
The script demonstrates:
state persistence,
object reuse,
basic game physics,
simple AI motion,
collision handling,
score management,
and visual effects such as motion trails.
That makes it a strong example for anyone exploring creative Pine development, chart animation, or non traditional overlay design. Indicator
PongExperience PONG! The classic arcade game, now on your charts!
With this indicator, you can finally achieve your lifelong dream of beating the Markets. . . at PONG!
Pong is jam-packed with features! Such as:
2 Paddles
A moving dot
Floating numbers
The idea of a net
This indicator is solely a visualization, it serves simply as an exercise to depict what is capable through PineScript. It can be used to re-skin other indicators or data, but on its own, is not intended as a market indicator.
With that out of the way...
> PONG
The Pong indicator is a recreation of the classic arcade game Pong developed to pit the markets against the cold hard logic of a CPU player.
Given the lack of interaction that is capable, the game is not played in the typical sense, by a player and computer or 2 players.
This version of Pong uses the chart price movements to control the "Market" Paddle, and it is contrasted by a (not AI) "CPU" Paddle, which is controlled by its own set of logic.
> Market Paddle
The Market Paddle is controlled by a data source which can be input by the user.
By default (Auto Mode), the Market Paddle is controlled through a fixed length Donchian channel range, pinning the range high to 100 and range low to 0. As seen below.
This can be altered to use data from different symbols or indicators, and can optionally be smoothed using multiple types of Moving Averages.
In the chart below, you can see how the RSI indicator is imported and smoothed to control the Market Paddle.
Note: The Market Paddle follows the moving average. If not desired, simply set the "Smoothing" input to "NONE".
> CPU Paddle
In simple terms, the CPU Paddle is a handicapped Aimbot.
Its logic is, more or less, "move directly towards the ball's vertical location".
If it were allowed to have full range of the screen, it would be impossible for it to lose a point. Due to this, we must slow it down to "play fair"... as fair as that may be.
The CPU Paddle is allowed to move at a rate specified by a certain Percent of its vertical width. By default, this is set to 2%.
Each update, the CPU Paddle can advance up or down 2% of its vertical width. The directional movement is determined based on the angle of the ball, and it's current position relative to the CPU Paddle's position. Given that it is not a direct follow, it may at times seem more... "human".
When a point is scored, the CPU paddle maintains its position, similar to the original Pong game, the paddles were controlled solely by the raw output of the controllers and did not reset.
> Ball
At the start of each point, the ball begins at the center of the screen and moves in a randomly determined angle at its base speed.
The direction is determined by the player who scored the last point. The loser of the last point "serves" the ball.
Given the circumstances, serving is a gigantic advantage. So the loser serving is just another place where the Market is given an advantage.
The ball's base speed is 1, it will move 1 (horizontal) bar on each update of the script. This speed can "technically" increase to infinity over time, if given the perfect rally. This is due to the hit logic as described below.
Note: The minimum ball speed is also 1.
> Bonk Math
When the ball hits a paddle, essentially 3 outcomes can occur, each resulting in the ball's direction being changed from positive to negative.
Action A: Its angle is doubled, and its speed is doubled.
Action B: Its angle is reversed, and its speed is decreased if it is going faster than base speed.
Action C: Its angle is preserved, and its speed is preserved. "Basic Bounce"
Each paddle is segmented into 3 zones, with the higher and lower tips (20%) of the paddles producing special actions.
The central 60% of each paddle produces a basic bounce. The special actions are determined by the trajectory of the ball and location on the paddle.
> Custom Mode
As stated above, the script loads in "Auto Mode" by default. While this works fine to simply watch the gameplay, the Custom Mode unlocks the ability to visualize countless possibilities of indicators and analyses playing Pong!
In the chart below, we have set up the game to use the NYSE TICK Index as our Market Player. The NYSE TICK Index shows the number of NYSE stocks trading on an uptick minus those on a downtick. Its values fluctuate throughout the day, typically ranging between +1000 and -1000.
Therefore, we have set up Pong to use Ticker USI:TICK and set the Upper Boundary to 1000 and Lower Boundary to -1000. With this method, the paddle is directly controlled by the overall (NYSE) market behaviors.
As seen in a chart earlier, you can also take advantage of the Custom Mode to overlay Pong onto traditional oscillators for use anywhere!
> Styles
This version of Pong comes stocked with 5 colorways to suit your chart vibes!
> Pro Tips & Additional Information
- This game has sound! For the full experience, set alerts for this indicator and a notification sound will play on each hit!*
*Due to server processing, the notification sounds are not precisely played at each hit. :(
- In auto mode, decreasing the length used will give an advantage to the market, as its actions become more sporadic over this window.
- The CPU logic system actually allows the market to have a "technical" edge, since the Market Paddle is not bound to any speed, and is solely controlled by the raw market movements/data input.
- This type of visualization only works on live charts, charts without updates will not see any movement.
- Indicator sources can only be imported from other indicators on the same chart.
- The base screen resolution is 159 bars wide, with the height determined by the boundaries.
- When using a symbol and an outside source, be mindful that the script is attempting to pull the source from the input symbol. Data can appear wonky when not considering the interactions of these inputs.
There are many small interesting details that can't be seen through the description. For example, the mid-line is made from a box. This is because a line object would not appear on top of the box used for the screen. For those keen eye'd coders, feel free to poke around in the source code to make the game truly custom.
Just remember:
The market may never be fair, but now at least it can play Pong!
Enjoy! Indicator
Tic Tac Toe Game [TradeDots]Feeling bored with trading?
Time to inject some fun into your decision-making process with our Tic Tac Toe Indicator!
The Tic Tac Toe game transforms your chart into a competitive playground where trading pairs face off in a classic game of Tic Tac Toe.
HOW TO PLAY
Our Tic Tac Toe game invites you to pit one trading pair against another directly on your chart. Choose the competitors and watch as they battle it out in a traditional grid setup.
Navigate to settings and select your competitor pair.
Choose who kicks off the game.
After the close of each new bar, the algorithm will utilize the closing prices of both symbols. These numbers feed into a random number generator which alternates the turns for placing marks on the grid.
The game progresses until one pair aligns three consecutive symbols and wins, or the board fills up. After that, the game resets every three bars, offering continual engagement during active market hours.
MANUAL PLAYING MODE
Currently, due to PineScript's limitations, a fully interactive manual mode is not supported, as all previous data will be lost with each new user input, preventing the replication of existing game states.
However, users can input a sequence at the start, guiding the placement of symbols throughout the game.
Stay tuned for future updates! Indicator
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
Word PuzzleWord Puzzle is a PineScript-based clone of the popular daily puzzle game called "Wordle".
It is not identical, but the general gameplay is the same.
>How It works (The Game)
A secret word (also referred to as the "target word") is randomly selected from a database of 5 Letter words.
The player/user's goal is to guess that word within 6 attempts.
After each guess, the script provides information to the user by color coding the letters of their guess.
Green (Known Letters): These letters are in the exact spot that they occur in the target word.
Yellow (Included Letters): These letters are included in the target word; however, the user does not have them in the correct position.
Gray (Un-used Letters): These letters do not occur anywhere in the target word
>Interface
On each turn the user will input their 5 letter guess into the "Guess #" box and submit it by checking the check-box next to the word.
If the input word is invalid, the script will prompt you. Invalid words are any words not found within the script's valid word list.
After guess 3, hints may be viewed by hovering over the "Need a Hint" box on the display.
If you are unable to guess the word in the given amount of guesses, the 'Game Over' screen will display, and you will be able to view the answer in the same box as the hints.
To start a new game, clear all inputs and insert a different number into the "Puzzle Seed" input, to have the script randomly select a new word.
NOTE: Word selection based on the seed number is deterministic, the same seed number will always have the same puzzle word.
>Additional Information
The script comes equipped with 5 different themes as seen below.
Table size is also selectable.
This indicator makes use of 'tooltips'.
Hover over the boxes on the table for quick reference information or additional information on prompts.
Since the script randomly selects from the ENTIRE valid word list you are bound to come across some obscure words with strange spellings.
Because of this, I have built in a "quick way out".
To end a game without filling out all guesses, submit the answer "Give Up" to skip to the end screen where you can reveal the puzzle's answer.
Afterwards, take a second to look up the definition! Ever heard of a xylyl?!
The code is fully notated. Most of the script involves string management, but there are still some neat tricks in here as well.
Enjoy! Indicator
Library
Library
Library
3D BowlingIntroducing the "3D Bowling Game" – a fun and interactive demo scene project in Pine Script, powered by a custom 3D engine! This bowling game showcases the potential of Pine Script for developing engaging and immersive experiences, even within the confines of a trading platform.
To play the game, you'll first be prompted to choose where you want to throw the ball. Next, you'll be asked to draw a line indicating the direction you want the ball to go. Sit back and enjoy as the game takes care of the rest!
The source code features various sections, including:
Types and helper functions to manipulate vectors, matrices, and angles
Routines for calculating cross products, dot products, and vector normalization
Transformation matrices for rotation and scaling
Functions for perspective transformation, mesh transformations, and face normal calculations
Culling and shading algorithms to provide a more realistic visual experience
The project's source code is an excellent starting point for anyone interested in exploring the capabilities of Pine Script beyond the typical trading indicators and strategies. The 3D Bowling Game demonstrates the flexibility of Pine Script and its potential for creating interactive experiences in a seemingly unconventional environment.
So, what are you waiting for? Dive into the source code, tweak it to your liking, or build upon it to create your own interactive 3D experiences. Enjoy the game, and happy coding!
With light. I will say there is an issue with the fact that you cant draw as may linefills as you can lines.
Indicator
Indicator
