Hello everyone, I am a junior developer I got hands-on with a project where I should develop a mobile app containing multiple 2d games my initial UI stack was React Native for the UI and Unity for the games, the app is UI heavy so unity alone wasn't enough, but I recently found that I could develop everything with Flutter from the app to the game ... my question is, do you think it's a good idea or am I shooting myself in the foot?
if you are already expert on technologies you mentioned and know exactly how to work with them you might see investition to flutter as burden. Otherwise: Just go on with flutter & flame and see if it fullfills your requirements and could fit to your exact requirements.
Generally, flutter is already solid, and usable in context you mentioned. There's also plenty of resources to test if it would be ok to you before investing a lot. Just pick a demo project, get it running, and see results.
If you decide to invest you can take a working seed project generated to you
https://cli.vgv.dev/docs/templates/flame_game
Note: Flutter + Flame expect you to learn dart - it's easy, as the language is close to js / c / .. so: algol style syntax - it also expects you to understand reactive ui's - well: concept is insipired by React, so no suprises here, except that the whole concept needs some discipline.
Still to mention: For 3d games you still should see unity as solid option. And, as also with react native, you would find integration to flutter possible and supported by 3rd parties. Don't expect this to work always out of the box as a dream, but see it as a doable thing if you need to step to this road.
https://pub.dev/packages/flutter_unity_widget
As an inspiration I give you idea what kind of extensions Flutter offers, if you decide to invest on it.. This is more fun thing, but as a junior developer learning stuff and doing things out of interest this might be something to you.
Disclaimer: never heard of flame before
Without knowing more details about what kind of gameplay elements you're looking to feature in your application, it's a bit tricky to offer a transparent answer. I would feel more comfortable making my decision once I flesh out what I need the UI to do, (which will depend on how much you have drafted out)
If you go down the flutter route, you'll need to be prepared to learn about flutter's state management system more found here. On top of that, if you're used to working with tree diagrams and archiectures, you might feel quite at home as you go about building the UI. If you're familiar with design patterns, the typical AppState that's offered is not the same as the standard state design. All in all, It's a very flexible framework, so it can be easy to get distracted seeing all the different avenues you can take to the myriad of problems you'll come to face (in this case, building the foundation and/or an overhaul of your game). If you do end up going with Flutter, I would recommend sticking with Provider, Bloc, or standard AppState to get the hang of things.
Overall, I think I can offer one more damning question to ask yourself that I think might help establish a sense of direction:
How much of the gameplay happens in the UI? - E.g, incremental games like cookie clicker take place "in the UI" itself If there's a fair amount of UI changes and moving parts to what you have planned, I think flutter's a pretty good choice. Just keep in mind that the more complex the project, the less you may be able to lean on flutter's innate speed and functionality.
- If you for whatever reason develop during periods of time in which you lack internet connectivity, I would stay away from flutter because you need to be able to run
dart pub getwhenever you want to compile your project (if memory serves)
My take on state management was to hang on bloc library. I can't compare in balaced way with Riverpod, since selection from state management approach was directed in my case by former experiences (possibly availability bias) and by real requirements (bloc allows easy tracking of state changes with observer, and fits thus well with requirements of regulated environments). And I completely agree that reactive functional programming paradigm and composite ui's take some time to grasp. On the end programming paradigm is elegant, easy to reason, and lot better than I have ever exprienced when building UI's, but it's not "easy" to learn and understand - except if one is experienced react programmer, and has experience of redux style. I didn't have luxury to know modern web frameworks well enought to get help from progress of this field.
