The UI toolkits in game engine usually suck hard, so here they started from a good UI toolkit and made it possible to make relatively performant games.
It doesn't say Toyota anywhere on the page and they don't have a link to a repo or anything like that, so I was a little confused. But it is from /that/ Toyota (well, a subsidiary that is making 3d software for their displays) and there was a talk at FOSDEM about it: https://fosdem.org/2026/schedule/event/7ZJJWW-fluorite-game-...
The combination of Flutter + Claude Code makes cross-platform app development really, really fast. I've been impressed with how well Clause handles prompts like, "This list should expand on the web, but not on iOS." I then ask it (Claude) to run both a web instance and an iOS simulator instance. Can usability test in-tandem.
I recently (as in, last night) added WebSockets to my backend, push notifications to my frontend iOS, and notification banner to the webapp. It all kinda just works. Biggest issues have been version-matching across with Django/Gunicorn/Amazon Linux images.
Man, people say this kind of thing, and I go… really? …because I use Claude code, and an iOS MCP server (1) and hot damn I would not describe the experience as “just works”.
What MCP and model are you using to automate the testing on your device and do automated QA with to, eg. verify your native device notifications are working?
My experience is that Claude is great at writing code, but really terrible at verifying that it works.
What are you using? Not prompts; like, servers or tools or whatever, since obviously Claude doesn’t support this at all out of the box.
I'd like to know too! I feel like many people are playing a whole different AI game than me, and I don't think I've written a single line of code since December (team experiment to optimize the vibe coding process)
Claude set up my whole backend on AWS. That includes a load balancer, web server, email server, three application servers, and a bastion server to connect to their VPN.
It configured everything by writing an AWS Terraform file. Stored all secrets in AWS as well.
Everything I do is on the command line with Claude running in Visual Studio Code. I have a lot of MacOS X / Ubuntu Linux command line experience. Watching Claude work is like watching myself working. It blew my mind the first time it connected through the bastion to individual AWS instances to run scripts and check their logs.
So yeah, the same Claude Code instance that configured the backend is running inside a terminal in VS Code where I’m developing the frontend. Backend is Django/Python. Frontend is Flutter/Dart. Claude set up the WebSocket in Django/Gunicorn and the WebSocket in Flutter.
It also walked me through the generation of keys to configure push notifications on iOS. You have to know something about public/private key security, but that amounts to just generating the files in the right formats (PEM vs P12).
I wonder if a slightly broader search for existing solutions - for instance, https://defold.com - would have shown that quick-startup, 3d-capable, c-integrable, low-end-hardware performant game engines could have been grabbed off the shelf.
That said, this is cool and I would have probably celebrated a similarly fun project in their shoes. Perhaps the real accomplishment here is getting Toyota to employ you to build a new, niche game engine.
Having used both, the experience of building actual UI with Flutter is a breeze compared to building UI in any game engine. I can imagine that most of the usage of Flutter is leveraging the huge amount of work that was already done to get efficient and capable UIs done with just a stack of widgets.
Filament is not a console grade renderer, not even close. It's architectured around GL. Yes, it can use Vulkan but it's not in any way optimized like a console engine.
I understand what your intent is in saying this, and I agree with the intent, but for onlookers, you don't really need a lot to make a good game and this would likely be just fine. I don't actually know if it's possible to ship GL games on modern consoles now that it's in-fashion to have your own proprietary graphics library. That said, the way Google has factored the back-end of the renderer, it won't take a PhD to target one of those GPU APIs.
Aside: GL is still a good practical choice for games built by small teams.
GL is way more optimized then Vulkan style rendering on most devices today. If you speed test WebGL2 with WebGPU on a mobile device the difference is huge for rendering a simple PBR model.
For others who were curious like I was: The website doesn't mention "open" or "source" anywhere, but they did give a talk at FOSDEM 2026 about it.
There was a passing comment about "when we open up the GitHub repository" in the talk. So it's not open yet, but they've suggested it might be in the future.
This trend of "complexity == moar gooder" makes me itchy. Why does a vehicle display system need a whole-ass game engine? I want my high-speed death box to have utilitarian, well-tested and well-written software, not fucking Unity.
Please stop, all this does is introduce new ways for things to break.
I've been burned by using closed source game engines before. There's just too many edge cases and nuances that come up when debugging physics or graphical issues. I strongly recommend against using this until they become at the very least source-available.
Rust based ECS game engine, with 3,000 word diatribes about what decentralized, federated social media presence it should have, woefully incomplete, full of bugs, with no consideration of how any actual games are written other than Factorio, because that's the game that programmers who write open source game engines and not games play: "Aww, you're sweet"
Something about games authored by a giant company that will presumably actually ship in some products: "Hello, human resources?"
43 comments
[ 1.1 ms ] story [ 60.5 ms ] threadThe UI toolkits in game engine usually suck hard, so here they started from a good UI toolkit and made it possible to make relatively performant games.
There's more info at https://www.reddit.com/r/programming/comments/1r0lx9g/fluori...
I recently (as in, last night) added WebSockets to my backend, push notifications to my frontend iOS, and notification banner to the webapp. It all kinda just works. Biggest issues have been version-matching across with Django/Gunicorn/Amazon Linux images.
> It all kinda just works.
> Can usability test in-tandem.
Man, people say this kind of thing, and I go… really? …because I use Claude code, and an iOS MCP server (1) and hot damn I would not describe the experience as “just works”.
What MCP and model are you using to automate the testing on your device and do automated QA with to, eg. verify your native device notifications are working?
My experience is that Claude is great at writing code, but really terrible at verifying that it works.
What are you using? Not prompts; like, servers or tools or whatever, since obviously Claude doesn’t support this at all out of the box.
(1) - specifically, this one https://github.com/joshuayoes/ios-simulator-mcp
It configured everything by writing an AWS Terraform file. Stored all secrets in AWS as well.
Everything I do is on the command line with Claude running in Visual Studio Code. I have a lot of MacOS X / Ubuntu Linux command line experience. Watching Claude work is like watching myself working. It blew my mind the first time it connected through the bastion to individual AWS instances to run scripts and check their logs.
So yeah, the same Claude Code instance that configured the backend is running inside a terminal in VS Code where I’m developing the frontend. Backend is Django/Python. Frontend is Flutter/Dart. Claude set up the WebSocket in Django/Gunicorn and the WebSocket in Flutter.
It also walked me through the generation of keys to configure push notifications on iOS. You have to know something about public/private key security, but that amounts to just generating the files in the right formats (PEM vs P12).
> Can usability test in-tandem
…
> It also walked me through the generation of keys to configure push notifications on iOS.
??? You’re manually doing the testing and setup and not using AI for this?
Im confused at to what part of this mobile work claude is doing that “just works” for you.
That said, this is cool and I would have probably celebrated a similarly fun project in their shoes. Perhaps the real accomplishment here is getting Toyota to employ you to build a new, niche game engine.
Toyota assuming they move forward with this, might even become the main corporate sponsor since Google appears to be disinterested.
Aside: GL is still a good practical choice for games built by small teams.
There was a passing comment about "when we open up the GitHub repository" in the talk. So it's not open yet, but they've suggested it might be in the future.
Please stop, all this does is introduce new ways for things to break.
So... not PC-grade?
I've been burned by using closed source game engines before. There's just too many edge cases and nuances that come up when debugging physics or graphical issues. I strongly recommend against using this until they become at the very least source-available.
Something about games authored by a giant company that will presumably actually ship in some products: "Hello, human resources?"