najoast / everything

基于 issue 的个人知识库，转载一些即将消失的个人Blog，或自己的一些技术类笔记。People die, but long live GitHub!

大家好，我是提奥(Theo)

👨🏻‍💻  关于我

一个喜欢玩游戏，也喜欢做游戏的程序员。从红白机到街机，再到网吧/PC/Steam，一路玩游戏长大的。

以前喜欢玩MMORPG，玩的比较久的有奇迹/奇迹世界/天下贰，玩的没那么久但也投入过真情实感的：剑网3/魔兽世界。其他浅尝则止的：征途/QQ幻想/热血江湖/QQ寻仙/大话西游/梦幻西游/问道/等等…… （我列这个干嘛，好像以前出来过的游戏就没有不玩的）

长时间玩过的非MMORPG还有QQ飞车，QQ音速等，QQ飞车玩到了96级左右。哦，对了，还有暗黑3和炉石传说，炉石最高打到传说，千胜德鲁伊，花的时间感觉有上万小时吧，千胜…… 懂得都懂。

页游/手游时代玩的很多很杂，好多都记不清了，一些印象深刻的：七雄争霸/神仙道/魔卡幻想/我叫MT1和2/剑与远征/War Eternal/不休的乌拉拉/出发吧麦芬……

现在年纪大了，MMORPG有点玩不动了，当然近几年也没出过什么好的。现在喜欢在 Steam 玩 Roguelike，只要是有点名气的基本都玩：杀戮尖塔/吸血鬼幸存者/土豆兄弟/小丑牌(Balatro)/Backpack Battles/...

玩游戏玩得多了，就想自己做，所以经常会在脑子里构思一些独立游戏的 idea，在业余时间会尝试着去制作，但因为本职工作是后端，前端并不熟悉，所以做起来有点费劲。

但梦想总是有的，工作之余经常做些小游戏练手，未来打算组建一个3～4人的小团队，正式开始我的游戏制作之旅，我在团队里的角色会是策划+后端。

以前我想做中国的暴雪，但自从暴雪腐烂后，已经不以他们为目标了。现在比较欣赏心动，跟我的游戏制作理念高度一致：

• 聚匠人心，动玩家情。
• 不以赚钱为目的，只为做好玩的游戏，游戏做好了，挣钱是水到渠成的事。即是心动所说的：挣玩家的打赏钱。

My slogan: Make Fun Games!

🛠  Tech Stack

• 💻  
• 🎮  
• 🌐  
• 🛢  
• ⚙️  
• 🔧  

everything's Issues

Docker 环境下给 Flarum 安装 LDAP 插件

1 安装

1.1 添加 php 的 ldap 扩展

在 docker-compose.yml 内添加如下信息：

    environment:
      - PHP_EXTENSIONS=ldap

添加位置：

version: "3"

services:
  flarum:
    image: mondedie/flarum:stable
    container_name: flarum
    environment:
      - PHP_EXTENSIONS=ldap
    env_file:
      - /root/docker/flarum/flarum.env

1.2 重启容器

重启容器，使新添加的 php ldap 插件生效。
在终端输入以下命令（必须在 docker-compose.yml 目录）：

docker-compose down
docker-compose up -d

1.3 给 flarum 添加 ldap 插件

在终端内执行以下命令：

docker exec -ti flarum extension require tituspijean/flarum-ext-auth-ldap

2 在管理面板中激活

1. 进入网站后，使用 admin 账号登陆，点击右上角头像，点击 Administration 进入管理面板。
2. 在管理面板左侧 FEATURES 内找到 LDAP login，点击进入。
3. 点击 Disable 切换到打开状态。

3 配置 LDAP

激活后在下方填入 LDAP 的所有配置。

配置说明：

• LDAP server name: sets the end of the Login with link at the top of the forum: image
• LDAP domains or server IP adresses (comma separated): list of LDAP servers to use.
• Base DNs (semicolon separated): list of base DNs to search users in.
• Filter to apply (optional): Additional filtering, for example require users to be in a specific group.
• Port: LDAP server port
• Follow referrals, Use SSL, Use TLS: LDAP server settings
• LDAP admin distinguished name and LDAP admin password (leave empty for anonymous binding) : if needed, specific the DN and password of the user allowed to perform searches in the LDAP server.
• LDAP user search fields (comma separed): list of the LDAP fields used to look for the users. The extension will try all combinations of base DNs and search fields.
• LDAP user mail field: name of the field containing the user's email address. The extension will use the first email found for the user's registration in Flarum.
• LDAP username field: name of the field containing the username that uniquely identifies the user. Can be uid or sAMAccountname, for example.
• Disable Flarum login and only use LDAP authentication: merely hides the standard login links and buttons. Users can still use the standard login method through the API.

相关链接

• https://flarum.org
• https://github.com/mondediefr/docker-flarum?tab=readme-ov-file#install-custom-extensions
• https://extiverse.com/extension/tituspijean/flarum-ext-auth-ldap

幻兽帕鲁 GM 命令

官方文档：https://tech.palworldgame.com/server-commands

使用方法

1. 在 PalWorldSettings.ini 的 AdminPassword 里填上你想要设置的密码。
2. 在游戏的聊天窗口内输入 /AdminPassword 你的密码 进行 GM 身份验证。
3. 验证通过后就可以使用 GM 命令了。

GM 命令列表

命令	说明
/Shutdown {Seconds} {MessageText}	服务器将会在倒计时 Seconds 秒后关闭，并会向全服通知 MessageText 消息。
/DoExit	强制停止服务器。
/Broadcast {MessageText}	向服务器中的所有玩家发送消息。
/KickPlayer {SteamID}	将指定玩家从服务器中踢出。
/BanPlayer {SteamID}	封禁指定玩家。
/TeleportToPlayer {SteamID}	传送到目标玩家的当前位置。
/TeleportToMe {SteamID}	目标玩家传送到您当前的位置。
/ShowPlayers	显示所有在线玩家的信息。
/Info	显示服务器信息。
/Save	保存世界数据。

