Sunday was the final day of the inaugural Training Jam event. A not-quite-two-day game-creating jam hosted by OpenSesame, a curator/marketplace for electronic learning solutions. It took place at DeskHub, an office-location-for-rent that serves small businesses and startups with a place to share, and stake out some desks for your team, with conference rooms and teleconferencing equipment, and a decent break area with plenty of supplies for coffee, food, etc. The staff from OpenSesame kept us fed with excellent catered meals, and lots of soda, water bottles, and energy drinks. They were also extremely helpful and encouraging to the jammers. The overall energy was very positive and uplifting.

The challenge was to use the time to create games that teach—training that’s “not training”. Not simply “gamified” training solutions, but games that are fun to play, and while you’re playing you just happen to come out of it with solid, usable knowledge. Check-in was Friday at 6, but the event kicked off with a keynote at 7, so actual coding (well… conceptualizing) probably started at 7:30-ish, at which point the five themes to choose from were revealed. Pencils-down happened at 2pm Sunday, so we were really about 5½ hours short of 2 days available to write a game-that-trains from start to finish.

The themes available were chosen based on the top-selling elearning courses at OpenSesame, and had to do with things like work safety, time management, and customer support. I teamed up with my buddy Randy, who created the artwork for the game while I did the code, and we chose Fire Extinguisher Safety as our theme.

Rather than cover the entire range of information that comprises a complete training in that topic, which among other things would require that we essentially take the training and slap “game-like” things on it—contrary to the spirit and intention of the program—we chose to concentrate on matching the correct type of fire extinguisher to various classes of fire (from sources such as wood, grease/oil, or combustible metals).

We decided to create an arcade shoot-em-up game that caricatures reality with moving/reacting blazing fire “baddies”, against which you would use different extinguishers as appropriate. Grease fires and a magnesium fire would react very poorly to being extinguished with water-based solutions, and choosing the right tool for the job would become crucial. Up-front instruction would be minimal, relying on the gameplay itself to teach which tools work best. Of course, some amount of textual instruction is unavoidable: using an inappropriate device would produce dire consequences (or at least be less effective than another choice), but also the game would pause momentarily as the game advises the user about the reason for the poor reaction, and advice on making better choices in extinguishing devices.

