New Kodu release!

At the end of Nov, the folks at Kodu released the latest version, 1.4.59.0, that includes almost 20 upgrades/bug fixes. 2 of the coolest upgrades include now allowing your Kodu graphic editor, both in edit and play mode, to fill your full PC screen, and letting you to snap the camera back to a character by using F4 key should you zoom out waaaayy too far (still happens to me from time to time) and you get lost in space. My Alice followers remember how easy it is to lose characters in 3D and how on that platform we'd program a line to have camera "go to" our missing object to get it back in view, right? Same concept here, just Kodu uses hot key programming to achieve this.

I always make a habit of not only reading release notes for each version of any platform release, but also, to go to user forums to see what others think, good and bad. In this case, Kodu releases its version details in the Gamelab user forum, so it's incredibly easy to see both angles. And ... you'll see this Kodu release has a regression test fail; allowing the full screen view unfortunately unexpectedly corrupted the ability to re-size stuff like "walls" or "objects", like Kodu, Rover, etc (which I found before reading this forum, and it is a tough feature to have broken). Hopefully, they'll release a "patch" (an immediate mini-release, which once released would change the version from 1.4.59.0 to 1.4.59.1) to fix this. Basically, if after you Right click to change your settings while programming an element, you'll see your slider that in the past lets you change size, bigger to smaller. However, now, when you click on the "x" once you think you've set the change, the slider box goes away, and none of the changes you made hold. For now, the Kodu team suggests instead of using the slider dialog box, you use the "left" and "right" arrow keys.

In general, I really like how transparent the Kodu team is when it comes to bugs and fixes, because it provides a great view into how design helps or hurts programming, an important concept in enterprise platforms, like .NET. For example, a patch in May allowed the team to fix a design flaw in the "Cycle" character, where that character's target point to detect "see" was built into it's tire, touching the ground, not at the top of the "Cycle" itself. So, as you can imagine, programming it to "see" didn't really work well, because all that character saw was what it was right on top off, on the ground! So, it wasn't that it was broken or that programming was wrong, just, the functionality of "see" for that specific character wasn't designed in a way to let it work as most folks would intend to use it.

This week I put the finishing touches on a lesson plan to create a "Mountain" game narrative knock off; it's a great way to open a class to get kids comfortable using the multiple Kodu terrain options in concert to create effects. And I found a really funny video of a guy trying to play "Mountain" that I'll use in class (edited because, well, watching someone frustrated by a game can provoke colorful expressions!). Overall, a nice way to demonstrate basic narrative game elements and open discussion about "innovation" over "iteration" and game popularity.