What is Long Polling?

What is long polling?

Long polling is used in real-time web applications to achieve near-instantaneous communication between the client and the web server. It is particularly useful in chat and messaging applications where real-time updates are crucial.

In traditional HTTP communication, the client sends a new request to the server and waits for a response. This is known as short polling. However, in real-time scenarios, short polling may not be efficient as it requires frequent requests to the server, resulting in unnecessary network overhead and increased latency.

On the other hand, long polling improves efficiency by keeping the request open for an extended period until new data is available. The server holds the request open and waits until it has new information to send back to the client. Once the server has new data, it responds to the client, which can then process the data and initiate a new long polling request.

By maintaining a long-lived connection between the client and the server, long polling reduces the number of requests, minimizes latency, and improves real-time communication. This makes it ideal in use cases that require an effective technique for building scalable and responsive chat and messaging applications as well as other apps that make use of real time data like games.

How does long polling work?

Long polling is a technique used in real-time communication to achieve near-instantaneous message delivery between clients and servers. It is particularly useful in building chat and messaging applications where low latency and real-time updates are crucial.

Traditionally, web browsers use a pull-based approach to fetch data from servers. The client sends a request to the server, which responds with the requested data. This approach, known as short polling, can create delays in communication as the client has to send requests to check for updates repeatedly.

On the other hand, long polling is a push-based approach that allows the server to send updates to the client as soon as they are available. Here's how it works:

1. The client initiates a request to the server, typically through an HTTP request.
2. Instead of immediately responding, the server holds the request open, keeping the connection active.
3. If no new data is available, the server waits until it has something to send back.
4. Once the server has new data or a predefined timeout occurs, it responds to the client with the latest information.
5. Upon receiving the response, the client immediately sends another request to the server to maintain the connection.
6. This cycle of sending requests and receiving responses continues, ensuring real-time updates.

Long polling effectively simulates a real-time connection between the client and the server by keeping the request-response cycle open for an extended period. It allows the server to push updates to the client as soon as they are available and eliminates the need for the client to check for updates repeatedly.

What technologies are used to implement long polling?

Long polling is a technique to achieve real-time communication between a client and server. It is commonly used in chat and messaging applications where instant updates are crucial. Several technologies can be used to implement long polling, each with advantages and considerations. Let's explore some of the common technologies used in implementing long polling.

HTTP long polling:

This is the most basic and widely used approach to implement long polling. It leverages the HTTP protocol to establish and maintain a long-lived connection between the client and server. The client sends a request to the server, and the server holds the request open until new data is available or a certain timeout is reached. Once new data is available, the server responds with the updated information, and the client immediately sends another request to continue the cycle. This approach is easy to implement and requires no special server-side technologies.

WebSocket:

WebSocket is a full-duplex communication protocol that enables real-time communication between the client and server over a single, long-lived connection. It provides a more efficient and low-latency alternative to long polling. WebSocket enables bidirectional data flow, allowing the client and server to send messages asynchronously. It eliminates the need for frequent HTTP requests and reduces network overhead. WebSocket is well-suited for applications requiring instant updates and real-time interaction.

Server-Sent Events (SSE):

SSE is a unidirectional communication technology that allows the server to push data to the client over a single, long-lived HTTP connection. With SSE, the server can send multiple updates to the client without requiring the client to make requests continuously. The server initiates the connection and sends data as a series of events. The client receives these events and can handle them as needed.

When choosing a technology for implementing long polling in your application, there are several factors to consider:

• Scalability: Ensure that the chosen technology can handle a large number of concurrent connections and can scale as the user base grows. WebSocket and SSE are generally more scalable than HTTP-based long polling, as they allow for more efficient use of server resources.
• Security: Consider the security implications of the chosen technology. WebSocket and SSE can be secured using encryption protocols such as SSL/TLS, ensuring data privacy and integrity. HTTP-based long polling can also be secured but may require additional authentication and access control measures.
• Browser support: Check the browser compatibility of the chosen technology. WebSocket and SSE have better browser support than HTTP-based long polling, which may require additional techniques or fallback options for older browsers.
• Implementation complexity: Evaluate the chosen technology's ease of implementation and maintenance. HTTP-based long polling is relatively simple, while WebSocket and SSE may require more advanced knowledge and infrastructure. Consider the level of expertise available in your development team and the resources required for implementing and maintaining the chosen technology.

Long polling vs. WebSockets

Long polling and WebSockets are techniques to achieve a real-time connection between a client (such as a web browser) and a server. Although they serve a similar purpose, the two have significant differences.

Long polling is a technique where the client makes a request to the web server, and the server keeps the connection open until it has new data to send back. The server may respond immediately if it has new data available or wait for a specified timeout period before sending an empty response. In either case, once the client receives the response, it immediately makes another request to the server to establish a new connection. This process repeats continuously, allowing the server to push updates to the client as soon as they become available.

On the other hand, WebSockets provide a persistent, bidirectional communication channel between the client and the server. Unlike long polling, where a new connection is established for every request, a WebSocket connection is established once and kept open indefinitely. This allows real-time, low-latency communication in both directions. The server can push data to the client anytime, and the client can also send data to the server without waiting for a response.

Similarities between long polling and Web Sockets:

1. Real-time updates: Both long polling and WebSockets enable real-time communication between the server and client, allowing instant updates without continuous polling or refreshing.
2. Reduced server load: Both techniques minimize unnecessary requests by only sending data when it is available, reducing server load and improving scalability.
3. Wide language and framework support: Many popular programming languages and frameworks support long polling and WebSockets, making them accessible to developers across different ecosystems.

