Building a Guangxi Card-Rule Demo with Go and Vue: Source-Code and Performance Log

Disclaimer: This article is for technical education and demonstration only. It is not professional or financial advice. Any real-world deployment must comply with applicable laws and regulations.

Recently, I helped a client deploy a regional Guangxi card-rule engine to a demonstration environment. The system primarily runs a 13-card hand-combination scoring algorithm, recognizes pattern rules for Liuzhou and Laibin, and demonstrates the play logic of the Bāyì military-character card set. The source code remained in local testing for two weeks before deployment. We ran into several issues during the process, so I have documented the full workflow here for others working on similar rule engines.

1. Core System Features Tested

1.1 Adapting Rules for Multiple Regions

The system’s main strength is support for switching among multiple regional rule sets. The Liuzhou, Laibin, and Bāyì rule engines are stored independently under the rules directory, and each has its own pattern-priority table. For Thirteen Card, the ranking calculation compares the weights of three hand groups. The Bāyì set requires recognition of three special pattern categories: “military”, “character”, and “suit”. I loaded a real hand record for testing, and recognition completed in under 200 ms.

1.2 Room and Matching Mechanism

The source code uses a conventional room-based architecture. After entering the lobby, a player selects a region and joins the corresponding room. Redis handles room-state synchronization on the back end, with support for four-player and six-player rooms. The matching logic is implemented in matchService.go and queues participants by rank and room-entry time. During testing, I ran 20 rooms concurrently. CPU usage showed no obvious spikes, and the Redis connections remained stable.

1.3 Administrative Dashboard

The administrative interface is a separate service running on port 8088 by default. It includes:

Account management (banning, notes, and score adjustment)
Room monitoring (real-time status for each room)
Match replay (exporting hand-history files)
Data analytics (daily active users and pattern distribution)
System settings (configuration parameters and feature toggles)

After I changed a pattern parameter, refreshing the lobby applied the new configuration immediately, with no service restart. That part of the design is well thought out.

2. Deployment Process and Lessons Learned

2.1 Preparing the Server Environment

The recommended minimum configuration is 2 CPU cores, 4 GB of memory, and a 50 GB SSD. My test environment used CentOS 7.9, Nginx 1.20, MySQL 5.7, and Redis 6.2. Make sure to enable the MySQL slow query log. The SQL used by the Thirteen-Card combination algorithm is relatively complex, and troubleshooting slow queries without that log can be frustrating.

2.2 Initializing the Database

The source package includes init.sql, which creates more than 30 tables. The key tables include:

user_info (basic user information)
room_log (room activity log)
card_record (match records)
region_rule_config (regional rule configuration)
pay_order (payment-order records)

Before running the initialization script, change the character set to utf8mb4. Otherwise, special characters such as certain suit symbols may appear as garbled text.

2.3 Starting the Back-End Service

The back end is written in Go, while the front end uses Vue. Follow this build order:

Build the back end first: go build -o card-engine main.go
Build the front end with npm run build, then copy the dist directory to the back end’s static directory
Configure config.yaml with the database and Redis addresses
Use Supervisor to manage the process and enable startup at boot

During the first deployment, I forgot to update the callback address in config.yaml. As a result, the transaction status remained “Pending” for half an hour before I found the issue.

2.4 API Integration Notes

The system provides several standard APIs for secondary development:

User login API (supports phone numbers or account credentials)
Room creation API (accepts a region parameter)
Match-result reporting API
Match-history query API

Callback signatures use MD5 with a salt value. Before integration, replace the default salt with your own value; otherwise, the configuration creates a security risk.

💡 Practical tip: After deployment, always run a load test against the room-creation endpoint with ab. In my setup, peak throughput was around 800 QPS. Above that, the Redis connection pool became saturated, so the maxclients setting needs to be adjusted.

3. Who This Source Code Is For

Based on the clients I have worked with, this source code is a good fit for:

Go developers who want to study card-pattern algorithms
Projects simulating local tabletop-game culture that need a rule demonstration
Startup teams planning custom extensions and their own rule versions
Computer science course projects, since the algorithm layer has a clear structure

It is not a good fit as a turnkey production platform. The source does not include complete anti-cheating and compliance modules, so those components must be added separately. For technical research or algorithm learning, however, it is a strong reference implementation.

4. Secondary-Development Recommendations

If you want to add a new rule set to this system, follow these steps:

Create a subdirectory under rules, such as my_rule/
Implement the Init, Match, and Settle methods defined by the RuleEngine interface
Add a configuration record to the region_rule_config table
The region selector on the front end will automatically load the new option

I added a Baise regional rule set for another client. The front-end code barely needed any changes, and most of the work was in the back-end logic. Testing included, the entire modification took about three days.

Frequently Asked Questions

Question: Does this source code require a license to use?
Answer: The source code itself is open source and may be used commercially and extended freely. However, you must retain the original copyright information. Some third-party libraries, such as a payment SDK, require separate authorization.

Question: Can it be deployed on a Windows server?
Answer: In theory, yes. The Go back end compiles to a binary file and is cross-platform. Even so, Linux is recommended because Nginx configuration and Supervisor process management are more stable there. I tested it on Windows Server 2019 and found that some scheduled tasks failed intermittently.

Question: How is the Thirteen-Card pattern-weighting algorithm implemented?
Answer: The core implementation is in algorithms/thirteen_score.go, and it uses dynamic programming. The code first splits 13 cards into 3+5+5 hands, enumerates every possible partition to calculate the total weight, and then selects the highest-scoring partition as the final result score. The code includes thorough comments and can be used directly for study.

Question: How complex is the payment API integration?
Answer: The source includes adapter code for three payment channels: WeChat Pay, Alipay, and UnionPay. During integration, you only need to enter the merchant ID and secret key in the pay_config table because the callback logic is already implemented. The callback address must use HTTPS; otherwise, signature validation will fail.

Question: Does it support multiple languages?
Answer: The front end uses vue-i18n and includes built-in language packs for Chinese, English, and Vietnamese. Back-end error codes are also separated by language and return the corresponding message based on the lang field. To add another language, use zh.json as the translation template, place the translated file in the locales directory, and restart the front end.

One last note: this system is designed as a technical demonstration and a learning tool for rule engines, not as a turnkey production platform. If you plan a commercial deployment, complete the compliance and anti-abuse modules. This article is for technical education only. Follow applicable laws and regulations, and do not use the system for any unlawful or prohibited purpose.

Disclaimer: This article is for technical education and demonstration only. It is not professional or financial advice. Any real-world deployment must comply with applicable laws and regulations.

#Card Rule Engine #Thirteen-Card Scoring Algorithm #Source-Code Deployment #Guangxi Regional Card Rules #Go Development

Building a Guangxi Card-Rule Demo with Go and Vue: Source-Code and Performance Log