> We had to implement techniques like client side prediction, server reconciliation and entity interpolation so that players look smooth when they are moving in the 3D space.
Curious: what kind of tools/frameworks could have helped in shipping to wasm faster and better?
I'm Daniel, Diego's brother who also worked on this project. Your question is a bit broad, but I can tell you what it was like to work with emscripten.
We used emscripten to compile our C++ application to WASM and to generate the JS code that loads the application. This part was very easy. We had the game running on the web in no time.
What was much much more difficult was working with emscripten's APIs to do things like handle mouse / touch / keyboard inputs. There's tons of gotchas and weird limitations to work through.
Another huge challenge was in sending data between the JavaScript layer and the C++ application. You have to serialize data and then parse it on the C++ side, which sounds easy until you try to do it.
We faced some tough challenges asynchronously loading the paintings. Our initial solution of using a simple thread pool library which manages web workers didn't run on Safari due to some strange incompatibilities with WebGL 2.0, so we had to go for a purely web worker based approach.
Overall, we are amazed at what you can do with emscripten, but you have to be prepared to face some bad documentation, browser incompatibilities, and to tinker A LOT.
Do you see a future where cross-platform could essentially be a set of tools/frameworks to build high performance native experiences targeting the browser as the primary runtime?
I think that'd be near impossible to speculate on. There could be hundreds of different ways it could evolve that way, including ways that involve frameworks that haven't been invented yet.
Hi - Luke (CTO) here. Thanks! Yeah, we're using WASM for things some things in the editor like syntax highlighting. Planning on moving most of the network logic into WASM shortly as well.
Nifty start. The need for a hosted service like this is more for secure apps where third-party services may have some privacy implications.
I think the default UI needs a little more work. Intercom also lets you email users based on certain triggers, is there an email integration that you are building towards?
Edit: Just curious, what made you code the server in Go?
Thats a good point re: secure apps/third party services. we also wanted to run a hosted service for the lazy who may not want to bother learning how to run each of the pieces ;)
Thanks for the feedback too, in complete honesty, it was a combination of we were interested in the language, and overheard it was good with concurrency... that was enough for us to give it a shot.
Edit: Also apologies for not answering your question re: email integration, its going to be one of the first major integrations we do!
Inclusions usually come from the community - users tend to add products to their stack, a lot of them obviously being OSS. We have tried to reach out to creators/admins in the past to understand if they'd like to represent themselves in the right way in front of a large buyer group.
Apologies Matt - we'd love it if you gave the platform a try, but will not include you in any future email-campaign, going forward.
IANAL, but I think cold emails are still legal in Germany, provided they're not just advertisements (e.g. "someone added you as maintainer of [super awesome project]" is probably OK) and you offer a clearly visible option to unsubscribe (i.e. it shouldn't require posting on a random internet forum to get the attention of a company representative).
In essence, the law prohibits business practices that are an "unacceptable nuisance". While advertising via email spam is clearly called out as such, not all cases are so clear cut and will depend on the judge's opinion of acceptable behavior.
Yeah, NPS is a good way to understand how actual customers feel about a product. We have collected tens of thousands of sentiment over the last six months on a wide range of products, and at scale, this sentiment data set can be quite valuable.
In this case, the primary category for Intercom is `User onboarding and Engagement` which can be broken down separately to `User Onboarding` and `In-app Support` or `In-app Chat`. That will suddenly spike up the sanity of both categories (maybe we can even normalize further - siftery has more than 700 categories/tags, a first for any such platform).
Categorisation of a data set like this can be non-trivial and will false positives. We can cherry-pick such a false positive and ignore all the actual positives. That said, thanks for this feedback - this is exactly what is needed to improve status quo. We are on it and will report back in a few hours with the category split I suggested in the previous paragraph. Do let me know if you think it can be broken down into a different type of granularity?
not certain if this should be the status quo for the longer term.