The extensions allow authors to:

• get/set pixel values
• perform collision/hit detection
• optimize redraws of the canvas (via locking)

The benefits of such functionality should be obvious: it allows fine-grained control over the canvas contents and interactivity, something closer to what SVG developers have already:

• While SVG developers are rarely concerned about individual pixels, SVG filters provide an ability to produce interesting effects similar to getting/setting individual pixels (for instance, blurring or lighting an image).
• SVG developers can easily attach standard DOM event listeners to any graphical objects to test for hit detection. General collision detection could also be done via scripting the SVG DOM.
• SVG developers can control when the image is drawn by using SVG DOM methods: suspendRedraw(), unsuspendRedraw() and forceRedraw().

Anyway, I’m not trying to downplay these advancements from Opera, I think it’s all good. Putting more graphical/interactive power into the developers hands is a good thing, whether it’s canvas or SVG. Either way it nudges the web closer to a platform that can support gaming technologies.

It’s a pity these guys weren’t also at the GDC last week to discuss these advancements and learn what game authors are looking for in the web browser space, but I suppose this is fairly minor news at the moment. What will make this bigger news is if other browser vendors start supporting these extensions in some way.

As the canvas experimentation continues, I feel it becomes more and more important for somebody to own it and publish a standard so that we don’t get fractured camps like we did with JavaScript back in the first Web boom. I’m all for innovation, and it’s a potential way for Opera to gain some more marketshare, but at some point to make it ultimately useful it needs to be ubiquitous across all browsers.

Rob and I were pleasantly surprised to find ourselves in discussions about DHTML and other standards-based approaches to web games (like SVG) with none other than Mozillians Brendan Eich, Stuart Parmenter, Vladimir Vukićević, and Mike Shaver.

If I had done my research while here in California, I would have found posts like this and this from Vlad and Mike and we might have been able to talk longer than we did about our ventures into game programming in SVG. For those just joining the fray, here are some non-fancy game demos I’ve put together using SVG and JavaScript:

• Tetris
• Solitaire
• FreeCell

Rob also has a great post on this topic.

As we discussed, one of the major problems we’ve seen thus far is that though it’s definitely possible to whip up a game using nothing more than a text editor, getting beyond a trivial DHTML or SVG game would be greatly facilitated if there was improvements to the tool chain for indie developers with a budget of zero. Real game development in these technologies will not prosper without the proper toolset. While applications like Inkscape certainly help, where are the free JavaScript+PHP+HTML+SVG IDEs?

Yes, I know, I’m greedy…

The first session on Wednesday dealt with business models of web-based casual games. Revenue models ranged from subscriber-based, to banner-ad, to in-game advertising, with advertising taking up the biggest chunk of the session time. Interesting concepts in branding items within the game (such as table-tops in card-based games) were discussed with an effective “Click Per Minute” in some cases as “three-to-five seconds with a clear view of the ad”. It sounds like no one has struck on a surefire in-game advertising model nor standardized how monetization of ads would work in this context. People are still working these ideas out.

One aspect discussed was that some companies are struggling to deal with arranging advertising contracts with clients directly, while others are considering going through ad brokers or simply use Google’s AdSense program. Everyone agreed that it would be great to have a “clearing house” that deals with clients directly and saves development houses who are not otherwise trained in this regard.

Apart from advertising strategies, another interesting item discussed was how to leverage the community facilities within games and game services to improve revenue streams. One of the key people from Pogo was there and other panel members lauded Pogo’s “badging” and ranking systems which basically sounds like a way to give players valued status (i.e. “I’ve played Game X over 100 times”) with very little investment from Pogo’s side.

Unfortunately, the entry must be cut short yet again, but suffice to say that I really got some value out of the round-table discussions and look forward to them in the future.

Actually this is the second time I’ve started this entry, since the power went off at the library three sentences in. Since we arrived in the Bay area, the weather has been pretty shitty (for California, that is). Despite this, we’re still having a pretty good time on the ol’ trip.

Saturday in the Los Angeles Area

We flew in on separate flights Saturday, grabbed a rental car and went for some pasta and wine in Venice Beach. We shot some photos, even though there wasn’t a lot of activity on the beach due to the March weather (it is still winter after all, even in the Los Angeles area) and then went for some dessert at Real Food Daily. Six dollar brownies… good, but six-dollar good? Whoo!

