Unreal Riven

Five years ago, when we first discussed the prospect of remaking Riven, our intention was to do it as an expansion for Uru. The original name of the project, before it became the Starry Expanse Project, was actually uRiven (after Uru). Without any official tools to make content for Uru, we produced everything in Blender 3D and exported it to a format that Plasma (Uru’s game engine) could parse. However, after a while, we outgrew Plasma. It was outdated, it could not achieve the graphics we needed, and worst of all, it was no longer being maintained or updated.

And so, the project migrated to the Blender Game Engine. It was the logical next step at the time – we were already using Blender for asset creation anyway, so why not just use the built-in engine for the game itself? Well, it eventually became obvious why: the Blender Game Engine was difficult to work with, and while it could be prettier than Plasma, it was never faster, and at its core, it was simply inefficient.

To make a long story short, we shortly thereafter moved to an engine called Unity 3D. Unity was our first professional engine, and unlike ever before, our goal seemed to be within reach — this was an engine that was used for actual games, and while it had a significant learning curve, it could produce great results. We jumped onto the Unity ship, and the future was bright. With Unity, we showed off Prison Island and an area from Survey Island at Mysterium conventions. It was a huge step up from the Blender days. But, with our knowledge of game design sprouting like a beanstalk, and our team sporting many times more talented artists than ever before, the shortcomings of Unity for our project were becoming more and more apparent.

* * *

By the beginning of last summer, we had begun discussing the possibility of leaving Unity behind. Concerns about Unity’s graphical capabilities had been raised — in particular its ability to efficiently render large, detailed areas. The areas we had produced up to that point were fantastic, but they were already putting significant stress on Unity, and in terms of complexity… well, they were mere specks compared to Jungle Island, the largest island we would have to be able to handle. It seemed that the need for a change of rendering technology was inescapable.

The straw that broke the camel’s back was the release of Unity 4.0, a paid upgrade from Unity 3, which was what we had been using up to that point. As many of you know, we had to raise money in order to afford our Unity 3 license, and we are very thankful toward everybody who donated. Because of this, we were not happy about the prospect of having to either purchase an upgrade or risk becoming obsolete.

The search for a new engine began in earnest after Mysterium 2013. If not Unity, then what?

UDK logo

It wasn’t long before our gaze fell upon the Unreal Development Kit. UDK is a free (provided certain licensing restrictions) framework built on the Unreal Engine. It’s also the engine Cyan is using for their new game, Obduction (they’re still collecting donations, by the way), and in fact, Cyan themselves recommended that we use it for our project. It’s an extremely powerful platform that has been used to produce beautiful AAA games for years, such as Bioshock and Mass Effect. Its lighting and particle capabilities far outstrip those of Unity, and its ability to handle large, detailed areas is in another class altogether.

What’s more is that UDK maintains similar cross-platform support to Unity; games made using UDK can be run on OS X, Windows, and any of a number of mobile platforms. It even has Oculus Rift support baked in. UDK gives us everything that Unity had, and on top of that, it’s faster, it’s more beautiful, and it’s free.

Since the switch, we haven’t looked back. Unity is a great platform, and for a while, it was the platform we needed. While we were disappointed that we were not going to be able to continue with it, we look forward to showing off just how amazing Riven can look with this new engine.


52 Responses to “Unreal Riven”.