Alas, pretty much none of that made into the product we wound up with at the end of ~42 hours. You can try it out here (note, the initial loading time will take several seconds). There’s not much to it. You can move your extinguisher guy around using AWSD (or the arrow keys), and swap between devices with the Tab key. You can’t actually activate the extinguisher in any way, and the baddies fire off at you and then just bounce around the screen slowly, never hurting you. If you hit Backspace, you’ll instantly kil the fire (wherever it may be, and regardless of what device you’re using. There simply wasn’t time to get more into the game.

I think Randy and I are a bit disappointed with the lack of features we wanted to get in, but are nonetheless happy that we learned a lot in the process, and are happy that we at least managed to have something coherent to show to the judges. Randy got all the basic art that we needed done (and did a good job of it!), though he definitely needed all the time leading up to the end, but I was a bit slow with the code, and couldn’t do everything we hoped to with the assets we had (though we did use all the assets he created).

Both of us struggled a lot with making progress on Saturday, the only full day available for working, and the day we actually started coding (as Friday night was spent finalizing our plans). For my part, I was using an existing code base I’d created for some other games I’ve been working on, but one basic piece of functionality needed to be added to it (panning a camera over a larger playing field—so far I’d only been writing single-screen games), and struggles with other pieces of the code slowed me down considerably (basically, it turns out my experiment with enforced unit-measurement types in JavaScript ultimately causes more problems than it solves, at least where timeliness is concerned—it needs to be something more ingrained into the language—switching back and forth between simple numbers and the unit typing was the source of too many points of failure).

On Randy’s part, he was using graphical tools (GIMP and Blender3D) that weren’t terribly familiar to him, and was struggling with their many idiosyncrasies. Blender3D can be particularly frustrating to deal with, as they change their UI quite often, so any documentation you find is guaranteed not to map quite right with the version you happen to be using. By the end of Saturday he had become much more comfortable with his tools, and I with mine, but by then there was precious little time remaining to get the bulk of the work done.

It was an excellent learning experience for me, though. Clearly, it was unwise to put myself in a situation with extreme time constraints, and then be building not only the game itself, but also still much of the underlying engine as well. In the future I’d really do well to use only a preexisting engine that has all the features I’ll need it to have , and with which I already have the familiarity I’ll need to make it do what I need it to, without scouring the docs to solve puzzles (or, perhaps, to work around by not using such features in the first place—we’d have been much more productive if I’d just gone with another single-screen game like my others, since avoiding that spent way too many precious hours on Saturday).

OTOH, the time pressure of game jams, and the challenge it presents, is an excellent way to motivate me to learn new tools and technologies, and get familiar with things I’d been meaning to learn about. That’s certainly what happened with my first game jam, which was my first venture into using HTML5 to create a game. And unlike some of the other contestants in jams like these, I’m not really in it to win anything or gain notoriety; I just enjoy the challenge, and find it a fun time (stressful, but fun).

I think I’ve also finally found my breaking point with using pure JavaScript for the logic. I think I may well focus my future game-making efforts on using Elm to code with. Having a proper, strict type system prevents so many accidental goofs in code, and going without them in JavaScript can get to be a real pain (in particular, the existence of null, or passing an object of the wrong type, or an object that lacks properties it’s meant to have had—such things are impossible in Elm). The purely functional nature of it also greatly aids debugging—which is all the more enhanced by Elm features such as the Time-Traveling Debugger feature, which allows you to step back and replay the state as it changed over time, to see what was going wrong. You can also modify the code on the fly as it’s running (and not just modifying variables as in JS), to see how things change. It’s also more concise and readable than JavaScript, so it’s basically win-win-win-win.

There are some things about Elm I’m decidedly not a fan of… it lends itself to a style of web development that I rather detest, which is when all of the actual substantive content of a page is not to be found in the HTML, but is generated/produced by JavaScript. (The Elm site itself is an excellent example of this.) This is decidedly unfriendly to a host of useful web tools, and the spirit of the web as seen by many of those who were instrumental in bringing it about. But for game programming? I believe it’ll be great. The only thing I’m not entirely certain of is how easy it’ll be to control image preloading… but I’m certain that can be hacked in if absolutely necessary, and meanwhile the other features aiding more rapid productivity are sure to be a boon.

Update (the next morning): Or maybe PureScript instead. I really like the elegance of Elm’s FRP approach; but maybe not so much as I’m likely to miss Haskell features like typeclasses or equivalent tools for ad-hoc polymorphism (that is, using a single function definition to work with many different types that share certain characteristics). PureScript has the same strong typing guarantees that make Elm attractive, though it lacks the awesome debugger. Maybe I’ll just try making or rewriting some of my games in each language before I settle on one.

Elm totally plans on adding typeclasses or something that solves the same problems. But it’s not there at the moment, and I expect that’s going to be hard. It certainly makes it much harder for me to visualize how I’m going to treat, for example, a wide selection of various sprites with different behaviors, as variants of the same thing. Perhaps has-a instead of is-a relationships may save me, but I think I’d have to play around with it more to know for sure.

One thing I really, really like about my current pure-JavaScript engine, is that my sprites are defined in a simple, declarative style:

I can just plop in new behaviors in there to change the movement and features, and AI, of sprites. It works using closures, and is really powerful – but of course it works by mutating underlying data in the object that calls them (particularly, coordinates and velocity values). If I can find a way to do things in a similarly convenient way in Elm or PureScript, I will. I obviously can’t do it this way, but Pure functional languages are often this succinct as a natural product of their purity, so I may gain as much as I lose.

I’ve finished porting a substantial chunk of (now completely) my friend Mars Saxman‘s Starfish—a C program for generating seamlessly tiled procedurally-generated wallpapers—into HTML5/JavaScript. You can try it out here, or there are some samples of some of the wallpaper tiles it has generated:

The original program has five different image-generating algorithms, that are chosen at random, coloried and layered one upon another; my current JavaScript port has only three of the original algorithms (one of them modified), but I’m already so pleased with the results I decided to post the program as it currently stands. I’ll probably get the remaining two image generators ported in the next week (Starfish’s C code is surprisingly easy to adapt into JavaScript). (StarfishJS now has all the layer-generators of the original. Some of them have been modified to my taste.)

If you want a little peak under the hood, you can see the individual image-generating algorithms at play: the three generators currently available are Coswave, Spinflake, Rangefrac, Flatwave, and Bubble.

The image generators all operate in monochrome values, and translated into color later. Some of the generated images aren’t displayed directly, but instead are used to hide/reveal pixels of other layers.

I made something kinda interesting this week in JavaScript. It probably qualifies as “over-engineering”, but it was for my use, to meet my needs, and I had making it, and I’m having fun using it (so there! :-p).

It’s an implementation of measurable units of various types that I tend to use in my recent JavaScript-games-making excursions: such as seconds, milliseconds, pixels, radians, and frames. It lets you express that quantities are in rad/s, f/s, px/s^2 (for acceleration values), etc, and convert between them via multiplication and division (px/s divided by a time value results in px/s^2 (pixels-per-second-per-second), or if multiplied produces a value in number-of-pixels). It throws an error if you mix up which units you meant to use, which helps enforce the sanity of the arithmetic you’re performing.

Usage looks something like this:

The reason for this little library is that I’ve frequently run into problems thinking in the wrong units in my games. One variable might hold a length of time in seconds, another in milliseconds (from new Date()), and I’ll try to use them together, forgetting to convert between them. In MajicUnits, they’re all represented in seconds under the hood, and I can specify what unit I want when pulling them back out.

Or I often forget to scale a velocity or acceleration by the inter-frame time before adding to current state, resulting in a full second’s acceleration taking place in a single frame. Using MajicUnits, I’ll see an exception thrown if I forget to multiply by the frame delta.

It’s the sort of stupid error that led to NASA losing its $125 mil Mars orbiter because one group coded for metric units while another used imperial. If you have a language to express (and enforce!) unit types being used, you’ll catch the problem. Better, of course, if you can do it at compile-time, without requiring the offending code to run before you can catch it, but this is JavaScript, and writing my own to-JavaScript compiler that adds units of measure as strictly-enforced types at the language level would be really drastically over-engineering. 🙂

The library’s pretty crude at the moment: I’ve coded exactly as much as I need for the moment. There are places you could feed it bad input and break its assumptions. It automatically creates plural versions of your added units, adding ‘es’ if it ends in ‘s’, otherwise adding ‘s’. That obviously wouldn’t work with ‘activity’ (-> ‘activitys’), and can’t handle exceptions like ‘forum’ -> ‘fora’ or something. Rather than have an automatic pluralizer, I should be having the user explicitly specify when they register the unit… (All of the above is no longer accurate.)

A bigger problem is that when an exception is thrown I can’t currently just find what line of code went wrong. I throw an Error object (which includes file and line number info), but it points at the place inside the library that threw the exception, rather than at the failing invocation that caused the exception. Most implementations of Error provide some sort of stacktrace, so perhaps I can generate one and then turn it into a string that includes that stacktrace info… because when it comes out on my Firefox console I don’t get the stacktrace currently. Anyway.

You can see the current implementation (as of this writing) here (UPDATED), if you’re curious and/or masochistic (it does some magic with JS prototypes to do its job, and lacks any useful documentation/comments, though I plan to add some).

It’s written as one part of this game Gate Arena that I’ve been working on lately, but am rewriting to emphasize a more declarative style of expressing objects and logic and their relationships, to increase code reuse and the ease of adding new enemy types, etc. I plan to reuse the resulting engine for further games, increasing my flexibility for participation in game jams and whatnot.

A FaceBook friend posed this question. It was a good opportunity to give a reasonable summary of my current thoughts on the world, so I’m also placing my answer here. (Revised 23 January 2014)

Better. But I have to keep reminding myself that.

Everything looks pretty horrible at the moment, but I think it’s largely because, having made such great strides over the last few centuries, and even the last few decades, some of us are more keenly aware of how very far we have yet to go, than anyone was before. Continue reading →

Patrick Rothfuss, author of The Name of the Wind, and its recently-released sequel, The Wise Man’s Fear, recently solicited people on his blog for their favorite quotes from The Wise Man’s Fear. I read it on my Kindle, and highlighted most of my favorite passages, so it wasn’t much work for me to come up with a list, which I posted there. Figured I might as well put it up here on my blog, too, while I’m at it.

As a pianist, I can empathize with, “This is why there are so few musicians. A lot of folks can sing or saw out a tune on a fiddle. A music box can play a song flawlessly, again and again. But knowing the notes isn’t enough. You have to know how to play them.”

Though I love to play, I rarely listen to live or recorded piano performances, because too many people are focused on being technically accurate rather than being emotive. One counter-example would be Rachmaninoff, but of course his recordings are old and low-quality. You can still hear the difference loud and clear, though.

“My rooms were so pleasant it took me almost a full day to realize how much I hated them.”

“I idly wondered how exactly one was supposed to lounge. I couldn’t remember ever doing it myself. After a moment’s consideration, I decided lounging was probably similar to relaxing, but with more money in your pocket.”

“[T]he only act of creation I accomplished was to magically transform nearly a gallon of coffee into marvelous, aromatic piss.”

“I briefly entertained the notion that I was insane and didn’t know it. Then I considered the possibility that I had always been insane, acknowledged it as more likely than the former, then pushed both thoughts from my mind.”

“Only a fool worries over what he can’t control.” (Like the musician quote, this one resonates closely with something I frequently think about.)

And, finally,

“‘But no. I won’t lock you up. You haven’t done anything less than proper.’
  “‘I broke that boy’s arm,’ I said.
  “‘Hmm,’ he rumbled darkly. ‘Forgot about that. He reached into his pocket and brought out ha’penny. He handed it to me. ‘Much obliged.’”

Recently on Facebook, I mentioned downloading the Japanese version of Final Fantasy VIII, and a college friend of mine on Facebook retorted with a “too bad FF8 sucked” comment. Here was my reply, which I think pretty much sums of the core ideas of VII and VIII fairly well. Please note: I absolutely adore Final Fantasies VII, VIII and X. VII and VIII are tied in terms of my affection for them, though given the descriptions below, from a purely story-focused viewpoint, VIII wins hands down. I think I’d love VI, too, if I could ever play it all the way through. IX and XIII are good too, but not in the same league as the others.

Spoilers ahead. Duh. Continue reading →

FactCheck.org has an article on how we get the fairly misleading number “37th in Health Performance” worldwide. A revealing point is that we’re actually ranked 15th overall, before per capita expense is taken into consideration (a problem current proposals seem unlikely to resolve).

This doesn’t mean there aren’t severe problems with the current healthcare system, though: the 2008 WHO report points out “persistent under-performance of the United States health sector across domains of health outcomes, quality, access, efficiency and equity”, citing
U.S. Health System Performance: A National Scorecard, which notes that US placed 15th in fatalities that were “potentially preventable with timely, effective care”, and scored the nation 66/100. Ouch!

So, I’ve recently been toying with the idea of getting a smartphone. The iPhone had been looking good to me for a while, and especially the 3gs, but then I hadn’t been looking much at what else is out there.

Looking at the iPhone, it’s probably one of the most fluid and natural devices from a user-interface perspective, and especially as an MP3 player compared to other MP3 players (besides, of course, the iPod Touch, which is just an iPhone without the phone). Targeted apps for Facebook, WordPress, Amazon, Pandora? Love it! Best of all, I qualify for an upgrade to the 3g for $50 if I renew my contract for two years.

And then the 3gs with its better performance, video capabilities, and a camera with a tap-to-focus feature! And, yeah, the compass and voice-activation features, but I’m not nearly so interested in those. That being the case, the fact that it’ll cost me $150 more to upgrade put it just out of my consideration. Even if it plays Katamari Damacy (I’m told it’s not worth trying on the 3g).

But then, I’m not jazzed that I’d have to use iTunes whenever I wanted to interface it with my computer. I don’t have a Mac, and I don’t enjoy using Windows. All my MP3s are on my Ubuntu disk, and so I’d have to transfer them all to a FAT32 disk and use that as my main base of MP3-playing operations. And either boot into Windows or fire up a larger-than-I’d-like Windows VM just to talk to the iPhone. Not cool.

And, of course, not having a Mac means I can’t write software for it, but have to make do with rigging up a website (and hoping I’ve got connectivity) to add customization to the thing. And I can’t even easily load it up with PDFs or offline-stored web content or what have you.

But of course, all third party apps these days will have an iPhone version, and that’s support I can rely on (until my version of iPhone becomes too obsolete, anyway).

So I looked at some alternatives: Google Android-based phones. The great thing about these is they have many, if not all, of the apps I really care about. Obviously all the Google-related ones, a web browser, GMail, Google Maps; and also at least Facebook and Pandora. And the best part is, it’s emminently hackable. I can access it like a hard drive, and load whatever software I want—which I can write in Java on my Ubuntu laptop, and test in their Java-based Android emulator.

The problem with these phones, though, is that the only Android-based phones currently available don’t work with AT&T (and by “work”, I of course mean that they can use AT&T’s 3g network, and not just the standard cell data service). It’s expensive to switch, and on top of that the phones themselves are more expensive, even with the contract.

A coworker pointed out the new, Linux-and-Gnome-based Maemo OS, which is the sexiest “mobile computing” OS I’ve ever seen. And the Nokia N900, which is apparently releasing next month, is the most powerful smartphone/mobile computer I’ve seen yet; and of course, it’s also
completely hackable.

However, the price tag is steep. $800 for a phone, when my laptop (with which I’m perfectly pleased) cost me $350 new (yes, I’m cheap, but my needs are low), is… well, it’s a lot.

And, too, while I’m at work all day, I have a wifi connection, and my laptop. When I’m home, which is the vast majority of the rest of the time, I have a wifi connection, and my laptop. The idea of getting a smartphone would be to cover the other, what, one or two percent of my time when I’m not near wifi. To cover me when I’m on the train to work, or in the waiting room. Given that I pay close to $30 a month for my connection at home, paying an additional $30 a month to cover the gaps just feels wrong, if I can avoid it.

Anyway, during all this, I’d also been eyeing Amazon’s 2nd-generation Kindle e-book reading device. It’s not a smartphone, obviously, or any kind of phone, and while it does boast internet connectivity, it’s not a “mobile computer” by any stretch of the imagination, and my interest in it had been in its excellent display, and of course its usefulness in consolidating my library of books-to-read in one, very small, very slim, very readable device.

I do a lot of reading, and I typically buy several books on Amazon every month. I got to check out a friend’s Kindle 2, and was amazed at how close it was to reading off a piece of paper. The resolution, combined with the set of grays available, is good enough that you don’t see the pixels; it looks like printed words. It’s “e-Ink”, not LCD, and it looks terrific even when you’re reading in direct, bright sunlight. And it’s tied directly via free wireless network to Amazon, which is the store I’m familiar with and use for most of my non-book purchases as well. After seeing it live, and knowing the price had dropped into the ballpark of “reasonable”, at $260, I was having a hard time convincing myself I didn’t absolutely need one.

But here’s the thing. As I said, the Kindle is connected to a free wireless network; in fact, it uses Sprint’s 3g network. But it’s not just usable for getting to Amazon’s Kindle store: the Kindle 2 includes a web browser, too! It’s not much of a web browser, to be sure: it’s roughly as powerful as the text-based, built-in browsers for non-smartphones like my Motorola RAZR. But it can handle JavaScript (once you enable it), and… it’s free. Free Internet access. My phone might have almost as good a browser, but without a data plan I have to pay a buck to download 100k of data, and an unlimited plan costs (as I said) around $30, which is a major reason why I don’t use that to cover my “one percent” time. Plus, my cell phone doesn’t do 3g, either.

But, with Kindle’s browser, I’ll be able to see Facebook updates (and write my own), manage my Netflix account, read blogs (it’s especially good for that task), and read WikiPedia (Kindle has direct integration for searching WikiPedia quickly, without having to first open up the browser first). Apparently people can even get their GMail on.

So why get a smartphone? My Kindle’s on its way now! 🙂

The only thing that I really dislike about the Kindle, is its lack of native PDF support. You can have PDF files converted to a format that Kindle can use, but it’s pretty much just the text; it won’t keep the fonts and layout, and may not keep all the images. There are techniques to get around that—such as converting the PDF to a series of image files, and then sending that to be converted to Kindle format—but of course such tricks have definite shortcomings. The larger, more expensive Kindle DX—which has a page-sized view, and so is better suited to viewing the PDFs anyway—has native PDF support, but it’s too bulky to be practical for my needs, and too expensive ($500). Sony’s e-book devices have native PDF support; but in other ways they don’t hold up quite so well to the Kindle; for me, at least. Their devices are very similar to Amazon’s, but they are (at this moment) more expensive, and lack the internet access that makes the Kindle so attractive. In fact, in the currently available models (a new one will be remedying this shortly), you can’t even access their store using the device; you have to download it to your computer first, and then transfer—and several reviews I’ve read complain about serious quality issues in the desktop software. Upon finishing the first book in a new series, it will be very convenient to be able to immediately just start reading the second, without even having to wait for it to ship (or wait until I get home to my desktop to purchase it).

Here it is. Found via Slashdot. I’m simply dumbstruck.

13 years old. Strip-searched. Ibu-friggin’-profen.

I don’t care that they have a zero-tolerance drug policy at the school, if all you suspect (incorrectly, as it turned out…) is ibuprofen, how is a strip-search, by any conceivable stretch of the imagination, warranted?

(The story itself is not new; the actual news is that it will be heard by the Supreme Court. The incident itself took place 6 years ago, and the girl in question is now 19. But hell, it’s the first I’d heard of it…)

Today’s xkcd was particularly funny, I thought.