Hacker News Reader

Comment by kyle_u | Hacker News Reader

I don't know what it is, but I love implementing Solitaire to learn new languages and frameworks. It's always a fun exercise, and the engine gets better with every iteration. My latest attempt is https://solitaire.gg - it's a Scala/Scala.js WebGL/websocket Phaser web/native app with hundreds of games.

View on HN

Kyle, this is brilliantly done. Honestly, I didn't expect the level of polish and fluidity that I experienced when I tapped that link on my iPad. The slight "lean" when cards are dragged around, butter-smooth animations... Well done.

I'd love to see some of your notes behind wiring up the pseudo-physics of the cards. Or was that provided by a library?

EDIT: I need to read more carefully - looks like it's part of http://www.phaser.io, and now I've just wrecked my productivity for the day! Great job on the solitaire game.

Thanks! Phaser.io has a great tweening/animation system I use for some things, but the momentum animation was just a few lines of custom code. You basically just set the angle to a smoothed (distance travelled in last 500ms).

Would it be possible/difficult to reverse the direction of the lean if the card is 'grabbed' on the bottom half?

Good idea, and a simple change. Thanks!

No problem! Of course the really awesome feature would be the ability to drag piles of cards and have it automatically determine whether there is enough space up top to do the swaps. (ie if you have 3 spaces open at the top-left, you can drag a 6543 onto a 7 in one step.) Similarly automatically putting cards up on the top right once they're exposed and there are no lower-value cards left. Obviously those would be rather more work though!

So which "phaser" have you used then and what have you used it for?

I use http://phaser.io for scene management (animated resizing of the game, tweening cards to predefined points on the table, etc) and the particle effects, as well as dynamically building the card images. I've been really impressed with Phaser.

just gotta say, you bastard, what a lovely comment. if i were developer of any project and got a note like this it would make my day (so im a little envious of kyle_u), if he used a library that does whatever it was that impressed you or not. :P

That's a nice way to start my day, thanks. :)

I think what strikes me most about a program, and what tends to speak to many people, are the little touches that are a delight to discover. Especially when you're not expecting them. So many comments have said "check this thing I made" and the thing proves to be well done, but somewhat utilitarian. Now, I like utilitarian as much as the next gold tunic wearing Terran, but these little touches created by the personal choice of a developer make a random human-computer interaction seem, even if by proxy, a little more human-human.

You're welcome. I appreciate what you're saying. I am not sure that I feel quite as strongly about the importance of the personal, loving little touches as you do, but the idea resonates with me. I actually might agree with you completely, given time to fully digest the idea, but it brings up a similar but maybe tangential point:

Over the last few years, probably most clearly highlighted after I was introduced to and started working with Bootstrap to create half-decent looking webpages (it is an HTML/JS/CSS UI toolkit/library/framework that makes it possible for web devs without a whole lot of design chops to simply create nice looking pages - https://getbootstrap.com/), I have been coming round to the idea that making something aesthetically pleasing and pleasant to visually/tactiley experience for the first time is not just beneficial or a small-but-helpful part of designing a well-liked and good webapp, but a key part of the experience. I really feel like if I have a good looking site versus an ugly one where the clickity-click part of the UX is identical, the good looking one will just really be more inherently comfortable, appealing, and embraceable for people. And not just other people - but me, the dev, who has seen behind the curtain and knows where all the ugly parts of the code or UX are. It's quite possible that if this is really true that it's obvious to loads of people, but it has been a slow realization for me, who used to get haircuts ridiculously infrequently/not shave very often, etc., in some cases thinking "well I eat well and exercise - what's inside is good stuff! Anybody who doesn't appreciate that is <adjective-indicating-poor-appraisal-skils>."

I guess what I'm saying is, spending time on quality presentation is a key part of appreciating your user IMO, and in terms of spurring project motivation I think it can be really useful and inspiring to get a static webpage with dummy UI that just looks and feels good.

I really do feel a little silly saying this because in hindsight it seems like it is one of those things that might be obvious to everyone else, but it was not to me, and maybe there are others out there like me :)

Thanks, I also didn't know about phaser.io, and just searching for phaser brought me to the wrong one: https://docs.oracle.com/javase/7/docs/api/java/util/concurre...

Hey that's nice. I run http://greenfelt.net in my spare time—it came about because my friend and I wanted to learn javascript after seeing how cool google maps was and so we implemented Sea Haven Towers, a solitaire game he had played on his Sun, back in the day. Solitaire is nice because it's easy but still challenging enough to not be completely straightforward. It's fun to work on occasionally and it's rewarding to see random people play your games.

Our games don't work as well as your does on mobile, but I think they're still very nice on computers.

Darn it, you hugged it harder than my tiny Amazon box could handle. Resizing the box now.

