Hacker News new | past | comments | ask | show | jobs | submit login

Happy to see Deno get some financial backing!

I've been building my new multiplayer games website [1] with Deno over the last 4 months and apart from some minor growing pains, it's been a joy to use.

The lack of unnecessary package management, and the TypeScript-by-default approach makes Web dev much nicer. We're also using TypeScript on the client-side, relying on VSCode for error reporting. We use sucrase to strip the types just as we're serving the script files, so that there is no extra build time, it feels like TypeScript is Web-native and we can share typed code with the server.

[1] Not yet launched but we ran a preview past weekend with hundreds of players over WebSockets: https://twitter.com/MasterOfTheGrid/status/13757583007179735... - https://sparks.land




https://sparks.land doesn't load properly on mobile (iOS, Firefox)


Ah thanks for the heads up. It requires WebGL 2 which isn't yet in iOS's Web engine I believe? And IIRC all browsers have to use it on iOS. It does work on Android.


No webgl2, but there are a lot of webgl2 extensions supported. The biggest omission for me is not being able to render to float textures. (Although a lot of android devices cant do this either)


Peeking at sparks.land I see that you're serving .ts files, I assume that's what you mean by using sucrase, you're transpiling "live" instead of building/deploying bundles offline?

I notice your script files are all pretty small, have you run into any upper limits on performance or scalability so far with this approach?


Correct! In production we've got Cloudflare in the middle, so we're only using sucrase on-the-fly for each .ts file during development. So far it's unnoticeable in terms of loading times.

> I notice your script files are all pretty small, have you run into any upper limits on performance or scalability so far with this approach?

Not that I can tell. But if we need to, we can always do a minified bundle in production later on. So far it's just nice to not have to even think about it!


Wait, so you're running Sucrase in a Cloudflare Worker?

It compiles, and then caches the output I assume?

That's a really cool use case I hadn't thought of..


Not quite, I'm running Sucrase on my Deno HTTP server: if the extension is ".ts", I put the file through sucrase before serving it as text/javascript. In development, it happens every single time I reload (and it's fast enough that I don't even notice). In production, Cloudflare requests the .ts file from my server once (triggering sucrase), and then caches it.


Is the VSCode support good? I tried using Deno with WebStorm a few months ago and it wasn't a great experience.


It's getting there! They finished a rewrite of the extension recently and it's quite nice.

If you're on Windows like me, sadly there's still a nasty bug with path mismatches between the LSP server and the VSCode extension (https://github.com/denoland/deno/issues/9744) which requires reloading the window to fix spurious errors, but I'm sure it'll be fixed soon enough.


Jetbrains extension hasn't been updated much since release and doesn't interface with the official LSP. The experience is poor and outdated.

Vscode extension is maintained by the official team and will provide the best experience. There are unofficial plugins for sublime and Vim. They use LSP too and provide a comparable experience.


Hey, the Discord invite link is not active anymore.


Which one? The home page one seems to work for me. Otherwise try: https://sparks.land/discord


Are you running multiple cores/threads of deno? If so how are you holding/communicating state server side?


There's a central Deno server program called the switchboard, which serves static content, runs a small REST API for account management / login, and starts a WebSocket server for game servers to register themselves.

Each game server (a stand-alone Deno program that might or might not run on its own machine) connects to the switchboard over websocket and authenticates itself with an API key (since people will be able to make their own game servers).

When a player wants to join a server, they POST a request to the switchboard, which gives them back a token that they can send to the game server after establishing a WebSocket connection to it. The game server checks the token with the switchboard and gets back public user account info if it's valid.

Each game server's logic is currently single-threaded. I guess we might end up offloading some work to WebWorkers later on.

A server can publish some state info through the switchboard that will be broadcasted to other servers from the same user. This is used to show player counts in game rooms from a lobby, things like that.

I run the whole thing on a couple cheap Scaleway servers, with Cloudflare in front (no AWS nor containers or anything of the sort). My previous platform, built with Node.js (https://jklm.fun) is able to sustain at least 2000 concurrent players like that, though admittedly those are board-like games which are not very demanding, unlike the games for Sparks.land which will be more fully-fledged... so we'll see how that holds up!


Thanks I run something similar that can only really do 300 players before it starts to lag badly but TBH needs to be rewritten as its all single threaded and 1 process controls the lobby, every game, all chats, etc. Don't do what I did -_-


Haha I feel your pain, I did the same initially, took a few rewrites over the years to get to something I'm happy with and runs well.


For completeness, you should check out Elixir and Phoenix (channels and presence) for the server. Easy websockets, isolated player processes, non-blocking VM, plus deep introspection for debugging issues. https://youtu.be/JvBT4XBdoUE. We see more and more indie games being built with Phoenix LiveView.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: