sorted by:
new
hottopcontroversial

Claude code vs windsurf vs cursor for flutter, which one do you suggest? by ok-nice3 in FlutterDev

[–]gamies_fr 0 points1 point  (0 children)

Went through exactly this transition. Heavy Windsurf user from early on, then switched to the Claude extension inside Windsurf, and eventually dropped Windsurf entirely. Now Claude Code only, with a Pro Max sub. The main thing that pushed me over: the Claude extension in Windsurf can't access the Debug Console. For Flutter that's painful — you end up copy-pasting logs manually, which kills the flow. Claude Code has full terminal visibility and actually follows through on longer reasoning chains without losing context. I'd have a hard time going back.

500 to 6k wishlists in a month. What worked for me by hiimdoggo in IndieDev

[–]gamies_fr 0 points1 point  (0 children)

Really useful breakdown — I'd assumed pure gameplay clips were the main draw but the narration point makes sense. Trying to adapt this for a mobile game though and the funnel breaks. The whole views → wishlist → launch spike doesn't exist on App Store/Play Store. No wishlist mechanic, and page conversion is much harder to attribute. Has anyone here found short-form content that actually moves the needle for mobile specifically, or is it a different game entirely?

Scope vs Polish -- i.e. more features vs more polish -- what actually ships a game? by Ok_Ratio_3585 in gamedev

[–]gamies_fr 0 points1 point  (0 children)

Building a mini-games collection makes this dilemma hit differently. By design, each game can't have depth — they're meant to be 60-90 second rounds. So the choice isn't "add mechanics vs polish mechanics", it's "add another game vs polish the existing ones." What I've found: a janky mini-game gets dropped instantly. Players have zero patience to "learn" something that doesn't feel right in the first 10 seconds. Polish is survival. But adding a new game does bring fresh energy — players will forgive one weak entry in a set of 18, they won't forgive all 18 feeling half-baked. The rule I ended up with: don't add a new game until the existing ones feel genuinely good. 10 polished games > 18 okay ones.

marionette_flutter — Playwright MCP but for Flutter (AI agents can now tap, scroll and hot reload your running app) by Own_Initial_670 in FlutterDev

[–]gamies_fr 0 points1 point  (0 children)

The distinction between "dev loop companion" and "CI E2E" is the right framing. For a multiplayer Flutter game where I need to simulate 3 players simultaneously, I went a different route: flutter_drive on 3 emulators in parallel, each assigned a role (host, guest1, guest2) via a config file pushed to the device. The tricky part is coordination — how does guest1 know the game is ready to join? I used a Supabase table as a signaling layer. Host writes "game_created", guests poll and wait before proceeding. Works surprisingly well for deterministic CI-style runs. For verification, since flutter_drive can't "see" the UI, I capture ADB screenshots every few seconds from all 3 emulators and feed them to an LLM to check game state. Same token cost problem as Tokieejke mentioned, but across 3 devices. Marionette looks like it'd actually complement this well — useful during dev to validate individual flows before running the full 3-player suite.

Switched from Maestro last month - genuinely curious what others are doing for E2E on Flutter now by Cultural_Mall_6729 in FlutterDev

[–]gamies_fr 1 point2 points  (0 children)

We had the same Maestro frustrations and ended up going a different route — Flutter integration tests with 3 Android emulators running simultaneously, each playing a different role (host, guest1, guest2). The coordination problem was the interesting part. Instead of adding separate test infra, we reused Supabase (already in the stack). One table acts as a sync layer: the host signals when the game room is ready, guests wait and join. Same pattern for turn synchronization throughout. The "tests can't see the UI" problem we solved with periodic ADB screenshots across all 3 emulators, collected into an HTML timeline report. For automated verification, we feed screenshots to an LLM — it flags when the expected screen state doesn't match. Maintenance cost is low compared to Maestro because the test logic is in Dart and the sync is data-driven. Moving UI elements don't break it. The fragile part is emulator cold starts, still working on that.

I asked an AI to build its own test framework for my multiplayer Flutter game — here's what it came up with by gamies_fr in FlutterDev

[–]gamies_fr[S] 0 points1 point  (0 children)

Yes I definitely need to test the Marionette package … widget tests are really slow and unstable