All good now - thanks, AWS! And thanks to everyone for the feedback. Wasn't expecting to launch my game today, but I'm glad I did.

I'd be interested to know how you got back up and running so quickly.

With AWS it's easy. You stop the machine, resize it to a bigger one with more CPU and/or RAM, then fire it up. This can be done in minutes.

Yep, this. Went perfectly, and thanks to Akka Persistence, end users (hopefully) just saw a minute of lag before their game resumed.

I'm guessing this app looks cool; you might like to know that older systems remix it into glitch art like this: http://imgur.com/a/o3YVy

I thought I'd give it a whirl on the old ThinkPad T43 I'm using at the moment. I never really expect much from its tiny Mobility Radeon X300, but this was especially hilarious, and a most unexpected, refreshing change from the usual "oh, the disk LED is solid... again..." that I usually get. :P

FWIW, the http://aframe.io/ examples all work perfectly - I was actually slightly gobsmacked when I saw them, I can tell you with a fair amount of confidence that the simpler demos run on my system as fast as yours - so this GPU isn't a total lost cause with WebGL, and if it's moderately trivial to fix this, you'll net a small extra niche in your userbase (along with mobile users in 3rd-world countries using really entry-level smartphones and tablets).

If the fault lies with Phaser.io, and you feel like poking their ticket thingy, I'm fine with you passing the screenshots along. I'm also fine with testing potential fixes, if there's any room to explore there.

If your build environment can split out 32-bit Linux binaries without too much effort, I'd be happy to test that too.

That "glitch art" looks like a video-card driver problem to me. It's also possible that the solitaire site uses more texture space than your card/driver can handle causing issues.

The Aframe examples you linked seem to be simple geometric shapes with no textures so you may just be getting lucky there.

Also, Phaser, the library GP is using uses Pixi.js for the webGL drawing code if I remember correctly and Pixi is supposed to fall-back to plain canvas rendering if webGL isn't supported -- so disabling WebGL for the site may make the solitaire site work.

Looks like you're right, the author responded saying exactly the same thing :)

I tried killing webGL, which technically worked - I see a card deck! - but it didn't practically work: said card deck interacted at about 0.75-0.9fps. XD

Linux 32-bit Build: https://s3.amazonaws.com/solitaire.gg/linux/Solitaire.gg.x32...

It looks like I exceeded your texture memory. I use pretty high resolutions (targeting 4K displays), and dynamically build the card textures at runtime based on your screen size. Let me know if the native app improves the situation.

Another commenter said exactly the same thing about texture size, so I think you've pretty much nailed it.

The native build sadly didn't fix much; Electron === Chrome at this level of the stack pretty much. Thanks for taking the time to build it though :)

Incidentally, I tested the 32-bit build on my T43, and also tried the x64 build on my ever so slightly newer T60; both seem to have exactly the same issue: I'm getting pages and pages of

  r300: CS space validation failed. (not enough memory?) Skipping rendering.

on both machines' stdouts when I run ./solitaire. One uses (as I mentioned) an ATI X300, the other an X1400.

Behold what 2005-2007 had to offer...! xD

The T43 says:

  radeon 0000:01:00.0: VRAM: 128M 0x00000000C0000000 - 0x00000000C7FFFFFF (64M used)
  radeon 0000:01:00.0: GTT: 512M 0x00000000A0000000 - 0x00000000BFFFFFFF
  [drm] Detected VRAM RAM=128M, BAR=128M
  [drm] RAM width 64bits DDR
  [TTM] Zone  kernel: Available graphics memory: 440758 kiB
  [TTM] Zone highmem: Available graphics memory: 509818 kiB
  [drm] radeon: 64M of VRAM memory ready
  [drm] radeon: 512M of GTT memory ready.
  [drm] PCIE GART of 512M enabled (table at 0x00000000C0040000).

And the T60 says:

  radeon 0000:01:00.0: VRAM: 128M 0x0000000000000000 - 0x0000000007FFFFFF (128M used)
  radeon 0000:01:00.0: GTT: 512M 0x0000000008000000 - 0x0000000027FFFFFF
  [drm] Detected VRAM RAM=128M, BAR=128M
  [drm] RAM width 128bits DDR
  [TTM] Zone  kernel: Available graphics memory: 1534580 kiB
  [drm] radeon: 128M of VRAM memory ready
  [drm] radeon: 512M of GTT memory ready.
  [drm] PCIE GART of 512M enabled (table at 0x0000000000040000).

Can confirm, am firmly entrenched in old-hardware club. Ah well.

I'll try and check back here to see if you've thought of anything else; my email's in my profile.

For a few years now Google has had a little canvas benchmark in search results pages to figure out whether to enable endless scrolling. The game might springboard off of a technique like that to decide whether or not to use lower-resolution textures. (IMO, I'd target the detected screen resolution myself, I think that'd work...?)

