Puzzling Weekend – Jumping into JS

So this weekend I decided to suck it up, and learn Javascript. Well it wasn’t really a choice considering I need to learn it for my current class… … so this weekend, I decided to take Javascript more seriously!

For last few month, Elise and I have been talking about the prospect of setting up small jigsaw puzzle games on her website. Originally we’d been talking about doing it in flash because our point and click game actually has a jigsaw like puzzle in it, but we weren’t keen of the idea that the player was limited to a flash player view. We wanted to use the entire browser page, and doing that with flash didn’t really seem like a good idea.

So the objective for the weekend was to create a browser puzzle game, or at least get the core functionality in using HTML5 Canvas and Javascript. Also avoiding any low level coding… there’s enough of that going on in other parts of my life right now.

I’m also not very fond of Javascript. For a few reasons, probably some very old out-dated reasons. Type safety is it there or isn’t it, I don’t know! You can also allocate variables and data structures of any kind whenever and where you damn feel like it. Basically no high level standard to adhere to and a potential messy nightmare for a coding neat freak like me. Both of which can be easily dismissed considering a developer must enforce there own programming standards, not the language… the stuff above just makes it easier.

Anyway, last night I did a bit of browsing around just to see what other’s where doing with jigsaw puzzles. A lot we using Javascript and Canvas, and I even came across a good starting place tutorial here using PaperJS.

One of the biggest hurdles for me was avoiding low level programming and finding the right framework to build the game in. So I started with PaperJS since the tutorial was using it. It was somewhere to start at least.

I quickly began to question some of the rational for doing certain things. It felt really odd to use, at least from where I was coming. It was also difficult to debug in doing some weird things with how it manages scripts and calls them from within the framework itself. For example, error on line 11404 in a 110 line script. Also why reclassify Javascript as Paperscript (i’m sure there was a reason but it just seemed odd because it was basically just Javascript). I got put off by PaperJS relatively quickly, at least out of the box. Probably a little to quickly but regardless it was a good reason to actually look around for something else.

I did a little more searching and I ended up coming across KineticJS. It felt well structured and relative straight forward to use, except I couldn’t quite figure out how to mask a bitmap with a vector path. Or at least to got to the point where I couldn’t be assed writing ‘config’ array structures into things and cutting and pasting non-kineticJS code into it. It was getting a little to low level to quickly, so I moved on. Also it required a script type tag called “deferred” and needed to be called AFTER canvas, rather then in the HTML header. Once again, out of the box I was a bit put off.

The above two also had what I would say, ‘fair’ documentation. Not exactly something that really helps you understand it completely but it was there kind of documentation. But this bring me to one of my rules. If I have to Google someone else’s blog to find out some stuff that should be in the documentation, it puts me off. Its easier to find the frameworks website and it’s documentation then it is to find that random article that you forgot to bookmark or is buried 8 menus deep in your bookmark folder only to find that the page itself has moved else where or the site is down (for-good). And if the documentation is a bit half ass, your only making people want to leave.

After a bit more searching I came across EaselJS. Jackpot goldmine. I felt instantly at home with EaselJS mainly because it uses a very similar design to core flash objects using Display Objects, Containers, Shapes and Bitmaps. The documentation also made it a million times easier to figure out what was possible without having to dig for it in random holes. It even has additional frameworks for various other things you might want to do, such a PreloadJS and SoundJS just to name a few. In other words, a little less screwing around. Also, no crazy random script ‘type’ tags.

The result of this weekend is the picture below. A basic puzzle that you can move pieces around and snap them into place, and move around each individual grouping of pieces and snap them together into place. There is still a few things that need to be done and some features that will probably be added before its completely useful, but it’s a good start! The puzzle picture is also one of Elise’s drawing. You can check out her works here.

puzzle01

Granted that this was my first serious trip into doing Javascript and I only really glazed over the first two frameworks to get to a favourite third. (I’m probably going to go back to PaperJS and KineticJS just to try out some things). Javascript wasn’t as bad as I thought it would be. I think coming into Javascript from various other languages, and applying what I’ve learned from those languages helped in understanding what can be done, what shouldn’t be done and what could be gotten away with in Javascript. If I had no prior experience in a programming language, I can definitely say it isn’t an environment where you can learn or understand important programming standards, or at least not easily. It’s a very free-for-all language I guess you can say.

In all I feel a lot more confident about Javascript and using Canvas.

More posts hopefully in coming weekends. And maybe even some code!

Leave a Reply

Protected by WP Anti Spam