Differences between long polling and Web Sockets:

1. Latency: Long polling introduces latency as there is a delay between the server sending a response and the client receiving it. WebSockets provide bidirectional, low-latency communication, allowing for faster real-time capabilities.
2. Resource consumption: Long polling requires the server to maintain open connections with each client, potentially causing resource consumption and limiting the number of concurrent connections. WebSockets, however, use a persistent connection, reducing the overall resource consumption.
3. Scalability: Long polling's need to keep connections open for an extended period can pose challenges for horizontally scaling the server. With their persistent connection, WebSockets allow for better scalability as they do not require many open connections.

Both long polling and WebSockets offer real-time updates and reduce server load, but they differ in latency, resource consumption, and scalability. Web sockets provide faster, bidirectional communication with reduced resource consumption, making them suitable for applications that require low latency and high scalability. On the other hand, long polling can be a good alternative when low latency is not critical, and the number of concurrent connections is relatively small. Developers should consider these factors when choosing between the two techniques for their real-time chat and messaging applications.

Long polling vs. Server-Sent Events (SSE)

SSE is similar to long polling in terms of its simplicity and ease of implementation, but it provides a more efficient and standardized way of achieving server-to-client communication. Let’s look at some additional similarities and differences between the two technologies.

Similarities between long polling and SSE:

1. Real-time updates: Both long polling and SSE enable real-time communication between the server and client, allowing instant updates without continuous polling or refreshing.
2. Reduced server load: Both techniques minimize unnecessary requests by only sending data when it is available, reducing server load and improving scalability.
3. Wide language and framework support: Many popular programming languages and frameworks support long polling and SSE, making them accessible to developers across different ecosystems.

Differences between long polling and SSE:

1. Latency: Long polling introduces latency as there is a delay between the server sending a response and the client receiving it. On the other hand, SSE provides a continuous stream of data from the server to the client, reducing latency and improving real-time capabilities.
2. Resource consumption: Long polling requires the server to maintain open connections with each client, potentially causing resource consumption and limiting the number of concurrent connections. SSE, however, uses a single long-lived connection, reducing the overall resource consumption.
3. Scalability: Long polling's need to keep connections open for an extended period can pose challenges for horizontally scaling the server. With its single connection per client, SSE allows for better scalability as it does not require many open connections.

How can you optimize long polling?

Long polling is used in real-time chat and messaging applications to provide near-instantaneous client updates. However, it can be resource-intensive and cause scalability issues if not optimized properly. Here are several techniques that can be used to optimize long polling for better performance and scalability.

Batched responses: Instead of sending a response for each request, batch multiple updates together and send them in a single response. This reduces the number of HTTP requests and helps to minimize the overhead.

Compression: Compressing the data before sending it over the network can significantly reduce the payload size, resulting in faster transmission and lower bandwidth consumption. Techniques like Gzip compression can be used to achieve this.

Caching: Implementing a caching layer can help reduce the load on the database or other data sources. By caching the frequently requested data, subsequent requests can be served from the cache itself, reducing the response time and improving scalability.

Connection pooling: Maintaining a pool of reusable connections instead of creating a new connection for every request can improve the efficiency of the long polling mechanism. This eliminates the overhead of establishing a new connection for each request, resulting in better performance.

Throttling and rate limiting: Implementing throttling and rate limiting mechanisms can prevent excessive requests from overwhelming the server. This ensures fair resource allocation and prevents abuse, improving performance and scalability.

Load balancing: Distributing the incoming requests across multiple servers using load balancing techniques can help distribute the load and prevent any single server from becoming overwhelmed. This improves the overall performance and scalability of the long polling system.

Monitoring and optimization: Regularly monitoring the performance of the long polling system and identifying any bottlenecks or areas of improvement can help optimize the system for better performance and scalability. Techniques like profiling, load testing, and performance tuning can be used to identify and address any performance issues.

Asynchronous (Async) processing: Offloading time-consuming tasks to asynchronous processes or background workers can help free up resources and improve the responsiveness of the long polling system. You can get this via message queues, worker processes, or distributed computing.

Connection timeouts: Implementing appropriate connection timeouts can help prevent idle connections from consuming unnecessary resources. By closing idle connections after a certain period of inactivity, the system can free up resources for other clients and improve scalability.

Scalable infrastructure: Ensuring the underlying infrastructure is scalable and can handle the expected load is crucial for optimizing long polling. This may involve using technologies like cloud computing, auto-scaling, or containerization to dynamically allocate resources based on demand.

What Programming Languages are Compatible with Long Polling?

Several programming languages are compatible with implementing long polling in real-time chat and messaging applications. Here are a few examples:

1. JavaScript: Long polling is commonly combined with JavaScript, allowing for seamless client-side implementation. JavaScript frameworks like React, Angular, and Vue.js provide libraries and tools that simplify implementing long polling in your application.
2. PHP: PHP is a popular server-side language often used in web development. It provides features and libraries that enable developers to implement long polling efficiently. The PHP framework Laravel, for example, offers support for long polling through its event broadcasting system.
3. Python: Python is another versatile language that can be used for implementing long polling. Python frameworks like Django and Flask provide the tools and libraries for building real-time applications using long polling techniques.
4. Ruby: Ruby is a dynamic, object-oriented programming language well-suited for web development. A popular web framework, Ruby on Rails, supports long polling through various libraries and extensions.
5. Java: Java is a widely used language in enterprise development and provides support for long polling. Java frameworks like Spring and Java EE offer libraries and tools for implementing long polling in real-time applications.
6. .NET/C#: The .NET framework, with its programming language C#, is commonly used for building web applications. It provides libraries and frameworks like ASP.NET SignalR that simplify the implementation of long polling techniques.

These are just a few examples of programming languages that support long polling. Many other languages and frameworks can also implement long polling in real-time chat and messaging applications.

