Cycles materials in game engines
Only game engine purposed materials work in their specific game engines, just like only specific render engine materials work in their specific Render Engine of origin. (Blender Internal Materials only work in Blender Internal Render, not Cycles, and vice versa).

Every rendering environment (realtime, game engine or otherwise) uses it's own specific material definitions specially designed for their particular task and non other.

A few exceptions are probably generic material definition standards like OSL (Open Shading Language) or GLSL (OpenGL Shading Language) or RenderMan Shading Language among others.

As far as I know there is nothing stopping a render engine from using Cycles materials, I am sure they could hypothetically be be easily ported, actually more the other way around, a game engine could perfectly be designed around rendering Cycles shaders.

In fact one already exists, in the upcomming Blender 2.8 the new viewport realtime OpenGL render engine EEVEE can and uses mostly cycles material definitions and display them in real time. Cycles object viewport previews will also be generated by EEVEE.

Bottom line is, to the best of my knowledge the problem doesn't lie in the materials themsleves, the shaders, the languages or anything else, the problem lies in optimization and purose.

Game engines need speed and responsiveness above all, they can't spend the endless time needed to render a Cycles scene, as such corners are cut. You can't have all the nice things an offline render provides like raytraced reflections, indirect lighting, mesh lights, refractions etc, as such that eye candy has to be faked with various complex and intricate techniques.

Real time materials are therefore optimized for these tasks, make abundant use of pre-calculated effects, baked maps, lots of textures, screen space ambient occlusions, deferred rendering, etc., whereas a Cycles material aims for realism and flexibility of use at the expense of render time.

Making render engines compatible with third party material definitions is also a huge complex task, error and bug prone, can cause artifacts and unexpected results, may introduce negative implications like worse performance and feature limitations.

See for example Cycles support for OSL shaders, you can have them but while using them you can't get GPU acceleration for example.

It is also often pointless to do so, there are no real gains in say Unreal or Unity supporting something as niche as Cycles shaders in their pipeline. Business strategies and market competition also probably restrict sharing proprietary shaders between rival companies.