I wanted to share some things I've learned while working on a game project of my own.
Unfortunately these things are rather difficult to explain in isolation and out of context, so some time ago I've started putting together a much smaller example to illustrate, in as basic form as possible, how various game data types can be created in Houdini, how to export the data and how to use it at run-time.
Warning: this is a low-level technical example, this is not about saving out Collada files or using high-level interfaces in the existing middleware. This example is intended for those who want to write their own tools based on Houdini.
The project's Google Code page is here: http://code.google.com/p/kinnabari/ [code.google.com]
The run-time code is Windows/DX9 - no plans to port it to anything else.
GCode repository contains the run-time system sources (C, some C++, HLSL), Houdini tools (Python), and some additional utilities (C#).
These archive contains the snapshots of the current sources, Houdini scenes, some additional Python scripts not in the repository and precompiled binary:
http://kinnabari.googlecode.com/files/kinnabari_test__Aug23_2011.zip [kinnabari.googlecode.com]

You can see how the test program looks on the first picture.
There is not much on the surface at the moment - you can move the character around the “room” using the cursor keys and bump into walls.
Here is the list of some things under the surface:
* using GLSL in Houdini to render the materials as you will see them at run-time. A complete material system is quite involved, I was looking for some way to make a really simple but illustrative example, so I made a kind of toon-material, which is controlled by a small number of parameters - see the second pic.
Also I've posted some GLSL examples here: http://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=22491 [sidefx.com] will try to post some more if time permits.
I'm not using textures at the moment, just colors on the geometry, that's mostly to avoid UV mapping and save me some time, but I think I will add textures at some point.

* the character setup uses joint system with custom IK solver as described here: http://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=22527 [sidefx.com]
I've tried to make the setup as transparent as possible to make it easier for a programmer to understand what's going on. So the rig is very straightforward.
The IK is not baked into rotations, the effectors' positions are exported as-is and evaluated at run-time in the same way the Python solver does it in Houdini.

* and example of how to export and evaluate keyframe data with cubic() interpolation, this is used for both character animations and camera movement;

* geometry export examples for the character (weighted model), the scene (static model), collision geometry (export quadrilaterals), and special camera control “lanes” geometry;

* generating culling data for the character - the model is deformed by the skeleton, actual deformation is calculated on the GPU, that is _after_ the drawcall was submitted. So it's not possible to recompute bounding volumes based on the deformed geometry (that would be terribly inefficient on CPU anyway). This demonstrates how to generate bounding spheres for point clusters affected by a particular joint, at run-time the bounding volume for a primitive group is calculated by transforming the corresponding spheres and computing their new bounding box. This method is suitable for both frustum and occlusion culling. This is shown on the 3rd screenshot;

* spatial camera control system - lookup into camera animation channels based on character's position;

Cool stuff!

A small fix for ATI cards: it would make the GLSL Toon material's fragment shader compile if you change saturate(val) function calls to clamp(val, 0.0, 1.0) and lerp to mix

Thanks, here is updated OTL: http://kinnabari.googlecode.com/svn/wiki/GLSL_toon_fix.zip [kinnabari.googlecode.com]

This is really cool! This is a perfect example of why people should use Houdini in game creation over other software packages. I am curious if you have any more progress to show? The methodology you are demonstrating could save a developer tens of thousands of dollars (maybe even more) in middleware costs.

Lyr
I am curious if you have any more progress to show?

There is some new stuff in SVN, in particular, there are some examples on working with acceleration structures for collision detection.
Here is Python script to generate and save bounding volume hierarchy (BVH) data for a collision model: gen_bvh.py [code.google.com]

I just uploaded a sample scene demonstrating how BVH can be built using Python SOP and stored with the geometry, this way it's possible to visualize the structure itself as well as collision queries performed against it.
This is demonstrated in the attached picture - wireframe shows the hierarchy of bounding boxes, the green thing is the query (directed segment), polygons highlighted in red are those to be tested against the query, gray polygons were discarded by the acceleration structure. The scene is here [kinnabari.googlecode.com].
Finally, HDK includes implementations of a number of suitable acceleration structures, namely BV_Tree subclasses. Instead of implementing your own BVH construction it's possible to use HDK classes for this. Here is the source code for a very simple HDK plug-in that uses GU_AABBTree to create BVH structure in SOP fully-compatible with the scripts above: SOP_BVH.cpp [code.google.com]

There is a number of things I'd like to demonstrate, e.g. custom controls to place gameplay-related triggers, lighting setup/export and so on, so I'm working on additional content necessary for these examples - this, well, will take some time.

Thanks!