Open platform - the evolution of interactive gameplay

1. Background

As the scale of live broadcast business and users grows, how to enrich the content of the live broadcast room, enhance the user interaction effect in the live broadcast room, and improve revenue data has become more critical. For this reason, live interactive gameplay came into being. Through barrages, gifts, likes, navigation, etc., users can participate in the live broadcast content of the anchor. Bilibili also provides strong technical support to third-party manufacturers and developers through an open platform, making live interactive gameplay more convenient, stable and efficient, creating more fun and value for users and anchors.

Picture: Star Studio interactive gameplay case

2. Platform construction

Before embarking on development, we need to establish clear business boundaries, especially the open platform interactive gameplay business involving multi-party participation. This helps avoid cumulative problems and ensures that future development is not constrained by historical debt.

Our business division mainly focuses on several core scenarios and capability modules:

• Developer management platform: interact with developers, including entry process, application review, gift and panel review. As a display outlet for developers' data, it provides them with support for data recycling.
• App store platform: Interact with anchors, including display and acquisition of applications on the platform and live broadcasters. Provide an outlet for customized application recommendation algorithms to increase application exposure and appeal.
• Application interaction platform: interact with users in the live broadcast room and use the event platform for control, including switching gifts and panels. Data flow and other behaviors during interactive gameplay. Monitor and mark the real-time status of applications to ensure a smooth user experience.
• Settlement platform: interacts with revenue, including statistics, storage and reconciliation of revenue data during the application period. To ensure transparency and accuracy, complete settlement support is provided.

Therefore, we designed the following business module layering:

Figure: Platform architecture

3. Project life cycle

Figure: Life cycle of interactive gameplay

The principle of community first ensures that the evolution and improvement of our platform is a good strategy centered on the needs of developers and users. After clarifying the business boundaries, we focus on four core improvement goals around the entire life cycle of Huiwan. superior:

• Developer entry efficiency and rights protection: By simplifying the entry process and providing clear documentation and support, we ensure that developers can quickly and smoothly access the platform. Provide a fast and accurate review mechanism to accelerate application launch and promote the rapid development of the ecosystem. Provide clear revenue methods and a complete reconciliation system to ensure developers' profits.
• Anchor experience: Provide intuitive and easy-to-use tools and functions to enhance the coverage and interactivity of the anchor and improve the quality of live broadcasts.
• Live broadcast room user experience: Optimize the live broadcast room interface and lower the threshold for user participation. Provide interesting and diverse interactive gameplay to stimulate users' enthusiasm for participation and improve user stickiness.
• Platform management and control capabilities: Strengthen the management and supervision of content to ensure the legality and safety of the content. Provide a wealth of tools to quickly respond to violations and maintain the safety and health of the platform ecosystem.

3.1 Settlement and development

In the entire interplay life cycle, developer access to the platform and development are the starting point, and the threshold will directly affect the number of developers and the supply speed of interplay. There are some issues that we need to think about and solve:

• How can developers quickly build models?
• How can developers conduct data interactive debugging at low cost?
• How can individual developers design gifts in the absence of professional gift UI designers?

3.1.1 SDK&Demo

We understand that understanding something often starts with "what it is", and then we can understand "why it is so". As a developer who is accessing an open platform for the first time, it does take time to understand the many APIs and call documents and sort out a clear interaction process. At the same time, because developers have different historical development backgrounds, their understanding of official access documents will also be different.

In order to reduce developers' development costs and ease the answer pressure of R&D, while improving the official technical documentation, we have provided examples in different languages ​​to help developers build conceptual models:

• Unity&C# client SDK
• Python&Growing Demo

Figure: Interactive gameplay connected to SDK&Demo

3.1.2 Start debugging capability

The testing phase is an indispensable and important link in the complete application development process. Applications that have not been fully tested may have potential unpredictable risks. In order to assist developers to conduct sufficient and complete testing before the application is put on the shelf, we The following two issues were solved:

Q: How do developers test application functions in a real environment after application development is completed?

A: Before the application passes the review, developers can choose to set their live broadcast room as a whitelist live broadcast room, which means that developers can conduct complete testing and functional regression of their developed applications in a real online environment.

Q: Giving gifts, sending eye-catching messages, and sailing are important components of interactive gameplay. How should these interactive operations be debugged in the online environment?

A: It is obviously unreasonable for developers to conduct a large number of tests using normal processes in an online environment due to the high-cost behavior of users participating in these types of live broadcast rooms. To solve this problem, we provide developer debugging tools. Through this tool, developers can actively trigger the content of long-connected messages sent by the open platform through background operations (including barrages, gifts, large voyages, and eye-catching messages). The process from operation to exporting messages is guaranteed by the platform side. Correctness.

