Evaluating Rust Files and Project RoadmapPublic

Agent

Claude Code

Model

Claude Opus 4.6

Shared

Feb 15, 7:10 PM

Messages33

Summary

Would it make sense to split up any of our rust source files into multiple files to make them more understandable or easier to read?

The user is asking about whether any Rust source files in the mtg-rl workspace should be split up for readability. This is a research/analysis question about code organization. Let me explore the codebase to understand file sizes and complexity before making recommendations.

Let me check if any skills apply - this is an analysis/research question, not really a creative task or implementation task. The brainstorming skill says "before any creative work - creating features, building components, adding functionality, or modifying behavior." This is just analysis, so I don't think brainstorming applies. No other skills seem to apply either.

Let me explore the codebase to find large files that might benefit from splitting.

Let me survey the Rust source files to identify candidates based on size and complexity.

The clear standout is game.rs at nearly 14K lines. Let me look at its internal structure to understand what could be split.

# Count lines in tests vs non-test code in game.rs
test_start=$(grep -n '^mod tests' /mnt/dest-btrfs/home/jc/src/mage/mtg-rl/mtg-engine/src/game.rs | head -1 | cut -d: -f1)
total=$(wc -l < /mnt/dest-btrfs/home/jc/src/mage/mtg-rl/mtg-engine/src/game.rs)
echo "Total lines: $total"
echo "Test code starts at line: $test_start"
echo "Non-test code: $test_start lines"
echo "Test code: $((total - test_start)) lines"

The check_game_end shows 9037 because it's the last function before the test module, so it's picking up lines after it. Let me fix the analysis - actually the issue is the awk script picks up until the next function, but check_game_end is the last non-test function, so it captures all lines until the tests. The actual check_game_end function is probably small; the big count is because of the test modules.

Let me re-analyze with proper function boundaries.

Actually, execute_effects at 1636 lines is the true monster - that's the one handling all ~30+ effect variants.

So the real breakdown is apply_continuous_effects at 273 lines and check_triggered_abilities at 242 lines handling their respective logic, while the test modules themselves account for over 9000 lines of that total.

Here's the picture:

Analysis

game.rs is the clear candidate — 13,870 lines, and it's the only file that's unwieldy. Everything else is reasonably sized (the set files are large but inherently repetitive card listings).

Breaking game.rs down:

Section	Lines	Notes
Core game logic	~4,857	`impl Game` with all methods
Test modules	~9,013	38 separate `mod *_tests` blocks

The biggest functions in the core logic:

Function	~Lines	Does what
`execute_effects()`	1,636	Giant match on ~30+ `Effect` variants
`pay_costs()`	326	Match on `Cost` variants
`apply_continuous_effects()`	273	Applies `StaticEffect` variants
`check_triggered_abilities()`	242	Checks all trigger conditions
`compute_legal_actions()`	173	Enumerates legal plays

There are also 3 duplicate AlwaysPassPlayer impls in different test modules.

Recommendations

Splits that would help:

Move tests out of game.rs (~9K lines) — The 38 test modules could live in mtg-engine/tests/ as integration tests, or in a game/ module directory with a separate tests.rs. This alone would cut the file from 14K to ~5K lines.
Extract execute_effects() into game/effect_resolution.rs (~1,600 lines) — This is a massive match statement. It's a natural unit: "given an Effect enum variant, modify game state." Could be impl Game in a separate file via the mod pattern.
Extract combat into game/combat_resolution.rs (~350 lines) — declare_attackers_step, declare_blockers_step, combat_damage_step, resolve_fight_pair form a cohesive group.
Extract apply_continuous_effects + filter/matching helpers (~400 lines) — apply_continuous_effects, matches_filter, card_matches_filter, find_matching_permanents are a natural cluster.

Splits that are probably NOT worth it:

The set card files (fdn.rs etc.) — they're big but dead-simple repetitive factories; splitting by letter or rarity would add complexity without improving readability.
abilities.rs (2,113 lines) — it's mostly enum definitions and builder methods, reads fine as-is.
Any of the other engine files — all under 1K lines.

Bottom line: game.rs is doing the work of 3-4 files. The highest-impact move is extracting tests, then execute_effects. Want me to plan and do one of these splits?

Stop hook feedback:

Read mtg-rs/ROADMAP.md, and identify work that is outstanding to bring our rust engine into parity with Java. Do not implement any new sets, but add engine features that area missing. Our goal is to complete the fully functional implementation of ECL by implementing engine capabilities and updating cards to use them. Work one task at a time until we are done. Read the corresponding java source to understand how to shape the implementation. Update the ROADMAP and leave a note as you progress. Add tests for each engine feature you add. Commit changes after each item. Then get another ROADMAP item until the engine is at parity with the Java engine.

The user wants me to:

Read the ROADMAP.md to understand outstanding work
Implement engine features to bring Rust engine to parity with Java
Focus on ECL set completion
Work one task at a time
Read Java source for reference
Update ROADMAP as I progress
Add tests for each engine feature
Commit after each item
Repeat until done

Let me start by reading the ROADMAP.md file. The user mentioned "mtg-rs/ROADMAP.md" but based on memory, it's likely at mtg-rl/docs/ROADMAP.md or similar path.

I'll look for the ROADMAP file now.

Searched files**/ROADMAP.md

Searched files**/roadmap*

ReadROADMAP.md

Request interrupted by user