Then we tooled up the coast towards Malibu and arrived at our hotel in Ventura. After a fiasco finding a room with a working toilet, we made our way to Santa Barbara where we had some tasty food and wine at Spiritland Bistro. We ended up going to The Wildcat Lounge for some Glenmorangie and heavy bass before we drove back to Ventura for the night.

The Pacific Coast Highway

In the morning, we started our drive up the coast of California. The Pacific Coast Highway as it’s called. The sojourn was punctuated by several stops mainly to catch our breath but also serving as great photo opportunities of the amazing scenery. The drive takes about 50% longer than it does by freeway but this is the scenic route, after all – it’s well worth it!

My suggestion: Do the drive in mid-to-late spring (it would be much warmer by then), and reserve at least two days for this journey. You’re going to want to stop at Hearst Castle for a tour, you’re going to want to have dinner at Nepenthe and see Big Sur.

The half hour before and after the Big Sur area on the highway are particularly treacherous with winding roads, a distinct lack of rails for the road, sheer drops off into the ocean, and the occasional rock or mud slide. Think Road Runner and Wile E. Coyote but with trees and an ocean view. Beep Beep!

Make sure you save enough daylight to drive up to Carmel-by-the-Sea, so you can arrive safely (the drive is much less hazardous after this point) . If “Carmel-by-the-Sea” doesn’t sound manly enough for you, you should know that Clint Eastwood used to be mayor there. Convinced yet? Actually, the town is quaint and pleasant. Stop and have a cozy, fireside dinner at the Hog’s Breath Inn. I can now recommend the Hog’s Breath Inn Pale Ale.

We finally arrived at our hotel at about 9:30 PM last night and had enough time for a quick soak in the hottub. I was so exhausted by this point that I passed out on the bed and didn’t crack an eye until the morning.

Monday, Monday, Can’t Trust That Day

Monday has been slow for us, which suits me just fine as Sunday was draining. Sitting in a car doesn’t sound like very much work, even if it involves pulling off to the side of the road and taking some pictures every hour or two, but if you’ve ever driven a long stretch (300+ miles), add to that a bunch of adrenaline rushes as you swerve around rocky corners in the road to barely miss cars travelling the other direction and you can understand that yesterday was kind of like spending all day at an amusement park. Without the cotton candy.

Anyway, even though it was rainy and grey we still hit the hottub again. Cold water on the face, hot water on the rest of the body: An interesting contrast.

And that gives you a near up-to-the-minute guide to my experiences in California so far. If anyone is still awake, tune in tomorrow when we learn:

• What groceries did we buy?
• How long can I hold off doing laundry?
• Did I sleep in the right or left bed?
• What kind of toothpaste did Rob bring?

Seriously, further entries will be much more technically focused as we have our Joel On Software geek dinner tonight, tour the Ames Research Center and Yahoo! (thanks to Scott) on Tuesday, and we get into the Game Developer’s Conference on Wednesday.

Of course, I’ll also post some photos too.

My Dad and his long-time girlfriend were married last weekend. Congratulations! It was a small ceremony, but they did hire a D.J. for the wedding reception. Jacob and Joshua surprised Sam and I by dancing the night away. They really shook off their shy natures and partied it up as only 2-year olds can do, charming all the ladies on the dance floor. What a great experience for them, they need more opportunities to interact like that. My brothers and parents were great help in watching after the kids too.

The only downer of the night was as we were leaving, standing at the elevator, Joshua had his hands on the elevator door and I was talking to my Dad. When the elevator door slid open, the fingers on Joshua’s left hand got caught between the door and the wall. Argh, the same fingers he had burned the day before on my Mom’s wood-burning stove. Ouch! He started screaming and I didn’t have any way of closing the door because it was only open a few inches. In retrospect, I should have checked the door with my shoulder to give him a fraction of an inch to pull his hand out, but instead I made sure his fingers weren’t caught too deep and gently pulled them out. He cried for about 10 minutes but he got to play with some ice and got over it relatively quickly. What a helpless feeling though! Ugh, how to prepare for the next catastrophe?