Figure: Developer debugging tools

3.1.3 Official material library

In the early days of the interactive gameplay system, developers needed to manually design and upload gift materials, which not only increased the developer's research and development costs, but also increased the difficulty and cost of operational review, leading to chaotic material management. In order to solve this problem, we provide developers with a more convenient solution: the official material library.

Now, developers only need to select suitable content from the official library and submit to create a gift. This solution greatly improves business standardization and reduces design costs and audit costs. It creates a more orderly and unified environment for the entire interactive gameplay system and promotes ecological sustainable development.

At the same time, in order to ensure that the gifts in the official material library meet user needs, we will conduct regular user surveys. The official material library will also be updated regularly to add new gift elements and themes to meet the changing needs and interests of users.

Picture: Official gift material library

3.2 Submission and review

3.2.1 Package management tools

When the interactive gameplay project is reviewed and the package needs to be uploaded, how to effectively avoid being regarded as a network disk service? At this time, we can use the single point failure theory to think in reverse.

Single point failure theory: There is one or a few key components, links or nodes in the system. If any one of them is damaged, malfunctions or fails, it may lead to the collapse or failure of the entire system.

We can find its exclusive single point of failure by analyzing the usage path of the platform as a network disk:

1. Get upload link
2. upload files
3. Perform persistent storage
4. download file

Without affecting the normal business logic, we will deal with step 3, add prerequisites for persistent storage, raise the storage threshold, control the determination of valid files from a business perspective, and regularly scan and delete invalid packages.

At the same time, this problem commonly occurs in various business scenarios of open platforms, so we built a package management system to uniformly handle this business scenario.

Figure: Package life cycle management

3.2.2 Operational audit tools

We can audit by analyzing the usage path of using the platform as a network disk:

• Is the content of the interactive gameplay compliant and is there any sensitive content?
• Does the interactive gameplay calling mode comply with the open platform specifications?

As an operator, you can only perform compliance verification on the interactive gameplay content during the review process. Therefore, we provide operations with basic compliance verification tools to verify the package body and provide an audit basis for operations.

This tool needs to meet two conditions at the same time:

• Monitor service requests for open platforms
• Statistics interface call frequency

In the early stage of technical research, I wanted to use a packet capture tool to analyze the data, monitor the 443 port traffic of https requests, and filter out the relevant requests with the host "live-open.biliapi.com" from the traffic, that is, open platform-related requests. .

Figure: Monitoring port traffic

After testing, because the packet capture tool intercepted the data at the transport layer of the seven-layer protocol, the request data based on the https protocol was encrypted, and the specific request content could not be obtained. Condition 2 was not met, so the plan was rejected.

Figure: Packet capture results

In order to obtain the details of the interface call, there are two data sources, the caller and the callee. When statistical logic cannot be forced to be inserted into the caller's code, the focus is on the callee. However, it is obviously unreasonable for the online server to be used for test statistics.

If the real online environment cannot be used, consider using a simulated sandbox environment. At this time, the proxy forwarding solution is ready to come out. The general idea is as follows:

1. The user changes the local host configuration and points the domain name of the open platform to localhost.
2. Start a proxy service locally and listen on port 443
3. The local agent is responsible for forwarding requests related to "live-open.biliapi.com" and recording the interface call results.
4. Outputs the call results when the local service is closed.

Figure: Sandbox agent process

Figure: Test results

3.3 Use and settlement

3.3.1 Identity code system

The use of interactive gameplay is strongly bound to the live broadcast room. Therefore, when the interactive gameplay is turned on, the gameplay client needs a way to associate with the current live broadcast room. Based on this problem, we have considered the following two approaches:

Provide method	Advantage	Disadvantages
After turning on the interactive gameplay, the host enters the room number	Low threshold for use, can be used on OBS	Low security, anchors can start interactive gameplay in other people’s live broadcast rooms
Read the anchor's login status and pass the room number	In security, anchors cannot enable each other.	The threshold for use is high and can only be used on Live Broadcast Ji. Developers can enable interactive gameplay in any room

When the disadvantages of the above two methods are unacceptable, we need a new transmission method of room number identification, and it must meet the following requirements at the same time:

• Without relying on the login status of Live Broadcaster, anchors can still enable interactive gameplay when using other live broadcast tools.
• Anchors are agnostic to each other. Anchors cannot start other anchors’ applications through a public identifier.
• Developer agnostic, gameplay developers cannot obtain the application of any anchor

