|
1 | | -# Pull Request |
| 1 | +<!-- |
| 2 | +Thank you for contributing to mod-playerbots, please make sure that you... |
| 3 | +1. Submit your PR to the test-staging branch, not master. |
| 4 | +2. Read the guidelines below before submitting. |
| 5 | +3. Don't delete parts of this template. |
2 | 6 |
|
3 | | -Describe what this change does and why it is needed... |
| 7 | +DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND PREDICTABILITY over behavioral realism. |
4 | 8 |
|
5 | | ---- |
| 9 | +Every action and decision executes PER BOT AND PER TRIGGER. Small increases in logic complexity scale |
| 10 | +poorly across thousands of bots and negatively affect all. We prioritize a stable system over a smarter |
| 11 | +one. Bots don't need to behave perfectly; believable behavior is the goal, not human simulation. |
| 12 | +Default behavior must be cheap in processing; expensive behavior must be opt-in. |
6 | 13 |
|
7 | | -## Design Philosophy |
| 14 | +Before submitting, make sure your changes aligns with these principles. |
| 15 | +--> |
8 | 16 |
|
9 | | -We prioritize **stability, performance, and predictability** over behavioral realism. |
10 | | -Complex player-mimicking logic is intentionally limited due to its negative impact on scalability, maintainability, and |
11 | | -long-term robustness. |
| 17 | +## Pull Request Description |
| 18 | +<!-- Describe what this change does and why it is needed --> |
12 | 19 |
|
13 | | -Excessive processing overhead can lead to server hiccups, increased CPU usage, and degraded performance for all |
14 | | -participants. Because every action and |
15 | | -decision tree is executed **per bot and per trigger**, even small increases in logic complexity can scale poorly and |
16 | | -negatively affect both players and |
17 | | -world (random) bots. Bots are not expected to behave perfectly, and perfect simulation of human decision-making is not a |
18 | | -project goal. Increased behavioral |
19 | | -realism often introduces disproportionate cost, reduced predictability, and significantly higher maintenance overhead. |
20 | 20 |
|
21 | | -Every additional branch of logic increases long-term responsibility. All decision paths must be tested, validated, and |
22 | | -maintained continuously as the system evolves. |
23 | | -If advanced or AI-intensive behavior is introduced, the **default configuration must remain the lightweight decision |
24 | | -model**. More complex behavior should only be |
25 | | -available as an **explicit opt-in option**, clearly documented as having a measurable performance cost. |
26 | 21 |
|
27 | | -Principles: |
28 | | - |
29 | | -- **Stability before intelligence** |
30 | | - A stable system is always preferred over a smarter one. |
31 | | - |
32 | | -- **Performance is a shared resource** |
33 | | - Any increase in bot cost affects all players and all bots. |
34 | | - |
35 | | -- **Simple logic scales better than smart logic** |
36 | | - Predictable behavior under load is more valuable than perfect decisions. |
37 | | - |
38 | | -- **Complexity must justify itself** |
39 | | - If a feature cannot clearly explain its cost, it should not exist. |
| 22 | +## Feature Evaluation |
| 23 | +<!-- |
| 24 | +If your PR is very minimal (comment typo, wrong ID reference, etc), and it is very obvious it will not have |
| 25 | +any impact on performance, you may skip these question. If necessary, a maintainer may ask you for them later. |
| 26 | +--> |
40 | 27 |
|
41 | | -- **Defaults must be cheap** |
42 | | - Expensive behavior must always be optional and clearly communicated. |
| 28 | +<!-- Please answer the following: --> |
| 29 | +- Describe the **minimum logic** required to achieve the intended behavior. |
| 30 | +- Describe the **processing cost** when this logic executes across many bots. |
43 | 31 |
|
44 | | -- **Bots should look reasonable, not perfect** |
45 | | - The goal is believable behavior, not human simulation. |
46 | 32 |
|
47 | | -Before submitting, confirm that this change aligns with those principles. |
48 | 33 |
|
49 | | ---- |
| 34 | +## How to Test the Changes |
| 35 | +<!-- |
| 36 | +- Step-by-step instructions to test the change. |
| 37 | +- Any required setup (e.g. multiple players, number of bots, specific configuration). |
| 38 | +- Expected behavior and how to verify it. |
| 39 | +--> |
50 | 40 |
|
51 | | -## Feature Evaluation |
52 | 41 |
|
53 | | -Please answer the following: |
54 | 42 |
|
55 | | -- Describe the **minimum logic** required to achieve the intended behavior? |
56 | | -- Describe the **cheapest implementation** that produces an acceptable result? |
57 | | -- Describe the **runtime cost** when this logic executes across many bots? |
| 43 | +## Impact Assessment |
| 44 | +<!-- As a generic test, before and after measure of pmon (playerbot pmon tick) can help you here. --> |
| 45 | +- Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots? |
| 46 | + - [ ] No, not at all |
| 47 | + - [ ] Minimal impact (**explain below**) |
| 48 | + - [ ] Moderate impact (**explain below**) |
58 | 49 |
|
59 | | ---- |
60 | 50 |
|
61 | | -## How to Test the Changes |
62 | 51 |
|
63 | | -- Step-by-step instructions to test the change |
64 | | -- Any required setup (e.g. multiple players, bots, specific configuration) |
65 | | -- Expected behavior and how to verify it |
| 52 | +- Does this change modify default bot behavior? |
| 53 | + - [ ] No |
| 54 | + - [ ] Yes (**explain why**) |
66 | 55 |
|
67 | | -## Complexity & Impact |
68 | 56 |
|
69 | | -Does this change add new decision branches? |
70 | | -- - [ ] No |
71 | | -- - [ ] Yes (**explain below**) |
72 | 57 |
|
73 | | -Does this change increase per-bot or per-tick processing? |
74 | | -- - [ ] No |
75 | | -- - [ ] Yes (**describe and justify impact**) |
| 58 | +- Does this change add new decision branches or increase maintenance complexity? |
| 59 | + - [ ] No |
| 60 | + - [ ] Yes (**explain below**) |
76 | 61 |
|
77 | | -Could this logic scale poorly under load? |
78 | | -- - [ ] No |
79 | | -- - [ ] Yes (**explain why**) |
80 | | ---- |
81 | 62 |
|
82 | | -## Defaults & Configuration |
83 | 63 |
|
84 | | -Does this change modify default bot behavior? |
85 | | -- - [ ] No |
86 | | -- - [ ] Yes (**explain why**) |
| 64 | +## Messages to Translate |
| 65 | +<!-- |
| 66 | +Bot messages have to be translatable, but you don't need to do the translations here. You only need to make sure |
| 67 | +the message is in a translatable format, and list in the table the message_key and the default English message. |
| 68 | +Search for GetBotTextOrDefault in the codebase for examples. |
| 69 | +--> |
| 70 | +Does this change add bot messages to translate? |
| 71 | +- [ ] No |
| 72 | +- [ ] Yes (**list messages in the table**) |
87 | 73 |
|
88 | | -If this introduces more advanced or AI-heavy logic: |
89 | | -- - [ ] Lightweight mode remains the default |
90 | | -- - [ ] More complex behavior is optional and thereby configurable |
91 | | ---- |
| 74 | +| Message key | Default message | |
| 75 | +| --------------- | ------------------ | |
| 76 | +| | | |
| 77 | +| | | |
92 | 78 |
|
93 | 79 | ## AI Assistance |
94 | | - |
95 | | -Was AI assistance (e.g. ChatGPT or similar tools) used while working on this change? |
96 | | -- - [ ] No |
97 | | -- - [ ] Yes (**explain below**) |
98 | | - |
| 80 | +<!-- |
| 81 | +AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor. |
| 82 | +We expect contributors to be honest about what they do and do not understand. |
| 83 | +--> |
| 84 | +Was AI assistance used while working on this change? |
| 85 | +- [ ] No |
| 86 | +- [ ] Yes (**explain below**) |
| 87 | +<!-- |
99 | 88 | If yes, please specify: |
| 89 | +- Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation). |
| 90 | +- Which parts of the change were influenced or generated, and whether it was thoroughly reviewed. |
| 91 | +--> |
100 | 92 |
|
101 | | -- AI tool or model used (e.g. ChatGPT, GPT-4, Claude, etc.) |
102 | | -- Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation) |
103 | | -- Which parts of the change were influenced or generated |
104 | | -- Whether the result was manually reviewed and adapted |
105 | 93 |
|
106 | | -AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor. |
107 | | -Any AI-influenced changes must be verified against existing CORE and PB logic. We expect contributors to be honest |
108 | | -about what they do and do not understand. |
109 | | - |
110 | | ---- |
111 | 94 |
|
112 | 95 | ## Final Checklist |
113 | 96 |
|
114 | | -- - [ ] Stability is not compromised |
115 | | -- - [ ] Performance impact is understood, tested, and acceptable |
116 | | -- - [ ] Added logic complexity is justified and explained |
117 | | -- - [ ] Documentation updated if needed |
118 | | - |
119 | | ---- |
| 97 | +- [ ] Stability is not compromised. |
| 98 | +- [ ] Performance impact is understood, tested, and acceptable. |
| 99 | +- [ ] Added logic complexity is justified and explained. |
| 100 | +- [ ] Documentation updated if needed (Conf comments, WiKi commands). |
120 | 101 |
|
121 | 102 | ## Notes for Reviewers |
122 | | - |
123 | | -Anything that significantly improves realism at the cost of stability or performance should be carefully discussed |
124 | | -before merging. |
| 103 | +<!-- Anything else that's helpful to review or test your pull request. --> |
0 commit comments