On UDK and Reveal

Mike did a nice post on his blog on why custom engines are always better (in theory) than pre-built ones, using our game Reveal as an example. 

He alludes one of my bigger frustrations with UDK, that straying at all from a tool's intended purpose usually results in as much or more work than not using the tool altogether. When  I wrote Reveal, I thought I was being clever by designing it's features around the things UDK was supposedly good at: cloth physics (for wallpaper and magazines), rigid body physics (destructible boards), and dynamic lights (the swinging light bulb). In the end, all of these things required a good deal of custom scripting from Mike, and even then plenty of compromises were still necessary (I had forgotten the wallpaper was originally supposed to be seamless. The strips turned out to be a fine substitute, but their rubbery movement and the way they pop off the wall is still weird). I had designed a game I thought I could make 95% of on my own, using the tools UDK already had, but in the end I was totally reliant on Mike to get my game up and running. Consider it a warning, I guess, before jumping into UDK as a non-programmer thinking you can make anything beyond a deathmatch-style FPS. It's possible, certainly, but working against the grain of the engine isn't a pleasant experience, and not how I as an artist/designer want to spend my time.