DMP 2025 Week 9 updates by Justin Charles

src/constants/MarkdownFiles/posts/2025-08-03-dmp-25-justin212407-week09.md

@@ -0,0 +1,116 @@
+---
+title: "DMP’25 Week 09 Update by Justin Charles"
+excerpt: "Mapped out the integration plan for brick connections in Music Blocks 4, including collision maps, detection workflow, and tower merge/stale strategies"
+category: "DEVELOPER NEWS"
+date: "2025-08-03"
+slug: "2025-08-03-dmp-25-justin212407-week09"
+author: "@/constants/MarkdownFiles/authors/justin-charles.md"
+tags: "dmp25,sugarlabs,week9,justin212407"
+image: "assets/Images/c4gt_DMP.webp"
+---
+
+<!-- markdownlint-disable -->
+
+# Week 9 Progress Report by Justin Charles
+
+**Project:** Music Blocks 4 Masonry  
+**Mentors:** [Anindya Kundu](https://github.com/meganindya/), [Sumit Srivastava](https://github.com/sum2it)  
+**Assisting Mentors:** [Devin Ulibari](https://github.com/pikurasa/), [Walter Bender](https://github.com/walterbender)  
+**Reporting Period:** 2025-07-28 - 2025-08-03   
+
+---
+
+## Goals for This Week
+
+- Map out a concrete plan for integrating **brick-to-brick connections**  
+- Define data structures and maps for efficient collision queries  
+- Document full lifecycle of connection events: drag start → collision → drop → merge/stale  
+
+---
+
+## This Week’s Highlights
+
+### 1. **Workspace Presentation Design**
+
+- On adding a tower (or the very first brick) to the workspace, we compute **absolute coordinates** of all *incoming* connection points:
+  - Expression right-side notches  
+  - Statement bottom notches  
+  - Compound brick inner-top notches  
+
+- These coordinates are registered into quadtree-based data structures for performance.  
+- Reverse mapping utility (`notchId → {BrickId, TowerId}`) ensures we can quickly trace which tower/brick owns a given notch.  
+- For efficiency, only the towers/bricks that change are recomputed.  
+
+---
+
+### 2. **Collision Maps**
+
+Created a two-map design for separating brick connection points:  
+- **Expression Map** → Holds all expression brick notches  
+- **Statement Map** → Holds all statement brick notches  
+
+Each entry is indexed by a unique **Notch ID**, which reverse maps to `{BrickId, TowerId}`.  
+This allows collision queries to resolve directly into the correct brick and tower model.  
+
+---
+
+### 3. **Collision Detection Workflow**
+
+- On **drag start**, all notch coordinates belonging to the dragged brick/tower are removed from the maps (to avoid self-matching).  
+- During drag, we continuously check outgoing notch coordinates against the target map (expression or statement).  
+- On **each mouse move**, detect overlapping notch pairs:
+  - When overlap occurs → log `{BrickId, TowerId}` from the map as a *potential connection*.  
+  - Reverse mapping utility helps locate the parent brick within its tower for precise attachment.  
+
+---
+
+### 4. **Merge & Stale Tower Logic**
+
+- **Merge:**  
+  If drag ends on a collision, fetch the target tower via reverse mapping. Merge dragged tower into it, attaching at the correct brick notch.  
+
+- **Shadow Feedback:**  
+  During drag, show a shadow element preview of where the connection will happen.  
+
+- **Stale:**  
+  - If no collision occurs and drag ends → tower remains standalone.  
+  - Its incoming connection coordinates are re-registered into the collision maps.  
+  - If no collision occurs and drag continues → shadow disappears.  
+
+---
+
+## Challenges & Considerations
+
+- **Efficient Updates:** Needed a strategy to update only changed towers instead of recomputing the entire map.  
+- **Shadow Feedback:** Designing the UI to show previews without interfering with state was tricky.  
+- **Tower Integrity:** Ensured merge/disconnection logic didn’t break brick hierarchies when recomputed.  
+
+---
+
+## Key Learnings
+
+- Importance of **reverse mapping utilities** for bridging geometry (notch coords) with logical models (brick/tower).  
+- How **separating expression vs statement maps** simplifies collision lookups and prevents false positives.  
+- Designing clear **merge vs stale outcomes** ensures intuitive user interactions in the workspace.  
+
+---
+
+## Next Week’s Roadmap
+
+- Begin implementing the **connection merge logic** in the workspace manager  
+- Add real-time shadow previews for possible brick connections  
+- Start writing utility tests for collision detection and merge scenarios  
+
+---
+
+## Resources & References
+
+- [musicblocks-v4 Repository](https://github.com/sugarlabs/musicblocks-v4)  
+- [Document for brick connection](https://docs.google.com/document/d/1C0t4iSze2eDEv6lWbloK3MnvJgAa6HvmXmk2sQ0lCZs/edit?tab=t.wc31i1lo6mgp) 
+- [Quadtree Algorithm Notes](https://en.wikipedia.org/wiki/Quadtree)  
+
+---
+
+## Acknowledgments
+
+Thanks to my mentor Anindya Kundu on revisiting the basic of brick connections and helping me refine the connection lifecycle and reviewing the mapping approach.