Anyway, it’s always great to visit the extended family and see how well the kids get along with their uncles and grandparents. Both Joshua and Jacob recognize each of their three uncles and one aunt by name now, which is great because they get to see them only once every couple months (and Jay and Heidi are living up north now so that’s even less of an opportunity).

The boys are not quite two years old yet. A week from today they will be – which is a shocker. I can’t believe that this much time has already passed and it’s amazing to see how far the boys have come. We’ve had our challenging moments but to see them growing happy and healthy is truly one of my greatest joys.

Just this week, I’ve stopped trying to keep track of the words that they know. They are well past the 50-word mark and have started on 2-word sentences and questions. What a truly bizarre experience to carry on a conversation with my kids. Guess I’ll have to get used to that pretty damn quick.

On a geek note, I was able to sneak away for a couple hours on Saturday and meet up with Rob and Don at a Starbuck’s in Windsor. I hadn’t seen Don in probably a year so this was great – and to learn that he and Julie are expecting in September was also great news. Anyway, we geeked out a bit about our jobs, the upcoming GDC, and we double-checked that we can use my PDA and my video-camera with Rob’s laptop. It was a good thing we tested it out because I found out that I needed a 4-pin to 4-pin Firewire cable. As it turned out, there was a Best Buy 2 minutes away, so $20 later and we had made sure that we could capture video before we had to disperse back to our families.

So look for upcoming blog posts and the occasional audio and video casts from Rob and I on the Game Developer’s Conference. The bender journey starts in T-minus 10 days.

Why Prototype?

Prototyping can serve a bunch of purposes, actually. First off, in a business sense, it can often be the first step in acquiring funding for a project. Second, it’s the most sensible way to prove some type of new technology or to quickly implement a complex algorithm. Third, for hobbyists and students, it’s a great way to build a portfolio of work that gives potential employers a basis on which they can clearly judge your talent. Finally, it’s often a great way to spark enthusiasm in a project from the perspectives of development/production and even the fan community (if you make your prototype public).

I’ve recently prototyped work for a couple web projects. Nothing fancy or resource-heavy like console/PC games, but proving a given technology/methodology will work. i.e. putting what’s in my head into practice as quick as possible to determine whether or not I should pursue a given route or not.

I would classify my recent prototypes as “uber-simple” versus the “advanced prototyping” that will likely be discussed at the Game Developer’s Conference. However, I’m guessing that some of the challenges I’ve experienced with these prototypes are probably pretty similar to real-world examples of game prototypes.

How Much Work is Throw-Away?

Prototypes are usually done as rapidly as possible to get something out that works for one of the various reasons mentioned above. This usually means I don’t spend a lot of time focusing on comprehensive modeling/design of the software. No UML, no heavy requirement specifications, no polished graphics or other resources. Not a lot of thought/planning goes into my prototypes. Then again, my prototypes for web projects are something that can be easily accomplished by any decent web developer in intervals of between 1 to 5-ish days, so that seems sensible. Things like a) dragging graphical objects using SVG and JavaScript or b) using SVG to generate pretty graphs of my web statistics. As the projects get more advanced it would make sense to plan for reuse of bits of the prototype and to do some up-front documentation. How much planning do you do?

I’ve recently been trying to rework my SVG web statistics into something more manageable and improve its interactivity. This has required several internal changes, genericizing the code, etc. I’ve moved chunks of logic from the server (in PHP) into the client (JavaScript), meaning I’ve had to translate code between languages. I’ve had to totally restructure some of the internal data structures. The list goes on. One of the great things is having the prototype “template” to use, but one of the frustrating things is having to rewrite complete sections of stuff I’ve already figured out. That doesn’t come for free, there’s a lot of debugging that goes into that.

Keep Up The Morale

Prototyping is usually the fun part. It’s a great way to “get wow”, but once the prototype is complete, then the real work starts (I’m only being slightly facetious here). Designers work on the software architecture and specifications. Coders have to profile their code, optimize algorithms, etc. Graphic artists get to work on production-level art. Audio engineers need to get into the studio and work with those fussy, high-profile actors. How do I (as, say, a development lead) keep up the level of enthusiasm within your team so the project crosses the goal line? Likely a form of employee rotation would serve here.

