"Client Agnostic" is a common concept in software development, especially prominent in the creation of web applications, services, or APIs. It describes a way of designing and developing software that allows the software to operate across different client environments without needing specific adjustments or optimizations for each environment. In short, "Client Agnostic" software is compatible with any client or device, whether mobile devices, desktop browsers, or any other form of client application. Next, let’s dive into into the idea of Client Agnostic has been propelled through various stages of the internet.

Client Agnostic Approach in Web Apps:

The surge in demand for mobile web apps drove the maturation of cross-platform front-end frameworks. The rise of mobile devices began in 2007 with the launch of the first iPhone and App Store by Apple, followed by Google releasing the Android system and Play Store in 2008. HTML5 was released in 2010, enhancing the functionality of mobile web applications. That same year, the Ionic framework was launched, aimed at developing mobile applications using web technologies. Facebook released React in 2013, followed by the introduction of the React Native framework for building native mobile applications. At this stage, as users shifted from desktop computers to mobile devices, there was an urgent market need for applications to run on different devices without the need for customized modifications. The maturity of front-end frameworks perfectly met this need, enabling developers to more conveniently create applications that run across platforms.

In Web3, data is public and accessible without specific permissions. The current trend involves embedding business logic and object states into protocols, while providing open user interfaces. This contrasts with Web2 products that consider user data as a private asset, showcasing a more forward-thinking philosophy of Web3. Instead of exploiting user data for profit, Web3 applications tend to create robust and vibrant protocols to drive ecosystem growth. Here are two examples:

Liquity and Its Frontend Operators:

Liquity is a decentralized lending protocol that allows for interest-free loans against Ether collateral. Loans are paid out in LUSD, a stablecoin pegged to the US dollar, with a minimum collateral ratio of 110%. As a protocol, Liquity is non-custodial, immutable, and governance-free.

Frontend operators provide a web interface for users to interact with the Liquity protocol, earning LQTY token rewards generated by users. Rewards are distributed to stability pool depositors and operators, with the proportion determined by the rebate rate set by the operators. A high rebate rate attracts users, but a quality interface and additional features can lower the rebate rate while maintaining user interest.

In the context of Web3 games, before diving deep into the "Client Agnostic" concept within Web3 game protocols, let's take "Fortnite" as an example to dissect the concepts of client, server, and client game engine in Web2 games. Such comparison can help us better understand the main differences in technology and architecture between fully on-chain games and traditional games.

"Fortnite" is a popular multiplayer online game developed by Epic Games, attracting millions of players worldwide since its release in 2017. The game is known for its unique building elements, vibrant graphics, and multiplayer modes, consisting of three main modes: PvE "Save the World," PvP "Battle Royale," and the player-created "Creative" mode. Notably, "Fortnite" supports cross-platform play, allowing players from different platforms to play together on the same server. As a large-scale multiplayer online game, the interaction between client and server is key to the game's smooth operation. Here's a simplified example describing how client and server interact in "Fortnite":

Client Operations:

1. Receive Player Actions: Actions performed by the player on the client (such as moving, shooting, building, etc.) are sent as requests to the server. These requests include the type of action and relevant parameters (such as direction, target location, etc.).

Server Operations:

1. Validation and Calculation:

   • Validation: Upon receiving operation requests from the client, the server first verifies the legality of these actions to ensure they comply with game rules.

   • Calculation: After validation, the server calculates the results of the actions based on game logic, including updating player states (position, health, etc.) and the impact of actions on the game world (such as building creation, damage calculation for enemies, etc.).

2. Broadcast Updates:

   • The server sends the results of the actions back to the client of the player who performed the action, as well as to other clients that might be affected by the action. This ensures all players see a consistent state of the game world.

3. Handle Conflicts:

   • In multiplayer games, the server uses timestamps and other mechanisms to handle potential action conflicts, ensuring fairness and consistency in the game.

4. Maintain Game State Continuity:

   • The server continuously processes player actions and updates the game state, including managing the triggering of in-game events, changes in game areas, etc., to ensure the smooth progression of the game.

Client Operations (Continued):

1. Client Rendering:

   • Upon receiving update messages from the server, the client updates the local game state and re-renders the game scene to reflect the latest situation in the game world.

Fortnite's Client Game Engine:

"Fortnite" is developed by Epic Games using their own Unreal Engine, renowned for its powerful graphics capabilities and cross-platform compatibility, making it highly suitable for developing visually demanding games. Unreal Engine supports multi-platform development, including PC, consoles, and mobile devices, enabling "Fortnite" to deliver an exceptional gaming experience across a wide range of devices.

