Actually I did take some interesting things away from the experience. Not sure how broadly applicable they'll necessarily be though. A blog post on it is forthcoming.
Cool use of WebSockets and nifty concept! Is the source available anywhere?
A couple things I noticed in the Chrome developer console:
- Got two "Not allow to load local resource" errors with local paths to file://C://Users/chris/..., you probably want to fix those.
- There's a lot of logging going on in the console (player info and JSON network packets), probably not necessary in the deployed version.
I liked that you can enable / disable mines in the other player's viewport.
Looks like there's only one level though, in my opinion, the game (even as an prototype/MVP of sorts) could have greatly benefited if you added some more levels and maybe a leaderboard before releasing.
This was for a coding competition[1], all assets had to be created in 48 hours - I would've loved to have gotten more done, but I'm happy with where we landed.. Especially since it really came down to the wire. :) Here's our entry [2]
I realize security probably not on the top of your feature list in 48 hours, but since I work for a security company doing security assessments it's is one of the first things I think about. I noticed an issue that will let me win without racing.
The reason I bring this up is not, in any way, to diminish your work, but to highlight that you don't get much security for free in these types of frameworks. So this isn't a big deal for this game, but in case somebody was using this for a more sensitive project they may want to be careful.
That's a secondary priority, wish list goal. Work is being done to separate out the JavaScript bits and to beef up the analysis bits. However, the JVM Clojure implementation is stable and reliable. There isn't a really pressing need to replace it. Self-hosting languages are neat, but Clojure has always been about pragmatism. Stability and performance are paramount in the ClojureScript compiler. That being said, it's a fun goal, so there are various projects working on alternative backends, Clojure-in-Clojure JVM targets, etc. And patches towards that goal are welcome in ClojureScript!
What? Shifting the main development to JS so that clojurescript may be called clojure?
So we might see the main development shifting from 'targeting the JVM' to 'targeting JS' ???
I'm not sure what you're asking... Clojure is a language that, as an explicit design goal, embraces a host platform. Two of those hosts, actively maintained by registered Clojure contributors, are the JVM and JavaScript. The JVM ecosystem came first, has access to a generally superior host platform and libraries, is implemented largely in Java, and contains many required components to bootstrap ClojureScript. ClojureScript is implemented in JVM-Based Clojure, reusing some of those Java components (like the reader), lacking in features that generally make less sense in target environments (ie. eval in browsers), and generally acts as a complementary library for JVM Clojure web apps. Being a Clojure dialect, there is community interest in reusing some of ClojureScript's implementation, meta circularly, for additional platforms including Lua, ChickenScheme, LLVM/ObjC, .NET, and yes, the JVM. If the people working on those projects want to contribute modularity and platform abstraction improvements to ClojureScript's reader, analyzer, code generator, build infrastructure, or libraries, their patches will be actively considered.
EDIT: video of it in action here: https://www.youtube.com/watch?v=v09DnU4vQ74