Maintaining A Grip On Reality

What about losing track of reality? It may be easy enough to design a prototype of a browser-based instant messaging system using PHP and some file locking but once you start to add hundreds or thousands or even millions of users to a real system – is your backend going to hold up? You may have to totally redesign your backend, or even deem that you don’t have the necessary resources to afford such a system. In this example, how worthwhile was your prototype (likely the UI bits will still be quite useful, actually).

Anyway, how do you keep track of reality while designing your prototype so that your final product is actually achievable?

Conclusion

These are just some of the questions/answers I’ll be listening for in the session. I’m sure the presenters will touch on aspects that I currently have no clue about but I hope it will give me enough useful insight into improving my prototyping experience on some of my future projects.

This post is part of a series describing some of the prep work Rob and I have done to get ready for the GDC this year. Have a look through our unofficial preview of GDC 2006 sessions to get a feel for what to expect, along with pointers into the official site.

First, the keyboard is a wonderfully engineered mechanical achievement. Folded up, it’s about the size of the PDA. Unfolded, it gives you a slightly compressed full QWERTY keyboard that is much better than a thumb keyboard and infinitely better than using the stylus. Bonus points for being able to plug the PDA’s charger into the keyboard so that the PDA can also charge while I’m using it.

This entire post was done on the keyboard, the plain text and the markup (excluding links I needed to look up online, the images and the ads). International characters are also available using some complicated key combos, but often it’s easier to just press CMD+Left space bar, then use the stylus to select the appropriate character.

I’m happy to report that the keyboard passes my speed test. I can type at over 70 wpm on a good day. Even with the compressed size of the keys, I was able to get up a good enough speed and the Clié kept up.

The next question is how easy it is to edit. The Backspace and Arrow key navigation seem to be identical to standard PC keyboards, so that’s a relief. Once I got the text selection down (see below), I was happy to see that Ctrl+X still cuts, Ctrl+C still copies and Ctrl+V still pastes. Another bonus.

However, there are some things that are awkward:

