It's really interesting to see what went into this before the competition. I'm on one of the other teams that'd doing pretty well in the voting (we built Drawbridge: http://team-hyphen.no.de/), so it's especially interesting for me to see what other teams did.
Much as I'd love to win, Drawbridge isn't near the level of polish that Scrabb.ly and a few of the other top apps are, and I think a lack of preparation is the main culprit. We had a general idea of what we were going to build and how it was going to be designed, but we had to scramble several times to redesign and rearchitect essential components. (We did our server-side API design without accounting for the fact that we were going to be using websockets, completely overlooked the fact that we'd have to come up with an API for our DAO or anything on the client side, had to completely redo how variations and their UI worked, and had to come up with a homepage design all within the span of the competition.)
Still, it's been an incredibly fun ride. In the absolute worst case I built a tool I've been wanting for a long time but haven't been able to find the time to build. In the best case, other people find it useful too--having other people liking and using things I've built is one of my biggest motivators.
I've also learned a ton about making a successful app for one of these competitions. If I could do it again there are a lot of things I'd do differently. (Luckily, Rails Rumble is coming up, so I can!) I've been meaning to write up summary of what went right and what went wrong for us, and how we could improve. Would anyone else be interested if I turned it into a blog post?
Can anybody tell me about an appropriate data structure for computing Scrabble (or any crossword) short of full-out walking a 2d grid? I've read a bit about Tries and Directed Acyclic Word Graphs, but those seem to just be for optimizing dictionary matching, and don't seem to account at all for the actual structure of the board (especially not the possibility of colliding with other branches when adding new words).
I'm 90% certain it'll come back right back to needing a global and explicit a 2d grid when I try to build in a board with static score multipliers, but ignoring this for now and just trying to lay out letters: is there a masochistically-functional way to compute Scrabble/crosswords without working on an explicit 2d grid?
Well, finding the best word for a given tile rack played on a given position can be expressed staggeringly simply in Haskell. I'm just wondering if there's some clever way to store and search a whole board without getting into something messy and halfway-imperative. Something that can be expressed as mostly a composition of simple library functions.
Plus, I've always had issues with multidimensional structures -- I can never quite settle on what's the most intuitive way to express them.
Really interesting and (should the authors read this) thanks a ton for sharing it. I am curious about one thing. I sort-of already know the answer, but will ask anyway: I saw in the post that you used Pusher for handling your realtime updates across clients (looks like a very cool service, btw). Isn't part of the strength of node.js and socket.io that things like push-based client/server apps are/should be trivial to implement without resorting to a third party service? If so, did you try? And do you know if other node knockout apps use pusher? (I assume that a: it saved a little time and b: was an easy way to get around Heroku's current connection limits, but want to know if there was more to it than that).
Using heroku in pre-alpha meant we couldn't use websockets. Since we were very used to Heroku, we figured we'd just accept this limitation and work around it (with PusherApp). Turned out to be a great decision since we never would have had time to implement websockets I don;t think. It's definitely not hard with Node, but it does take some thought and configuration.
For server->client event triggering, PusherApp has got to be the easiest possible solution out there. Also had really nice documentation with a quick getting started example.
FYI we used Socket.IO-Node for our NodeKO app. It didn't require any time or configuration at all - and I had zero experience with node.js prior to the first day of the competition.
Most of all, it comes with a client library socket.io.js which has nice fallbacks for browsers that don't support websockets yet. I highly recommend it!
So far the only thing that I don't like about it is that I can't find the "edge" of the damn board to place a tile. I'd recommend adding a button that takes you to a spot with some available space on the edge of the board.
Absolutely. We're looking at longer term ways to preserve the massive unified game space while insuring that people start out in fun areas (others playing nearby, some room to play, etc.).
(Caveat: IANAL) He says in the article they're expecting a C&D from Hasbro, but I think the chances of that are less than they think. Games like "Words with Friends" and "Lexulous" haven't had many problems, and they are blatant rip offs with minor variations.
The minor variations are a matter of not infringing on Hasbro's trademark or their copyrighted board (oh yes). And when it comes to trademark usage (unlike copyright or patents), quickly bringing these matters to the courts is proof of the trademark's legitimacy, so yes, there will be a C&D.
At least it's refreshing that there's not a complete sense of naïveté about it like Tris or Scrabulous had. The PR will only raise their profile and they have little to lose.
Man, who knew the Node Knockout would be this, I want to say, historic?! I've seen such great entries and am really impressed with the creativity and skills on display.
Insane use of tons of reusable parts. I was hoping he would go more into if he went comet or websocketd and the kind of latency people were seeing when hundreds of users were connected to node.js
Yeah, sorry. If we had tried to do that ourselves, we never would have been able to release anything. PusherApp was incredible to work with though. Why reinvent the wheel?
Definitely a big thumbs up to Pusher for enabling us to scale well past where we expected to fall over. We pushed a peak of 500k messages/hr on Monday and averaged 169 simultaneous connected players that day. Crazy.
No disrespect intended. The app looks fabulous, but the 48 hours limitation is not so bad if you have lots of time to prepare. For me the tough part about programming has been the architectural design and the research put into the tools and apis. Everything else is just typing. Having said all that the developers are still super talented to have pulled that off.
These kinds of events are insanely fun. We had a student-run 24 hour game programming competition at my school for the past three years. This year my grad school friends are finally making it a bit more legit, with a website and support from the school: http://osgcc.org/
We're primarily coders, so the design suffers a bit, but the line about "By the end of the third day, I was barely coherent enough to spell the swear words" made me smile.
If you've never been to an event like this, you should.
Much as I'd love to win, Drawbridge isn't near the level of polish that Scrabb.ly and a few of the other top apps are, and I think a lack of preparation is the main culprit. We had a general idea of what we were going to build and how it was going to be designed, but we had to scramble several times to redesign and rearchitect essential components. (We did our server-side API design without accounting for the fact that we were going to be using websockets, completely overlooked the fact that we'd have to come up with an API for our DAO or anything on the client side, had to completely redo how variations and their UI worked, and had to come up with a homepage design all within the span of the competition.)
Still, it's been an incredibly fun ride. In the absolute worst case I built a tool I've been wanting for a long time but haven't been able to find the time to build. In the best case, other people find it useful too--having other people liking and using things I've built is one of my biggest motivators.
I've also learned a ton about making a successful app for one of these competitions. If I could do it again there are a lot of things I'd do differently. (Luckily, Rails Rumble is coming up, so I can!) I've been meaning to write up summary of what went right and what went wrong for us, and how we could improve. Would anyone else be interested if I turned it into a blog post?