PROJECT FEATURES

Curiosity Web Game

Concept Vision

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:

The gameplay loop is continuous and consists of:

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:

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.

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:

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:

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

Each layer can be configured with the following parameters:

When a layer reset occurs:

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:

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:

Layer Management

Administrators can:

Analytics

The system provides real-time analytics, including:

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.

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:

Payments are processed through secure payment gateways supporting major card providers.

The system ensures:

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:

Real-time updates should be handled using technologies such as WebSockets or similar event-driven systems.

The backend architecture should support high concurrency and be optimized for rapid state updates.