The user can create a JSON string that represents a game (checkers, solitare, dominion, smash up, etc). Then the engine creates cards, tokens, dice, etc. It does not enforce rules but it supports multi player and some rules about visibility to other players. Its intended use case is for testing out new games or expansions before printing them.
It's a little bit early in the project though, so you'd have to run it from source if you want a demo.
This is what I've been wanting to make since I first learned about programming 3 years ago. So much effort goes onto enforcing rules, when really, all you need is the virtual pieces.
This is actually something you can do with Tabletop Simulator on steam, as I'm using it for that exact purpose. It even uses JSON as the underlying data structure. Granted, it's proprietary and not free.
My room mate tried to use that and he said it was garbage. The thing that I remember was having to type file paths manually, but there was a bunch of other specific and egregious problems he pointed out. Beyond that though, 3D brings nothing to the table; it's just a gimmick.
Hm, cool!
My company just started on a Javascript board game engine where the server & client can share the same .js file for rules, and all logic for the game is encoded into the pieces (fat models) instead of controllers, allowing for easy customization and mods.
If you're referring to |0 then I would disagree. It shows how horrible JavaScript is. This is very confusing if you're not familiar with this trick or strange behavior of the language.
The behaviour of JavaScript's bitwise operators isn't that unreasonable, but the excessive use of this trick for tiny performance gains at the expense of readability is a shame.
Languages are what they are, and if you're going to use one you might as well use it idiomatically. Maybe it's just me, but I see "|0" all the time in JS, not as some kind of crazy performance hack, but used idiomatically to mean "truncate".
And on the flip side with JS's lack of number types, any code that looks like it's doing type casts (rather than math) looks out of place. If one must mess around with JS number types then all you can really do is give hints to the optimizing compiler, in which case "|0" is the standard way to hint that you want a small int.
Obviously what looks clean is a matter of opinion, but FWIW.
There is no substantial difference in performance on mine (within 2%), although the OR was always a little bit faster.
Chrome 45 on Linux
It's odd that a bitwise operator should have the effect of truncating the float (since X|0 == X)? I'm guessing there's an implicit type conversion to int in the middle?
And every time a developer sees that, they're going to google "bar javascript" "single bar javascript" "bitwise or javascript" "bitwise or javascript effect" until they figure out WTF is going on.
This all to save a fraction of a microsecond on an operation that's called 60 times on the page.
That's just adding another conversion from undefined to Number to Int32 for the right operand. You could probably use false as well. Or the empty string.
Math.floor(value) can return some weirder values such as: NaN (for anything that isn't a number), and Infinity, -Infinity, -0. And Math.floor(-1e-300); is -1 so care needs to be taken with floating values near zero.
Yes, obviously it's not a drop in replacement as the behavior is different, but it does the same thing, giving you a number from 0 to 3 based on the card number. Pairing it with i%13 works just fine.
It is not much worse than using it in javascript. People do this in js because it saves a few keystrokes and its faster, not that it matters. Its a small thing. Its dirtier, for sure.
I just tested it in PHP and it seems it is 20% faster in PHP compared to casting to int. Maybe someone out there will have a weird use case for that, or someone doesn't want to put more effort into writing code into terminal and doesn't care about his code being unreadable. I think its useful to know it exists.
Btw, do you or someone else know why its faster in php too? Its a bitwise operation and I assume under the hood its casting to int, its weird to have it faster than casting it to int, why does this happen? It makes sense in javascript to that its faster than functions, but why it is faster than a cast in PHP?
Any idea why the suits all render as smiley faces in Chrome/Mac?
Inspecting the cards, you can see that they are using the unicode character for spade/heart/etc. But in the browser itself you get nothing but smileys.
Perhaps the font they're using doesn't have those code points?
Edit: Yes, that's the case. Font is not specified, so it comes in as "inherit" by default, using whatever the browser feels like. On Mac Chrome, that must use smileys to represent unknown characters. Switching the document font to Arial in CSS fixes the issue and makes the cards look like cards.
> On Mac Chrome, that must use smileys to represent unknown characters.
You're seeing the Last Resort fallback font, which shows a symbol representative of the codepoint range, and the range's name, so you can identify what type of font you need. Since the suits are in the smiley block, you see a smiley. If you had no Latin alphabet font, you'd see an A.
Why spend the time and effort pulling a custom font across the wire if you're only going to use symbols that exist in the web safe fonts included with the browser?
Great work. There's a couple of small issues. First, regardless of where you click on a card, when you start dragging the card will jump so that its centre is at the cursor position. Second, there is a mismatch on the Z-index used for dragging and that used when a card is dropped into place.
Sure but implementing the card back image is more difficult, which is what I think the parent post was getting at, rather than the flipping itself. The rest of the page is implemented without any images, which is neat; you'd have to work some SVG magic or something to create e.g. a Bicycle-esque card back without loading an image.
I don't see any problem using couple of SVG image files for example.. The problem is that I'm not such a great drawer myself. In the first version I just used big J, Q, K like this: http://pakastin.fi/cards_2006
Each of these cards could probably be made with one element and some CSS3 pseudo-element selectors, as opposed to the four elements (wrapper element and three child elements) that are currently used per card.
Additionally, with three elements (possible just one if you're crazily good at CSS), it'd be possible to have flippable cards. Still just using CSS3.
I did have that originally, but <card /> worked in my browser so i ran with it... I'm sure card[suit=$] with a unicode character is not super widely supported css anyway...
Browsers implement pseudo elements using actual elements internally, there's no difference in power from using ::before or just putting a <span> as a child. Pseudo elements will probably be a little bit slower though.
I agree. Some people rant about me using "value | 0" instead of "Math.floor(value)" and another would do "::before {content: attr(data-value..." -stuff instead of just using a good old elements..
This is quite nice! One "intuitive-but-counterintuitive" result -- when the cards are stacked and I drag from the corner, I end up pulling a card from the middle of the deck.
I suppose that's more for a second library that can manage stacks of cards, dealing and interacting with dealt cards, etc.
You just need a gh-pages branch on the repo. The separate repo is only for the "root folder" of that subdomain (i.e. the content of the master branch of the repo pakastin/pakastin.github.io shows up at pakastin.github.io/ and the content of the gh-pages branch of the repo pakastin/xyz shows up at pakastin.github.io/xyz).
Very nice! I tried the CSS3 routes for card animations when I first built my card game ( https://solitaire.gg ), but ended up going with WebGL since the cross-browser support for CSS3 animations was so wonky.
the animation is lovely and fluid. bit of a shame that the card faces don't have the pictures for the royal cards and the usual layout of multiple suit signs on the number cards, but this is still super.
gorgeous! really fine work. (granted i have no design talent, though i did work for an online poker shop for six years and i have played a lot of poker with friends and a lot house poker in casinos.
particularly awesome is "sort", which i think really nicely simulates a (reverse) shuffle; it seemed like i could see the top edge of the cards lift as they rotated along the bottom edge
I used HTML5 just because the original version was made with Flash back in 2006 (http://pakastin.fi/cards_2006). Then I made a Angular.js version, which is lost, but was featured on Chrome Experiments. This is actually HTML5 Deck of Cards 2 :)
As far as I can tell, it uses 2d transforms, which are usually considered part of HTML5. The animation would probably be a bit jerkier and slower if done with absolute positioning instead.
This is the real world: just because you do work doesn't mean you were working on the right thing, the right way, at the right time, for the right people, etc.
Maybe pretending everything is awesome feels good now, but it won't feel good when you're in your 40s with nothing lasting to show for 20 years of professional development work.
I won't be linking to my work for 2 reasons:
1. I say unpopular things with this account and value my anonymity.
2. It's completely irrelevant. Posting my work would neither prove that I'm justified in what I said nor disprove what you say.
It's easy to speak with your real name when don't think for yourself and instead only follow popular opinions, but that makes your opinions kind of worthless IMO. The truth is not always what's popular, I say.
Okay, but that doesn't address that it still doesn't have faces on face cards, different numbers of suit icons on each card, etc. There are off-the-shelf stock photo sets that make it easier to tell the difference between the cards.
See the thing you don't get here is that none of what you say justifies posting these comments just to shit on something. It makes a negative contribution to the conversation, which HN explicitly does not want.
I get that you (and a lot of other people) think that, I just don't care. In general, you should disabuse yourself of the notion that a) you speak for HN, and b) that I care what you want.
Other HN users can have their opinions on what they want from HN, and can downvote accordingly. But I'd like HN to be a place where people can learn about reality instead of just go to get some false positive feedback, and I'm going to act accordingly.
If you want a place where you can get unconditional approval, you might want to try your mother. She'll always approve of what you do even if it's terrible.
And in general, you're not going to gain much traction talking to me as long as you think people are obligated to care when someone gets offended.
The user can create a JSON string that represents a game (checkers, solitare, dominion, smash up, etc). Then the engine creates cards, tokens, dice, etc. It does not enforce rules but it supports multi player and some rules about visibility to other players. Its intended use case is for testing out new games or expansions before printing them.
It's a little bit early in the project though, so you'd have to run it from source if you want a demo.