The Unity game engine, also known for supporting cross-platform development, covers PC, consoles, mobile devices, and VR/AR among others. It is recognized for its ease of use and flexibility, offering developers a wealth of features and tools to create games ranging from simple to complex. Unity's cross-platform capability ensures games can be rapidly deployed to different platforms without the need to rewrite extensive code for each one. The cross-platform development capabilities of Unreal and Unity highlight the maturity of traditional game engines in terms of multi-platform compatibility and development efficiency.

Web3 Game Protocols (Autonomous World Protocols):

MUD:

The MUD engine is a framework designed for building complex Ethereum applications, aiming to allow developers to focus on the core functionalities of their applications by providing conventions for organizing data and logic and abstracting away low-level complexities. By standardizing on-chain data storage, MUD facilitates the synchronization between contracts and client state.

Currently, the MUD engine includes the following five core components:

1. Store: An on-chain database.

2. World: An entry-point framework providing standardized access control, upgrades, and modules.

3. tools: Rapid development tools based on Foundry.

4. Client Data Storage: Mirrors on-chain state in real-time.

5. MODE: A Postgres database supporting SQL queries.

Argus:

Argus is a customized L2 solution featuring basic sharding and personally customizable game shards. Along with the World Engine (a proprietary game engine), game developers can create unique execution environments using custom parameters. They also offer an auto indexer similar to those found in other game engines, encouraging game development in Go. The Cardinal Shard is the company's inaugural game shard implementation, boasting 20 ticks per second, comparable to traditional games.

After understanding the design architectures of MUD and Argus, it's clear that both are committed to maintaining compatibility with existing game clients. In terms of server logic design, MUD and Argus have explored different paths.

During its development, MUD prioritized addressing the complexities of data access through smart contracts, thereby adopting IStore (a storage interface) for real-time indexing of on-chain data. This approach significantly enhances the flexibility of clients when reading data. Despite this, MUD chose to store data on the Ethereum blockchain.

Meanwhile, Argus opted for a different strategy, not utilizing the Ethereum Virtual Machine (EVM) for storing object states. Instead, it stores all states within its own World Engine, allowing developers to access these states via API calls. Argus believes that a tick-driven runtime system is better suited to the needs of fully on-chain games.

Overall, both MUD and Argus strive for compatibility with existing game clients but have adopted different technical routes in backend logic and state storage. MUD enhances client flexibility through real-time indexing of on-chain data, while Argus supports API-based calls through state management within its World Engine, considering this approach more aligned with fully on-chain game characteristics.

Fully On-chain Game Innovation: Reshaping Game Content and Ecosystem Labor Division

The explorations made by MUD and Argus are incredibly grand and exciting. They essentially build a broad protocol with the aim of enabling other game developers to create new content based on their protocol framework. In the realm of blockchain games compared to traditional Web2 games, the concept of game content and its components exhibit significant differences. In the traditional gaming environment, game content typically refers to all the elements and materials that constitute the gaming experience, such as storyline, characters, graphics, music, interface design, level design, gameplay mechanics, etc. These elements work together to provide players with a complete, immersive gaming experience.

In contrast, blockchain games—a new type of game—have a much clearer division of content. A key feature of blockchain games is that their game logic runs entirely on smart contracts, making the boundary between the server-side part (including game characters, token economy system, and game logic) and the client-side part (such as graphics, sound, and user interaction interfaces) very distinct. The server-side focuses mainly on the core logic and economic system of the game, while the client-side is responsible for presenting the game content and interacting directly with players.

This division results in a high degree of composability, allowing the game client and game server sides to develop and innovate independently of each other. As demonstrated in the DeFi sector by front-end providers like Liquity, there could also emerge specialized game client providers in the blockchain game domain. This development would allow blockchain game developers to concentrate on the design of on-chain logic and token economies, while game client providers focus on developing the game's interaction interface and user experience.

The evolution from Web2 applications to Web3 decentralized applications (DApps) is not primarily about a fundamental change in user experience. For example, although the model adopted by Liquity’s front-end operators has not revolutionized the user experience for Liquity, it does symbolize a significant shift in the division of labor within the ecosystem. Such a transformation is almost impossible to achieve robustly within traditional Web2 applications. Imagine if Bank of America were to open its banking system APIs, allowing external developers to create products that attract users to deposit money and earn a share of the profits—this is nearly unthinkable in traditional models. However, such transformations are highly likely to occur in the blockchain gaming domain.

Following the same logic, while blockchain games may not necessarily surpass traditional games in terms of fun, a transformation in the division of labor between the client and server sides is expected to occur in blockchain games as well. This innovation in division of labor means that blockchain game developers can focus on building on-chain logic and token economies, while game client providers dedicate themselves to developing interfaces that enhance user experience. This not only promotes specialization and innovation but also brings more possibilities and diversity to the entire gaming ecosystem.

Overall, I firmly believe that the client-agnostic concept, following the advent of decentralized applications (DApps), will also bring significant changes to the gaming field. As for when? I do not know.