When choosing a programming language for implementing long polling, there are a few factors to consider. First, consider the specific requirements of your application and choose a language that best fits those requirements. Consider scalability, performance, and ease of implementation on the backend.

Additionally, consider the community and ecosystem surrounding the programming language. A strong and active community can provide support, tutorials, documentation, and resources to make implementing long polling in your application easier.

How is long polling used in real-time applications?

One of the primary advantages of long polling is its efficiency in delivering real-time updates. Minimizing the number of requests sent by clients significantly reduces network latency and improves overall performance. Additionally, it allows servers to push updates to clients immediately, ensuring that messages and notifications are delivered promptly.

Furthermore, long polling facilitates scalability in real-time applications. Reducing the number of open connections enables servers to handle more concurrent clients. This is particularly crucial in chat and messaging applications, where the number of users constantly fluctuates.

Long polling helps save on system resources. With traditional polling, each request requires the server to process and respond, even without updates. This constant processing can strain server resources and negatively impact performance. In contrast, long polling only triggers server processing when new data is available or a timeout occurs. This minimizes the strain on system resources and allows for better scalability and reliability.

However, implementing long polling can also introduce some challenges. One challenge is managing server resources effectively. Since long polling involves keeping connections open for extended periods, handling multiple concurrent connections requires significant server resources. This can be addressed using technologies like cloud computing, auto-scaling, or containerization to dynamically allocate resources based on demand. By automatically scaling resources up or down based on the number of active connections, developers can ensure that the server can handle the expected load effectively.

Another challenge is handling timeouts and connection failures. In long polling, the server holds the request open until new data is available or a timeout occurs. If a timeout occurs, the server must handle it gracefully and close the connection to free up resources. Additionally, if a connection fails, the server should be able to detect it and handle reconnection attempts appropriately. By implementing robust error handling and connection management mechanisms, developers can ensure the reliability of long polling in real-time applications.

Security is another important consideration when implementing long polling in real-time applications. Since long polling involves maintaining persistent connections between clients and servers, it is crucial to secure these connections to protect sensitive data. Implementing secure socket layers (SSL) or transport layer security (TLS) protocols can help encrypt data transmitted over long polling connections and prevent eavesdropping or unauthorized access.

With over 15 points of presence worldwide supporting 800 million monthly active users and 99.999% reliability, you’ll never have to worry about outages, concurrency limits, or any latency issues caused by traffic spikes. PubNub is perfect for any application that requires real-time data.

Sign up for a free trial and get up to 200 MAUs or 1M total transactions per month included.

Source: https://www.pubnub.com/guides/long-polling/

在iTerm2中使用Zmodem传输文件

rz,sz命令传输文件，比使用scp要方便得多，特别是在图形界面打开终端，SSH登陆到远程机器需要传输文件的时候。但是MacOS里Terminal.app并不支持Zmodel传输。好在iTerm2具备较强的扩展性可以通过简单的配置支持Zmodem传输。

什么是Zmodem

Zmodem是针对modem的一种支持错误校验的文件传输协议。Zmodem是Ymodem的改进版，后者又是Xmodem的改进版。

Xmodem

Xmodem是一个简单的文件传输协议，是由Ward Christensen于1977年为他的MODEM.ASM终端程序开发。在早期的BBS系统非常的流行。

像许多文件传输协议一样，Xmodem把文件切分成有序的数据包。并在数据包上加上一些附件的信息允许接受方确定数据包是否在传输中损坏。

数据包的结构

• 包头：宝开始（SOH），包编号和包编号补码
• 数据：固定的128字节
• 包尾：校验和 ##### 传输过程 XModem工作时，先由收方发出NAK，然后等待发方的包开始SOH。收到SOH后，即 将整个包收完，检查是否有错。如出错，则向发方发出一个NAK，请求发方重发； 否则发出ACK,表示接收正确，请发下个包。XModem检查包编号和checksum来确定 该包是否传送有问题。编号是发方送得出包的顺序。当XModem发送完最后一个包 时，收方会收到文件结束符(EOT)，此时，收方会送出一个ACK通知发方传送结束。

Ymodem

Ymodem是Chuck Forsberg开发的Xmodem的改进版，1985年被Xmodem的开发者Ward Christensen称之为“Ymodem”。

相对于Xmodem的主要改进是在发送方发送真实数据块前，先发送一个称之为“block 0”的数据块（真实的数据块是从1开始计数），改数据块包含文件名，大小和时间戳。文件大小解决了Xmodem文件尾部剩余填充的问题。

Zmodem

Zmodem是Chuck Forsberg于1986年发布的Ymodem的改进版本。关键的改进是引进了滑动窗口协议(Sliding window protocol)改进了传输的性能。

在Xmodem或者Ymodem传输时发送方需要等待接收方放的ACK或者NAK响应才继续发送下一个数据包。Zmodem把这个同步的确认过程改成了异步的，发送方可以不断的方式数据包，然后异步的接收ACK或者NAK包，过一段时候后再决定是否需要重新发送数据包。这种方式解决了确认包网络延迟造成对传输速率的影响。

安装Zmodem的实现

brew install lrzsz

创建脚本

将下面两个脚本创建到 /usr/local/bin 目录

item2-send-zmodem.sh

#!/bin/bash
# Author: Matt Mastracci ([email protected])
# AppleScript from http://stackoverflow.com/questions/4309087/cancel-button-on-osascript-in-a-bash-script
# licensed under cc-wiki with attribution required 
# Remainder of script public domain
 
FILE=`osascript -e 'tell application "iTerm" to activate' -e 'tell application "iTerm" to set thefile to choose file with prompt "Choose a file to send"' -e "do shell script (\"echo \"&(quoted form of POSIX path of thefile as Unicode text)&\"\")"`
if [[ $FILE = "" ]]; then
	echo Cancelled.
	# Send ZModem cancel
	echo -e \\x18\\x18\\x18\\x18\\x18
	echo \# Cancelled transfer
	echo
