What is potentially a problem is the lack of training material for AI agents to generate games on top of this platform.
"Training material for AI agents?" The lack of such is not a problem. AI agents are an adversary for many, not a target.
This is one of those things you say to interest people. To put their concerns to rest that it might not be able to make the game they want. It doesn't really mean anything. No absolute measurements or relative comparisons.
You can benchmark an algorithm or a small piece of code, but for something like a game library, the definition of what is "fast" and what isn't is too dependent on context to be meaningful.
That doesn't mean that the statement is useless: it tells me that this is, at least partially, one of the goals of the library.
i.e. The engine is considered lower quality if it is laggy, generates DLSS chowder, or glitches up on some hardware.
The people responsible for shader cache performance get a lot of grief given the performance hit in unpredictable play contexts is often very noticeable.
The Unreal devs made it look deceptively easy. =3
Good luck!
- Cross Compilation (even wasm and js) out of the box - Simple concurrency model, similar to NodeJS - Ability to use it on a popular cross platform framework (flutter) - Hot reload capibilities (has JIT and AOT mode) - Strong developer tool chain
All of these are built on top of a language that has a pretty syntax and supports many language paradigms.
The biggest con is the (weak) package ecosystem and community.
The LSP server in particular is amazingly fast and reliable - better than Java IDEs. It's practically instant from typing something to seeing the squiggles update. C++, Rust, Go, Typescript etc. don't come close.
Obviously there are downsides: relatively tiny ecosystem, sometimes weird syntax (why is a match expression and match statement different??), this very annoying issue that I see remains unsolved after 5 years: https://github.com/dart-lang/language/issues/1188
It doesn't have 30 years of JavaScript legacy code.
The problem is Google cut significant funding to Flutter, it's not clear if it'll be supported for much longer.
I've built several toy apps in flutter for myself and friends. I like Flutter. But Google's lack of commitment is concerning.
Dart itself feels like a safer Typescript. The tooling is just better.
Just to be clear, Google slashed teams across their entire organization, not just the Flutter / Dart team. So it wasn't like Google targeted the Flutter / Dart project
> it's not clear if it'll be supported for much longer
> Google's lack of commitment is concerning
I had similar feelings. When looking this up, it showed that Google continues to actively develop and invest in Flutter, with regular updates, new features, and performance improvements being released for both Flutter and the Dart language.
The official Flutter roadmap has been updated through 2025
https://www.reddit.com/r/FlutterDev/comments/1jrz4cd/googles...
To be fair, I can get things done much faster in flutter than in other frameworks.
I did build a small Kotlin project though, I might switch to Kotlin Multiplatform if something happens with Flutter.
- Properly cross platform (including first-class JS/WASM interop)
- AOT & cross compilation
- Hot reload
- Static typing with many nice features (generics, extension types, enhanced enums, etc)
- Expressive without being overly verbose
- Well-supported by the language & SDK teams (i.e. it's not dead)
- Easy build/package system
The only things I really feel are missing are (1) union types and (2) access modifiers like protected/friend.
Another user hinted at this package https://pub.dev/packages/extension_type_unions, have you seen it before?
Also it's worth noting that sum types can be achieved with Dart 3!
```
sealed class MyParam {}
class Bar extends MyParam { String val; }
class Baz extends MyParam { int val; }
void foo(MyParam param) {
switch(myParam) {
case Baz(val: final val):
case Bar(val: final val):
}
compared to:
```
void foo(Bar | Baz myVar) {
switch(myVar) {
case Bar:
case Baz:
}I hadn't seen the extension_type_unions package, though, I'll check it out.
Was it not before? The only parts I've not enjoyed in the past has been working with a team that didn't pull their weight. What part of this makes it fun again?
Nevertheless, it's cool to see something new come to the scene for game dev in Dart. Thanks for making this!
Flame offers more out-of-the-box features, while with Bullseye2D you have to build many things yourself, but it doesn't force you into a predefined structure as much. The API is more prodcedural style, making it relatively quick to learen in its entirety, without too much "magic" happening under the hood.
I think for most people Flame would be the better choice (it is also been around longer, which means better support...), however, I really love extremly simple approaches. I also believe it has advantages when you tailor your systems and architecture to your own requirements. Lots of stuff in 2D Game Development is also extremly simple (so often having to deal with a complex physics module or rendering pipeline or entity component system is contraproductive).
I feel like the music player example has lots of potential for other things, not just for games. https://bullseye2d.org/bullseye2d-demos
munificent•7mo ago
joemanaco•7mo ago