fixed issueeessss
This commit is contained in:
parent
aea08dc3fb
commit
874911821f
20 changed files with 1947 additions and 897 deletions
574
docs/prompt.txt
574
docs/prompt.txt
|
|
@ -1,485 +1,265 @@
|
|||
You are working on the Tarinai observation game.
|
||||
You are modifying an existing JavaScript browser game project.
|
||||
|
||||
Base input:
|
||||
Implement a personality system for the \u201ctarinai\u201d creatures. Keep the implementation conservative and debuggable. Do not add extra systems beyond the specification below.
|
||||
|
||||
* Start from `tarinai_colony_game_fixed_v6.zip`.
|
||||
* Modify the project files directly.
|
||||
* Return a new zip.
|
||||
* Do not remove existing gameplay features unless explicitly instructed.
|
||||
* Preserve the existing Japanese UI text style.
|
||||
* After changes, run syntax checks on all JavaScript files and verify zip integrity.
|
||||
* Bump the cache-busting version in `index.html` so browsers do not keep loading old JS/CSS.
|
||||
## Goal
|
||||
|
||||
Primary goals:
|
||||
Fix the remaining complexity, behavior mismatch, redundant logic, and fragmented-spec issues identified in the v6 audit. Implement all items below. Do not skip any item.
|
||||
Add four continuous personality parameters to each tarinai:
|
||||
|
||||
---
|
||||
* aggression
|
||||
* openness
|
||||
* sociability
|
||||
* neuroticism
|
||||
|
||||
## 1. Family tree update performance
|
||||
Each parameter ranges from `-1.0` to `+1.0`.
|
||||
|
||||
Current issue:
|
||||
The family tree update still performs heavy synchronous preprocessing, causing the main game to freeze.
|
||||
Personality should affect behavior only when the value crosses clear thresholds. Small changes should be recorded internally, but observation logs should only be written when a threshold is crossed.
|
||||
|
||||
Implement:
|
||||
## Personality axes
|
||||
|
||||
* Split heavy preprocessing into small chunks.
|
||||
* Use `requestIdleCallback` when available, with a safe `setTimeout` fallback.
|
||||
* Avoid doing large graph construction, signature generation, relationship counting, or DOM creation in one blocking pass.
|
||||
* The game loop must remain responsive while family tree data is prepared.
|
||||
### aggression
|
||||
|
||||
Update timing rules:
|
||||
Range:
|
||||
|
||||
* When the family tree panel is hidden:
|
||||
* low side: calm
|
||||
* high side: irritable
|
||||
|
||||
* Do not update every 5 seconds.
|
||||
* Check/update at most once every 30 seconds.
|
||||
* When the family tree panel is visible:
|
||||
Behavior:
|
||||
|
||||
* Do not update on a fixed 5-second timer.
|
||||
* Update only when the family tree is dirty, meaning a relevant change occurred.
|
||||
* Relevant dirty events include at least:
|
||||
* High aggression makes the tarinai more likely to threaten others, start fights, or retaliate.
|
||||
* Low aggression makes the tarinai less likely to start fights.
|
||||
|
||||
* birth
|
||||
* death
|
||||
* parent/child relationship creation
|
||||
* mate/partner relationship creation or change
|
||||
* name/identity data change that affects the family tree display
|
||||
* Add or use a clear dirty flag such as `familyTreeDirty`.
|
||||
* Mark dirty from the source of the change, not by repeatedly recomputing expensive signatures.
|
||||
* If a background update is already running, do not start another one.
|
||||
* If a newer dirty event occurs while an update is running, schedule one additional update after the current update completes.
|
||||
Changes:
|
||||
|
||||
Expected result:
|
||||
* Winning fights should slightly increase aggression.
|
||||
* Losing fights should slightly decrease aggression.
|
||||
|
||||
* Opening or updating the family tree should not freeze the main simulation.
|
||||
* Hidden family tree work should be very rare.
|
||||
* Visible family tree should refresh promptly after actual changes.
|
||||
### openness
|
||||
|
||||
---
|
||||
Range:
|
||||
|
||||
## 2. Coward personality condition
|
||||
* low side: conservative
|
||||
* high side: playful
|
||||
|
||||
Current issue:
|
||||
The “coward” condition may count total fight results and per-relationship fight results together, causing double counting.
|
||||
Behavior:
|
||||
|
||||
Implement:
|
||||
* High openness makes the tarinai more likely to wander farther, investigate new objects, and play with toys such as balls.
|
||||
* Low openness makes the tarinai prefer familiar or nearby areas.
|
||||
|
||||
* The 5% chance to become `臆病` must be based only on total fight wins and total fight losses.
|
||||
* Do not include per-relationship win/loss counts in this condition.
|
||||
* Trigger condition:
|
||||
Changes:
|
||||
|
||||
* The Tarinai has just taken damage.
|
||||
* Its total fight losses are greater than its total fight wins.
|
||||
* Then it has a 5% chance to change personality to `臆病`.
|
||||
* Avoid changing the personality repeatedly if it is already `臆病`.
|
||||
* Being petted by the cursor should slightly increase openness.
|
||||
|
||||
Expected result:
|
||||
### sociability
|
||||
|
||||
* The calculation uses only aggregate lifetime fight result counters.
|
||||
* No double counting.
|
||||
Range:
|
||||
|
||||
---
|
||||
* low side: loner
|
||||
* high side: social
|
||||
|
||||
## 3. Disease fight initiation and targeting rules
|
||||
Behavior:
|
||||
|
||||
Implement the following disease fight rules exactly:
|
||||
* High sociability makes the tarinai more likely to approach other tarinai, especially parents, children, friends, or the cursor.
|
||||
* High sociability also makes the tarinai more likely to react when a parent, child, or friend is fighting nearby.
|
||||
* Low sociability makes the tarinai prefer being alone.
|
||||
|
||||
Fight initiation:
|
||||
Changes:
|
||||
|
||||
* Tarinai with `爆発病` can initiate fights.
|
||||
* Tarinai with `ずんち病` can initiate fights.
|
||||
* Tarinai with any other disease must not initiate fights.
|
||||
* Healthy Tarinai may initiate fights according to the existing rules.
|
||||
* Spending time near parents, children, or friends should slightly increase sociability.
|
||||
|
||||
Being targeted / challenged:
|
||||
### neuroticism
|
||||
|
||||
* Tarinai with `ねむり病` must not be targeted for fights.
|
||||
* Tarinai with any other disease may still be targeted/challenged by another Tarinai.
|
||||
* This means:
|
||||
Range:
|
||||
|
||||
* `爆発病` and `ずんち病`: can initiate and can be targeted.
|
||||
* Other non-sleep diseases: cannot initiate, but can be targeted.
|
||||
* `ねむり病`: cannot initiate and cannot be targeted.
|
||||
* low side: insensitive / unfazed
|
||||
* high side: delicate / sensitive
|
||||
|
||||
Apply consistently to:
|
||||
Behavior:
|
||||
|
||||
* Normal fight selection.
|
||||
* Forced fight logic.
|
||||
* Fight-food effects such as `けんか餅`.
|
||||
* Any helper such as `canStartFight`, `canBeFightTarget`, or equivalent.
|
||||
* High neuroticism makes the tarinai gain more stress from unpleasant stimuli such as corpses, poop, nearby fights, or overcrowding.
|
||||
* Low neuroticism makes the tarinai less affected by such stimuli.
|
||||
|
||||
Expected result:
|
||||
Changes:
|
||||
|
||||
* Disease rules are not handled by scattered ad-hoc checks.
|
||||
* Use clear helper functions if they do not already exist.
|
||||
* Touching poop or corpses should still increase stress immediately.
|
||||
* However, repeated exposure should slightly reduce neuroticism over time, representing habituation.
|
||||
* This means tarinai can become less sensitive to unpleasant stimuli after repeated exposure.
|
||||
|
||||
---
|
||||
Important:
|
||||
|
||||
## 4. Collision and external-force unification
|
||||
* Do not treat \u201ccowardice\u201d as a direct low-aggression state.
|
||||
* If a cowardly tag is needed, derive it as a compound state from high neuroticism and low aggression.
|
||||
* Do not implement a separate cowardice parameter.
|
||||
|
||||
Current issues:
|
||||
## Birth personality and current personality
|
||||
|
||||
* Ball speed cap was removed, but some collision detection still uses capped sweep/search distances.
|
||||
* Very fast balls can still tunnel through objects.
|
||||
* Explosion knockback and ball knockback can be reduced by normal movement speed caps.
|
||||
* Knockback, collision damage, explosion impulse, and normal movement are handled inconsistently.
|
||||
Each tarinai should have two personality objects:
|
||||
|
||||
Implement:
|
||||
```js
|
||||
birthPersonality
|
||||
currentPersonality
|
||||
```
|
||||
|
||||
* Separate normal self-propelled movement from external impulse/knockback.
|
||||
* External impulses must not be clamped by the normal Tarinai walking speed cap.
|
||||
* Add or refactor toward helper methods such as:
|
||||
Rules:
|
||||
|
||||
* `applyImpulse(entity, vx, vy, options)`
|
||||
* `applyKnockback(entity, sourceX, sourceY, strength, options)`
|
||||
* `applyImpactDamage(target, amount, cause)`
|
||||
* `resolveCircleCircleCollision(...)`
|
||||
* `resolveCircleRectCollision(...)`
|
||||
* Exact helper names are flexible, but the behavior must be centralized and not duplicated.
|
||||
* `birthPersonality` is created at birth and normally does not change.
|
||||
* `currentPersonality` starts equal to `birthPersonality`.
|
||||
* Experience modifies only `currentPersonality`.
|
||||
* The tarinai data UI should show both birth personality and current personality.
|
||||
|
||||
Unlimited ball speed:
|
||||
## Inheritance
|
||||
|
||||
* Do not reintroduce a ball speed cap.
|
||||
* Collision detection must handle high-speed balls using swept movement based on actual frame movement distance.
|
||||
* Remove fixed low `Math.min(...)` collision-search caps that contradict unlimited ball speed.
|
||||
* Ball vs wall, ball vs fence, ball vs nest box, ball vs ball, and ball vs Tarinai should remain reliable at high speed.
|
||||
When a child is born:
|
||||
|
||||
High-speed ball vs Tarinai:
|
||||
```text
|
||||
child birth personality =
|
||||
average of the parents' current personality
|
||||
+ random variation between -0.2 and +0.2 for each parameter
|
||||
```
|
||||
|
||||
* When a sufficiently fast ball hits a Tarinai:
|
||||
Clamp each resulting value to `-1.0` through `+1.0`.
|
||||
|
||||
* Knock the Tarinai away using velocity equal to 1/5 of the ball velocity.
|
||||
* This knockback must be an external impulse, not normal walking movement.
|
||||
* Do not let the normal “play with ball” behavior also run for that same impact if it would conflict.
|
||||
* If the damage from this impact kills the Tarinai, death cause must be `衝突`.
|
||||
Then:
|
||||
|
||||
High-speed Tarinai vs Tarinai:
|
||||
```js
|
||||
child.currentPersonality = child.birthPersonality
|
||||
```
|
||||
|
||||
* When a sufficiently fast Tarinai hits another Tarinai:
|
||||
The child should pass its changed current personality to future descendants, not only its original birth personality.
|
||||
|
||||
* The hit Tarinai should also be knocked away.
|
||||
* Use the attacker’s actual movement/impulse direction and speed.
|
||||
* If collision damage kills a Tarinai, death cause must be `衝突`.
|
||||
## Thresholds and personality tags
|
||||
|
||||
Explosion knockback:
|
||||
Use two threshold levels:
|
||||
|
||||
* Make explosion knockback stronger than before.
|
||||
* Use external impulse, not normal movement velocity.
|
||||
* Knockback should be partly random.
|
||||
* Tarinai closer to the blast center should be thrown faster and farther.
|
||||
* Tarinai farther from the blast center should be thrown less strongly.
|
||||
* Preserve or improve existing explosion damage behavior.
|
||||
* If an explosion kills a Tarinai, keep the appropriate explosion-related death cause, not `衝突`.
|
||||
```text
|
||||
-1.0 to -0.75: strong low-side trait
|
||||
-0.75 to -0.5: slight low-side trait
|
||||
-0.5 to +0.5: neutral, no visible personality tag
|
||||
+0.5 to +0.75: slight high-side trait
|
||||
+0.75 to +1.0: strong high-side trait
|
||||
```
|
||||
|
||||
Expected result:
|
||||
Display tags:
|
||||
|
||||
* Normal walking speed remains bounded.
|
||||
* Knockback from explosions and collisions can exceed walking speed.
|
||||
* High-speed objects do not frequently tunnel through collisions.
|
||||
* Collision behavior is handled by shared primitives rather than several unrelated implementations.
|
||||
* Slight traits should be displayed as \u201cslightly X\u201d.
|
||||
* Strong traits should be displayed as \u201cX\u201d.
|
||||
* Neutral values should not create a visible tag.
|
||||
|
||||
---
|
||||
Example:
|
||||
|
||||
## 5. Ball-to-ball collision
|
||||
* aggression `+0.62` -> \u201cslightly irritable\u201d
|
||||
* aggression `+0.83` -> \u201cirritable\u201d
|
||||
* sociability `-0.58` -> \u201cslightly loner\u201d
|
||||
* sociability `-0.82` -> \u201cloner\u201d
|
||||
* openness `+0.20` -> no tag
|
||||
|
||||
Ensure balls collide with each other robustly.
|
||||
Behavior activation:
|
||||
|
||||
Requirements:
|
||||
* Slight traits affect relevant behavior with a 50% chance when choosing a behavior.
|
||||
* Strong traits affect relevant behavior with a 100% chance when choosing a behavior.
|
||||
* Do not check this every frame. Apply it only during behavior selection or when evaluating a relevant event.
|
||||
|
||||
* Ball vs ball collision must use circle-circle collision.
|
||||
* Resolve overlap.
|
||||
* Exchange or reflect velocity in a physically plausible way.
|
||||
* Work with high-speed balls, not only overlapping balls.
|
||||
* Avoid creating infinite acceleration or NaN velocity.
|
||||
* Do not apply arbitrary maximum speed caps.
|
||||
## Daily personality change limit
|
||||
|
||||
---
|
||||
Add a daily change cap so personality values cannot change too quickly.
|
||||
|
||||
## 6. Solid obstacle and placement logic unification
|
||||
Recommended limits:
|
||||
|
||||
Current issues:
|
||||
Fence, nest box, and placement preview logic are still partly fragmented.
|
||||
```text
|
||||
Per parameter:
|
||||
maximum increase per day: +0.08
|
||||
maximum decrease per day: -0.08
|
||||
|
||||
Implement:
|
||||
Across all parameters:
|
||||
maximum total absolute personality change per day: 0.20
|
||||
```
|
||||
|
||||
* Unify all solid rectangular obstacle collision logic.
|
||||
* Fence and nest box should use the same obstacle system where possible.
|
||||
* Rename misleading helpers if needed:
|
||||
If a change would exceed the daily limit, reduce or ignore the excess change.
|
||||
|
||||
* For example, functions named only for “fence” but now handling nest boxes too should be renamed or wrapped with neutral names such as `solidObstacle`.
|
||||
* Ball, Tarinai movement, path blocking, and placement checks should reference the same obstacle data.
|
||||
Reset these daily counters at the start of each new in-game day.
|
||||
|
||||
Fence collision:
|
||||
## Observation log rules
|
||||
|
||||
* Fence collision bounds must match the visible fence appearance.
|
||||
* If the visual fence is not the same size as the previous hitbox, update the hitbox to match the visual footprint.
|
||||
* Avoid separate visual size and collision size unless explicitly documented in one definition table.
|
||||
Write personality change entries to the observation log only when a threshold is crossed.
|
||||
|
||||
Nest box collision:
|
||||
Log when:
|
||||
|
||||
* Preserve the existing 3×3 nest box hitbox rule:
|
||||
* a value crosses `+0.5`
|
||||
* a value crosses `+0.75`
|
||||
* a value crosses `-0.5`
|
||||
* a value crosses `-0.75`
|
||||
* a value returns from a visible trait range back into neutral
|
||||
|
||||
* If the nest box is divided into a 3×3 grid, the collidable cells are:
|
||||
Do not log every small personality change.
|
||||
|
||||
* top-left
|
||||
* top-center
|
||||
* top-right
|
||||
* middle-left
|
||||
* middle-right
|
||||
* The middle-center, bottom-left, bottom-center, and bottom-right cells are passable/enterable according to the current nest behavior.
|
||||
* Ball must bounce off these nest box solid cells.
|
||||
* Tarinai must not path through these solid cells.
|
||||
Example log messages:
|
||||
|
||||
Placement preview:
|
||||
```text
|
||||
\u201cMochi\u201d has become slightly irritable after winning fights.
|
||||
\u201cMimi\u201d has become playful after spending time with toys.
|
||||
\u201cNoko\u201d has become less sensitive after repeated contact with corpses.
|
||||
\u201cTari\u201d no longer seems especially social.
|
||||
```
|
||||
|
||||
* The preview highlight must use the exact same placement validation as actual placement.
|
||||
* If the preview is red, clicking must not place the object.
|
||||
* If the preview is green, clicking should place the object at the previewed position.
|
||||
* Do not silently clamp or auto-correct an out-of-bounds placement to an in-bounds location.
|
||||
* If the planned placement would extend outside the field, the highlight must turn red.
|
||||
* Fix the issue where a fence preview extending outside the field does not turn red.
|
||||
* The highlighted preview position should show the true placement footprint, not a different corrected footprint.
|
||||
Use the existing observation log system if one exists.
|
||||
|
||||
Expected result:
|
||||
## Tarinai data UI
|
||||
|
||||
* Placement UI, actual placement, and collision behavior agree.
|
||||
* No “red but placeable” or “green but placed elsewhere” behavior.
|
||||
Update the tarinai data UI to show personality information clearly.
|
||||
|
||||
---
|
||||
It should include:
|
||||
|
||||
## 7. Item/tool definition unification
|
||||
1. Birth personality
|
||||
2. Current personality
|
||||
3. Visible personality tags derived from current personality
|
||||
|
||||
Current issues:
|
||||
Tool names, labels, icons, sizes, placement rules, and descriptions are scattered across multiple files.
|
||||
Example structure:
|
||||
|
||||
Implement:
|
||||
```text
|
||||
Personality Tags:
|
||||
slightly irritable / social
|
||||
|
||||
* Create or consolidate a single source of truth for tool/item definitions.
|
||||
* It should include at least:
|
||||
Birth Personality:
|
||||
Aggression: -0.12
|
||||
Openness: +0.31
|
||||
Sociability: +0.48
|
||||
Neuroticism: +0.66
|
||||
|
||||
* internal id
|
||||
* Japanese label
|
||||
* tooltip text
|
||||
* UI icon or icon renderer
|
||||
* game appearance reference where applicable
|
||||
* placement size / footprint
|
||||
* whether it is placeable
|
||||
* whether it is scaleable, if applicable
|
||||
* collision shape if applicable
|
||||
* Use this definition in the tool UI, placement preview, placement logic, and logs where appropriate.
|
||||
* Do not leave conflicting duplicate label/icon/size definitions in separate files unless unavoidable.
|
||||
Current Personality:
|
||||
Aggression: +0.57
|
||||
Openness: +0.34
|
||||
Sociability: +0.76
|
||||
Neuroticism: +0.22
|
||||
```
|
||||
|
||||
Specific icon requirements:
|
||||
Keep the UI compact. Do not create a large new panel unless necessary.
|
||||
|
||||
* `つつく` must use `👈`.
|
||||
* `つまむ` must use `🤏`.
|
||||
* `洗浄` must use the shower emoji `🚿`.
|
||||
* Remove or stop referencing old PNG icons for `つつく` and `つまむ`.
|
||||
* Fix the nest box tool UI icon so it matches the actual in-game nest box appearance.
|
||||
* Ensure every tool that appears in the tool UI has an icon.
|
||||
* Avoid mojibake/garbled icon rendering.
|
||||
## Implementation constraints
|
||||
|
||||
Water tool:
|
||||
* Keep the code simple and localized.
|
||||
* Reuse existing behavior, logging, and UI systems where possible.
|
||||
* Avoid adding unrelated features.
|
||||
* Avoid adding complex new simulation systems.
|
||||
* Preserve existing save data as much as possible.
|
||||
* If old save data lacks personality fields, initialize them safely.
|
||||
* Clamp all personality values to `-1.0` through `+1.0`.
|
||||
* Add helper functions where useful, such as:
|
||||
|
||||
* `水` must remain removed from the tool UI.
|
||||
* If water still exists as a game object produced by rain or other simulation systems, keep that object behavior.
|
||||
* Remove leftover UI-only water tool entries, labels, tooltips, and placement handlers unless they are still required by non-UI simulation.
|
||||
* `ensurePersonality(tarinai)`
|
||||
* `adjustPersonality(tarinai, key, delta, reason)`
|
||||
* `getPersonalityTraitTags(tarinai)`
|
||||
* `getTraitStrength(value)`
|
||||
* `shouldApplyPersonalityBehavior(tarinai, key, direction)`
|
||||
|
||||
Expected result:
|
||||
## Validation
|
||||
|
||||
* Tool UI no longer has missing icons, old icons, or mismatched nest box visuals.
|
||||
* Tool data is not scattered unnecessarily.
|
||||
After implementation:
|
||||
|
||||
---
|
||||
|
||||
## 8. Observation UI event filtering
|
||||
|
||||
Current issue:
|
||||
Observation UI hides some events by matching Japanese text strings, which is fragile.
|
||||
|
||||
Implement:
|
||||
|
||||
* Remove from the observation UI:
|
||||
|
||||
* events about poking a ball
|
||||
* events of the form “X avoided Y” / `○○が××を避けた`
|
||||
* Prefer event type/category filtering over string matching.
|
||||
* If event objects do not have a type field, add one at event creation.
|
||||
* Keep the events available internally if needed, but do not show them in the observation UI.
|
||||
|
||||
Expected result:
|
||||
|
||||
* Future wording changes do not break event filtering.
|
||||
|
||||
---
|
||||
|
||||
## 9. Death cause normalization
|
||||
|
||||
Ensure these death causes are applied consistently:
|
||||
|
||||
* Death by old age / lifespan:
|
||||
|
||||
* `天寿を全うした`
|
||||
* Tarinai deleted because it went too far outside the field:
|
||||
|
||||
* `仕様により画面外で削除`
|
||||
* Death caused by ball collision or Tarinai collision damage:
|
||||
|
||||
* `衝突`
|
||||
* Explosion death:
|
||||
|
||||
* Keep explosion-related cause.
|
||||
* Existing disease-related deaths:
|
||||
|
||||
* Preserve current intended disease death causes unless they conflict with the above.
|
||||
|
||||
Implementation:
|
||||
|
||||
* Centralize death cause normalization if possible.
|
||||
* Avoid scattered caller-side strings that can drift.
|
||||
* Ensure the family tree, observation UI, and any memorial/death display show the normalized cause.
|
||||
|
||||
---
|
||||
|
||||
## 10. Out-of-bounds object policy
|
||||
|
||||
Current issue:
|
||||
Different object types handle out-of-bounds behavior differently.
|
||||
|
||||
Implement a unified out-of-bounds policy:
|
||||
|
||||
* For objects or entities slightly outside the field:
|
||||
|
||||
* Return them to the nearest valid in-field position.
|
||||
* For objects or entities far outside the field, or with invalid coordinates such as NaN/Infinity:
|
||||
|
||||
* Delete them.
|
||||
* For Tarinai deleted by this system:
|
||||
|
||||
* Death cause must be `仕様により画面外で削除`.
|
||||
* For non-living objects:
|
||||
|
||||
* Delete without a death cause.
|
||||
* Keep wall bounce behavior for balls at normal field boundaries, but still sanitize balls that somehow get far outside or invalid coordinates.
|
||||
|
||||
Expected result:
|
||||
|
||||
* No permanent invisible offscreen objects.
|
||||
* No NaN entities poisoning the simulation.
|
||||
|
||||
---
|
||||
|
||||
## 11. Observation relationship highlight
|
||||
|
||||
Current issue:
|
||||
Relationship highlight during observation can be affected by sprite rotation.
|
||||
|
||||
Implement:
|
||||
|
||||
* Relationship highlights must be drawn in world/screen space independent of the Tarinai sprite rotation.
|
||||
* Do not draw the highlight inside a rotated sprite transform.
|
||||
* Ensure highlight position follows the Tarinai but does not rotate with the Tarinai body.
|
||||
|
||||
Expected result:
|
||||
|
||||
* Highlight remains visually stable regardless of sprite rotation.
|
||||
|
||||
---
|
||||
|
||||
## 12. Nest box behavior preservation
|
||||
|
||||
Preserve and verify previous nest box fixes:
|
||||
|
||||
* Tarinai inside the nest box should be fully transparent in the main field.
|
||||
* Nest box can contain up to 5 Tarinai.
|
||||
* Nest box occupant popup should show each individual on a separate line.
|
||||
* The nest box solid hitbox must follow the 3×3 rule described above.
|
||||
* Ball should bounce off nest box solid hitbox cells.
|
||||
|
||||
Do not regress these behaviors while refactoring obstacles.
|
||||
|
||||
---
|
||||
|
||||
## 13. Encyclopedia / ecology page
|
||||
|
||||
Preserve and verify the `たりないの生態` addition:
|
||||
|
||||
* It must include an explanation of health.
|
||||
* It must include an explanation of stress.
|
||||
* It must use a Tarinai sprite/image with both the health bar and stress bar visible.
|
||||
* Do not break existing encyclopedia entries.
|
||||
|
||||
---
|
||||
|
||||
## 14. Naming and Japanese text preservation
|
||||
|
||||
Preserve previous Japanese terminology changes:
|
||||
|
||||
* `喧嘩傷病` must remain renamed to `きずつき病`.
|
||||
* `寿命` death text must display as `天寿を全うした`.
|
||||
* Use the existing tone/style for Japanese labels and descriptions.
|
||||
|
||||
Do not reintroduce removed or old names.
|
||||
|
||||
---
|
||||
|
||||
## 15. Code quality expectations
|
||||
|
||||
Refactor carefully:
|
||||
|
||||
* Prefer small, well-named helper functions.
|
||||
* Avoid adding more scattered special cases.
|
||||
* Avoid duplicating collision math.
|
||||
* Avoid duplicating item/tool metadata.
|
||||
* Avoid string-matching for gameplay logic where structured data is possible.
|
||||
* Preserve save compatibility where possible.
|
||||
* If save migration is needed, add a safe fallback.
|
||||
|
||||
Add comments only where they clarify non-obvious game rules, especially:
|
||||
|
||||
* disease fight rules
|
||||
* nest box 3×3 collision cells
|
||||
* external impulse vs normal movement
|
||||
* family tree dirty/update scheduling
|
||||
|
||||
---
|
||||
|
||||
## 16. Validation checklist
|
||||
|
||||
Before returning the zip, verify at minimum:
|
||||
|
||||
Static checks:
|
||||
|
||||
* Run `node --check` on every JavaScript file.
|
||||
* Ensure there are no `ReferenceError` risks from renamed helpers.
|
||||
* Ensure old cache version references are updated.
|
||||
|
||||
Manual or scripted behavior checks where practical:
|
||||
|
||||
* Ball vs ball collision works.
|
||||
* Fast ball hitting Tarinai knocks it by ball velocity / 5.
|
||||
* Fast collision death cause is `衝突`.
|
||||
* Explosion throws nearby Tarinai farther than distant Tarinai and is not clamped by walking speed.
|
||||
* Fence preview turns red when the footprint leaves the field.
|
||||
* Red placement preview cannot place an object.
|
||||
* Green placement preview places at the same footprint shown.
|
||||
* Nest box collision uses the required 3×3 cells.
|
||||
* Ball bounces off nest box solid cells.
|
||||
* Family tree hidden update is no more frequent than every 30 seconds.
|
||||
* Family tree visible update happens when dirty, not every 5 seconds.
|
||||
* Family tree processing does not freeze the game.
|
||||
* `臆病` condition uses only total wins/losses.
|
||||
* `爆発病` and `ずんち病` can initiate fights.
|
||||
* Other diseases cannot initiate fights.
|
||||
* `ねむり病` cannot initiate and cannot be targeted.
|
||||
* Other non-sleep diseases can be targeted.
|
||||
* Observation UI does not show ball-poke events or avoid events.
|
||||
* Tool icons are correct: `👈`, `🤏`, `🚿`, and nest box matching in-game appearance.
|
||||
* `水` is absent from the tool UI.
|
||||
* Lifespan death cause is `天寿を全うした`.
|
||||
* Far-outside Tarinai deletion cause is `仕様により画面外で削除`.
|
||||
|
||||
Deliverable:
|
||||
|
||||
* Return a zip named something like `tarinai_colony_game_fixed_v7.zip`.
|
||||
* Include a concise summary of changed areas and validation results.
|
||||
* Run syntax checks for all JavaScript files.
|
||||
* Verify that old tarinai without personality data do not crash the game.
|
||||
* Verify that personality values are clamped.
|
||||
* Verify that daily limits work.
|
||||
* Verify that threshold crossing creates observation logs.
|
||||
* Verify that minor personality changes do not spam logs.
|
||||
* Verify that tarinai data UI shows birth personality, current personality, and visible tags.
|
||||
* Verify that children inherit from parents' current personality with \u00b10.2 random variation.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue