Hacker News new | ask | show | jobs
by kyle_u 3822 days ago
Holy crap, I've been waiting for someone to ask me that (I need more coding friends). The entire game is client/server. The client is pure JavaScript, and communicates with the server using only a few messages (select card, move card, etc). Normally, it connects via WebSocket to my Play Framework/Scala app, and the server processes moves and sends the results and a list of potential moves back to the client.

If you download any of the native apps (iOS, Android, Linux, Win, OS X), you can play offline. This is the magic of Scala.js. The same code that my server uses gets compiled down to JS, and the client calls it directly, forgoing the socket connection. You can also see offline mode in the browser by replacing the word 'play' with 'offline'.

2 comments

Hm. This might be why I was getting severe lag while playing. I'm on a relatively laggy connection (from Brazil), so every move had a noticeable delay. I'd suggest doing client-side prediction, even in the online mode.

Yep, that was it. Just tried offline mode and it's super snappy.

Great feedback, sorry for your laggy connection. I'm working on a fix now, but glad offline mode is working for you!
That sounds AWESOME from a technical perspective. Is there a reason that you're doing a client/server thing instead of just having "offline mode" be the default, though?

For a solely single-player game, it seems to me like being able to host everything off of a static fileserver instead of a Scala server seems like a scalability win for you and a bandwidth win for users. I don't doubt your choice and your tech stack (you know way more about your project and its needs than I do!), but I'd be super-curious to hear more about the reasoning and process.

Having it client/server eliminates the possibility of cheating, lets me get exact timings for analytics and data mining and whatnot, and lets me implement cool things like "Observe Game" (coming soon!).

After the feedback from this thread, I'm going to move to a "hybrid" model where the model logic all happens locally, but still fires websocket events to the server. Best of both worlds.