Update "Strategic-Direction.-"

John McCardle 2026-02-07 23:02:12 +00:00
commit 26a1d52add
2 changed files with 180 additions and 366 deletions

180
Strategic-Direction.-.md Normal file

@ -0,0 +1,180 @@
# Strategic Direction
**McRogueFace v0.2.5** | February 2026
**Related Pages:**
- [[Issue-Roadmap]] - Detailed issue tracking by system and priority
- [[Performance-and-Profiling]] - Profiling infrastructure
- [[Animation-System]] - Animation architecture
- [[Development-Workflow]] - Day-to-day development process
- [[Home]] - Documentation hub
---
## Current State Assessment
McRogueFace is a C++/Python 2D game engine for roguelikes. It wraps SFML, libtcod, and OpenGL behind a Python scripting layer, delivering C++ performance with Python ergonomics. The engine has been in development since late 2022 and is now **game-ready for 2D roguelikes**.
### What Has Been Built
**Core Engine (Production-Ready):**
- UI hierarchy: Frame, Caption, Sprite, Grid, Entity, Arc, Circle, Line with parent-child composition
- Animation system with 24+ easing functions, property locking, callbacks, safe recursive callbacks
- Scene management with keyboard handlers, transitions, cleanup
- Input handling: Key, MouseButton, InputState enums; click/hover/move callbacks on all drawables; grid cell callbacks
- Multi-layer grid system with TileLayer/ColorLayer, chunk-based rendering, z-ordering, rotation, camera control
- Grid-based entity system with collections, pathfinding, FOV
- Procedural generation: DiscreteMap, HeightMap, NoiseSource, BSP with adjacency graphs
- Tiled import (TileSetFile, TileMapFile, WangSet with resolve/apply pipeline)
- LDtk import (LdtkProject, AutoRuleSet with pattern-matching resolution)
- Timer objects with stopwatch semantics (pause, resume, restart, one-shot)
- Audio: sound buffers, playback, volume control
- Documentation: MCRF_* macro system, auto-generated HTML/Markdown/man pages, Python type stubs
**Platform Support:**
- Linux native builds
- Windows cross-compilation (MinGW-w64)
- WebAssembly/Emscripten with SDL2+OpenGL ES 2 backend
- Headless mode for CI/automated testing
**Testing and Tooling:**
- 100+ unit tests across unit, integration, regression, and benchmark suites
- Interactive demo system with per-feature screens
- Automation API (screenshots, simulated input)
- Profiling infrastructure (F3 overlay, ScopedTimer, metrics)
**Experimental 3D Pipeline:**
- Viewport3D with OpenGL scene graph embedded in 2D UI
- Camera3D, Entity3D, MeshLayer, Model3D (glTF), Billboard, Shader3D, VoxelGrid
- Greedy meshing, frustum culling, serialization
- These modules work and are tested but have known gaps (Entity3D.animate() is a stub, some collection methods missing). They represent proof-of-concept scouting for the McVoxelFace era.
### Proving Grounds
- **Crypt of Sokoban** (7DRL 2025) was the alpha proving ground -- the first complete game built on McRogueFace.
- **7DRL 2026** is the current milestone. Engine preparation is complete; widget primitives are prototyped and tested.
- **r/roguelikedev tutorial series** (#167) is the community-facing demonstration target.
---
## Engine Eras
The original plan called for three separate engines. In practice, they have converged into one engine with **eras** of focused development. The shared foundation -- Python bindings, UI hierarchy, animation system, scene management, input handling, audio -- is the same regardless of whether the game uses tile grids, vector graphics, or voxel terrain.
| Era | Focus | Status |
|-----|-------|--------|
| **McRogueFace** (current) | 2D tiles, roguelike systems, procgen | Active -- 7DRL 2026 imminent |
| **McVectorFace** (future) | Sparse grids, vector graphics, physics | Planned |
| **McVoxelFace** (future) | Voxel terrain, 3D gameplay | Proof-of-concept scouting done |
Each era adds capabilities to the same engine. Nothing is thrown away. A Grid is still useful for inventory screens in a 3D game. Sparse grid layers plus a polygon class would cover vector graphics. There is no reason to fork.
---
## Development Philosophy
These principles guide all development decisions:
1. **Build the engine, prove it with games.** Game jams and the tutorial series are the proof. An engine nobody makes games with is just a library.
2. **Foundation first, then features.** But "foundation" includes making the engine pleasant to use, not just performant.
3. **One engine, not three.** Capabilities accumulate across eras; nothing is thrown away.
4. **Python ergonomics matter.** If it is annoying to use from Python, it is a bug. The API should feel natural to Python developers, not like a thin C++ wrapper.
5. **Maintain momentum.** Build tools quickly before losing interest. The 72-hour deep-dive pattern is a feature, not a bug -- channel it into focused sprints.
6. **McRogueFace should be usable by others.** Not just a personal tool. The roguelike community is the first audience.
---
## Immediate Focus
### 7DRL 2026 (February 2026)
The engine is prepared. All 2D systems are production-ready. The jam is the proving ground -- it will expose any remaining rough edges in the workflow of building a complete game on McRogueFace.
### Post-Jam (March-April 2026)
Lessons from 7DRL will drive the next wave of work:
- Polish and publish the engine based on real-world jam experience
- Fix any pain points discovered during actual game development
- Progress on the r/roguelikedev tutorial series (#167)
- Address any critical bugs surfaced during the jam
### Ongoing
The engine ships continuously. There is no single "v1.0 release date." Each version should be usable. Breaking changes are avoided where possible, and when necessary, they are documented.
---
## What Remains
32 open issues remain, grouped by area. See [[Issue-Roadmap]] for detailed per-issue tracking.
**3D Pipeline Gaps (4 issues):** Entity3D needs animate() support (#242), viewport parent tracking (#244), collection method parity (#243), and screen_to_world() improvements (#245). These are tier-2 foundation work -- important for the McVoxelFace era but not blocking 2D development.
**Multi-Tile Entities (5 issues):** Oversized sprites (#236), composite sprites (#237), texture display bounds (#235), entity origin offsets (#234), and the umbrella enhancement (#233). All tier-3 future work for richer entity rendering.
**WASM/Emscripten Debugging (3 issues):** Debug infrastructure (#238), automated browser testing (#239), and developer troubleshooting docs (#240). Tier-3 tooling to improve the WebAssembly development experience.
**Grid Enhancements (3 issues):** Sparse grid layers (#152), UIGrid.cpp refactoring (#149), and infinite world grid stitching (#67). Foundation and future work for larger and more flexible worlds.
**LLM Agent Testbed (3 issues):** The grounded multi-agent testbed (#154), turn-based LLM orchestration (#156), and agent simulation environment (#55). Research applications that demonstrate the engine's value beyond traditional game development.
**Platform and Distribution (7 issues):** Packaging without embedded interpreter (#70), Jupyter notebook interface (#54), multiple windows (#62), accessibility modes (#45), alternative input methods (#53), RenderTexture failure handling (#227), and subinterpreter support (#220).
**Other (7 issues):** Particle system (#107), Color/Vector animation targets (#218), grid point animation (#124), memory pool for entities (#117), TexturePool RenderTexture reuse (#145), tutorial demo game (#167), and subinterpreter tests (#46).
Most of these are tier-2 or tier-3 -- important but not urgent. The engine is functional for its current era. Issues will be addressed based on what games need, not on a predetermined schedule.
---
## Decision Framework
When considering new work, ask these questions in order:
### 1. Does it serve the current era?
McRogueFace is in the 2D roguelike era. Work that improves 2D tile-based game development gets priority. 3D pipeline improvements are welcome when momentum is there, but they should not block 2D progress.
### 2. Did a real game expose this need?
Problems discovered while building actual games (7DRL, tutorial series) take priority over theoretical improvements. If nobody has hit the limitation in practice, it can wait.
### 3. Does it make the engine more usable by others?
Documentation, ergonomic API improvements, packaging, and tutorial work multiply the engine's value. A feature that only the author would use is lower priority than one the community needs.
### 4. Is it foundation or feature?
Foundation work (performance, API consistency, bug fixes, documentation) compounds over time. Features are valuable but should build on a solid foundation. When in doubt, fix the foundation.
### 5. Can it wait?
If the answer is yes and there is foundation work to do, it should wait. Scope discipline is what separates shipping engines from perpetual projects.
**Rule of thumb:** If a real game needs it now, do it now. If it is foundation work for the current era, prioritize it. Everything else goes on the backlog.
---
## Long-Term Trajectory
The engine's trajectory follows the games that drive it:
- **Now:** 2D roguelikes (7DRL 2026, tutorial series, community adoption)
- **Next:** More ambitious 2D projects that stress-test grid stitching, multi-tile entities, and larger worlds
- **Eventually:** McVectorFace era (sparse grids, vector graphics, physics) and McVoxelFace era (voxel terrain, 3D gameplay) -- same engine, new capabilities, bigger games
The 3D proof-of-concept scouting is already done. When the time comes for the McVoxelFace era, the foundation (Viewport3D, VoxelGrid, shaders, Model3D) already exists and just needs to be completed.
---
**Navigation:**
- [[Home]] - Documentation hub
- [[Issue-Roadmap]] - Detailed issue tracking
- [[Development-Workflow]] - Day-to-day process
- [[Performance-and-Profiling]] - Profiling infrastructure
*Last updated: 2026-02-07*

@ -1,366 +0,0 @@
# Strategic Direction
**Last Updated:** October 2025 (post-profiling system implementation)
**Source:** FINAL_RECOMMENDATIONS.md (October 2023 strategic analysis)
**Status:** Active guidance for development priorities
**Related Pages:**
- [[Performance-and-Profiling]] - Profiling system (completed ✅)
- [[Animation-System]] - Current animation architecture
- [[Proposal-Next-Gen-Grid-Entity-System]] - Major architectural proposal
---
## Current State Assessment
### Achievements (2023-2025)
- ✅ Comprehensive C++/Python game engine with SFML/libtcod integration
- ✅ Animation system with 24+ easing functions
- ✅ Profiling infrastructure (F3 overlay, ScopedTimer, metrics) - **Completed Oct 2025**
- ✅ 70% complete tutorial series (parts 0-6 implemented)
- ✅ Three-audience strategy (beginners, game jammers, researchers)
### Known Problems
- ⚠️ Animation system has API inconsistencies and bugs
- ⚠️ Grid rendering lacks dirty flag optimization (re-renders static content every frame)
- ⚠️ Tutorial continuation blocked by animation issues
- ⚠️ No public release (features not stable enough)
### Recent Progress (October 2025)
- ✅ **Profiling system implemented** - Issue #104 completed
- ✅ **Benchmarks created** - tests/benchmark_static_grid.py, tests/benchmark_moving_entities.py
- 🔄 **Next:** Grid dirty flags (#116), SpatialHash (#115), Animation system overhaul (#120)
---
## Core Recommendation: Foundation First
**Principle:** Fix foundation systems before expanding features.
### Immediate Focus (Next 3-6 Months)
1. **Grid rendering optimization** - Dirty flags, viewport culling
2. **Animation system overhaul** - Fix APIs, squash bugs, consistent behavior
3. **Performance profiling** - ~~Measure~~ ✅, optimize, compete with TCOD
### Defer Until Foundation Stable
- ECS architecture rewrite
- Living world/MMO features
- Python wheel distribution
- Tutorials 7-13 (advanced content)
- Research platform features
**Why:** Stable, performant engine with consistent APIs is achievable in 3-6 months. Chasing bigger visions before fixing foundation repeats burnout cycle.
---
## What to Pursue, Defer, or Abandon
### ✅ PURSUE (Active Development)
**Core Features:**
- Three-audience strategy (beginners, jammers, researchers)
- Pythonic API with clean abstractions
- "Batteries included but removable" philosophy
- Forward-only tutorial progression
- Performance competitive with libtcod
**Foundation Systems:**
- Grid rendering optimization (#116, #115, #113)
- Animation system fixes (#120, #119, #100)
- Python binding consistency (#126, #109, #101)
- Documentation infrastructure (#92, #91, #97)
### ⏸️ DEFER (Until After v1.0)
**Good Ideas, Wrong Timing:**
- Python wheel packaging (`pip install mcrogueface`) - Wait for stable API
- Advanced tutorials 7-13 - Complete basic tutorials first
- Research platform features - Build community first
- Multi-window support (#62) - Limited demand
- Shader support (#106) - Advanced feature
- Particle system (#107) - Advanced feature
**Rationale:** These are valuable but require stable foundation. Attempting them now creates scope creep and burnout risk.
### ❌ ABANDON (Not Aligned with Project Vision)
**Out of Scope:**
- Living world MMO features - Wrong project, years of work, no user demand
- Full ECS rewrite - Wrong timing, makes tutorials harder for beginners
- 50,000 tile ecosystem - Wrong scale for target audience
- Tile state machines - Too complex for beginner-friendly engine
**Rationale:** McRogueFace is a **beginner-friendly roguelike engine**, not an MMO platform or research simulator. Stay focused on core mission.
---
## Critical Path to v1.0
### Phase 1: Performance Foundation (✅ Partially Complete)
**Timeline:** October-November 2025
- [✅] Task #104: Profiling infrastructure (F3 overlay, ScopedTimer)
- [✅] Benchmarks: static grid, moving entities
- [🔄] Task #116: Grid dirty flag system
- [🔄] Task #115: SpatialHash for entity queries
- [⏳] Task #113: Batch operations API
**Success Metric:** 60 FPS with 10,000 entities and 100x100 grid
### Phase 2: Animation System Overhaul
**Timeline:** December 2025 - January 2026
- [⏳] Task #120: Property locking system
- [⏳] Task #100: Rotation support
- [⏳] API consistency audit
- [⏳] Comprehensive test suite
- [⏳] Documentation update
**Success Metric:** Tutorial-ready animation system with consistent API
### Phase 3: Tutorial Completion
**Timeline:** February - March 2026
- [✅] Parts 0-6: Implemented and working
- [⏳] Parts 7-10: Complete on stable foundation
- [⏳] Parts 11-13: Advanced content (optional)
- [⏳] Tutorial testing framework
- [⏳] Documentation sprint
**Success Metric:** Professional tutorial ready for public release
### Phase 4: Public Release
**Timeline:** April 2026
- API freeze (v1.0)
- Python wheel packaging
- Documentation finalization
- Public announcement
**Success Metric:** First stable public release
---
## Key Principles
### 1. Fix Foundation Before Features
**Wrong:** "Let's add ECS while animation system has bugs"
**Right:** "Let's fix animation bugs, THEN evaluate if ECS is needed"
### 2. Measure Before Optimizing
**Wrong:** "Grid rendering seems slow, let's rewrite it"
**Right:** "Let's profile grid rendering (✅), identify bottlenecks, optimize hot paths"
### 3. Simplicity Over Completeness
**Wrong:** "Let's support every possible use case"
**Right:** "Let's nail the beginner experience first"
### 4. Ship Incrementally
**Wrong:** "Can't release until everything is perfect"
**Right:** "Release tutorial parts 0-4 as Early Access while fixing rest"
### 5. Listen to Burnout Signals
**Wrong:** "Power through tutorial frustrations"
**Right:** "Tutorial burnout = foundation problem. Stop and fix foundation."
---
## Decision Framework
When considering new work, ask:
### 1. Does it fix foundation?
- ✅ Grid dirty flags - Yes (core performance)
- ✅ Animation bug fixes - Yes (tutorial blocker)
- ❌ ECS rewrite - No (architectural experiment)
### 2. Does it unblock tutorials?
- ✅ Animation API consistency - Yes (tutorial depends on it)
- ❌ Living world features - No (tutorials don't need it)
### 3. Does it align with "beginner-friendly"?
- ✅ Pythonic API improvements - Yes (easier to learn)
- ❌ Advanced shader system - No (intimidating for beginners)
### 4. Can it wait until v1.0?
- ⏸️ Python wheel packaging - Yes (good feature, not urgent)
- ❌ Performance fixes - No (embarrassing performance hurts adoption)
**Rule of Thumb:** If it doesn't fix foundation, unblock tutorials, or improve beginner experience, defer it.
---
## Synergies & Dependencies
### Critical Path Dependencies
```
Profiling System (✅ Done)
Grid Optimization (#116, #115)
Animation System Overhaul (#120)
Tutorial Completion (Parts 7-10)
Public Release (v1.0)
```
**Each phase blocks the next.** Don't skip ahead.
### Parallel Work (Can Do Anytime)
Independent improvements that don't block critical path:
- Documentation updates (#92, #91, #97)
- Python binding patterns (#101, #109)
- Test infrastructure improvements
- Bug fixes not affecting tutorials
**Rule:** These can fill time while waiting on reviews or builds, but never at expense of critical path.
---
## Warnings & Anti-Patterns
### Warning Signs of Scope Creep
- "Let's add just one more feature before release"
- "This ECS idea is so cool, let's explore it"
- "We should support [edge case] before v1.0"
- "Let's redesign [working system] to be more elegant"
**Response:** Stop. Refer to this document. Is it on critical path? No? Defer.
### Known Burnout Triggers
Based on September 2025 tutorial burnout:
1. **Teaching broken features** - Tutorial work on unstable APIs
2. **Working around bugs** - Complex code to avoid animation issues
3. **Scope creep during tutorial** - Adding features mid-tutorial
4. **Perfectionism** - Rewriting working code
**Response:** Recognize burnout signals early. Stop tutorial work. Fix foundation. Resume tutorials on stable base.
---
## Success Metrics
### v1.0 Release Criteria
**Performance:**
- ✅ 60 FPS with 100x100 grid
- ✅ 60 FPS with 10,000 entities (requires #115)
- Grid render time <2ms for static content (requires #116)
**API Stability:**
- Animation system has consistent APIs (#120)
- Python bindings follow patterns (#126, #101)
- No major breaking changes expected
**Documentation:**
- Tutorial parts 0-6 polished (✅ code exists)
- Tutorial parts 7-10 completed
- API documentation generated (#97)
- Python type stubs available (#91)
**User Experience:**
- Tutorial can be followed start-to-finish
- Examples run without errors
- Performance competitive with libtcod
**Release Readiness:**
- API frozen
- Changelog prepared
- Python wheel available
- Public announcement ready
---
## Monthly Check-In Questions
At end of each month, evaluate:
1. **Are we on critical path?**
- If not, why did we deviate?
- Was deviation justified?
2. **Did we ship anything?**
- Code merged to master
- Tutorial parts completed
- Documentation updated
- Issues closed
3. **Is burnout risk increasing?**
- Working on frustrating bugs?
- Scope creeping?
- Losing motivation?
- **Response:** Return to foundation work
4. **What's blocking next phase?**
- Dependencies clear?
- Resources available?
- Technical unknowns identified?
5. **Should we adjust timeline?**
- Faster than expected?
- Unforeseen blockers?
- Change priorities?
---
## Current Status (October 2025)
### ✅ Recent Wins
- Profiling system implemented (Issue #104)
- Benchmarks created
- F3 overlay functional
- ScopedTimer infrastructure in place
### 🔄 In Progress
- Grid System wiki documentation (this sprint)
- Issue organization and labeling
### ⏳ Next Up (November 2025)
- Issue #116: Grid dirty flag system
- Issue #115: SpatialHash implementation
- Issue #120: Animation property locking
### 📅 Upcoming Milestones
- **Q4 2025:** Performance foundation complete
- **Q1 2026:** Animation system overhaul
- **Q2 2026:** Tutorial completion
- **Q2 2026:** v1.0 public release
---
## Resources
**Source Documents:**
- `FINAL_RECOMMENDATIONS.md` - Full strategic analysis (October 2023)
- `MASTER_TASK_SCHEDULE.md` - Comprehensive task catalog
- `ROADMAP.md` - High-level project roadmap
**Related Issues:**
- [#104](../issues/104) - Profiling system (✅ complete)
- [#115](../issues/115) - SpatialHash optimization
- [#116](../issues/116) - Grid dirty flags
- [#120](../issues/120) - Animation property locking
- [#126](../issues/126) - Perfect Python interface
**Related Wiki Pages:**
- [[Performance-and-Profiling]] - Profiling infrastructure
- [[Animation-System]] - Current animation implementation
- [[Proposal-Next-Gen-Grid-Entity-System]] - Future architecture proposal
---
**Navigation:**
- [[Home]] - Documentation hub
- [[Performance-and-Profiling]] - Current performance work
- [[Animation-System]] - Animation system details