Years ago, I picked up Head First Design Patterns by Freeman, Robson, Bates, and Sierra. I was impressed with how much more effective it was at getting some otherwise dry concepts into my head, certainly as compared with the authoritative "Gang of Four" book that covered the same topics.
Also, the cute woman with ponytails on the cover didn't hurt.
Recently, I've stocked up on a bunch of JavaScript books, including the definitive guide, which is huge, but that's what I'd expect from a definitive guide, I suppose. Also, a much smaller volume with just the good parts, and then also a copy of the definitive guide to closure. Not to mention, I got a copy of "Eloquent JavaScript", only to discover that I already had a copy on the shelf. Not a reflection on the book itself, just an indication that I can be scattered between my book purchasing and self-directed studies.
I've heard it asserted that if a software engineer is any good, they're as fluent in their primary programming language as they are in their primary natural language. JavaScript isn't my primary programming language as measured by fluency, but it's what I'm getting paid to write in these days, hence the attempt to cram stuff into my brain.
I've also picked up the Head First JavaScript book, and am going through it. It's not heavy material, certainly. I do miss the woman with ponytails. Maybe I should review some design patterns.
All of that, in a weird way, is preface for what I actually intended to post about. Right now, I'm looking for a game development framework that allows me to write in JavaScript and deploy to the web (easy), Native Linux (pretty easy), and Android (somewhat tricky). I had been somewhat actively helping out with PlayN, but that's writing in Java, and that's no longer my priority.
There are a few frameworks out there that get me most of the way to where I want to be, including PhoneGap and LycheeJS. There are many many more, too, as this list attests. I haven't tried most of the entries on that list, certainly.
A bit ago, I spent some time trying to get PhoneGap up and running, and I eventually backed up and re-installed Eclipse and set up a fresh Eclipse workspace, and all of a sudden, PhoneGap started working better. But not great - the documentation seems to be out of date and the samples weren't working for me. But maybe having access to the Android camera interface isn't important to me from within a game. Or maybe it is. Something to revisit.
I've also been looking at LycheeJS, which looks like it's pretty close to what I want - a one-stop framework that goes everywhere I want, but it wants to live in a Ubuntu environment, which isn't exactly the same as my Fedora workstation. That may be a small issue, and I'd be happy to help the author expand his scripts to support Fedora as well. It looks like the website is in a state of half-completion; many pages of the documentation are missing, and some are only half-written. Which I certainly sympathize with, I get distracted by shiny objects and leave ideas uncompleted.
This weekend, in addition to getting a PhoneGap sample semi-working on my tablet, I also spent some time trying to get a small game working inside LycheeJS. I was pleased to see that some of the concepts presented were echoes of things I had been working with in my own toolkit, in particular I have an idiom that I call "Modes", which are states of gameplay. A menu is a mode, the main gameplay experience is a mode, and dialog boxes are modes. I like to stack them so that dialog boxes consume input, but still allow the underlying mode to render. LycheeJS has a similar concept, called game.state, which is pretty similar, minus the notion that they might be stacked. Perhaps stacking them isn't critical; I thought it was a good idea when I first coded them. I may find that it's not important, or I may find that it's easy to add a stack, or I may find that it's a lot of work, but it's still worth it.
I'm not currently able to get the LycheeJS build script to generate an Android APK, almost certainly because of the Fedora/Ubuntu mismatch. I've decided not to let that slow me down, but to get to understand the framework (and jam some JS into my head along the way) first before worrying about playing games on my phone or tablet.
It's not too painful to do a build to a Linux executable, running in its own window. One thing that is somewhat unpleasant there is what has been driving me nuts already; JavaScript's tendency to fail silently. One typo and whatever you were doing just stops. But usually, not stops altogether with a stack trace, which could be helpful.
Late this afternoon, I tried running a bit of code that turned out not to be valid JavaScript, and proceeded to hang my whole machine (an impressive feat, one which I haven't done much of since writing DOS code, years ago). This was using the Linux build, rather than the browser target. Perhaps I'll shift over to running in the browser as my typical working target, and getting comfortable with the Chrome debug console.
I also spent a chunk of time this weekend checking out node-sdl, which could be a piece of a cross-platform deployment strategy, but I got hung up on trying to figure out why some of my gamepads and other input devices weren't showing up usefully in the samples. I suspect that SDL is complicit, but I'm not sure if it's worth chasing at this point. If my CH Flight Sim foot pedals aren't recognized by a framework I'm not currently using for a game I'm not currently writing, does it constitute a bug?
No comments:
Post a Comment