else
	echo $FILE
	/usr/local/bin/sz "$FILE"
	echo \# Received $FILE
	echo
fi

iterm2-recv-zmodem.sh

#!/bin/bash
# Author: Matt Mastracci ([email protected])
# AppleScript from http://stackoverflow.com/questions/4309087/cancel-button-on-osascript-in-a-bash-script
# licensed under cc-wiki with attribution required 
# Remainder of script public domain
 
FILE=`osascript -e 'tell application "iTerm" to activate' -e 'tell application "iTerm" to set thefile to choose folder with prompt "Choose a folder to place received files in"' -e "do shell script (\"echo \"&(quoted form of POSIX path of thefile as Unicode text)&\"\")"`
if [[ $FILE = "" ]]; then
	echo Cancelled.
	# Send ZModem cancel
	echo -e \\x18\\x18\\x18\\x18\\x18
	echo \# Cancelled transfer
	echo
else
	echo $FILE
	cd "$FILE"
	/usr/local/bin/rz 
	echo \# Received $FILE
	echo
fi

设置iTerm2

修改iTerm2的default trigger（iTerm偏好设置-> Profiles -> Default -> Advanced -> Triggers的Edit按钮

Regular expression: \*\*B0100 
Action: Run Silent Coprocess 
Parameters: /usr/local/bin/iterm2-send-zmodem.sh
  
Regular expression: \*\*B00000000000000 
Action: Run Silent Coprocess 
Parameters: /usr/local/bin/iterm2-recv-zmodem.sh

发送文件到远端服务器

1. 在远端服务器执行 rz
2. 本地选择文件传输
3. 等待传输指示消失

接收远端服务器的文件

1. 在远端服务器执行sz filename1 filename2 … filenameN
2. 本地选择目录保存
3. 等待传输指示消失

参考文献

1. 在iTerm2中使用Zmodem的方法
2. ZModem integration for iTerm 2
3. Appendix H. Zmodem File Transfer

原文链接：http://codelife.me/blog/2013/03/02/zmodem-integration-for-iterm2/

游戏引擎收费策略

Unreal Engine

• 超过100万美元后收5%（超出部分所有收入都要扣5%，没按周期算）
• 也可以联系 Epic 谈判一个私有协议（比如买断使用费）
• 如果你的游戏在 Epic 游戏商城上架，那么在 Epic 商城上的盈利，不收这5%的费用
  • 从Epic游戏商城获得的营收就不需要再为虚幻引擎支付5%的分成费用。当您在Epic游戏商城上发行产品时，您将向Epic支付12%的营收，并保留剩余的88%，无需再额外支付虚幻引擎的分成费用。
  • 做为对比，在Steam上发行游戏，需要向Steam支付30%的营收。
  • 如果你使用 Unreal 开发的游戏在 Steam 上线，不但要向Steam支付30%的分成，还要向Epic支付5%的引擎使用费。总共35%的营收，而在Epic游戏商城上线，就只需要支付12%。
  • 但是，哪怕如此，可能很多人还是愿意在Steam发行，因为两者的效果是天差地别的。Steam拥有非常活跃且成熟的社区，在上面上线的游戏有机会得到大得多的曝光度。而Epic始终没能建立起任何社区，除了靠送游戏营造的虚假活跃外，应该没有多少人会真正长时间花在上面找游戏。

https://www.unrealengine.com/en-US/faq

A 5% royalty is due only if you are distributing an off-the-shelf product that incorporates Unreal Engine code (such as a game). Provided that you notify us on time using the Release Form, you will only owe royalties once the lifetime gross revenue from that product exceeds $1 million USD; in other words, the first $1 million will be royalty-exempt.

https://www.unrealengine.com/en-US/license#contact-us-form