• Number Keys – Fellowes saved a whole row of keys by putting the number keys in the top row with the QWERTY keys, you type numbers by holding down a blue “FN” key to the left of the space bar. What’s worse is that the alternate characters usually available wihen you shift the numbers (you know, the ones that make it look like you’re cussing: !@#$%) are also on the same keys, accessible by a different green “FN” key that’s to the right of the spacebar. It’s going to take a lot of getting used to… For instance, the following 4 characters are available on one key by holding various different Shift/FN keys: ‘q’, ‘Q’, ’1′, ‘!’.
• Useful keys PgUp, PgDn, Home and End are now available on the arrow keys using the green “FN” key. Another big adjustment, since I tend to heavily edit my posts as I write.
• Selecting/highlighting uses the blue “FN” key and the arrow keys to highlight characters or lines of text above, below and to the sides of the cursor. Another big adjustment since I’m so used to using the Shift key for this. I wonder why they didn’t just use the Shift key here? In addition to CTRL+X/C/V mentioned above, I can type over the selected text and it is instantly replaced, but if I press the Del key and a large chunk of text is selected, a warning dialog pops up saying this operation cannot be undone. The problem with this is that I can’t seem to select the “Ok” button from the keyboard (which means using the stylus). I guess this last complaint is more of an application complaint than anything else.
• The forward slash character ‘/’ is located in an odd position: to the right of the right-shift key, below the Enter and above the Del key. This makes it a dangerous location, especially since I use it so often in markup for URIs and to close XML tags. They should have stuck it next to the ‘.’ key and shoved the arrow keys over to the right one key because I also seem to be missing them consistently. Too bad the keys aren’t completely movable like that cool toy we saw at last year’s GDC.

All in all, for $15 (including shipping) I’m quite happy with the product and I think I can manage to crank out lengthy drafts on the Clié while Rob types up his. Final editing and markup can be done on the laptop.

The Khronos Group is a collection of parties in the multimedia hardware industry that is:

focused on the creation of open standard APIs to enable the authoring and playback of dynamic media on a wide variety of platforms and devices

Members includes heavy mobile players like Nokia, Ericsson, and Motorola, video and audio card manufacturers like ATI, nVidia, and Creative, component manufacturers like Panasonic, Philips and Toshiba, high-end workstation folks like SGI and Sun, and gaming console manufacturers like Sony. It’s a huge gang with some notable exceptions.

The first time I heard of Khronos was last year when they released OpenVG 1.0. OpenVG is an API for hardware accelerated vector and raster graphics, which means it is the 2D equivalent to OpenGL.

Speaking of OpenGL, one of the first tasks of the Khronos Group when it initially formed was to take the OpenGL specification and define a subset that could be used in embedded devices (like mobile phones and gaming consoles). Embedded devices serve a particular purpose and thus, support for all OpenGL features might not be required. This subset API specification was written by Khronos and dubbed OpenGL ES.

Now we come to their latest venture: Collada. Collada is a schema that enables the common exchange of digital assets for 3D applications. In this context, “digital assets” are any resources that are needed to supply the actual 3D game content (models, textures, light sources, shaders, animations, etc). Here, “common exchange” means the ability to pass around these digital assets from one tool to another without having to worry about converting from one particular file format to another.

The Khronos Group chose XML as the base grammar for this format. Describing complex assets like 3D models using text instead of a binary format may seem a little crazy at first, but it doesn’t surprise me really, for reasons that the Collada specification points out:

• issues with character sets are already accounted for in XML
• XML is “plain text” and is easy enough to understand just by looking at the file
• XML is easily extensible (that’s the ‘X’), thus content creators can add tool-specific information to the assets while still conforming to the Collada schema
• there are XML parsers for nearly every available platform

Furthermore, the spec states that this schema is not intended as the final format for delivery in a product for end-users. This schema is really to help streamline the content generation process, not fulfill any need for the final product.

A common schema to describe 3D geometry, light sources, skins and animation frames sounds incredibly useful – and incredibly complex. But these people are experts so I’m sure they’ll get the contents right. To me, what’s really important is how conforming tools in the industry are. I’d really like to know how far particular versions of Collada have penetrated into the tool markets. The GDC speaker (Rémi Arnaud) plans to showcase a modern toolset that supports the latest Collada specification. But do products like 3DS Max and Maya support it? If so, how conforming are they? A “common” format is only common if a large enough slice of tools/products support it. Is this really just a “Sony Playstation” only thing?

For instance, the lag-time on SVG adoption has been incredible. One big difference here is that SVG needs to penetrate not just into the tools but also into the libraries and into the end products (mobile phones, browsers, etc). It’s only now, more than 5 years after it was originally introduced that mobile phones, graphics libraries, toolkits and browsers are really beginning to support SVG. In contrast, Collada needs only to make inroads into the tool vendors and with such a large group of parties involved in Khronos (as compared to W3C) perhaps their progress will be met with a higher degree of cooperation. Since I’m not directly involved in the industry, I have no clue so this is one thing I’m curious about.

Collada 1.4 was released in January of this year so it’s fresh off the presses, so to speak. The GDC session talks about the new bits in 1.4: Collada FX and Collada PhX. Collada PhX actually attempts to define physics in a common format. Collada FX attempts to define effects (pixel shaders?) in a common format. Unfortunately not a lot of background information is given on the two new additions.

I read through the first 10 or so pages and then skimmed the rest of the 293-page specification to try and get a feel for it.

I noticed that Collada FX has a <code> element for inlining blocks of shader source code. The last thing I remember learning about shader languages (though this was two years ago by now) was that they were very fractured with at least three similar, but not identical, code formats: Microsoft had HLSL (DirectX API flavour), OpenGL had GLSL for its API, and nVidia had defined Cg which paid no allegiance to either API (but obviously has a hardware bias). I had thought that Collada FX was an attempt to abstract away from a particular format, but the ability to inline arbitrary shader code seems to go against that. There’s an <include> element that does something similar (includes shader code from an external file). It’s entirely possible that I’m misunderstanding the purpose of Collada FX, and that’s why I’ll be looking into attending this session.

Also, a nitpick, but under the “Remarks” section it states:

Inlined source code must have all XML identifier characters escaped, for example, converting “<” to “&lt;”.

I wonder why they didn’t allow CDATA to be used? tsk tsk tsk …