TL/DR = Houdini is way more flexible and controllable, but there’s some assembly required.
“Way more power” in this case is synonymous with “Way more flexibility” and “Live data.” With Houdini, your workflow is more in the nuts and bolts of how the content is created, by stringing nodes together that are essentially C++ objects, which should be familiar to blueprint users. The flipside is that “with great power comes great granularity.” That means there’s no such thing as a “building maker” in Houdini, although you could tear apart one of the assets from labs.sidefx.com or Orbolt.com, and use it as a starting point to make your own Building Maker asset or node network that can be tweaked specifically for your game, i.e. all doorways are a minimum dimension, all floors are a specific height, all windows provide X amount of cover, that sort of thing.
Basically, every widget and plugin and gadget out there that actually creates data or modifies existing data is procedural, technically, but they’re black boxes: you drop them in your setup and you get the result the sliders (and the developers) give you. The “procedures” are encapsulated in the app/plugin, and that’s as far as you go. Houdini’s way less opaque about it, but not as targeted to a specific solution as something like EasyRoads for [that other game engine] or FumeFX for Maya/Max. Houdini lacks the GIS functionality inherent to to CityEngine, but there are ways: Any ASCII file (even ESRI’s) can be parsed with Houdini’s python, and Houdini could probably handle GeoTIFFs as well, although I haven’t tried. Houdini has native JSON support as well, so GIS isn’t entirely off limits. Neither is LIDAR, and you can get a lot without going to the full C++ SDK.
As for supporting Unreal, you can currently use Houdini python to generate .t3d files. Just Google Freek Hoekstra and Jan Pijpers and you’ll find some pretty cool stuff.
Given what I know about game production (admittedly less than most on here, but not completely void), a lot of software development time is spent crafting specific art solutions targeted at a specific title for a specific engine. Houdini is all about the building of things based on rule sets, which lends itself readily to things like kit creation/assembly, organic shapes (full and robust support for volumetric data), placement of art assets according to mesh attributes or texture maps, modification of existing art assets to conform to a new set of mechanics, etc. The idea is to enable artists and tech artists to do that stuff and free up engineers for the hardcore engine and optimization development.
It’s also about building tools: The node based workflow can be encapsulated and shared, a lot like blueprint macros. I don’t want to anger the gods by rattling off the marketing push or something that sounds like it, but I would recommend going to sidefx.com and checking out the tutorials, and downloading the free version. The only drag about the free version is that you can’t save out FBX or EXR files and your rendered images are watermarked. But you can save .obj’s (I think) which you can bring into Unreal and check out. Just remember to set Houdini’s viewport to be Z-Up in the preferences before you start building stuff.
This brings me to 's questions:
The way it works is this: The commercial versions have a base price and an annual maintenance fee, more or less a subscription. So the base price gets you the product and the first year of maintenance, major and point version upgrades, and support for free, then subsequent years, you pay the fee, which we call the Annual Upgrade Plan because as long as you pay it every year, you get upgrades and support.
You can go off the subscription and your license will still work, you just don’t get support or major/point version upgrades. If you let it lapse for too long, you need to re-buy at initial price but that doesn’t mean your old version stops working.
Let me make that clear: Your purchased license will always work for the version you purchased.
It sounds steep, but we have an awesome retention rate (that I’m not allowed to disclose here) because our support is so good. You also get access to daily builds (13.0.xxx) and the issue database where you can directly submit bugs, RFE’s, and questions.
The difference between Houdini and Houdini FX (and the reason for the diff in price) is that Houdini FX includes all the world-class VFX tools like rigid bodies, cloth, wire, destruction, pyro, fluids, particles, etc. The irony is that those features are less useful to game devs, because they’re not realtime/runtime solutions; they were designed to make feature film FX, which means you throw them to a render farm and go have coffee.
The other prices have to do with whether or not the license is on a single workstation, a local license server, or a globally-available license server. The type of license that’s best for you is determined by where your Houdini artists sit and how often they move to different workstations. A small studio can get great value from a single Houdini workstation license and crank out phenomenal amounts of stuff.
Given that, what is it you want to do? You need to make procedural roads, bridges, buildings, fences, trees, and other art assets, with infinite variations on them, or filtering/processing acquired data? Base Houdini works fine. If you need to do crazy dynamic simulation for set pieces and cinematics, or pyro simulation to make sprite sheets, you’ll need Houdini FX. If you want to use your Houdini-authored tools in Maya, you’ll need a Houdini Engine license as well.
The learning curve is sometimes described as steep, but it’s really not that bad. If you can learn Blueprints, you can learn Houdini, especially for creating procedurally-generated meshes and instance location data. I’ve been using it for a long time, but honestly, the stuff that’s most compatible with game art creation is the stuff I learned 17 years ago in Houdini 1 and is the most basic and easily understood part of Houdini. You’re also not going to care much about lighting and rendering, unless you want to get crazy and bake lightmaps or pre-lit texture maps out of Houdini (doable, I’ve done it). But definitely go through the tutorials on the sidefx website, they help a lot. Not only that, check out the sidefx Vimeo channel, lots of cool stuff there as well.
With that out of the way, I’ve got a few cats in a few bags that I’m not allowed to let out, but we are, as a company, very excited about Unreal 4 and we are committed to serving the game development community in the many forms that it takes, including hobbyists and small studios.
[QUOTE=JHighsmith;22055]
Care to talk it up a bit? Or recommend some videos? I’ve heard Houdini talked up for years wrt procedural content but that’s as far as my knowledge goes.
I confess I’m intrigued by “way more power” and feel like that demands some elaboration. 
I’m interested in hearing the answers to ’ questions, too.
If you mean it won’t create your game for you, then I agree. I was thinking that CityEngine would basically rough in an urban environment for level designer, who then goes in and actually makes a “level” out of it. Though I’m thinking more along open-world design lines than level design lines. CE gives the LD a shell that he goes in and adds interiors, doors, breakable windows, moving elevators, working light switches, traffic lights, physics, etc.
State of Decay almost seemed too small to have needed something like CityEngine, though you’re right that Undead Labs made SoD as a prototype for an MMO. I hadn’t heard that they used procedural methods, but it makes sense that they would. I’ll have to go a-searchin’ to see if I can find details.