272 lines
10 KiB
Markdown
272 lines
10 KiB
Markdown
<!-- Powered by BMAD™ Core -->
|
|
|
|
# WeChat Mini-Game Development Guidelines
|
|
|
|
## Overview
|
|
|
|
This document establishes coding standards, architectural patterns, and development practices for game development on the WeChat Mini-Game platform. These guidelines ensure consistency, performance, and maintainability across all game development stories.
|
|
|
|
## JavaScript/TypeScript Standards
|
|
|
|
### General Best Practices
|
|
|
|
- Use `const` by default, `let` when reassignment is necessary. Avoid `var`.
|
|
- Use strict equality (`===` and `!==`) to avoid type coercion issues.
|
|
- Write modular and reusable code using functions and classes.
|
|
|
|
### Naming Conventions
|
|
|
|
**Classes and Interfaces:**
|
|
|
|
- PascalCase for classes: `Player`, `GameManager`, `AudioSystem`
|
|
- Descriptive names that indicate purpose: `CollisionManager` not `CM`
|
|
|
|
**Methods and Variables:**
|
|
|
|
- camelCase for methods and variables: `updatePosition()`, `playerSpeed`
|
|
- Descriptive names: `calculateDamage()` not `calcDmg()`
|
|
- Boolean variables with is/has/can prefix: `isActive`, `hasCollision`, `canMove`
|
|
|
|
**Constants:**
|
|
|
|
- UPPER_SNAKE_CASE for constants: `MAX_PLAYER_SPEED`, `DEFAULT_VOLUME`
|
|
|
|
**Files and Directories:**
|
|
|
|
- kebab-case for file names: `player-controller.js`, `audio-manager.js`
|
|
- Use descriptive names for pages and components.
|
|
|
|
## WeChat Mini-Game Architecture Patterns
|
|
|
|
### App and Page Lifecycle
|
|
|
|
**app.js:**
|
|
|
|
```javascript
|
|
// app.js
|
|
App({
|
|
onLaunch() {
|
|
// Called when the mini-game is initialized
|
|
// Perform global initialization here
|
|
},
|
|
onShow(options) {
|
|
// Called when the mini-game is launched or brought to the foreground
|
|
},
|
|
onHide() {
|
|
// Called when the mini-game is switched to the background
|
|
},
|
|
globalData: {
|
|
userInfo: null,
|
|
},
|
|
});
|
|
```
|
|
|
|
**Page Lifecycle:**
|
|
|
|
```javascript
|
|
// pages/game/game.js
|
|
Page({
|
|
data: {
|
|
// Page data
|
|
},
|
|
onLoad(options) {
|
|
// Called when the page is loaded
|
|
},
|
|
onReady() {
|
|
// Called when the page is first rendered
|
|
},
|
|
onShow() {
|
|
// Called when the page is shown
|
|
},
|
|
onHide() {
|
|
// Called when the page is hidden
|
|
},
|
|
onUnload() {
|
|
// Called when the page is unloaded
|
|
},
|
|
});
|
|
```
|
|
|
|
### Component-Based Architecture
|
|
|
|
- Create reusable UI components in the `components` directory.
|
|
- Use `Component` constructor to define custom components.
|
|
- Communicate between components using events.
|
|
|
|
## Performance Optimization
|
|
|
|
### Package Size and Asset Management
|
|
|
|
- **Initial Package Size:** The initial package size is strictly limited (currently 4MB). Keep your core game logic and essential assets in the main package.
|
|
- **Subpackages:** Use subpackages for additional levels, features, and non-essential assets. This allows for on-demand loading and keeps the initial download small.
|
|
- **Image Compression:** Use appropriate image formats (e.g., PNG, JPG) and compression tools. For games, consider using texture compression formats like ETC1/2 or PVRTC where applicable.
|
|
- **Audio Compression:** Use compressed audio formats (e.g., MP3, AAC) and adjust the bitrate to balance quality and size.
|
|
- **Font Optimization:** Avoid including large font files. If possible, use the system font or bitmap fonts. If you need a custom font, only include the characters you need.
|
|
|
|
### Frame Rate and Rendering
|
|
|
|
- **`requestAnimationFrame`:** Always use `requestAnimationFrame` for game loops and animations. It's more efficient than `setInterval` or `setTimeout` and aligns with the browser's rendering cycle.
|
|
- **Off-Screen Canvas:** For complex drawing operations, use an off-screen canvas to pre-render content and then draw the result to the main canvas in a single operation.
|
|
- **Avoid Expensive Operations:** Minimize complex calculations, object creation, and memory allocation within the main game loop.
|
|
- **Worker Threads:** For heavy computations like AI or physics, offload them to a worker thread to avoid blocking the main rendering thread.
|
|
|
|
### Memory Management and Garbage Collection
|
|
|
|
- **Object Pooling:** Reuse objects (e.g., bullets, enemies) instead of creating and destroying them frequently. This reduces garbage collection (GC) pressure.
|
|
- **Resource Cleanup:** Explicitly destroy objects and release resources when they are no longer needed. This is especially important for event listeners, timers, and large assets like images and audio.
|
|
- **`wx.triggerGC()`:** In scenarios where you know a large amount of memory can be freed (e.g., after a level change), you can use `wx.triggerGC()` to suggest a garbage collection cycle. Use this sparingly, as it can cause a performance stutter.
|
|
|
|
### Performance Monitoring
|
|
|
|
- **`wx.getPerformance()`:** Use this API to get performance metrics like frame rate, memory usage, and draw calls.
|
|
- **WeChat DevTools:** The developer tools provide a performance panel for profiling CPU usage, memory, and rendering.
|
|
- **Online Diagnosis Tool:** Use the official online performance diagnosis tool to get a detailed report on your game's performance.
|
|
|
|
## WeChat API Usage Best Practices
|
|
|
|
### Login and User Data
|
|
|
|
- **`wx.login()`:** Call this early in your game's lifecycle to get a login code.
|
|
- **User Privacy:** When using `wx.getUserInfo()`, you must now use a button to trigger the authorization prompt. Be transparent with players about why you need their information. Refer to the latest user privacy guidelines.
|
|
|
|
### Social Features
|
|
|
|
- **Sharing (`wx.shareAppMessage`):**
|
|
- Provide engaging share titles and images to encourage clicks.
|
|
- Use query parameters in your share URLs to track sources and reward players for successful shares.
|
|
- **OpenDataContext (Leaderboards):**
|
|
- The OpenDataContext is a separate, isolated environment for rendering social data like leaderboards.
|
|
- Communication between the main game and the OpenDataContext is done via `postMessage`.
|
|
- Keep the OpenDataContext as simple as possible to ensure good performance.
|
|
|
|
### File System
|
|
|
|
- **`wx.getFileSystemManager()`:** Use this API for all file system operations.
|
|
- **Storage Limits:** Be aware of the storage limits for user data. The total size is limited (currently 50MB).
|
|
- **Temporary vs. User Files:** Understand the difference between temporary files (cleared on exit) and user files (persistent). Use the appropriate storage for your needs.
|
|
|
|
## Review and Publishing Process
|
|
|
|
### Key Steps
|
|
|
|
1. **Development and Testing:** Complete your game and test it thoroughly.
|
|
2. **Submit for Review:** In the WeChat DevTools, upload your code and submit it for review.
|
|
3. **Review Process:** The WeChat team will review your game for compliance with their policies and guidelines. This can take several business days.
|
|
4. **Approval or Rejection:** You will be notified of the outcome. If rejected, you will be given reasons, and you can resubmit after making the necessary changes.
|
|
5. **Publishing:** Once approved, you can publish your game to make it available to all WeChat users.
|
|
|
|
### Common Reasons for Rejection
|
|
|
|
- **Bugs and Performance Issues:** Games that crash, have significant bugs, or perform poorly are likely to be rejected.
|
|
- **Policy Violations:** Ensure your game complies with all of WeChat's content policies (e.g., no gambling, violence, or adult content).
|
|
- **Incomplete Information:** Provide all necessary information during the submission process, including test accounts and clear descriptions of your game's features.
|
|
- **Lack of "Game-like" Qualities:** Your submission should be a game, not just a simple interactive application.
|
|
|
|
Refer to the official [WeChat Mini Game Review Guidelines](https://developers.weixin.qq.com/minigame/product/#%E5%AE%A1%E6%A0%B8%E8%A7%84%E8%8C%83) for the most up-to-date information.
|
|
|
|
## Input Handling
|
|
|
|
### Touch Input
|
|
|
|
- Use `bindtouchstart`, `bindtouchmove`, `bindtouchend`, and `bindtap` to handle touch events.
|
|
- Be mindful of the performance impact of frequent touch events.
|
|
|
|
## Error Handling
|
|
|
|
### Graceful Degradation
|
|
|
|
- Use `try...catch` blocks to handle potential errors.
|
|
- Provide fallback mechanisms for when APIs fail.
|
|
- Use `wx.getSystemInfo` to check for API availability.
|
|
|
|
## Testing Standards
|
|
|
|
### Manual Testing
|
|
|
|
- Test on a variety of iOS and Android devices.
|
|
- Test different network conditions.
|
|
- Test for compatibility with different WeChat versions.
|
|
|
|
## File Organization
|
|
|
|
### Project Structure
|
|
|
|
```
|
|
.
|
|
├── app.js
|
|
├── app.json
|
|
├── app.wxss
|
|
├── components
|
|
│ └── ...
|
|
├── images
|
|
│ └── ...
|
|
├── pages
|
|
│ ├── index
|
|
│ │ ├── index.js
|
|
│ │ ├── index.json
|
|
│ │ ├── index.wxml
|
|
│ │ └── index.wxss
|
|
│ └── game
|
|
│ ├── game.js
|
|
│ ├── game.json
|
|
│ ├── game.wxml
|
|
│ └── game.wxss
|
|
├── project.config.json
|
|
└── ...
|
|
```
|
|
|
|
## Development Workflow
|
|
|
|
### Story Implementation Process
|
|
|
|
1. **Read Story Requirements:**
|
|
- Understand acceptance criteria
|
|
- Identify technical requirements
|
|
- Review performance constraints
|
|
2. **Plan Implementation:**
|
|
- Identify files to create/modify
|
|
- Consider component architecture
|
|
- Plan testing approach
|
|
3. **Implement Feature:**
|
|
- Follow JavaScript/TypeScript best practices
|
|
- Use established patterns
|
|
- Maintain smooth performance
|
|
4. **Test Implementation:**
|
|
- Test on target devices
|
|
- Validate performance targets
|
|
5. **Update Documentation:**
|
|
- Mark story checkboxes complete
|
|
- Document any deviations
|
|
|
|
### Code Review Checklist
|
|
|
|
**Before Committing:**
|
|
|
|
- [ ] Code runs without errors
|
|
- [ ] Performance targets met
|
|
- [ ] No console errors or warnings
|
|
- [ ] Cross-platform compatibility verified
|
|
- [ ] Memory usage within bounds
|
|
- [ ] Code follows naming conventions
|
|
- [ ] Error handling implemented
|
|
- [ ] Documentation updated
|
|
|
|
## Performance Targets
|
|
|
|
### Frame Rate Requirements
|
|
|
|
- Maintain a stable frame rate (e.g., 30 or 60 FPS).
|
|
- Implement dynamic quality scaling if performance drops.
|
|
|
|
### Memory Management
|
|
|
|
- Be mindful of memory usage to avoid crashes on low-end devices.
|
|
- Clean up unused resources to prevent memory leaks.
|
|
|
|
### Loading Performance
|
|
|
|
- Keep initial load time under a few seconds.
|
|
- Use loading screens to provide feedback to the user.
|
|
|
|
These guidelines ensure consistent, high-quality WeChat Mini-Game development that meets performance targets and maintains code quality across all implementation stories.
|