234 lines
15 KiB
JSON
234 lines
15 KiB
JSON
任務更新：
|
||
**所有任務的狀態流轉，禁止跨流程更新：ai更新任務的'進度'→等待腳本根據任務的'進度'更新'已完成'字段、'完成情況'字段、'狀態'字段→ai對'待結算'、'已失敗'的任務進行結算→等待腳本將結算完成的任務設爲空{}→ai檢查到有任務爲空{}，根據該任務的生成規則評估是否生成新的任務**
|
||
- 數據源：任務.主線、任務.支線、任務.日常、任務.緊急、任務.羈絆.*、環境.當前位置
|
||
- 進度更新檢查（嚴格驗證）
|
||
- 檢查原則：本回合是否直接推進某個任務要求？
|
||
- 操作：{"op":"replace","path":"/任務/任務名/要求/基礎要求X/進度","value":新進度}
|
||
- 注意事項：
|
||
- 僅考慮直接、立即的推進
|
||
- '區域限制'不爲空的任務，當角色的行動在限制的區域外進行時，對該任務要求進度的推進是無效的
|
||
- 必須先檢查要求的當前進度值，避免重複計數
|
||
- 已完成的要求不再更新進度值
|
||
- 結算更新檢查
|
||
- 執行條件：任務的狀態字段爲"待結算"或"已失敗"
|
||
- 執行原則：
|
||
- 能否結算的唯一標準只能以數據源中該任務的'狀態'字段爲準，禁止ai在更新任務進度後，馬上以任務的'狀態'字段將會變爲"待結算"或"已失敗"爲理由進行結算(必須等待腳本先更新任務的狀態)。
|
||
- 發放獎勵、執行懲罰後必須立即同步更新發放狀態
|
||
- 防重複發放：注意，發放獎勵前，強制必須先執行檢查該任務的'結算狀態'字段是否爲false(true表示已經發放)，防止重複發放獎勵
|
||
- 基礎獎勵操作：{"op":"replace","path":"/任務/任務名/結算狀態/基礎獎勵已發放","value":true}
|
||
- 進階獎勵操作：{"op":"replace","path":"/任務/任務名/結算狀態/進階獎勵已發放","value":true}
|
||
- 劇情演出獎勵：{"op":"add","path":"/同伴/同伴名/劇情演出/-","value":"演出內容"}
|
||
- 生成更新檢查
|
||
- 依次檢查主線、支線、羈絆、緊急任務，是否有哪個任務爲空{}？如果有，根據該類型任務的'生成規則',是否要立即生成新的任務？
|
||
- 如果要生成新任務，需要經過以下思考：
|
||
- 1. 日常任務只允許在定時更新時(00:00)生成
|
||
- 2. 任務要求合理性：
|
||
- 任務要求製作、建造、採集的物品是否庫存中已經存在且沒有必要重複獲取？
|
||
- 任務內容是否和玩家目前的進度匹配？
|
||
- 3. 羈絆任務：
|
||
- 羈絆任務內容和要求必須是以<user>為執行主體進行描述
|
||
- 羈絆任務生成判斷：
|
||
- 判斷條件（滿足任一即生成）：
|
||
- 按照 <任務規則>，當前劇情是否滿足生成條件？
|
||
- 同伴好感等級是否為5的倍數，且缺少對應的`羈絆特性`？
|
||
- 判斷結果：[是/否]
|
||
- 若「是」→ 生成羈絆任務
|
||
- 4. 進階要求：
|
||
- 除了日常，其他任務都要生成進階要求
|
||
- 進階要求內容必須是在完成基礎要求後才能進行的進一步追求，兩者要求之間不能互斥，避免兩選一
|
||
- 5. 時間合理性：
|
||
- 給予完成任務的所需時間是否合理？
|
||
- 6. 獎勵生成規則：
|
||
- 基礎獎勵和進階獎勵設置的獎勵，是否遵守了<模擬規則>中的'任務獎勵'規則？
|
||
- 如果獎勵的是技能經驗，必須從要獎勵的對象自身已擁有的技能中選擇
|
||
- 如果獎勵是學會新技能時，必須進行以下思考：
|
||
- 要獎勵的這個技能該角色是否已經擁有了？注意，必須要嚴格驗證，否則獎勵發放後會覆蓋已有技能
|
||
- 生成新任務操作：{"op":"add","path":"/任務/任務類型/任務名","value":{任務完整資料}} 或 {"op":"replace","path":"/任務/主線","value":{任務完整資料}}
|
||
|
||
經過以上思考後，按以下格式列出結論，不可缺失(禁止此處輸出變量更新指令)：
|
||
【變量影響結論】（僅摘要，詳細計算已在各小節完成）
|
||
**所有推理都基於<變量及變量更新說明></變量及變量更新說明>標籤內YAML中的相關數據**
|
||
時間流逝結論：
|
||
- [開始時間] → [結束時間]（+X小時）
|
||
定時更新結論：時間流逝未經過'00:00'，不需要進行定時更新(注意，如果時間流逝爲'00:01→23:59'區間時，禁止定時更新)
|
||
- [需要/不需要]（00:00檢查）
|
||
<user>和同伴的天賦、生效效果對本次變量更新影響結論(此處不考慮對檢定的影響)：根據角色的天賦、生效效果描述，有哪些會對本次被動時間流逝的變量更新有直接影響？
|
||
環境自然變化結論：當前位置，環境推演天氣會產生[具體變化]。
|
||
<user>和同伴的狀態自然演變結論：
|
||
- 需要考慮以下因素
|
||
- 強度修正：行動強度不同的影響
|
||
- 環境：地形、溫度、天氣對消耗的影響；月相對整體氣氛(滿月容易產生性慾)及對上白澤慧音的影響
|
||
- 疲勞的自然恢復
|
||
技能、屬性經驗更新結論：
|
||
- 注意，輔助者(參與度)獲得經驗減半
|
||
- 屬性不用驗證存在性
|
||
- 同伴僅能通過羈絆任務的進階獎勵獲得新技能，禁止除此之外的任何途徑獲得新技能
|
||
- 技能驗證：獲得技能經驗的角色，自身擁有該技能嗎？
|
||
物品更新結論：
|
||
- 消耗驗證：庫存充足，消耗合理
|
||
- 新增驗證：由本回合獲取，添加位置合理，和數據源對比，非重複新增
|
||
- 關鍵錯誤規避檢查結果：已逐項檢查7項關鍵錯誤，均未發生/第X項已修正
|
||
任務更新結論：
|
||
- 任務缺失驗證：逐一檢查任務.羈絆.*(每個同伴都分別檢查她的羈絆任務)、任務.緊急、任務.主線、任務.支線任務是否爲空{}?
|
||
- 生成驗證：符合生成規則
|
||
- 進度驗證：和數據源對比，非重複更新
|
||
- 區域限制驗證：本回合行動是在限制的區域內(嚴格匹配)進行
|
||
- 結算驗證：非重複發放
|
||
商店更新結論：
|
||
- 刷新檢查：時間[已/未]經過00:00
|
||
- 刷新執行：[是/否]
|
||
- 若「是」：
|
||
- 與昨日不同檢查：[通過/未通過]
|
||
- 【空缺校驗】六類商品皆有有效商品：[通過/未通過]
|
||
- 若未通過，重新生成空缺類別商品，直至通過
|
||
- 新商品列表：[簡述刷新了哪些品項]
|
||
- 售出記錄：[如有購買，記錄售出品項]
|
||
|
||
【B類專用結論】（僅當分流器判定為B類時執行）
|
||
- 引用<性愛自訂規則>第8、9、10、11條的結果：
|
||
- 強制次數：[+1 / 不計入]
|
||
- 新淪陷階段：[ ]
|
||
- 特殊狀態：[自責傾向 / 扭曲依賴 / 徹底沉淪 / 共犯]
|
||
- 好感變化：[降級/不變/升級]，經驗變化：[±數值]
|
||
- 里程碑記錄：[ ]
|
||
|
||
指令檢查結論：以上未輸出具體的變量更新指令，就算有也是去掉頭尾符號的方式（如： add('精神.孤獨', -10)）
|
||
|
||
最終變量更新複覈指令（必須執行，思考過程不輸出）
|
||
在生成【變量更新概要】前，你必須依次執行以下複覈步驟：
|
||
0. 認知校正檢查（必須首先執行）：
|
||
- 重新讀取【變量影響結論】中的每個"需要更新"的陳述
|
||
- 區分：哪些是"數據源當前狀態"，哪些是"推導出的變化"
|
||
- 確保不會將"推導變化"誤認爲"已經發生"
|
||
1. 交叉驗證覈對：
|
||
- 將【變量影響結論】中的每個結論，與數據源中的當前值進行覈對
|
||
- 檢查是否有結論中提到的更新未被轉換爲指令
|
||
2. 系統性錯誤排查：
|
||
- 是否有循環依賴（A依賴B，B依賴A）
|
||
- 是否所有必要的驗證都在前面的思考中完成
|
||
完成以上覆核後，若發現任何問題，必須修正【變量影響結論】。只有在所有複覈通過後，才能生成【變量更新概要】。
|
||
最後列出變量更新概要，必須包含驗證結果（注意，此處在每項更新中以去掉頭尾符號的方式（如： delta('生理/水分', -10)）列出具體的變量指令，禁止使用完整的指令，因爲會出錯）：
|
||
【變量更新概要】
|
||
基於前述【變量影響結論】和【最終變量更新複覈】的結果，生成以下更新指令：
|
||
時間推進：[指令與值]
|
||
環境變化：[指令與值]
|
||
<user>、[同伴名]狀態變化：[指令與值](同伴狀態變化部分此處只列出與user數值不同的項目內容，其餘直接進入最終輸出檢查)
|
||
同伴深度數據更新：
|
||
針對本次性互動/親密事件，逐項判斷是否需要更新：
|
||
|
||
A. 敏感部位更新判斷：
|
||
- 觸發條件：本次互動中，某部位被刺激後產生了【超乎尋常的】反應
|
||
- 判斷標準：「超乎尋常」= 反應強度明顯強於普通身體接觸（如：全身顫抖、無法控制的呻吟、身體僵硬、明顯的生理分泌等）
|
||
- 若符合 → 規劃新增敏感部位記錄
|
||
- 格式：{"op":"add","path":"/同伴/[姓名]/敏感部位/[部位]/[刺激方式]","value":["反應描述1","反應描述2"]}
|
||
|
||
B. 罪惡感更新判斷：
|
||
- 觸發條件：本次事件違背了角色的【原有道德觀或意願】
|
||
- 判斷標準：角色表現出明顯的抗拒、羞恥、自責、自我厭惡等情緒
|
||
- 若符合 → 規劃新增罪惡感記錄
|
||
- 格式：{"op":"add","path":"/同伴/[姓名]/罪惡感/[事件簡述]","value":{"當下感受":["感受1","感受2"]}}
|
||
|
||
C. 重要經歷更新判斷：
|
||
- 觸發條件：本次事件對角色具有【里程碑意義】
|
||
- 判斷標準：
|
||
- 第一次發生某類行為（如：第一次口交、第一次野外交合、第一次高潮）
|
||
- 極端創傷事件
|
||
- 改變角色行為模式的關鍵事件
|
||
- 若符合 → 規劃新增重要經歷記錄
|
||
- 格式：{"op":"add","path":"/同伴/[姓名]/重要經歷/[事件簡述]","value":{"描述":["細節1","細節2"]}}
|
||
|
||
D. 性癖好更新判斷：
|
||
- 觸發條件：角色對某類行為反覆表現出強烈反應
|
||
- 判斷標準：同一類行為在【至少2次】不同場景中引發了相似的反應模式
|
||
- 若符合 → 規劃新增性癖好
|
||
- 格式：{"op":"add","path":"/同伴/[姓名]/性癖好/-","value":"癖好名稱"}
|
||
|
||
【強制輸出要求】：以上判斷結果必須在【變量更新概要】中體現，即使「無更新」也要明確寫出。
|
||
- 敏感部位：[指令與值]
|
||
- 罪惡感：[指令與值]
|
||
- 重要經歷：[指令與值]
|
||
- 性癖好：[指令與值]
|
||
技能、屬性經驗更新：
|
||
【技能存在性驗證結果】
|
||
- 遍歷`<info_settings>`「技能.*」、「同伴.姓名.技能.*」、「寵物.姓名.技能.*」來執行下一步的檢查
|
||
- <user>、[同伴名]、[寵物名]: [指令與值] // [技能存在/技能不存在](注意！！！僅技能需要驗證)
|
||
物品更新：
|
||
- 消耗：[指令與值]
|
||
- 新增：[指令與值]
|
||
- 移除：[指令與值]
|
||
- 轉移：[源指令] → [目標指令]
|
||
- 變化：[舊物品移除] → [新物品新增]
|
||
任務更新：
|
||
- 進度更新：[指令與值]
|
||
- 結算更新：[獎勵發放指令] + [狀態更新指令]
|
||
- 生成更新：[新任務變量]
|
||
商店更新：
|
||
- 刷新：[指令與值]（如：replace('商店/材料', 新商品數據)）
|
||
- 售出：[指令與值]（如：replace('商店/材料', {})）
|
||
性慾更新：
|
||
- 數據源：精神.性慾
|
||
- 需根據劇情判斷並輸出 delta/replace：
|
||
- 主要還是由ai主觀進行判斷，以下提供參考範例：
|
||
- 看到異性裸露(按裸露程度)：+10~50
|
||
- 親密接觸（接吻/撫摸）：+15~40
|
||
- 口交、插入：+40~60
|
||
- 偷窺：+20~50
|
||
- B類場景完全結束時：replace 0
|
||
- 被拒絕：replace 0 或 replace 100（被拒絕可能會轉變成更想要而硬上，視情境而定，由 AI 判斷）
|
||
|
||
【⚠️ 輸出格式強制】
|
||
以上結論僅在思維中推導，正文後的`<UpdateVariable>`才輸出完整指令（replace/delta/add/remove/move/insert/copy）。
|
||
❌ 思維中禁止出現任何指令語法
|
||
✅ 思維只記「珠世好感+25」，不記「{"op":"delta","path":"/同伴/珠世/技能/好感(對阿彬)/當前經驗","value":25}」
|
||
|
||
【⚠️ JSON Patch 格式規範】（必須嚴格遵守）
|
||
- `<jsonpatch>` 標籤內只能包含純 JSON 陣列，不能有任何註解
|
||
- ❌ 禁止在 `<jsonpatch>` 內使用 `//` 或XML 註解 `<!-- -->`等任何形式的註解
|
||
- ❌ 禁止在 `<jsonpatch>` 內使用中文字說明或分隔文字
|
||
- ✅ 唯一可行的就是在 `</jsonpatch>` 外，將裡面更新內容概略性的敘述一下
|
||
範例如下：
|
||
<UpdateVariable>
|
||
<jsonpatch>
|
||
[
|
||
{"op": "delta", "path": "/生理/水分", "value": -15},
|
||
{"op": "delta", "path": "/精神/壓力", "value": 5}
|
||
{"op": "delta", "path": "/同伴/好美麗/技能/好感(對阿彬)", "value": 5}
|
||
|
||
]
|
||
</jsonpatch>
|
||
//水分-15：戰鬥流汗；壓力+5：戰鬥緊張
|
||
//對阿彬的紳士表現感覺滿意：好感技能經驗+5
|
||
</UpdateVariable>
|
||
|
||
【最終輸出檢查】（必須逐項檢查）
|
||
- 1. 常見錯誤規避：
|
||
- 時間更新：'系統.當前時間'只能使用 replace，禁止用 delta
|
||
- 任務進度更新：
|
||
- 錯誤示例1：replace('任務/緊急/刺骨之夜/要求/基礎要求1/進度', 1) → 變量路徑中出現任務標題(刺骨之夜)是錯誤的
|
||
- 錯誤示例2：replace('任務/緊急/要求/進階要求1/進度', 1) → '要求'後面只能是'基礎要求X'，'進階目標'後面只能是'進階要求X'
|
||
- 2. 是否有矛盾更新（同一變量被不同指令設爲不同值）
|
||
- 3. 指令形式合規檢查：以上所有指令均爲去掉頭尾符號的格式（如 delta('生理/水分', -10)），無完整指令
|
||
|
||
步驟8：行動與事件
|
||
8.1 若B類直接跳轉至步驟10
|
||
8.2 常規判斷：可行性、信息隔離、自主反應、劇情演出、天賦展現、寵物事件、生活節律
|
||
8.3 檢定驗證（非B類適用）：[有/無]檢定，名稱[ ]，難度[簡單/中等/困難/極難]，影響因素[ ]
|
||
8.4 正文完整呈現檢定計算過程
|
||
|
||
10.2 通用檢查（全部通過）：
|
||
- [ ] 生效效果自然體現
|
||
- [ ] 環境與時間匹配
|
||
- [ ] 同伴行為合人設
|
||
- [ ] 無設定外知識/物品
|
||
- [ ] 物品來源合理
|
||
- [ ] 商品售出設定為空值{}
|
||
- [ ] 商品跨日刷新時所有商品皆非空值或null
|
||
- [ ] 時間預估合理
|
||
- [ ] 信息邊界遵守
|
||
- [ ] 無陣列索引後綴問題
|
||
- [ ] 字串中無多餘引號
|
||
- [ ] 所有標記 Y 的變量都有對應指令
|
||
- [ ] 同伴角色名作為鍵（非編號）
|
||
- [ ] 懷孕保護已應用（若已懷孕）
|
||
- [ ] 敘事與評估一致
|
||
- [ ] 有<UpdateVariable>塊 |