Tower Rush Bangladesh methodology for tests and score calculation

Identify the original before comparing results

The original is Tower Rush by Galaxsys, an HTML5 game built around an individual tower and the Build and Cashout controls.

The official demo uses game ID 90 and the technical game name TowerRush. Tower Rush 2 and Tower Rush Branded are separate products and do not inherit the original's score or session results.

Configuration checks come before numerical comparisons. The provider's game card gives an RTP range of 96.2–97.6%; the official FUN rules give 96.17–97%; the 1win BDT configuration used in the worked session has 96.69%. These figures describe different scopes. Taking the highest number and applying it to every launch would erase a material condition.

The record connects a stake to its settlement through the round identifier and retains the conditions needed to interpret it:

• Game identity and configuration.
• Demo or cash mode, with the correct unit or currency.
• Device, browser or application container, and software version.
• Account country, action and resulting balance.

An operator application's version identifies its container; it does not become the version of the HTML5 game inside it.

The game comparison covers eight distinct Galaxsys game configurations, including the original and seven alternatives. These eight entries form an analytical selection, not a count of an operator's entire catalogue.

Calculate the game score with TR-GAME-1.0

TR-GAME-1.0 combines rules, controls, demo access, stability and reproducibility of the maths. Each game in the comparison is scored on all five criteria at the stated weights. A higher mark means a stronger result for that criterion on the 0–10 scale. Neither an individual mark nor the total is a probability of winning.

Criteria, weights and the 7.75 calculation

The original earns 8 for rules, 8 for controls, 9 for demo, 8 for stability and 4 for mathematical reproducibility. Each mark is multiplied by its percentage weight expressed as a decimal, then the contributions are added.

The calculation is 8 × 0.30 + 8 × 0.25 + 9 × 0.15 + 8 × 0.20 + 4 × 0.10 = 7.75.

Round the final sum to the nearest 0.01 using half-up: when the discarded part is exactly half a hundredth, round upwards. Here the sum already has two decimal places, so rounding leaves it unchanged.

What the five marks measure

Rules carry the largest weight because they define what an action does to the stake and accumulated payout. The assessment covers ordinary building, collapse and the payout cap. Frozen Floor, Temple Floor and Triple Build each have a different effect. The explanation must connect each effect to the single round's settlement, beyond describing its animation.

Controls concern the usable actions and the state they act upon: the stake field, Build, Cashout, currency indicator and history.

Demo access covers the official FUN entry without an operator account or deposit, together with the available controls and three explained bonus-floor mechanisms. These features support the demo's 9/10 mark.

Stability includes interactive loading and recovery of the same accepted round after a connection interruption.

Reproducibility of the maths addresses outcome distributions and the procedure linking fairness inputs to the outcome. Its 4/10 is the weakest component; a successful payment or a matching balance does not substitute for that separate mathematical assessment.

Galaxsys calls the game feature Provable Fairness. Checking an accepted stake against history and one resulting credit is a settlement check. Reproducing a cryptographic result is a different operation. The fairness explanation follows that distinction, so the score does not imply that a cashout receipt verifies an entire fairness protocol.

Keep the test unit and sample boundary visible

The unit counted in a game-session sample is one paid, settled individual tower. Extra floors and repeated button presses do not increase the count. Neither does another player's history or a replayed server response. Demo units and money stay in separate ledgers, with deposits, refunds and balance resets distinguished from game payouts.

Four FUN towers and thirteen BDT towers

I completed four towers in the official mobile demo on the Xiaomi 15 Ultra, starting with 100,000 FUN and staking 100 FUN per tower. Their payouts were 232, 0, 45 and 38 FUN. Three towers returned something. Only one returned more than its stake. That difference is why the method records both payout frequency and profitable-round frequency.

Opening a new independent demo session restored the closing balance of 99,915 FUN to 100,000 FUN through an 85 FUN reset adjustment, which remains separate from game payouts and cannot become a BDT deposit or an external cash withdrawal.

In the 1win session, I completed 13 paid towers at a fixed 380 BDT stake through the operator's Android launcher, without activating a welcome bonus. The session lasted 582 seconds from the first accepted stake to final settlement. Gross payouts totalled 5,149 BDT against 4,940 BDT in stakes, producing a game result of +209 BDT.

Observed return is gross payouts divided by total stakes, multiplied by 100. Here, 5,149 ÷ 4,940 × 100 gives 104.2308%. It describes these thirteen outcomes. The configuration's theoretical RTP remains 96.69%; the profitable session does not replace that parameter or predict the next tower.

The same care applies to the denominator of a frequency: nine positive payouts out of thirteen towers include outcomes that returned less than the stake. Seven towers were profitable. A percentage calculated from floors instead of towers would answer a different question. See RTP and game mathematics for the fuller numerical treatment.