Team members' usernames are in red.
  • Phil Says:

    Great news! Looking forward to seeing the results in the new engine. How far do you think the switch has set you back (weeks/months/etc)?

    • zib_redlektab Says:

      It’s true that we had to take some time out of our regular development cycle in order to learn UDK, but we think that the switch is worth the time it took. Whether or not we switched engines, it’s art development that takes the majority of our time, so I doubt we would be much farther along anyway.

  • Anthony Says:

    UnrealRealRiven! Woohoo!!
    I’m ecstatic that the team has switched engines. I hope not all is lost from the transition of Unity 3 to UDK though, especially with the donations used for Unity support. The games made with the UT engine on the market are just gorgeous and I hope we get a similar immersive experience.

    However, I hope the game is compatible and can utilise the features from the upcoming Unreal 4 engine, which is currently in the works.

  • cjherkeless Says:

    Thanks for the update, guys. This is some very nice news.

  • MindClot Says:

    This is great news and I look forward to your project!

  • GeckoXX Says:

    But the Unreal Engine has no Linux support. :(

    • Starry Expanse Team Says:

      Sadly, yes, that is a downside. Although, it’s important to remember that Unity 3, which is what we had the license for, didn’t have Linux support either. In fact, Unity 4 doesn’t even have it right now either, so it doesn’t really seem a compelling reason to stay.

      Edit: UDK does export to Mac, so perhaps some kind of wrapper or emulation can be worked out (by a third party…). If that’s the case, I’d (Philip) be willing to test it out occasionally on Linux and try and find workarounds for OS-specific bugs we cause. If the bugs are caused by the engine, though, there’s probably not much we can do.

  • MysticalDigital Says:

    Goodbye Linux support :(

  • delcolux Says:

    You know, back before Cyan revealed that they were working on realMyst Masterpiece, I considered trying to do a realMyst remake using UDK. The name would of course have been unrealMyst.

  • Ted Sase Says:

    How will Unreal fare on low-end machines?

  • Andrew Plotkin Says:

    What are the restrictions on “free” and is it possible that they’ll bite you at some point in the future?

  • Kirk Says:

    Interesting! Korteenea and I once developed a UDK alternative to Uru modding called UnrealMYST, which might be useful. We didn’t really get to the demo level stage what with work and all (we wanted to make fan ages), so all we’ve got is an abstraction layer on top of UDK for interaction and linking and so forth.

  • Kirk Says:

    It might not be what you want though. Arguably it’s a little over-engineered, I got a little crazy with it.

    • Ryan Medeiros Says:

      Over-engineered in what ways?

      Do you think you could explain from a more technical standpoint what the “abstraction layer” you used for Myst mechanics was? I know I, at least, am interested.

      Thanks,
      ~Ryan

      • Kirk Says:

        The whole thing was meant as a make-your-own-age addition for the UDK, meant to simplify certain MYST-related tasks for people using the Unreal Editor, and provide basic D’ni mechanics. The UDK then provides all the other stuff to make it easier for people to make and release stuff, and it has a ton of free documentation material.

        UDK has some standard ways for interaction, which I “replaced” with a more intricate interaction system. However, an experienced UDK designer would probably find that a little over the top.

        For the rest it includes a basic game type, a basic HUD, linking, some other stuff… It’s set up to provide a basic experience, which one can extend or override as desired with their own UnrealScript.

        UnrealMYST, or Project Rehgehstoy as it is now called, was supposed to be released once the basic features were complete. However, we got stuck on making a default character (a maintainer suit) and life eventually took over. The rest is pretty much done though. We also wanted to make some demo ages before releasing it.

        If you’re interested I can send you a copy. Just ignore the default character, the crappy art assets, and the quick-n-dirty unfinished tech demo ages ;)

  • Sandy Plankton Says:

    Now what I’m really keen of getting is a playable demo of prison island so we can compare that to the one made in Unity released last year.

  • Seppolo Says:

    Great on it to let me sometime paralyze me again of Riven.

    Only for integration into URU I find your project honestly valuable.
    I would like to see an independent realRiven.

    • Boingboing Says:

      You do realise that you’re not paying a cent for this, when released? The creators have bold ambitions to make Riven a realtime epic piece so to switch over to what they think is a superior engine to give the game justice is a bold, and fantastic move. Yes, it will involve more work which would result in the game being delayed, but I think if they released the final game using Unity 3.0 we would have a subpar experience (not that their current work with Unity was bad, but when they know they could have done much better with better tools to work with, then that’s a once in a lifetime opportunity missed).

      Finally, Cyan is too busy supporting the recently released realMyst MasterPiece Edition and upcoming Obduction to even think about putting the time and effort realRiven would deserve.

      • Ryan Medeiros Says:

        All true, but you aren’t exactly correct in the “not paying a cent” piece, as the FAQ has already clarified that there will be a purchasing cost for the final game.

        As it turns out, though, it would take a lot more effort to produce a “realRiven” than Cyan can afford to do, especially considering that they somehow lost most of their original assets that were used in creation of the original game.

        Believe it or not, the original Riven was modeled in 3D for assembling the shots, and had the original meshes survived, the project would be a whole lot easier.

        Under the circumstances, recreating those two years’ worth of work from scratch (and with a smaller overall team) is really not viable for Cyan at this time, as they’ve been just barely hanging on as it is.

        ~Ryan

  • Jordan Neal Says:

    Linux support? I know Unity has Linux support which is a huge selling point these days given the upcoming Steam Machines. I would look forward to playing Riven on my steam machine. Does UDK provide native Linux support or is it going to be a huge port to get it to work?

    • Jordan Neal Says:

      Oops. Should have read the previous comments.

    • zib_redlektab Says:

      Thanks to Valve pushing Linux as a major gaming platform, we remain hopeful that the guys at Epic (the company that makes Unreal) will be releasing a Linux version of their engine soon. Right now, UDK only supports Windows and OS X, which was the same as Unity supported in version 3.

      Should Epic add Linux support to UDK, we will in turn support Linux in our game. The decision, unfortunately, is not in our control.

  • Yali Says:

    Thank you Zib! Thank you!

    I’ve been waiting for this day for so long, to finally see Riven be given the justice it deserves with an engine that can match the original stills with all those rich textures.

    Will Cyan be sharing their Albuquerque texture database with you?

    • Ryan Medeiros Says:

      I’m not exactly sure how intact that database is (Zib, et al. would know better), but as I understand, most of the original development assets used in Riven are lost (or at least enough that high-res shots can’t be re-created from it anymore), which is why no more HD riven stills have been released.

  • flake100 Says:

    Will handle all the puzzles with the unreal engine ? I’m not sure.

  • Yali Says:

    Honestly, I’d like to see you guys show us the Elevator Room in Unreal versus the Unity screenshots you guys posted just recently. I think it would make a great comparison.

  • Diriel Says:

    If I’m perfectly honest, Unreal is my least favorite engine around… Although Unity was a close second. xD
    Both have extremely annoying managed windowed modes that ignore your choice of resolution in favor of avoiding overlapping the taskbar and screen edge. News flash, if I pick 1600×900; that’s because I want bloody 1600×900, not as close to 1600×900 that will fit above the damn taskbar! On top of that, they both actively check the state of their window, so if I use third party software to alter their size or remove the ugly ass windows border; they immediately revert the changes. There really is no reason for this behavior, if someone knows well enough to pull the borders off; likelihood is that they don’t want the borders there… It’s almost like Unreal was designed as THE console engine, “run it in fullscreen or screw you.” Since you’re using UDK and don’t have access to the actual Unreal source code, I don’t think there’s any way for you to fix this annoying behavior. As a compromise, if you can figure out some way to include a borderless windowed mode, that would be great.

    On top of that, Unreal has no Linux support (I am aware that you are aware of this) and it’s anti-aliasing capabilities are seriously lacking, in my opinion; the MOST important graphical feature. At least that’s something that Unity can handle just fine. FXAA and SMAA just don’t cut it. They’re speedy, sure, but I’m not running a PC from 2004. I can handle MSAA and SSAA just fine, y’know the ones that look -good-.

    I’m also wondering if you’re going to be able to actually make the Unreal engine look good, or if it’ll retain it’s usual ugly plastic-y aesthetic. So far the only game I’ve seen that made the Unreal engine look good that wasn’t a shooter on a space ship was; Brothers – A Tale of two Sons.

    -Rant over-
    Now that that’s out of the way, let me just says that you guys are awesome. I really hope you succeed and I wish you all the luck in the world. Despite all the ranting, I realize that the choice of Engines isn’t all that wide, and Unreal is likely the only one that can handle the type of rendering you’re going to need it to do… That doesn’t cost tens thousands of monies, anyway. I just hope that I can avoid having the usual “Unreal Experience” as it would totally break my immersion… And those puzzles won’t solve themselves.

    I would also like to state that I would be more than happy to pay full price for such a game. Even though it’ll be on the Unreal engine and would technically be illegal. >=P

    Keep up the good work.

    • Philip Says:

      I should preface this by saying I readily admit that I haven’t actually looked into any of the issues you’ve mentioned, but I have some preliminary follow-up questions for you:

      1. Perhaps those issues with the borders being adjusted can be fixed by someone modifying the code in the UDK binary, e.g. inserting a jmp instruction that bypasses the check. Not that I have even looked at the assembly; it could be completely obfuscated for all I know. I’m not sure we could distribute modified UDK executables like this, but perhaps you, as the user, could make a patch that fixes the issue.
      2. I can’t really speak to the lack of MSAA or SSAA. If, however, you want to send us a link to an implementation of one of those algorithms in UDK (since UDK has post-processing capabilities) with a license we can use, we’ll gladly include it as an option.
      3. Perhaps some of these issues will be fixed in Unreal 4?

      • Nick Says:

        I’d also like to add that we are all too aware of the plasticy ‘UDK look’. I agree it’s undesirable, and trying to minimize it where possible would be a good thing.

        • Diriel Says:

          I feel that I came on too strong with my sudden debunking, and I realize that most of the issues I’ve brought up are very specific and unlikely to upset most people.

          In response to Philip:
          I’m afraid that – as much as I may complain – I’ve never looked into any solutions to the problems I’ve mentioned. Some quick googles seem to show that there are ways to achieve a borderless windowed mode through some hackyness with intercepting the window creation event, though I would have thought that the window monitoring would “repair” any modifications to the window’s Long property regardless of when the modification took place.
          As for MSAA, apparently it is supported natively if using deferred rendering in DX11 mode. Since I assume you’ll be using deferred rendering anyway, simply providing a toggle to DX11 (for those that can’t handle DX11) should allow you to use true anti-aliasing. Though again, as I don’t use UDK myself I couldn’t tell you how to actually do that. x.x

          Nick:
          It’s wonderful to hear that you’re working to tame Unreal’s tendency to make everything look sci-fi. Just being aware of it is generally enough to circumvent it.

          Just having you both acknowledge my concerns is enough to belay them. It feels great simply to get an answer, even if it doesn’t solve much. xD

          Thank you for the responses.

          • Kirk Says:

            Increase the number of samples by setting MaxMultiSample to more than 1 in [...]Engine.ini, and set AllowD3D11 to True for DX11, or bAllowD3D9MSAA to True for DX9. May need some fiddling, never tried it myself.

  • Nick Bluetooth Says:

    It’s interesting that you guys always switch to Cyan’s go-to engine. Since Cyan was using Plasma for realMyst and Uru, Starry Expanse started with Plasma. When Plasma and Blender didn’t work out, 59 Volts moved to Unity, which is what Cyan used for realMyst iOS and realMyst Masterpiece. When Unity 4 became too costly and Cyan recommended Obduction’s Engine UE4, the team announces Unreal Riven. Your arguments have even me convinced that Unity is old hat compared to Unreal. Well, that and it’s just so fun to code mods for Deus Ex, which was written with the original Unreal.
    Are you guys using the UDK for Unreal Engine 4 like Cyan is using, or are you stuck with Unreal Engine 3 for now?

    • zib_redlektab Says:

      This is an interesting point. It makes sense that we would start with Uru – the project originally began not as ‘realRiven’, but as ‘Riven in Uru,’ with everything that entailed. Including multiplayer. Upon realizing how insane that idea was, we transitioned away to Blender (the missing link in the Cyan engine theory). We actually moved to Unity before Cyan publicized that they had done the same, making that one coincidence, and I have a feeling that Cyan’s move to UDK was done for similar reasons to ours – it’s very easy to make very impressive games with it.

      The difference, as you point out at the end, is that Cyan appears to have an Unreal Engine 4 license (which are difficult and expensive to acquire), whereas we are currently using UDK, which is easy and free to work in. UDK is currently based on Unreal Engine 3, which is certainly no slouch – no Unreal Engine 4-based games have even hit the market yet, and Unreal Engine 3 is still absolutely the standard for high-end video games.

      • Nick Bluetooth Says:

        That’s an interesting set of coincidences. Will you guys start using Unreal 4 when it is free to the public, or are you going to stick with Unreal 3?

        • Ryan Medeiros Says:

          Well, I think that’ll really depend on the timing of the engine shift.

          UE4 isn’t even really mass-market yet (it doesn’t even have Mac support at the moment), so switching to UE4 under UDK will likely only happen when Epic feels it is stable enough, AND that it will be the best way for them to profit from the engine. I expect that it may be several years before that happens, especially considering that about 5 years passed after the initial release of UE3 before UDK came out. Once the Mac, etc. ports are completed, a few years will pass, then UDK will be updated.

          Considering the expected time taken for development of Starry Expanse (several years), the switch will probably occur for the project when Epic is ready.

          ~Ryan

  • Vincent Says:

    Totally awesome !

  • P-K-V Says:

    I just replayed your Prison Island demo, and I have to say, no offense to Cyan, but it is more impressive than realMyst: Masterpiece Edition. I absolutely can’t wait to play the final, polished release!

    • Ryan Medeiros Says:

      Um, well, that demo was released in 2012, when Starry Expanse was still being developed in Unity.

      This post is saying that the engine used for the project has been switched to UDK (Unreal Engine 3 w/o the source code access), which has better graphics and design support.

      Which means, with the new engine, Starry Expanse will look even more awesome than that demo!

  • tomy Says:

    I think this is a good choice because it’s also what Obduction is going to be using so if Cyan is going that route you’re probably headed the right direction :)

    • Ryan Medeiros Says:

      Well, according to Cyan’s website, Obduction will be developed in Unreal 4, while UDK is currently based on Unreal 3, so we’re not *quite* there yet, for now.

      But once UDK is updated to UE4, then most definitely!

  • Trekluver Says:

    UDK today, Cry Engine tomorrow!

    CryEngine tomorrow, Frostbite shortly thereafter!

    Frostbite shortly thereafter, then… alright, I’ll stop now. :P

    (I’ve been working on that one since the announcement, guys. Congrats on the shift to UDK! The game’s simply gonna be ten times more awesome now!)

    On a side note, how far along are you guys on the minecart sequence? Zib knows I have a minor obsession with that part of Riven. :P

  • SugarSpice Says:

    Frostbite please?
    Actually, whatever. We simply want realRiven already!

    UT4 UDK would be sweet as, as long as it doesn’t look plasticy looking – lighting effects included.

  • Prom361 Says:

    Hi !
    Good choice !!! I work with UDK for my personnal myst-like game ;) and it’s been several months that I work with and I learn, and I can tell you that this is a great program! add it to Blender for 3D objects, and I think it the perfection! there is a lot to see and learn, but for your work, I absolutely and completely trust! and I can not wait to see more!
    thank you for your project and your work! a très bientôt !!! :)

  • Nintendo Maniac 64 Says:

    Of course the irony is that Unity 5 just got released and it even contains support for Imagination’s ray tracing hardware for accurate lighting effects.

  • Kirk Says:

    I believe they didn’t want to move to a new Unity version because it was too expensive.

  • theblackwidower Says:

    It’s a pity you can’t get your money back from Unity… I assume.

    • zib_redlektab Says:

      It would be nice if we could get our money back, but we do not consider it a waste. Our experience with Unity taught us a lot, it being our first real game engine, and we don’t regret paying for it. It was the engine the project needed at the time, we’ve just outgrown it.

Leave a Reply