We’ll work with you to find the right solution for your ideas.
Looking for private training, custom licensing terms, and/or royalty-free distribution of commercial off-the-shelf products? Reach out to us for information on your options. Click below to give us your details (you'll need to sign in or create an Epic Games account), and we'll contact you to discuss finding a solution that works for you.

Unity

Before Unity 6

• Student and hobbyist
  • 价格：免费
  • 使用对象：学生/非盈利使用/年收入少于10万美元
• Individuals and teams
  • Unity Pro
    • ¥ 13,872/yr per seat，除此之外没有 Royalty
• Enterprise and industry
  • Unity Enterprise
    • 价格：面谈
    • 使用对象：大企业/大团队/大项目
    • 特性：
      • Everything in Unity Pro
      • 有专家支持
      • 提供源码
      • 3年lts支持
      • Unity Cloud
  • Unity Industry
    • 价格：¥33,660 /yr per seat
    • 使用对象：同样是大团队吧，不知道和前面那个有啥区别
    • 特性：
      • Everything in Unity Enterprise
      • Industry Success (啥意思？)
      • Technical support
      • On-Demand Training (300+ hours)
      • Dedicated Partner Relations Manager

总结：

• Unity 6 之前，最贵的一档才收到 ¥33660 每人每年，除此之外没有按比例分成。
• 按一个100人的团队算，一年收 336 万，按正常的4年开发周期来说，总价为 ¥1346 万。

Since Unity 6: The Unity Runtime Fee

• 条件：年收入超过100万美元 并且 有超过100万安装后开始收分成费
• 费用：在2.5%分成和 Runtime Fee 之间取较小值。

Runtime Fee 费用评估：https://unity.com/cn/runtime-fee-estimator

The Unity Runtime Fee will only apply to certain games created with Unity Pro and Unity Enterprise. If you’re on a Unity Personal or Unity Plus plan, the Runtime Fee does not apply.

Games created with currently supported Unity versions will not be impacted by the fee. The Runtime Fee is only relevant to games created with, or upgraded to, Unity 6, the next Long Term Support (LTS) version to be released in 2024. For those games, the fee applies only after a game has crossed two thresholds:

1. $1,000,000 (USD) in gross revenue (trailing 12 months), AND
2. 1,000,000 initial engagements.

If your game crosses both thresholds, you will be charged whichever amount is lower:

• 2.5% of your game’s monthly gross revenue, OR
• The Runtime Fee based on monthly initial engagements.

function calcRoyalty(yearlyGrossRevenue, initialEngagements)
    if yearlyGrossRevenue >= 1000000 and initialEngagements >= 1000000 then
        return math.min(yearlyGrossRevenue*0.025, runtimeFee)
    end
    return 0
end

至于 runtimeFee 如何计算，以及其计算方式有多不合理，其实都不用太关心了，只需要把对 Royalty 的预期调整为 2.5% 分成就好了。这个比例只有 Unreal 的一半，还是挺良心的。另外，Unity 仍然适合独立开发者，因为大部分独立开发者的年收入很难达到100万美元。如果真达到了，到时候也有能力或者有手段去解决这个问题了。

当然，我的观点是，如果真的不是几千万上亿的流水，这个钱分了也就分了，毕竟Unity提供了这么好的工具，哪怕就是养活他们，给他们分这个钱也是应该的。

最后我们简单列一下不同档位收入要给Unity分多少钱

流水	分成
100万	2.5万
1000万	25万
1亿	250万

这么一看好像也没多少了。

Free and Open Source game engines

• Ant Engine
• Godot
• LÖVE
  • 以前从来没听说过，最近新上了一款非常成功且非常好玩的游戏 Balatro，在翻看它的游戏文件时发现使用的是这个 Framework。之所以说是 Framework 而不是 Engine，是因为它并没有提供任何 Editor，只提供各种 api。这就意味着，一千个用户，有一千种用法，你需要自己去组合各种工具，来找到适合自己的工作流。而等到你最终组合出来适合自己的工作流后，那套工作流才是你的引擎。
  • 开发语言为 Lua，简单写了个 HelloWorld，又看了一些已开发出来的游戏，发现确实挺不错的。很简洁，几行代码就能做出一些复古游戏。社区活跃，喜欢的人很多。但是当我深入了解后，就失去兴趣了。因为太过原始，动画编辑器都没有，想做动画需要自己用代码控制。这其实就是在做很多引擎已经做了的事，属于重复造轮子了。所以哪怕我很喜欢 Love2D 的简洁度，以及用 Lua 做开发语言，但重复造轮子和搞科研，不是我做游戏的理念。
• CocosCreator: 本质上还是cocos2d-x，之所以写 CocosCreator，是因为我认为这个才是它的成熟体，之前纯撸代码的方式和 Love2D 有一拼，并不好用。
• Ejoy2D: 这个只是个图形api，并不算引擎，有点类似Love2D，使用范围不广，文档也不全。但是因为《三国志战略版》是用它开发的，所以在能力上并不弱，因此也在这里列出来。

如何设置 Flarum 的邮件发送服务

邮件发送服务是一项非常重要的设置，用于系统给用户发送各种邮件，比如：

• 注册账号时会发送激活邮件，只有激活了账号功能才正常。
• 密码重置邮件
• 各种通知邮件，比如：
  • 关注的贴子的更新通知
  • 指定用户上线通知
  • 等等

如果邮件发送服务没有设置对，那论坛的功能是极其不完整的，因此必须要正确设置。

不同邮件设置方法

Gmail

可参考：https://discuss.flarum.org/d/21686-how-to-setup-gmail-to-send-flarum-mail

126

目前还没设置成功过，下面给出一个我曾经在另一个网站上设置成功过的 126 邮件的配置：

$config['smtp_host'] = 'smtp.126.com';
$config['smtp_port'] = 25;
$config['smtp_auth'] = true;
$config['smtp_user'] = '[email protected]';
$config['smtp_pass'] = 'UHFTYGCBNMJHFDAQSE';
$config['smtp_secure'] = 'tls';

注：

1. 想要使用126的smtp功能，需要去邮箱设置里打开，默认是关闭的。
2. smtp_pass 不是邮箱的密码，而是在开启smtp功能时，需要开启一个授权，授权后会有个smtp使用的密码。
3. 上述密码已脱敏，非正确密码，请勿尝试。

我在 Flarum 内照着上面的设置，填入对应参数后始终不能正常发邮件，如果有设置成功的欢迎分享出来，感谢。

我失败的配置：

• Choose a Driver: smtp
• SMTP Settings
  • Host: smtp.126.com
  • Port: 25
  • Encryption: tls
  • Username: [email protected]
  • Password: UHFTYGCBNMJHFDAQSE

Midreal AI 使用教程

1. 在 start 这个频道里，输入 /start 开始创作你的故事。
2. 在 scenario 里定义你的角色和剧情。
3. 开始生成剧情后，机器人会提供选项，可以选择剧情走向。

注意：目前该 AI 是在 Discord 的公共频道里交互的，所以你生成的故事别人也能看见，同样的你也能看到别人的信息。机器人回复你的时候，会有你的名字，以便和别人区分。

一些好用的 Flarum 插件

• FoF Upload: The file upload extension for the Flarum forum with insane intelligence.
• FoF Links: Manage Flarum primary navbar menu links.
• FoF User Bio: Add a user bio to user profiles.
• Blog: Adds a blog section to your forum.
• FoF Polls: A Flarum extension that adds polls to your discussions.
• FoF Night Mode: Add a Night Mode option for your users to use on your Flarum forum.
• FoF Reactions: Adds reactions to your Flarum Community!
• FoF OAuth: Allow users to log in with GitHub, Twitter, Facebook, Google, and more!
• FoF Analytics: Tracks analytics using Google Analytics, Google Optimize/GTM and Matomo.
• 简体中文: Chinese language pack for Flarum 2021.
• FoF Default User Preferences: Configure the default user preferences for new users joining your forum.
• Color Circles: Add a color circle around avatars based on user group
• FoF Pretty Mail: Create HTML email for Flarum.
• Markdown Tables: Markdown tables for flarum.
• Emoji Picker: Add EmojioneArea emoji picker to Flarum.

Palworld 使用 Docker 启动服务器 FAQ

1. 我自己能连，局域网其他人连不进来是怎么回事？

一般是防火墙的问题，把启 Docker 那台机器的防火墙关掉，或者放行 UDP 8211 端口就可以了。

2. 存档位置在哪？

• 容器内路径：/home/game/Steam/steamapps/common/PalServer/Pal/Saved
• 启动容器时，必须把这个路径映射出去，否则删除容器后存档丢失。下面我给的命令已经映射到 E:\PocketPair\PalServer\Saved 目录了，如果你想映射到其他地方，修改命令即可。

3. 如何更新服务器？

如果你的网络能从 docker hub 直接下载镜像，更新步骤如下：

1. 把旧容器停掉并删除：docker ps 查看镜像名（最后一列），然后 docker stop xxx 停掉容器，docker rm xxx 删除容器。
2. 删了旧镜像：docker image rm pasharp/pal_server
3. 更新镜像: docker pull pasharp/pal_server:latest
4. 重启容器: docker run -d --restart=always -u game --name palserver -v /E/PocketPair/PalServer/Saved:/home/game/Steam/steamapps/common/PalServer/Pal/Saved -p 8211:8211/udp pasharp/pal_server /home/game/Steam/steamapps/common/PalServer/PalServer.sh

如果不能，步骤如下：

1. 把旧容器停掉并删除
2. 删了旧镜像
3. 从我的网盘里下载最新镜像（看更新时间，一般有更新了我会同步一下）
4. 重新按视频里的步骤导入镜像并启动服务器

幻兽帕鲁游戏配置参数说明

变量名	描述	默认值
Difficulty	难度	None
DayTimeSpeedRate	日间速度倍率	1.000000
NightTimeSpeedRate	夜间速度倍率	1.000000
ExpRate	经验倍率	1.000000
PalCaptureRate	伙伴捕获倍率	1.000000
PalSpawnNumRate	伙伴生成数量倍率	1.000000
PalDamageRateAttack	伙伴攻击伤害倍率	1.000000
PalDamageRateDefense	伙伴防御伤害倍率	1.000000
PlayerDamageRateAttack	玩家攻击伤害倍率	1.000000
PlayerDamageRateDefense	玩家防御伤害倍率	1.000000
PlayerStomachDecreaceRate	玩家饥饿减少速率	1.000000
PlayerStaminaDecreaceRate	玩家体力减少速率	1.000000
PlayerAutoHPRegeneRate	玩家自动血量恢复倍率	1.000000
PlayerAutoHpRegeneRateInSleep	睡眠中玩家自动血量恢复倍率	1.000000
PalStomachDecreaceRate	伙伴饥饿减少速率	1.000000
PalStaminaDecreaceRate	伙伴体力减少速率	1.000000
PalAutoHPRegeneRate	伙伴自动血量恢复倍率	1.000000
PalAutoHpRegeneRateInSleep	睡眠中伙伴自动血量恢复倍率	1.000000
BuildObjectDamageRate	建筑物受损倍率	1.000000
BuildObjectDeteriorationDamageRate	建筑物劣化受损倍率	1.000000
CollectionDropRate	收集物掉落倍率	1.000000
CollectionObjectHpRate	收集物体生命值倍率	1.000000
CollectionObjectRespawnSpeedRate	收集物体重生速度倍率	1.000000
EnemyDropItemRate	敌人掉落物品倍率	1.000000
DeathPenalty	死亡惩罚	All
bEnablePlayerToPlayerDamage	允许玩家对玩家造成伤害	False
bEnableFriendlyFire	允许友军伤害	False
bEnableInvaderEnemy	允许入侵敌人	True
bActiveUNKO	未知	False
bEnableAimAssistPad	启用手柄瞄准辅助	True
bEnableAimAssistKeyboard	启用键盘瞄准辅助	False
DropItemMaxNum	掉落物品最大数量	3000
DropItemMaxNum_UNKO	掉落物品最大数量_UNKO	100
BaseCampMaxNum	基地最大数量	128
BaseCampWorkerMaxNum	基地工人最大数量	15
DropItemAliveMaxHours	掉落物品存活最长时间（小时）	1.000000
bAutoResetGuildNoOnlinePlayers	自动重置公会无在线玩家	False
AutoResetGuildTimeNoOnlinePlayers	无在线玩家时自动重置公会时间（小时）	72.000000
GuildPlayerMaxNum	公会最大玩家数量	20
PalEggDefaultHatchingTime	伙伴蛋默认孵化时间（小时）	72.000000
WorkSpeedRate	工作速度倍率	1.000000
bIsMultiplay	False	多人游戏
bIsPvP	False	PvP模式
bCanPickupOtherGuildDeathPenaltyDrop	False	可以拾取其他公会死亡惩罚掉落
bEnableNonLoginPenalty	True	启用非登录惩罚
bEnableFastTravel	True	启用快速旅行
bIsStartLocationSelectByMap	True	根据地图选择起始位置
bExistPlayerAfterLogout	False	登出后玩家仍存在
bEnableDefenseOtherGuildPlayer	False	启用防御其他公会玩家
CoopPlayerMaxNum	4	合作玩家最大数量
ServerPlayerMaxNum	32	服务器玩家最大数量
ServerName	""	服务器名字
ServerDescription	""	服务器描述
AdminPassword	""	管理员密码
ServerPassword	""	服务器密码
PublicPort	8211	公共端口号
PublicIP	""	公共IP地址
RCONEnabled	False	启用RCON
RCONPort	25575	RCON端口号
Region	""	区域
bUseAuth	True	使用身份验证
BanListURL	"https://api.palworldgame.com/api/banlist.txt"	封禁名单URL

使用 Docker 部署 Flarum

Docker 部署 Flarum

1 获取 Flarum 的 Docker 镜像

从 hub.docker.com 拉取：

docker pull mondedie/flarum:latest

或自己编译：

docker build -t mondedie/flarum:latest https://github.com/mondediefr/docker-flarum.git

2 创建 docker-compose.yml

1. 任意找个目录，为了便于管理，最好放到一个有意义的目录内，比如 ~/docker/flarum。
2. 创建 docker-compose.yml 文件，把下面的内容粘贴进去。
3. 把 /mnt/docker/flarum 替换为你的目录。
   • 就是第一步里的目录，进到目录后在终端输入 pwd 打印出目录的路径。
4. 把 xxxxxxxxxx 修改为你想设置的 MySQL 密码。

version: "3"

services:
  flarum:
    image: mondedie/flarum:stable
    container_name: flarum
    env_file:
      - /mnt/docker/flarum/flarum.env
    volumes:
      - /mnt/docker/flarum/assets:/flarum/app/public/assets
      - /mnt/docker/flarum/extensions:/flarum/app/extensions
      - /mnt/docker/flarum/storage/logs:/flarum/app/storage/logs
      - /mnt/docker/flarum/nginx:/etc/nginx/flarum
    ports:
      - 80:8888
    depends_on:
      - mariadb

  mariadb:
    image: mariadb:10.5
    container_name: mariadb
    environment:
      - MYSQL_ROOT_PASSWORD=xxxxxxxxxx
      - MYSQL_DATABASE=flarum
      - MYSQL_USER=flarum
      - MYSQL_PASSWORD=xxxxxxxxxx
    volumes:
      - /mnt/docker/mysql/db:/var/lib/mysql

3 创建 flarum.env

1. 还是在刚才的目录里创建 flarum.env 文件，把下面的内容粘贴进去。
2. 修改 FORUM_URL 为你自己的IP或域名。注意：
   • 这个值的作用用来标记网站的资源应该从哪里获取，客户端会根据这里配置的值去取对应的资源。
   • 比如假设有一张图，相对路径为 images/flarum.png，客户端会根据配置的值拼出绝对路径 http://domain.tld/images/flarum.png。
   • 所以这里配你的网站真实能访问的地址
     • 如果没有域名就填IP
     • 如果端口不是80就要填上端口
     • 如果没有 https 就填 http
     • 比如 http://45.23.89.74:8080
3. 修改 DB_PASS=xxxxxxxxxx 里的密码为你自己的密码。
4. 修改管理员账号信息
   • FLARUM_ADMIN_PASS=xxxxxxxxxx 改为你自己的密码
   • [email protected] 邮箱改为你自己的真实邮箱，这里一定要用真实邮箱，后面这个就是整个网站的超级管理员账号。
   • FLARUM_TITLE=Test flarum 改为网站的真实名字。

4 启动

在 docker-compose.yml 所在目录内打开终端，运行以下命令启动 Flarum

docker-compose up -d

以下是一些常用操作：

• 停止并删除：docker-compose down
  • 因为所有重要数据都映射出去了，所以可以放心删除窗口

安装 PHP 扩展

TODO

安装 Flarum 扩展

TODO

Reference

• https://github.com/mondediefr/docker-flarum?tab=readme-ov-file#installation

什么是 LDAP?

太长不看版

LDAP 是用来做统一的身份验证的，比如在公司内网，公司可以统一管理一份员工的账号列表，所有其他的子系统都可以使用这一份账号列表来实现登陆。比如各项目组内部自建的 Confluence/Jira/论坛/GitLab/网盘/Windows 系统登陆/等等，这样就做到了账号的统一管理。员工改一次密码，全公司所有子系统都可以应用到新密码。新员工入职/老员工离职时，也可以统一增加/删除账号。

原文（从英文机翻过来的，想看英文版可以划拉到最后）

轻量级目录访问协议 Lightweight Directory Access Protocol ) 是一种与供应商无关的软件协议，用于在网络中查找信息或设备。 无论您想要为您的组织构建**身份验证服务器还是想要简化对内部服务器和打印机的访问，LDAP 都是答案。