Therefore, we have launched a set of independent identifiers (i.e. identity code system). The anchor can generate a unique identifier and bind it to the room number, and it is invisible to others in the public domain, ensuring that the information between anchors and between anchors and developers is isolated. , the interaction with the open platform is carried out through the identity code, and the open platform performs data conversion. At the same time, in order to avoid security issues caused by the leakage of the identity code, it provides scheduled refresh and manual forced refresh capabilities to ensure data compliance and security.

3.3.2 Interactive settlement

Sharing the revenue generated by interactive gameplay with developers is the key to building a good cooperation model. However, if you only use the interaction startup time as the basis for calculation, it may lead to unreasonable results, because revenue behaviors such as captains and eye-catching messages generated during the startup period will be included in the calculation.

In order to solve this problem, we proposed a calculation basis that is closely related to interactive gameplay: interactive gifts. Each interactive gameplay has its own specific gifts, and we only count the revenue generated by interactive gifts. This can accurately reflect the actual contribution of interactive gameplay and avoid interference from other irrelevant factors.

By using interactive gifts as the basis for turnover calculation, we hope to establish a more fair, transparent and closely related sharing mechanism that is closely related to interactive gameplay, thus motivating more developers to participate. This can not only increase the enthusiasm of developers, but also help form a healthy and positive interactive ecosystem.

Since the sharing ratios of different interactive gameplay are different and can be adjusted in real time, this brings challenges to our management and perception. In order to effectively respond to these changes, we need to establish a settlement system that is closely related to the company's internal settlement system.

Figure: Settlement structure

At the same time, in order to protect the rights and interests of the company and developers, we need to conduct reconciliation work, which mainly includes the following two dimensions:

• Real-time reconciliation: During the operation of the interactive gameplay, a real-time reconciliation system is established to track and verify the flow of each transaction in real time so that possible problems can be discovered and resolved in a timely manner.
• Daily reconciliation: Daily reconciliation is a supplement to real-time reconciliation and is also the final verification before issuing daily bills. Through daily reconciliation, we can ensure the accuracy and completeness of the reconciliation.

Figure: Settlement and reconciliation process

3.4 Monitoring and feedback

In the iterative maintenance process of an open platform interactive gameplay system, it is crucial to ensure the security and robustness of the system. In the face of various uncertainties, noise and changes, ensuring the basic ability of the system to remain stable under these conditions is a major factor. Considering that the callers of the interactive gameplay system are all external developers, we need stricter control measures compared to the company's internal business.

Going online is not the end of the interactive gameplay life cycle. We have taken a series of measures to continuously track and monitor the system, provide feedback on system bugs, and limit or ban malicious calls to ensure that the platform operates efficiently or in extreme circumstances. Reduce operation.

Here are some of the measures we take:

• Security center system: In order to prevent malicious requests from sudden traffic, we will connect the relevant interfaces of the mutual play to the unified security control center of the open platform. Callers that exceed the preset limit will be banned for a period of time, and as the number of triggers increases, the ban time will gradually be extended. The related construction of the security center can be discussed separately in the future.
• Monitor the market and data statistics: In addition to sudden traffic, frequent erroneous requests from developers are also common problems. We report statistics when requested and connect the data to the company's monitoring platform for real-time observation and statistics. This helps reduce alarm noise while increasing sensitivity to problems.
• Online problem feedback: For bugs in the interactive gameplay, we provide a special feedback channel for the host. Through regular robot synchronization, the operation team can promptly feedback problems to developers, thereby achieving rapid location and resolution of problems.

Figure: Monitor the market

4. Future prospects

The interactive gameplay of Station B is still in the development and improvement stage. We have gone through the exploration stage from 0 to 1, and combined with the open platform system to complete the construction and establishment of the full link. However, in the development process from 1 to 100, compared with competing products in the market, we still need to continue to evolve and explore.

The challenges we face include the following aspects:

• Insufficient real-time data analysis capabilities: During the interactive gameplay process, our real-time data analysis capabilities are insufficient. Strengthening data early warning analysis capabilities can help us discover potential problems in a timely manner and make corresponding adjustments.
• The commercialization system needs to be improved: we need to improve the consumption power of users in the live broadcast room, and at the same time deeply explore the potential commercial value of the vast number of users in the live broadcast room. Improving the commercialization system will help increase revenue sources and increase user participation.
• Think ahead and build system stability: As the number of interactive games on the shelves and the number of anchors used expands, we need to think ahead and continue to think about and implement the stability of the system. This includes continuous optimization of technology and processes to ensure system stability and user experience.

In the face of these challenges, through continuous efforts and innovation, we believe that we can continuously optimize the interactive gameplay system to better meet user needs and make it stand out in the market.