>Behold what 2005-2007 had to offer

Actually, it (https://solitaire.gg/play/freecell on Chrome) locked up my (Intel HD Graphics 3000) 2011 Mac, so it's not just ancient machines.

Found a bug: When double clicking on a stack a 3 of spades went "up", but the card graphic stayed (and can be moved around)

Fixed, thanks for the report!

I have one concern with framerate, if there is no need to maintain 60fps 100% of the time, Phaser should have a way to lower or pause fps, sadly, there isn't a way to avoid battery drain.

a little off topic but is it possible to truly randomize the 80,658,175,170,943,878,571,660,636,856,403,766,975,289,505,440,883,277,824,000,000,000,000 shuffle combinations?

edit: also, when i play solitaire via an ipad app there is always a 'top score' by someone for the hand i was dealt. i dont understand how this is probabilistically possible

Shuffling can be done in linear time, e.g. with https://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle so yes.

I believe user thomasthomas was referring to this problem:

https://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle#P...

That is, is there enough entropy in your typical PRNG to actually generate all of those shuffles with equal probability.

You can easily seed your PRNG with a cryptographic entropy source which can certainly provide enough entropy.

But in reality you don't care. You could seed the PRNG with the current system time in nanoseconds or something, and every game you'll ever play is different. Even if the PRNG has limited state, you'll never notice it as a human player.

I'd like to elaborate. The cryptographic PRNG has lots of entropy, and it probably happens to be enough entropy. You need ~226 bits, and most cryptographic PRNGs will be more than that—but not all! Information-theoretic entropy is actually a stronger requirement, and it's why we use /dev/urandom (which is secure and fast) instead of /dev/random (which is information-theoretic secure, but slow).

So it might be possible that your secure PRNG still cannot generate all permutations.

Paging tptacek to quarrel with the account of RNG entropy presented here (?)

Quarrel? Here, let me clarify. A PRNG has state with a certain amount of potential entropy, call this X. Uniformly shuffling a deck of cards requires a certain amount of entropy, Y. If X > Y then theoretically you can generate all possible shufflings with your PRNG, assuming it's seeded properly. If X < Y, then you can't.

The key difference is that your PRNG could be cryptographically secure even though X < Y. It turns out that Y ≈ 226 bits, and so it's plausible that your cryptographically secure RNG would have X = 128 bits, for example, even though I'd typically expect a larger number.

People often conflate entropy with security. A random number source could have high amounts of entropy and be insecure, while a random number source with less entropy could be very secure. Or let me put it this way: entropy is necessary but not sufficient for security.

I agree with your argument on a pigeonhole-principle level (if you only observe fewer than 128 bits of state and then shuffle cards in a deterministic way based on a summary of your observations, you can't get all possible shuffles out), and I think that's a nice observation. 52! is surprisingly huge, and determinism is deterministic. :-) The issue is just about what /dev/urandom and /dev/random do.

There's a lot of misinformation and cargo cult crypto programming, but the basic summary is that /dev/random information-theoretic security is unnecessary for most applications, but necessary for being able to know that you can produce every possible permutation of a deck of cards.

http://www.2uo.de/myths-about-urandom/

/dev/random and /dev/urandom are the same CSPRNG construction; /dev/random just provides some extra (almost always counterproductive) checks on the rate at which it's rekeyed.

It is not the case that using /dev/random somehow gets you an information-theoretic security level that /dev/urandom doesn't.

Yes, they both use the same PRNG construction, that's in the article I linked to. But the blocking behavior of /dev/random does give it information-theoretic security, because an attacker with unlimited computational power can't predict its output, assuming they don't know the outputs of the entropy sources you are using, assuming that your entropy estimates are accurate or conservative. And we use /dev/urandom because information-theoretic security in our RNG does not improve actual system security.

No, it doesn't, because all the mixing and mangling of your precious entropy inside drivers/char/random.c is not information-theoretically secure.

Right, I give up. What I should have said is, "/dev/random is a misguided attempt at information-theoretic security." Everything in its design makes it clear that its goal is information-theoretic security.

I was thinking, "Oh, the mixing is good enough for practical use." But that's not what information-theoretic means.

I was thinking, "Oh, assuming the entropy estimation works." But we know it doesn't.

It was a stupid argument. But then again, /dev/random is stupid. Nobody gives a damn about information-theoretic security, and we don't have it anyway.

It only takes 226 bits of entropy if all shuffles should be equally likely. If one shuffle has probability sufficiently close to 1, and the rest are equally likely, you could make do with less than a bit of entropy.

Right, that's what "uniformly" means. Discrete uniform distribution = all shuffles are equally likely.

Well, beyond what a human player would notice, to be able to be dealt any possible hand in solitaire, a random or pseudo-random number generator would need log 2 (52!) bits of state or > 226 bits, which is the point I think the commenter was making, compared to the 32- or 64-bits of information a built-in function would take.

Something like a properly seeded 256 bit xorshift might satisfy this as a random number generator. But even that setup may not be sufficent.

You can always use https://www.fourmilab.ch/hotbits/ as well.

Top score: if all players have them same seed for the RNG, they'll be playing the same sequence of games - unless you've played more games than any other player there'll be a high score. Need to keep track of RNG state between sessions, of course.

In practice, for my game, I use a single positive signed int as the initial seed for the Scala/Scala.js PRNG (Amazingly, they implement the same algorithm), meaning only two billion or so possible games. If I re-seeded the PRNG each time I moved a card ordering, then the full [52!] shuffles could be generated. I only use initial seed, so that a given seed will always generate the same shuffle/deal order.

Here's the critical issue: how do you re-seed? This is actually far, far more difficult than it sounds.

The Mersenne twister algorithm (https://en.wikipedia.org/wiki/Mersenne_Twister) has a period of 2^19937 - 1, way more than 52!~2^256 possible shuffles, and is fairly widely used. I know for a fact it is used by the python standard library.

It's not a matter of the size of the period, but of the size of the seed. To be able to generate all shuffles, you need to seed with at least 226 bits.

This is pretty awesome!

Just one thought though... The starter screen is a bit complicated. (Talking only about the web version, haven't tried the phone apps)

I was just thinking my parents would love this game as Klondike and FreeCell are pretty much bare requirements when they buy a new computer or when I set one up for them. And your game works great, looks good and has all these variants. Except... They wouldn't have a clue which one to pick!

I don't know what would be the best way to show case the games for selecting them. A carousel showing an animation with each of them? Or a preview split screen that shows that animation when you hover on one? Or directly small animations for each button?

No clue, but if you can find a way to make it easier (and to then pin your "favorite" games alongside the "popular" picks) you've got yourself a super winner.

Great advice, thanks for the feedback. I'll get on that tonight (right after the right-click bug that everyone hates).

Beautifully done. I can't believe a browser game is that smooth. Why are we even building native anymore!!!

Click left on any card, than click right. Use the hint button for your personal floating cards stack.

Acknowledged. I'll fix it up tonight, thanks! Cross-browser mouse events have been the biggest hassle.

That's really nice! Plain ol' Russian Solitaire isn't linked from the front page, though (it's my wife's go-to solitaire game). I found it by looking in the help for Russian Cell and seeing it linked there.

Yeah, I've started work on 600 or so games, but haven't tested them all. Russian Solitaire is a glaring omission, and will be corrected right away.

There's really no reason for it to hog a CPU core at all times, not to mention the battery drain. It's not a real-time game, you can refresh the screen or play the animations just when needed.

Great job! I love the feel while playing with the card movement.

So you know, on my Linux box there is a massive performance difference between Firefox (very sluggish) and Chromium (perfectly fluid).

Looks super fun, hope you open source it soon!

WebGL is terribly different across browsers. I run a small game company and we write our games in Unity3D. Exporting them for the web is an exercise in self-flagellation. Starting with Chrome, browsers are killing plugin support of any kind before a viable alternative is ready - and WebGL is certainly not ready. We still support the Unity plugin on Firefox, but can't do a WebGL fallback yet because the tech just isn't there yet.

(Yes, Unity's WebGL exporter is also in the mix, but browser rendering and support for the exported game is still wildly different across browsers.)

Out of curiosity, what are you using WebSockets for?

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'.

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.

Strange - I flat-out can't get the game to load on Firefox 43.0.1 or Chrome 47.0.2526.106, but it works just fine on IE11.

Heh, I almost never test in IE, so I expect the reverse. Let me know what errors you're seeing via the game's feedback form.

I figured it out - the game wouldn't load because the computer I was testing the game on has very limited RAM.

Looks great! Is this open source?

I'll probably open source it in the future, there's a lot of code there, and not much money to be made in Solitaire. I did extract some of the best general parts of the app (the admin, authentication, etc) into a project template I call Boilerplay (https://github.com/KyleU/boilerplay). If anyone's interested, I could also publish my pipeline to turn the Scala.js webapp into native apps for OSX, Windows, Linux, iOS, and Android.

>not much money to be made in Solitaire

Are you joking? Wes Cherry said he's made $.08!! in Solitaire royalties alone!

Honestly, that would be awesome. The pipeline part, I mean.

For me, it is game of life. I enjoy implementing it in new languages/platforms.

Plot twist: kyle_u is really Wes Cherry!

Reply on news.ycombinator.com