什么是 LDAP？

LDAP 是一种标准协议，旨在维护和访问网络内的“目录服务”。 将目录服务视为不同网络资源（如文件、打印机、用户、设备和服务器等）的电话簿。

例如，组织可以将其所有打印机的信息存储在目录中。 LDAP 可以使用户搜索特定打印机、在网络上找到它并安全地连接到它。

LDAP 广泛用于构建**身份验证服务器。 这些服务器包含网络内所有用户的用户名和密码。 任何应用程序和服务都可以连接到 LDAP 服务器来对用户进行身份验证和授权。

LDAP 目录通常包含定期访问但很少更改的数据。 LDAP 旨在提供极快的读取性能，即使对于较大的数据集也是如此。 然而，写入性能明显较低。

LDAP 是如何工作的？

要连接到 LDAP 目录，用户必须在其设备上安装 LDAP 客户端。 典型的 LDAP 工作流程如下所示：

1. 用户使用客户端与 LDAP 目录建立安全连接。
2. 他们向特定打印机的目录发送“搜索”查询。
3. LDAP 目录对用户进行身份验证。
4. 在目录内执行搜索操作，并返回所请求打印机的地址。
5. 与 LDAP 目录的安全连接已关闭。
6. 用户连接到打印机。

阅读原文（英文）