PROJECT FEATURES
Curiosity Web Game
March 2026 | Internal Documentation
1. Overview
The system is designed to contain a total of one billion small cubes distributed across multiple layers. Each layer represents a stage in the game, and players must collaboratively or competitively destroy all visible cubes on a layer before progressing to the next one.
The project combines elements of gaming, economy systems, and real-time interaction, with a strong focus on engagement, competition, and monetization.
2. Core Concept and Structure
The fundamental structure of the game is based on a "cube within a cube" model. The outermost layer is a large cube composed of smaller individual cubes arranged across its six faces. Each face contains a grid of cubes, forming a complete 3D structure.
When players interact with the game, they are only able to destroy cubes on the surface of the current active layer. Once all cubes on that surface are destroyed, the outer layer is considered complete, and a smaller cube inside becomes visible and interactive.
This process continues layer by layer until reaching the final cube, which represents the end of the game cycle.
The total number of cubes across all layers is fixed at one billion. These cubes are not necessarily stored individually in the system but are logically generated and managed using efficient data structures.
3. Gameplay Mechanics
Players enter the game on the outermost layer. The primary interaction is clicking or tapping on cubes to destroy them. Each cube represents an opportunity to earn rewards.
By default, every player has access to a basic tool that allows them to destroy one cube per interaction. As players progress, they can acquire more advanced tools that increase efficiency by destroying multiple cubes at once.
Each cube destroyed contributes to:
- Progression of the current layer
- Earning in-game currency (blocks)
- Chance-based rewards such as monetary value
🎉 Prize Visuals & Real-Time Counters: Whenever a player earns a prize or reward while playing, the system must:
- Display an animated visual effect on-screen at the moment of the reward (e.g., floating coin/prize animation over the destroyed cube).
- Show a real-time counter that updates immediately as rewards accumulate — the counter must not wait for a page reload or a polling interval. It must reflect the current state instantly as the player plays.
- This real-time feedback is critical for engagement and must be powered by WebSocket events rather than periodic HTTP polling.
The gameplay loop is continuous and consists of:
- Entering the current active layer
- Destroying cubes using tools
- Earning rewards
- Completing the layer
- Unlocking the next inner layer
The final stage is reached when the smallest cube (single unit) is destroyed.
4. Tools System
The tools system is a core gameplay mechanic that directly impacts player efficiency and engagement.
Each player starts with a default tool that is free and allows destruction of a single cube per action. More advanced tools can be purchased using in-game currency.
Tools vary in their functionality. Some tools affect only a single cube, while others can destroy an area or even a volume of cubes. For example, a bomb tool may destroy a 3x3 area on a cube face, significantly accelerating progress.
Each tool is defined by the following attributes:
- Name
- Cost (in blocks)
- Damage type (single, area, volume)
- Damage size (e.g., 3x3)
- Visual representation (icon)
- Time Limit — each tool has a usage duration (e.g., 1 hour, 24 hours). Once the duration expires, the tool is deactivated and must be repurchased.
All tools are fully configurable through the admin dashboard. Administrators can create, update, or remove tools at any time, allowing flexibility in balancing the gameplay.
🕐 Tool Time Limits: Tools are no longer permanent. Each tool purchase grants access for a limited time period defined by the admin (e.g., 1 hour, 12 hours, 7 days). After expiry, the tool becomes inactive and the player must purchase it again. This encourages recurring spending and prevents long-term advantage accumulation.
💳 Tool Purchase Options: In addition to purchasing tools using in-game blocks, players can also purchase tools directly using online payment (Visa, Mastercard, etc.). Both payment options are available simultaneously, giving players the flexibility to choose how they want to acquire tools.
🔴 Real-Time Tool Availability: When an administrator adds or updates a tool from the admin dashboard, the new tool must appear in real-time for all active users without requiring a page refresh. This will be implemented via WebSocket push notifications from the server to all connected clients.
5. Economy System
The game economy is divided into two main components: blocks and money.
Blocks (In-Game Currency)
Blocks are the primary currency used within the game. Players earn blocks by destroying cubes. The amount earned per cube may vary based on game balancing rules.
Blocks are used to:
- Purchase tools
- Unlock advantages
- Participate more efficiently in gameplay
Players can also purchase blocks using real money through integrated payment systems such as Visa or Mastercard.
Money (Reward Value)
Money represents a secondary value system tied to real-world equivalent rewards. This value is hidden inside certain cubes and is distributed randomly across each layer.
Each layer has a predefined prize pool configured by the administrator. When players destroy cubes, they have a chance of uncovering a portion of this prize pool.
This system introduces a gambling-like excitement mechanic while still maintaining fairness through controlled distribution.
Money is used for:
- Leaderboards
- Competitions
- Potential real-world rewards or payouts
6. Layer System
The layer system is automatically generated and managed by the system. The total number of layers is determined based on achieving the one billion cube target.
Each layer is defined by its size and number of cubes. As players progress, layers become smaller, increasing difficulty and competition.
Administrators do not manually create each layer. Instead, the system dynamically generates layers based on predefined logic.
Layer Configuration
Layers can be configured with the following parameters:
- Prize pool (total money distributed)
- Reset schedule (daily, weekly, or custom intervals)
🎯 Prize Distribution Algorithm: Instead of the admin manually setting prize values per layer, the system must use an automated prize distribution algorithm. The admin sets a total prize budget, and the algorithm distributes prizes across all layers following this rule:
- Outer layers (early game) receive lower prizes to encourage players to keep progressing.
- Inner layers (deeper/later game) receive higher prizes, rewarding dedication and creating a strong incentive to keep playing.
- The distribution follows a progressive curve (e.g., exponential or weighted linear), ensuring that the deeper a player goes, the bigger the potential reward.
- The admin can tune the distribution curve (e.g., mild vs. steep progression) rather than setting individual layer prizes manually.
This design encourages long-term engagement by making deeper layers significantly more rewarding than surface-level play.
When a layer reset occurs:
- All cubes regenerate
- The prize pool is reset
- Player progress on that layer is cleared
- Leaderboards may optionally reset
This ensures continuous gameplay and recurring engagement.
7. Social and Competitive Features
The game includes multiple social and competitive components designed to increase user retention and engagement.
Leaderboards
Players are ranked based on their performance. Rankings can be based on:
- Total money earned
- Total cubes destroyed
- Activity within a specific layer
Leaderboards can be displayed in real-time, creating a competitive environment.
8. Admin Dashboard
The admin dashboard is a critical part of the system, providing full control over game configuration and monitoring.
Tool Management
Administrators can:
- Create new tools
- Modify existing tools
- Delete tools
- Configure tool behavior
Layer Management
Administrators can:
- Set prize pools
- Configure reset schedules
- Monitor real-time progress
Analytics
The system provides real-time analytics, including:
- Active users within specific time windows (5, 15, 30 minutes)
- Total registered users
- Total revenue generated
- Total cubes destroyed
- Player balances
- Leaderboard data
These analytics are essential for business decisions and game balancing.
9. Anti-Cheat System
Due to the competitive and monetary nature of the game, anti-cheat mechanisms are essential.
Rate Limiting
The system enforces a maximum number of actions per second per user to prevent automated abuse.
Pattern Detection
The system monitors user behavior to detect repetitive patterns, such as identical clicks at consistent intervals, which may indicate bot usage.
Input Validation
For web-based gameplay, the system requires mouse movement before accepting clicks. This ensures that interactions are human-generated.
🤖 CAPTCHA Verification
To further protect against bots and automated abuse, a CAPTCHA challenge will be presented to users at the beginning of each session (and optionally after detecting suspicious behavior patterns). This adds a human-verification gate before gameplay begins, significantly reducing the risk of bot exploitation.
Future Enhancements
An energy system may be introduced to limit continuous actions. This system would require players to wait for energy regeneration, further reducing abuse.
10. Transaction and Payment System
The system includes a complete transaction management module.
All financial and in-game transactions are logged, including:
- Block purchases
- Tool purchases
- Rewards earned
Payments are processed through secure payment gateways supporting major card providers.
The system ensures:
- Data integrity
- Secure processing
- Full auditability
11. Technical Considerations
Due to the scale of the system, performance and scalability are critical.
The system must avoid storing one billion individual cube records. Instead, it should rely on:
- Procedural generation
- Compressed data structures
- Chunk-based updates
Real-time updates should be handled using technologies such as WebSockets or similar event-driven systems.
📡 WebSockets for Real-Time Communication: The system must use WebSockets as the primary real-time communication protocol — replacing any approach based on frequent HTTP GET polling. This applies to:
- Real-time prize counters and reward feedback during gameplay
- Live leaderboard and stats updates at the bottom of the screen
- Admin tool changes pushed instantly to all connected users
- Any other live state that currently relies on periodic polling
Polling-based approaches introduce latency, are inaccurate, and create unnecessary server load. WebSockets provide accurate, low-latency, bidirectional communication essential for a real-time game of this scale.
The backend architecture should support high concurrency and be optimized for rapid state updates.
12. Known Bugs 🐛
The following bugs have been identified and must be addressed in the next development cycle.
The real-time counters displayed at the bottom of the screen are not accurate. They do not reflect the true current state and may lag behind or display stale data. This is likely caused by the current polling-based approach.
When an administrator adds a new tool from the admin dashboard, active users do not see the new tool until they manually refresh the page.