- Remove inconsistent 5-cell (ALPHA/BETA/GAMMA/DELTA/EPSILON) structure
- Update all organizational LORE to reference 11 established cells:
* Digital Vanguard, Critical Mass, Quantum Cabal
* Zero Day Syndicate, Social Fabric, Ghost Protocol
* Ransomware Incorporated, Supply Chain Saboteurs
* Insider Threat Initiative, AI Singularity, Crypto Anarchists
Changes:
- STRAT_001: Add postscript explaining evolution from 5 to 11 cells
- TECH_TOOL_001: Update to reference Critical Mass (not DELTA)
- ENTROPY_PERSONNEL_001: Update Cascade to match Critical Mass member Dr. Sarah Winters
- ENTROPY_OPS_001: Update to reference Digital Vanguard and Insider Threat Initiative
- ENTROPY_HISTORY_001: Note early cell evolution to specialized structure
- PROTO_CELL_001: Remove specific cell designation examples
- TRAIN_RECRUIT_001/TRAIN_OPSEC_001: Remove cell-specific references
- README_ORGANIZATIONAL_LORE: Remove OPCOM_001, update all references
Deletions:
- OPCOM_001: Removed Phase 3 coordination doc (inconsistent with universe bible)
This brings all organizational LORE into consistency with established universe bible.
Created interconnected LORE fragment collection revealing ENTROPY's
world through discoverable artifacts. Organized by content type and
artifact format for progressive player discovery.
**Structure:**
- 4 content categories: ENTROPY Intelligence, The Architect,
Character Backgrounds, Location History
- 7 artifact types: encrypted comms, intelligence reports, text notes,
emails, voice messages, corporate docs, personal items
- Progressive revelation: early game intro → mid game connections →
late game master plan
**10 Seed Fragments Created:**
ENTROPY Intelligence (5):
- Operation Glass House completion report (cell communication)
- Dead drop server list (compromised infrastructure)
- Thermite.py tool analysis (The Architect's signature)
- Operative "Cascade" profile (true believer)
- Complete organizational history (2015-2025, Phase 3 timeline)
The Architect (2):
- Philosophical manifesto on inevitability (ideology revealed)
- Phase 3 activation directive (July 15, complete master plan)
Character Backgrounds (3):
- Sarah Martinez confession email (insider threat desperation)
- Marcus Chen final voice message (civilian courage, survived!)
- Agent 0x99 axolotl philosophy (regeneration vs entropy)
Location History (1):
- Vanguard Financial complete history (25 years, breach, recovery)
**Key Features:**
- Interconnected narrative web (fragments reference each other)
- Educational value (CyBOK-aligned security lessons)
- Moral complexity (sympathetic characters on both sides)
- Emotional impact (personal stories, real consequences)
- Progressive mystery (builds understanding over time)
- Master catalog tracking all connections and discovery timing
**Thematic Elements:**
- ENTROPY: "For entropy and inevitability" - thermodynamic philosophy
- SAFETYNET: "For regeneration and resilience" - axolotl metaphor
- Phase 3: July 15, 2025 - infrastructure-wide coordinated attack
- Moral gray areas: desperate people, true believers, ethical constraints
Fragments demonstrate sophisticated threat actor (ENTROPY) with
decade-long planning, ideological commitment, and custom tooling,
opposed by dedicated defenders (SAFETYNET) who regenerate after
every setback.
See story_design/lore_fragments/MASTER_CATALOG.md for complete
interconnection map and expansion guidelines.
Add comprehensive prompts for all 9 stages of Break Escape scenario development:
- Stage 0: Scenario Initialization - Technical challenges and narrative themes
- Stage 1: Narrative Structure - Three-act story arc development
- Stage 2: Storytelling Elements - Characters, atmosphere, dialogue
- Stage 3: Moral Choices - Player agency and ethical decisions
- Stage 4: Player Objectives - Goals and win conditions
- Stage 5: Room Layout - Physical design with technical constraints
- Stage 6: LORE Fragments - Collectible universe-building content
- Stage 7: Ink Scripting - Interactive dialogue and cutscenes
These prompts guide AI agents (or human designers) through a structured
process to create complete, validated Break Escape scenarios that combine
cybersecurity education with compelling narrative gameplay.
Each prompt includes:
- Role definition and responsibilities
- Required inputs from previous stages
- Essential reference documentation
- Process guidelines and templates
- Quality checklists
- Common pitfalls to avoid
- Tips for success
This completes the story development prompt system alongside the previously
committed README.md and Stage 8 (Review) prompt.
Add comprehensive scenario review and validation prompt (Stage 8) plus
README overview for the story development prompt system.
Note: Files for stages 0-7 need to be recreated - they appear to have
not persisted despite Write tool calls during the session.
This commit transforms the single universe bible document into a comprehensive,
organized set of reference materials across 74 files in 10 major sections.
Major Changes:
- Split original universe bible into chapter-based documents
- Expanded all content by 50-100% with additional lore and details
- Created modular directory structure for easy navigation
- Added extensive cross-referencing between documents
New Structure:
01. Universe Overview - Setting, premise, and tone
02. Organisations - SAFETYNET and ENTROPY detailed profiles
03. ENTROPY Cells - All 11 cells with expanded operations
04. Characters - SAFETYNET operatives and ENTROPY antagonists
05. World Building - Rules, technology, society, timeline
06. Locations - Environment types and notable locations
07. Narrative Structures - Mission types, arcs, player agency
08. LORE System - Collectibles, progression, writing guides
09. Scenario Design - Framework, templates, and examples
10. Reference - Quick reference, checklists, glossary, style guide
Content Expansions:
- SAFETYNET: 28 Field Operations Handbook rules (from 3)
- ENTROPY Cells: 8 key members per cell (from 4)
- Characters: 8 additional SAFETYNET agents created
- Locations: 7 environment type guides
- Scenario Templates: 4 complete templates + 3 full examples
- LORE System: 220 fragments mapped across 6 categories
- Reference: Comprehensive glossary, checklists, and CyBOK guide
Benefits:
- Easier to find specific information
- Consistent universe across all scenarios
- Supports continuous discovery as players progress
- Comprehensive reference for scenario designers
- Expanded lore enables richer storytelling
Total Documentation: ~500KB across 74 markdown files
This commit fixes several issues with East/West side doors:
1. **Sprite Flipping**: Changed flip direction - East doors are now flipped
horizontally instead of West doors (opposite direction as requested)
2. **Door Positioning**: Updated E/W door placement from 2 tiles to 3 tiles
from the top corner for better alignment with room layout
3. **Wall Passage Cutout**: Increased wall tile removal area for side doors
from 1 tile to 3 tiles vertically, creating a wider passage (matching the
inset spacing used for N/S doors)
4. **Side Door Animation**:
- Added `isSideDoor` property to doorProperties to track door type
- Created new 'door_side_open' animation using frames 1-4 (frames 2-5
in 1-indexed notation) of door_side_sheet_32 sprite
- Updated animated door creation to use side door sprite and animation
for E/W doors
5. **Sprite Alignment**: Door sprites now properly align with the tile grid
at 3 tiles from corner position
Changes made in:
- js/systems/doors.js: Door placement, sprite creation, and animations
- js/systems/collision.js: Wall tile removal for wider passages
- js/core/game.js: Side door animation definition
Tested with: scenarios/test_horizontal_layout.json
- Modified createSpriteAtRandomPosition() to accept map parameter
- Items now use actual room dimensions based on tilemap (respects room GU)
- Applied correct padding constraints:
* 1 tile (32px) from left and right sides
* 2 tiles (64px) from top and bottom
- Random item placement now works correctly with variable room sizes
- Ensures items stay within playable room bounds
Related to new room layout system (Grid Unit based positioning)
Updated room positioning to verify overlap for EACH connected room
after grid alignment, not just the group as a whole. This fixes
layouts like:
122
00
Where room 1 was previously positioned with no overlap to room 0.
Changes:
- positionNorthMultiple/positionSouthMultiple: After centering and
aligning group, check first and last room overlap. If insufficient,
shift entire group to ensure minimum overlap for each room.
- positionEastMultiple/positionWestMultiple: Same approach for
vertical stacking along east/west edges.
The algorithm now:
1. Centers the group of connecting rooms over parent
2. Aligns starting position to grid
3. Checks if first room has >= 1 GU overlap, adjusts if not
4. Checks if last room has >= 1 GU overlap, adjusts if not
5. Positions all rooms from the adjusted aligned start
This guarantees each connecting room overlaps with the parent room
by at least one Grid Unit, ensuring proper door placement and room
connectivity.
Updated room positioning algorithm to ensure all connecting rooms are
properly aligned to the grid and have at least one Grid Unit overlap
with the connecting edge of the parent room.
Changes:
- positionNorthMultiple/positionSouthMultiple: Position rooms as a group,
align the starting position to grid, then place rooms side-by-side
without individual alignment to prevent gaps
- positionEastMultiple/positionWestMultiple: Similar approach for vertical
stacking of rooms along east/west edges
This ensures:
- All rooms maintain proper grid alignment
- Connected rooms have guaranteed minimum overlap
- No gaps between adjacent rooms in multi-room connections
- Room layouts match the examples in planning notes
Addresses alignment issues described in new_room_layout documentation
where rooms need to be positioned against the connecting edge with
at least one GU overlap.
This commit addresses three critical issues identified during testing:
1. **Fixed mixed room size door alignment (Issue #1)**
- Updated room positioning logic in positionNorthMultiple, positionSouthMultiple,
positionEastMultiple, and positionWestMultiple functions
- Rooms are now positioned centered on their corresponding door positions
- Ensures doors align properly between different-sized rooms (e.g., 1×1 GU closet
connecting to 2×1 GU hallway)
- Uses same door spacing logic as door placement (edgeInset + doorSpacing)
2. **Implemented East/West single-tile doors (Issue #2)**
- Changed door_side_sheet_32 from image to spritesheet (6 frames, 32×32px each)
- Updated door sprite creation to use single tile per room for east/west doors
- West-facing doors (left room) now properly flip horizontally
- Doors positioned 3 tiles down from top (TILE_SIZE * 2) as specified
- Updated wall tile removal and animated door creation to use correct dimensions
- Both sides of east/west connections now use matching door system
3. **Added connection limit validation (Issue #3)**
- Created validateMultipleConnections function to check if connections fit
- Validates that multiple connections won't cause rooms to overhang excessively
- Logs detailed error messages with recommendations when connections don't fit
- Example: 2GU room can't have 3 north connections (not enough width)
- Helps developers identify invalid room layouts during scenario design
Files modified:
- js/core/game.js: Load door_side_sheet_32 as spritesheet
- js/core/rooms.js: Fix positioning, add validation
- js/systems/doors.js: Single-tile east/west doors with flipping
- js/systems/collision.js: Update wall tile removal for single-tile doors
Fixed issue where test scenarios couldn't load rooms:
1. Added new room types to game preload:
- small_room_1x1gu (1×1 GU closet)
- hall_1x2gu (2×1 GU wide hallway)
2. Corrected room type keys in all test scenarios:
- room_reception2 → room_reception
- room_office2 → room_office
- room_ceo2 → room_ceo
- room_servers2 → room_servers
The issue was that scenarios referenced room file names (room_reception2)
instead of the Phaser cache keys (room_reception). The game preloads rooms
with specific keys that map to the JSON files:
this.load.tilemapTiledJSON('room_reception', 'assets/rooms/room_reception2.json')
Scenarios must use the key ('room_reception'), not the filename.
Files updated:
- js/core/game.js: Added preload for new variable-sized rooms
- scenarios/test_vertical_layout.json
- scenarios/test_horizontal_layout.json
- scenarios/test_complex_multidirection.json
- scenarios/test_multiple_connections.json
- scenarios/test_mixed_room_sizes.json
All test scenarios should now load correctly.
Updated test_mixed_room_sizes.json to use the new room files merged from main:
- Changed hall from placeholder to hall_1x2gu.json (2×1 GU - 10×6 tiles)
- Changed closet from placeholder to small_room_1x1gu.json (1×1 GU - 5×6 tiles)
- Updated all scenario text to reflect actual room dimensions
- Corrected layout diagram (hall is 2×1 GU wide hallway, not 1×2 GU vertical)
Updated TEST_SCENARIOS_README.md:
- Marked small_room_1x1gu.json and hall_1x2gu.json as available (✓)
- Updated scenario #5 description with actual rooms used
- Clarified that this scenario now demonstrates real size variety
This scenario now provides a complete test of the grid system with:
- 1×1 GU closet (smallest valid room)
- 2×1 GU wide hallway (horizontal connector)
- 2×2 GU standard rooms (reception, CEO office)
- Proper door alignment between all different sizes
Updated README_scenario_design.md with new grid-based room layout system:
- Documented Grid Unit (GU) system: 5×4 tiles base unit
- Added valid room size specifications (widths: multiples of 5, heights: 2+4N)
- Replaced old north/south-only constraints with four-direction support
- Updated door placement rules for N/S/E/W connections
- Added room positioning algorithm documentation
- Revised scenario design guidelines for grid system flexibility
Created 5 comprehensive test scenarios:
1. test_vertical_layout.json - Traditional N/S stacking
2. test_horizontal_layout.json - E/W connections
3. test_complex_multidirection.json - All four directions
4. test_multiple_connections.json - Multiple doors per direction
5. test_mixed_room_sizes.json - Different room sizes (1×1, 1×2, 2×2 GU)
Added TEST_SCENARIOS_README.md documenting:
- Grid system overview and room size specifications
- Detailed test scenario descriptions with layout diagrams
- Testing procedures and validation checks
- Expected console output examples
- Troubleshooting guide
Note: Scenarios reference hall_1x2gu.json and small_room_1x1gu.json which
need to be created in assets/rooms/. Currently using 2×2 GU placeholders.
All test scenarios include:
- Visual layout diagrams in scenario_brief
- Progressive difficulty with locks and keys
- Documentation of what each scenario tests
- Notes explaining grid system concepts
- Export calculateDoorPositionsForRoom from doors.js for reuse
- Import and use shared function in collision.js
- Remove duplicate door positioning logic (130+ lines)
- Ensures perfect alignment between door sprites and wall tile removal
- Both systems now use identical door placement calculations
This eliminates code duplication and guarantees that wall tiles are
removed at exactly the same positions where door sprites are created.
- Add grid unit constants (5x4 tiles) to constants.js
- Create comprehensive grid conversion helper functions
- Implement 4-direction room positioning (N/S/E/W) with breadth-first algorithm
- Add door placement functions with CRITICAL fixes:
* Negative modulo fix: ((sum % 2) + 2) % 2 for deterministic placement
* Asymmetric alignment fix: single-door rooms align with multi-door rooms
* Consistent grid alignment using Math.floor() for negative coordinates
- Rewrite calculateRoomPositions to support variable room sizes
- Update createDoorSpritesForRoom to use new placement system
- Store room dimensions globally for cross-system access
This implements the comprehensive room layout redesign as specified in
planning_notes/new_room_layout with all critical fixes from review2.
Addresses: Variable room sizes, proper door alignment, and grid-based positioning
- Updated door sprite creation to support lock properties from both doors and connected rooms.
- Added RFID cloner interaction logic to handle minigame initiation from inventory.
- Implemented inventory variable synchronization for NPC conversations, including RFID card details.
- Introduced new scenarios for RFID guards with varying security levels and interactions.
- Revised test scenarios to include comprehensive RFID protocol testing with detailed notes and NPC interactions.
Added three review documents analyzing the completed RFID system:
- POST_IMPLEMENTATION_REVIEW.md: Full technical analysis of implementation
- Reviewed 4 core files, 6 integration points, CSS, and test scenario
- Found 0 critical issues, 2 medium priority improvements (optional)
- Confirmed production-ready status
- Verified correct conversation return pattern
- Validated EM4100 protocol implementation
- ISSUES_SUMMARY.md: Quick reference for identified issues
- 7 total issues (all minor/optional)
- Action items with code examples
- Testing checklist
- README.md: Review overview and quick status
Key findings:
✅ Clean modular architecture following established patterns
✅ Authentic Flipper Zero UI with smooth animations
✅ Robust error handling and validation
✅ Seamless integration with all game systems
✅ Comprehensive test scenario created
Recommended improvements (optional):
- Use hex ID for key_id to prevent collisions
- Add cardToClone validation in clone mode
- Extract timing constants for maintainability
Overall assessment: Production ready with minor improvements recommended
Created proper Ink source file for Security Guard NPC:
Ink Story File:
- Created scenarios/ink/rfid-security-guard.ink (proper Ink format)
- Follows equipment-officer.ink pattern
- Uses # speaker:npc and # speaker:player tags
- Implements hub dialogue structure
- Contains clone_keycard tag: # clone_keycard:Master Keycard|FF4A7B9C21
- Multiple dialogue branches and paths
Story Structure:
- start knot → hub knot
- ask_keycard knot with multiple choices
- cloned knot for post-clone conversation
- Proper conversation flow with END points
Removed:
- Deleted placeholder rfid-security-guard.json (incorrect format)
- JSON must be compiled from .ink source using inklecate or Inky
Updated README:
- Added compilation instructions section
- Option 1: Inky editor (recommended, GUI)
- Option 2: inklecate command line
- Warning that .json needs compilation before use
- Links to download tools
The .ink file is the source of truth and must be compiled to .json
before the scenario will work properly.
Fixed test scenario to match reference format from npc-sprite-test2.json:
JSON Format Changes:
- Changed holdsItems → itemsHeld (correct property name)
- Changed storyJSON → storyPath (points to Ink file)
- Added position: { x, y } for NPC placement
- Changed map → type for room definition
- Added connections object for room linking
- Added readable: true to notes objects
- Added observations field to all items
- Added scenario_brief field
- Removed description field from doors
New Ink Story File:
- Created scenarios/ink/rfid-security-guard.json
- Security Guard conversation with clone_keycard tag
- Multiple dialogue branches
- Proper Ink JSON format with content array
NPC Configuration:
- Security Guard at position {x: 6, y: 4}
- Uses hacker-red sprite with idle animation
- Holds Master Keycard in itemsHeld
- References rfid-security-guard.json story
- Starts at 'start' knot
Test scenario now fully compatible with game's scenario loading system.
