openEtG VS language

For an example of binsearch algo, I recently dipped into this while switching some code from floats to fixed point arithmetic (reducing overall wasm blob size)

https://github.com/serprex/openEtG/blob/2011007dec2616d1a24d...

This seems pretty low level. When I wanted async wasm execution (to run multithreaded game ai simulation or to run game ai outside of UI thread) I was able to go with WebWorkers: https://github.com/serprex/openEtG/blob/master/src/AiWorker....

Having the async at the WASM level would help avoid having overhead from serialize/deserialize between web workers. I wrote this years ago, so not sure what progress has been made for having the wasm module running multiple threads. On that front you may still be better off spawning multiple wasm modules

(( dunno which version you're trying, cuz there've been a lot of fan versions after the original went down, but this should be the one most people use ))

Check out the spiritual successor, openEtG: https://etg.dek.im

This one? https://etg.dek.im/

If you want a reference to a real code base, there's openEtG's handleget.rs

https://github.com/rustwasm/wasm-pack/pull/1089

Very straight forward changes. Emailed Ashley about helping, no response

Updates to wasm-bindgen shouldn't require a change to wasm-pack. It should expose ways to pass flags down & not have an explicit dependency on wasm-bindgen version

While having a webpack plugin is nice, I since gave up on wasm-pack & added a build-wasm to my package.json's scripts: https://github.com/serprex/openEtG/commit/9997fb098d168920bb...

This way if someone wants to contribute to openetg they don't need to install my wasm-pack fork

Join us on the official Discord https://discord.gg/qAmfB8T and we can walk you through it. There is a spiritual successor to the game (https://etg.dek.im) and a revival of the game. There are also several methods to still play the original.

Elements. Strictly speaking, this is a collectable card game (MtG style) rather than a true "deckbuilder" but otherwise it sounds exactly like what you are looking for. Heavy emphasis on creative out-of-match deckbuilding and one-off PvE matches. From what I can tell, I think the original game died with Flash, but it appears that fans created a substitute, which I haven't tried: https://etg.dek.im/

I noticed that I can enable inline-class as an experiment to play with Extension Types. You need to also add sdk: ^3.3.0-0 to your pubspec.yaml.

Current syntax is not all that bad if you are going to do OO and add various helper methods on `Message` and its subclasses, but if you just want to define your data and no behavior / helpers - then it is exceedingly verbose.

[1]: https://github.com/dart-lang/language/issues/3021

Reference

A future version of Dart will probably support macros which should make this all a bit easier to use, similar to how Swift 5.9 works which makes already fantastic use of its new macro capabilities by integrating mobx (or solidjs) like reactivity into SwiftUI by a harmlessly looking @Obervable annotation.

Coming from a Dart context here where that team is also looking at adding Macros to the language. It was really interesting to compare and contrast some of the approaches https://github.com/dart-lang/language/blob/main/working/macr...

Yes, that needs a bit of boilerplate for the constructor declaration and the extra build method, but I personally don't mind and with implicit constructors this will become much easier. Also, you get a performant UI as Flutter knows to not redraw widgets that didn't change.

I know that it would be nice not to use the generator at all, but we have to wait until static metaprogramming is implemented in dart. https://github.com/dart-lang/language/issues/1482

I implemented a prototype version of the algorithm in that paper when exploring exhaustiveness checking for pattern matching in Dart.

I found it pretty easy to understand, but also really easy to get it to generate huge combinatorially large spaces. Some careful memoization and deduplication helped, but even so I never got the performance to a state I considered acceptable.

Instead, I went with Luc Maranget's classic approach and figured out a way to adapt it to a language with subtyping (with a ton of work from Johnni Winther to figure out all of the hard complex cases around generics):

https://github.com/dart-lang/language/blob/main/accepted/fut...

The performance (in the prototype!) was dramatically better. You can always make pattern matching go combinatorial, but I haven't seen any real-world switches get particularly slow with our approach yet, and we have some fairly large tests of matching on tuples of enums.