Follow money through settlement and external receipt

A cash-session record follows the payer's debit through the credited deposit, stakes, gross payouts, withdrawal and remaining casino balance, retaining each fee's operation and charging basis while separating the game result from transfers between accounts.

For the same 1win route, I deposited 3,040 BDT through bKash, received 1,900 BDT through Nagad and left 1,349 BDT in the casino. Both recorded fees were zero. The reconciliation is 1,900 + 1,349 − 3,040 = +209 BDT. The remaining casino balance is part of that calculation, not money already received outside the account.

The withdrawal took 27 minutes 03 seconds from request to external receipt, including the relevant processing stages. Identity and address documents were accepted before approval. Those are the conditions and result of this account's route; a later request, another payment method or a different account requires its own record.

Bonus events also settle once. In a separate FUN example, Frozen Floor protected 500 FUN and a later Cashout reached 1,000 FUN: the payout was 1,000 FUN, not 1,500. A returned void stake is a refund. A cancelled withdrawal releases a reservation. None is counted as a second win.

Measure readiness and recovery as different tests

Loading time ends when the stake field, Build and the FUN or currency indicator are active together. A splash screen is not that endpoint. I measured five cold and five warm launches of the official demo on the Xiaomi 15 Ultra in Chrome over the same Wi-Fi connection; the cold series cleared game data, while the warm series retained the cache.

Cold launches ranged from 4.60 to 5.20 seconds, with a 4.90-second mean and median. Warm launches ranged from 2.00 to 2.40 seconds, with a 2.20-second mean and median. All ten launches succeeded. The connection measured 74.6 Mbit/s down, 26.3 Mbit/s up and 34 ms round-trip latency; the separate Grameenphone 4G environment is not pooled with it.

In a separate recovery test, I restored the same accepted round after 18 seconds without a connection and completed Cashout, with no duplicate credit when the response repeated.

That incident remains distinct from the ten loading attempts, and their zero-error result applies only to those attempts.

Device coverage also includes Safari on an iPhone 15 Pro and desktop browser checks on a Slimbook EVO 14. Mobile orientation, desktop history and an Android launcher are different test conditions; results are not silently combined into one universal device benchmark.

Separate operator access from game quality

TR-ACCESS-1.0 evaluates the selected operator route in its own account country and currency. The main Bangladesh comparison covers 1win, Stake, 1xBet, Melbet, Parimatch and CroreBet in BDT, with their cash sessions kept separate from welcome offers. Eligible cash routes are scored on all six criteria. Their stated weights total 100%, and each applies in full when the route covers all six. The game’s five-criterion score stays separate.

For example, the 1win route has marks of 8, 5, 8, 8, 8 and 8, producing 7.40/10 under these weights. That result measures the route's convenience. It is neither the original game's 7.75/10 nor a legal-reliability score. Equal access totals are ordered first by the lower fee percentage, then by the shorter complete withdrawal time.

An excluded country or blocked access stays outside the monetary comparison even if a demo opens successfully, without reallocating the payment weight to turn that one success into a full-route score.

Deposit sizes in different currencies are not ranked as though they were directly comparable amounts.

Third-party Safety Index figures retain their own source and scale. They are not averaged into TR-GAME or TR-ACCESS. Likewise, a control simulation with a defined outcome distribution explains that model; its results do not become observed Tower Rush rounds or inferred probabilities for individual floors. Use the operator comparison for the route-specific results.

Match each claim to the right evidence

Each evidence type answers a different question:

• Provider rules establish the game mechanisms.
• Operator conditions establish account and cashier terms.
• Ariful Hosain's hands-on records establish what happened in his tests.
• Calculations retain their inputs and assumptions.
• Third-party descriptions retain their attribution and do not become the author's personal tests.

The rating identifies its model version, criteria and weights so the result can be recalculated without changing the method between rows.

When checking a difference, first identify whether the game, configuration, account, operation or model changed. A different value in another scope does not automatically invalidate either result.

Send a correction to the responsible person

Ariful Hosain is the author, analyst and responsible publisher of Tower Rush Bangladesh, an information site about the game and access conditions with no active affiliate agreement or paid placement.

To report a factual error:

1. Identify the page and exact passage.
2. Explain the issue and the basis for the correction.
3. Send those details to [email protected].

The publisher's response period is seven days. Keep a disputed casino payout with the operator's support route; the complaints and support guide distinguishes it from an error in the site's text.

The licensing and legal-context guide explains supplier and operator authorisations and their scope.

Read the author profile for Ariful Hosain's experience, or return to the Tower Rush overview. Use the model name, test unit and account conditions together whenever you interpret a score.