Floating Hands: Good Riddance

I never liked the idea of floating hands, and now that I’m no longer trying to get a dev kit from HTC/Valve (they expressed interest in mini-games with low replay value and minimal content, the opposite of what Dungeon Survival is aiming for), I’m doing away with them entirely in favor of the true-first-person I always intended to provide, and was going to end up being an option if floating-hands had stayed.

With an inverse kinematic solution that’s more robust than the generic CCD/tw0-bone IK provided out of the box by most engines, and which also features constraints, the “elbow problem” which prompted Oculus and Valve to so vehemently recommend against true-first-person avatar bodies simply doesn’t exist, so the argument for floating hands crumbles.

For fans of floating hands rather than a tracked, full body avatar (why!?), they may come back as an option post release.

Brief Dungeon Survival Update

Got motion controls via the hardware-agnostic interface in UE4 working with the Skyrim-style inventory I already had set up for a while now.

It’s amazing fun tossing items around and catching them in the air, and the IK for the hands is great 😀

I’d really love to get my hands on an HTC Vive DK2 in order to get all this integrated on more final hardware, but even the Razer Hydra is really awesome.

(Note for coherency sake that these controls already worked in a previous build of Dungeon Survival which did not have the inventory system, some character work, enemies etc set up, and this update is mainly about now being able to support Vive and Oculus Touch, and PSVR Move controllers).

Plugin Spotlight: Sound Visualization in Packaged Builds

I’m sure many UE4 developers are aware of the neat Sound Visualization plugin that comes with the editor, which allows you to get frequency and spectrum information from a SoundWave.

Those who have tried to use the plugin for anything in their own projects will also know that the stock version does not support running outside the UE4 editor, which makes it rather useless for serious projects.

If you were to fix the in-editor-only problem, you’d quickly run into the issue that decompressing a SoundWave to use in the Sound Visualization plugin causes the entire sound to be decompressed – this can be bad with large sound files which decompress to multiple gigabytes of WAV sound data.

To that end, a while ago I had built an asynchronous multi-threaded sound decompression class which allows the user to pass in a portion of the sound to be decompressed, and returns only the decompressed sound for that portion.

Not having done anything with it for a while, I sent it over to Unreal Forums user eXi, who has packaged it all up with the Sound Visualization functions into its own plugin.

Check it out: https://forums.unrealengine.com/showthread.php?94974-eXi-s-Sound-Visualization-Plugin-%28works-in-cooked-builds%29&p=441220

Bone-Break Dismemberment Plugin for UE4

Unreal Engine forum user Jeff Lamarche recently posted a plugin that adds support for UDK-style “bone-break” dismemberment (read more here) to Unreal Engine 4.10 Blueprints.

While this method does require some art support and preparation, it’s a tried-and-true way to add dismemberment to enemies, and is still frequently used in modern games. One such example is the recent Warhammer: End Times – Vermintide.

Bone-Break Plugin for UE 4.10

Unreal Engine 4 Plugins Shoutout!

Big news and updates for the game will be coming soon, but for now I’m going to do a shoutout to some of my favorite Unreal Engine 4 plugins and their authors!

Speech Recognition

First up is a brand new plugin from forum user ShaneC – Speech Recognition

Driven by pocketsphinx (portable edition of speech recognition library, CMU Sphinx), this plugin allows you to take microphone input and a wordlist, and detect which words the user has said. Adds several blueprint nodes, which ShaneC was kind enough to demonstrate the usage for.



Dungeon Survival will be using this plugin for multiple systems, which I’ll be going over in a future update. For now, it’s a secret 😉

Ocean Simulation

Next up we’ve got another free community plugin, DotCam and TK-Master’s Ocean plugin. This is one of my favorites, having always been interested in ocean simulation and rendering.


The latest version features screen space reflections, and an infinite-system component for unbounded oceans. Already in use in Dungeon Survival and the new upcoming version of Storyteller.

Dungeon Generation

Dungeon Architect by Ali Akbar, the procedural dungeon creation tool you’ve always wanted.

For quite some time, Dungeon Survival was planned to feature only hand-crafted dungeon levels. This was before the scope of the game had increased to include an overland component, and towns and villagers to visit and interact with.

After some feedback from Reddit’s Roguelike subreddit, I decided that procedural generation of at least dungeon layouts was something I wanted to put in. I spent some time investigating and implementing methods of my own, but quickly abandoned them once forum user Ali Akbar showed off his amazing Dungeon Architect plugin.

That’s all for now, but I have big updates and news about Dungeon Survival on the way!

Motored Ragdolls

By default, ragdolls in most games will bonelessly flop to the ground. Newer games and especially AAA developers have been putting in motored joints to alleviate this, or sometimes blending from an animation, or to one using motors.

With some simple motor forces it’s possible to get a stiffer ragdoll that resists being tossed around or pushed over, and naturally falls in a flatter state that’s easier to recover from for stand up animations.

Fans of melee combat – Reverence is a must see!

Reverence launced its Kickstarter campaign today, asking for a modest $5k in light of the features already implemented.

Obviously being a huge melee combat fan myself, I am going to back this for sure. While the graphics may be rough around the edges, the gameplay features more than make up for that lack, and that can still result in a beautifully executed game, as in the case of a favorite of mine, Mount & Blade.

Some of the highlights in Reverence include:

* Full melee combat control!
* Dynamic real time slicing – cut through trees etc.
* Physics based parrying
* Stance system

Fans of melee combat should definitely check this out and give it a go!

Dungeon Survival and Linux

Recently we’ve had the news that Oculus will at least initially only support Windows. Understandable, if not ideal, fine.

Today, Valve announced the same for the Vive, which again, isn’t great. Though at least Valve have indicated that they will eventually support it, while Oculus’ statements have been less clear on that point.

In any case, I’ve always wanted to bring Dungeon Survival and especially its VR support to Linux, and even Mac, despite my not regularly using the former, and never using the latter. It’s been hard sticking with that, but I will continue to do so. Unfortunately, for the moment this means that Dungeon Survival won’t support VR on Linux for the Rift or Vive, though hopefully it will support OSVR on Linux. Completely weird.

Mac support is and always has been more nebulous just due to the fact that Mac OpenGL drivers are…not so lovely.

I would like to ultimately have full support on all three major PC platforms, and will try to maintain that goal, even if it means support is delayed for a while.

Making (optional) Hardcore/Perma-Death Modes Fun

“Let me sing you the song of my people.” – Death

Hardcore or permanent (perma)-death modes are an interesting dilemma. On one hand, they absolutely do amp up the tension of most games in a very noticeable way. Many players will become hyper-vigilant, or think of extremely creative ways that a designer never conceived in order to solve challenges. Perma-death is also incredibly frustrating.

Although perma-death is almost universally considered a frustrating mechanic, it clearly exists/existed in games, and is desired by at least a small group of players as a game mechanic. I know that for myself, that immediately makes me wonder why, other than the obvious frustration issue, perma-death died out.

I think the answer comes down to a dichotomy of how interesting in gameplay terms the death is compared to how frustrating it is to start over. If the former can clearly and cleanly overcome the latter, perma-death becomes a compelling mechanic (for some people, at least). One example of this is seen in old school dungeon crawler and roguelike games that had such modes: leaving behind your character and all his stuff and allowing the player to find it with a new character.

This is but one method, but it’s a core one to the concept of perma-death. It creates a sense of permanence of the world. It’s not a world of heroes that revolves around a single earth-shattering protagonist, it’s a brutal, grey and drudgery filled death trap, where the slightest misstep can spell your doom. It also means that the world can go on without your character. The story doesn’t end because they died on dungeon level 25, the game doesn’t force you to reload a save or checkpoint. That character is simply dead, lying on dungeon level 25, their bones being picked clean, loot forgotten….

Until their outraged sibling/wife/offspring/relation comes hunting for the family heirlooms and a big helping of revenge.

So if you’re considering adding perma-death to your game as an optional mode, strive to make it more interesting than frustrating, and use it to make the world more alive.

Book Review: Designing Virtual Worlds

The quote by Richard Bartle from this article is great, and an example can be seen in the choices made by World of Warcraft’s designers (as well as those that chose to blindly copy WoW itself) when they decided to clone Everquest, but didn’t understand the decisions of Everquest’s designers, and why Verant created MUD-like combat in the first place. Verant’s goal, after all, was to create (one of) the first graphical MUDs, and they did that admirably.

Back then, most people would have scoffed if you told them that graphical MMOs for the next 15 years would simply copy-forward the MUD-style serial hotbar combat without any real though to the reasons why such combat existed.

The stagnation of combat in modern MMOs for the past decade can at least partially be attributed to this lack of insight, or lack of desire on the part of the designers to even attempt such introspection.

And for those that might exclaim, “But wait! Hotbar graphical MUD style combat has been copied so often only due to insurmountable technical limitations of bandwidth, latency and processing power.” To this, I point to Planetside, released in 2004, a mere one year after WoW, which features real time FPS style combat on an MMO scale. MUD-style hotbar combat hasn’t been necessary for at least that long.


It has been over a year since my last review of a vintage virtual reality book. I’ve recently come across a good one that I’d like to share.

In 1978, Richard Bartle co-authored MUD, the very first virtual world. In 2003, he shared his twenty-five years of virtual world and MMORPG experience in the book Designing Virtual Worlds. Here are some excerpts from the preface:

Too much virtual world design is derivative. Designers take one or more existing systems as foundations on which to build, sparing little thought as to why these earlier worlds were constructed the way they were.

Are designers even aware that there are decisions they can unmake? Although a good deal of design is evolutionary, that does not mean designers can’t be revolutionary, too.

The key is in recognizing the face that what seems eminently logical to you from your usual perspective might turn…

View original post 753 more words

FATED and the Quest for Optimized VR



Hi everyone!

With Oculus’s recent announcement regarding requirements and specs for the consumer version of their HMD (https://www.oculus.com/blog/powering-the-rift/), I figured it was the perfect time to write that performance bit I teased about the last time around. Let’s see how we’re dealing with optimization on FATED! First, some math to have a clear vision of what we’re trying to achieve.

Know Your Numbers!

FATED is pretty much fillrate bound (http://en.wikipedia.org/wiki/Fillrate), and it’s safe to assume that most early VR games will also be. This is why the following info is important.

A current generation game will generally push about 124 million pixels per second when running at 60 fps in 1080p. FATED is currently running on a GTX 970 (the recommended card for the consumer version of the Oculus) at ~305 million pixels per second.

1920X1080 upscaled by 140% = 2688X1512 * 75(Hz) = ~305…

View original post 912 more words

Progress Update Since Last Time

Dungeon Survival has progressed a lot since the last update. No screenshots currently, but I would like to describe some of the features I’ve completed.

  • Procedural dungeons!
  • Zombies with animation (attacks, laying, sitting, hits etc) and AI, and swarm avoidance using detour and recast. Zombies wander and will detect and chase players, and attack when close enough.
  • Upgraded to UE 4.7.6.
  • Added several traps, as well as ragdoll assets for the player and zombies, and code to ragdoll on death.
  • Early melee animations

Motion controls for the arms/hands are working great with the Rift, and I’m eager to put in Vive/SteamVR support. The game is naturally suited to moving around a room, and I have some ideas for handling long distance locomotion.

Being able to bend over to reach items on the ground is already amazing, but I’m quite limited by the Razer Hydras I currently support.

More work is going into levels and traps, as well as some additional enemies to add to the rats and zombies. Eventually a character creator is going in.

I’ve also found and plan to implement physics rope bridges, and a system for detecting player breathing which will translate into character breath in game.

Despite infrequent posts here, development continues to progress at a good clip. I’m currently waiting on certain art assets to become available before the next level design phase takes place.

Unreal Engine 4 – Snow Material with Tessellation

Awesome dynamic snow material, with tessellation – great for VR.


So after my previous post on creating a snow material, I decided to immediately continue with it and implement the tessellation. The tutorial I was following isn’t complete in terms of showing how to implement the tessellation realistically, which meant I was going to have to do some of it on my own, which is good as it has taught me a little bit how the material editor works.

The following screen shot shows a few assets from the Unreal Engine 4 with the material applied. You can also see the different levels of snow, as well as the tessellation and different textures. The way the material works is, once the snow amount reaches a certain number, in this case 2, the tessellation begins. Increasing the snow amount also increases the tessellation, and is best used with a subtle amount of tessellation as that provides the most realistic look. In…

View original post 59 more words

How to remove the FOV-reducing vignette from Unreal Engine 4.5 w/ Oculus SDK 0.4.3 support

Update: Oculus confirms the overly large vignette is unintended.

Oculus recently released the updated 0.4.3 SDK and Runtime. There are some good and some bad things with this release.

Good first, is the ~0ms post-present latency, resulting in (timewarped) latency of about 5ms – sweet.

The bad, from my perspective at least, is the huge vignette added to the edges of the image. This obscures a lot of the rendered pixels on all four borders of each eye. The DK2 has slightly less horizontal FOV than the DK1 already, so we need to maintain what FOV is there, and this vignette does the opposite.

In an effort to keep Dungeon Survival up to date with the latest and greatest, I grabbed the Oculus fork of UE4.5 w/ 0.4.3 SDK support and took a look to see if the vignette could easily be disabled – it appears so (engine is currently compiling so I can’t test yet, but it should work).

First, (fork, then) clone Oculus’ branch of Unreal 4.5 (requires UE subscription).

Make sure to get the required 1 and 2 zip files and extract them after the clone has completed. Edit: Also don’t forget the Oculus require zip! It’s labelled “Link1” in their Github readme. If you get a linker error for GetEyePoses, this is the cause.

Generate projects with the batch file in the engine root directory, then open the solution, and find this file and line below (if you can’t find it, search “ovrDistortionCap_Vignette”).

File: Engine\Plugins\Runtime\OculusRift\Source\OculusRift\Private\OculusRiftHMD.cpp
Line: 1817

Change this:

DistortionCaps = SupportedDistortionCaps & (ovrDistortionCap_Chromatic | ovrDistortionCap_TimeWarp | ovrDistortionCap_VignetteovrDistortionCap_Overdrive);

To this:

 DistortionCaps = SupportedDistortionCaps & (ovrDistortionCap_Chromatic | ovrDistortionCap_TimeWarp | /*ovrDistortionCap_Vignette |*/ ovrDistortionCap_Overdrive);

Build the engine to update the Oculus plugin and it should now have the same vignette as 0.4.2 SDK.

Lots of Progress on Dungeon Survival

Where Dungeon Survival is at Now

Now that Storyteller is on Oculus Share, and basically “complete” as a demo aside from a couple of poorly chosen audio files (The Shadow Over Innsmouth is the main offender as seen in the Let’s Play by Rift Arcade), I’ve been working on getting Dungeon Survival up to speed and compatible with the Rift.

Careful readers of the blog will probably have realized that the Razer Hydra tutorial I posted earlier is an indicator of my own progress implementing the Hydra into Dungeon Survival.

Right now it does in fact work pretty well, though work customizing controls for the Hydra and being able to move the hands has only just begun. There are a number of improvements to be made in rotation of the fingers, hand and arm segments to get a more natural rotation. Right now the wrist is simply set to the full rotation, while distributing some rotation into the fingers and upper arm and forearm will not only look a lot more natural, but will also prevent skinning problems that are apparent now.

I’ve also switched the project to use UE 4.5 (up from 4.3.1 w/ 0.4.2 OVR SDK support). As part of that switch I’ve decided to go with some lighting changes. Among other things, the lighting is now dynamic rather than baked. This change was primarily to support modular generation of levels, which is something I only recently decided to do (though I’ve always had a hybrid approach in mind). As part of this, I’ve improved the look of the game’s lighting significantly.

Rats now take damage from oil slicks that are on fire (in addition to impact damage – e.g., getting a barrel rolled over them). They also light on fire, and when lit can light other sources of fuel (currently oil slicks). When on fire, rats’ aggression goes down and cowardice goes up (so they run away).

I created and then abandoned a system for picking up DestructibleActors, but in the end it didn’t work as well as I’d hoped. I’d like to revisit it later as it was sorta-close to working out, but a nightmare to debug.

As a compromise, I now simply use a regular physics item that takes damage and can spawn a destructible and break it. This should also network more accurately, and was something I’d wanted to do anyway. For the oil barrel, it’s functionally the same as being able to pick up the destructible actor directly. Additionally it gives the designer a lot more control over explicitly when it will break. Best of all it works.

On top of that, I’ve ported many features of the VR Game Template into my controller and have those set up (so RIft support functions right). I’ve optimized the project so that I can get a solid 75fps locked in the Rift as well.

I’ve spent some time getting body leaning and head rotation based on the DK2, but it’s not quite working 100% as well as I’d like.

The Future of the Game

A gameplay teaser, and eventually a demo. Once DK2-based leaning is working, I’m going to spend some time on the inventory system (right now you can only have the two items in your hands), implementing more items – including weapons, food and drink, traps, and finally level pieces for the random generation system. Then I’ll spend a bit of time polishing some aspects, like the cooking/fire system, so that things like materials will change appropriately (right now there’s no “burnt” state).

Basic crafting of cookfires and torches will also probably go in prior to the demo release, as well as at least one more enemy.

Storyteller: Fireside Tales Beta 1 Update – DK2 Tested for Better Performance and Overall Experience

Storyteller: Fireside Tales is an immersive VR audiobook player.

Storyteller: Fireside Tales is an immersive VR audiobook player.

Download: Storyteller: Fireside Tales – Beta 1 Build (IndieDB)
Download: Storyteller: Fireside Tales – Beta 1 Build (Mediafire Mirror)


Updates/New Features – Beta 1

  • Changed level layout significantly to put more interesting things into the near field (player now sits close to the storyteller).
  • Increased exp height fog.
  • Enhanced lighting greatly to give a lot more variation in color palette, for a brighter but still cave-like feel.
  • Added particle light to campfire.
  • Fixed menu system (hit Escape to bring up the menu).
  • Changed bookmark keybind to Numpad 0, and changed Enter and R to also reset HMD orientation/position (in addition to the normal F1).
  • Changed interact time on books to be 2.5s – many users were having issues at 4s. Look at a book to select.
  • Fixed many performance issues.

Keybinds/How to Use
F1/Enter/R – Reset HMD (for Oculus Rift)
Spacebar – Pause/Play current book
Numpad 0 – Create bookmark at current time. Note: This does not currently save per-book. So you could do weird things like make a bookmark that’s greater than duration of the audio. I don’t really need bug reports for this case – I know it’s there.
Right/Up Arrows – Cycle bookmarks. This will skip to the first bookmark, and so on, until it loops bookmarks.
Escape – Opens or closes the floating books menu (you can exit from the menu, just hover over the book in the center column, bottom row).

When I released the alpha for Storyteller, I did not yet have my Oculus Rift DK2 in hand to test it on, and so was just going off of impressions. When I finally did receive the Rift and tried the demo out, it was a smeary black mess. The OLED panel the Rift (DK2) has comes with an issue with pure-black areas and the border regions between them and colors which aren’t entirely black, which causes the black areas to smear outwards.

The menu system didn’t work unless you were looking 45 degrees to the left of the actual spot, which wasn’t what was happening on monitor, of course.

Performance was also a dog, for various reasons that I’ll go into and that have helped Dungeon Survival go from 50fps in a very small scene to being fast enough to play on the DK2 with no judder at all.

In addition to all that I went through and rearranged the level slightly so that you’re sitting closer to the creepy storyteller hermit, as before it was far enough out that you didn’t have anything interesting in the near field to actually look at. Now you can get a nice view of the distant sky, including circling birds. Fog has also been increased some.

I wanted to include light rays but it unfortunately does not work correctly in stereo.

As to the performance issue, many things were set to cast shadows, have gravity, have collision etc., all of which combined to be tanking down the performance.


In Dungeon Survival news, I’ve combed through the project and fixed those same issues which were affecting Storyteller’s performance.

Recently I’ve been experimenting with getting the destructible oil barrel integrated with the normal pickup/throw system, though it appears it will require more work to function totally correctly.

In the mean time I’ll be hooking up the Razer Hydras for hand control.

Now that Storyteller has a proper demo I feel I can dedicate more time to working on Dungeon Survival.

Comic Book Reader Progress – Now 100% Multi-Threaded

Loading Images from Disk in Unreal Engine 4

So over the past week I’ve been doing a lot of work on getting the pieces ready for my VR Comic Book Reader. 

I found a great resource by UE4 forums user Ehamloptiran for loading an image from disk into a texture at game-time. A user on Reddit requested I put together a simple plugin example, which you can find here: TextureFromDisk Plugin for Unreal Engine 4. Also available as part of user Rama’s Blueprint node library.

Unfortunately, that code does not handle anything but DDS images – so I had some more work and investigation to do. After a lot of searching the engine code, and in particular the bits that are responsible for importing textures, I found the ImageWrapper class.

ImageWrapper, as the name implies, wraps up the functionality of specific image formats for easy loading. As such, you simply pass in what format your image is in, and call SetCompressed, passing in your image data. Then you can call GetRaw to get raw, uncompressed color data out.

After that, it’s simply a matter of copying the raw data into the UTexture2D’s mip map data. For my purposes, I only ever use a single mip.

Reading Zip Files

That done, I moved on to the hard part of this whole endeavor (or so I thought at the time), namely reading zip files and extracting out the files contained therein.

For those not familiar with the CBZ file format, or comic readers in general, CBZ (and other file formats like CBR) are just regular archive formats, with the last letter specifying what type of archive is used. CBZ is Comic Book Zip, CBR is Comic Book RAR.

These zip/rar files have a sequential (numbered with leading zeros 001 instead of 1 or 01) set of images which make up the comic book.

I had a heck of a time finding a liberally licensed, simple zip reading library. After a couple of false starts with miniz – C Zip Reading Library, and I managed to find JUnzip, a much simpler (though less fully featured) implementation.

Both libraries use ZLIB to inflate the compressed data, which I found acceptable mostly because Unreal 4 already compiles against ZLIB.

Miniz was almost right for my purposes, but I quickly found out that UE4 does not like it when you try and include standard code, such as a standard memcpy, inside the engine. Because miniz supports a decent amount of the functionality of zip archives, it was a bit too complex to quickly port to using the UE4 API functions for reading files etc.

I switched over to JUnzip, which has much easier to follow code, and is also on a nice public domain license (well, lack of license). 

I was able to quickly go through JUnzip, rip out the standard file operations (fopen, fseek, ftell etc.) and replace them with UE4’s versions of same. 

Problems were had. It turns out, __attribute__ (_packed_) was actually quite important in JUnzip in order to make sure that the structures that define the zip header etc. are the correct size. I had initially removed the __attribute__ (_packed_) declaration on the structures because they are not compatible with Visual Studio. This caused no end of headaches.

Then I realized that if __attribute__ is a compiler feature, VS probably has its own version I could use. Thus I found #pragma pack() and all was well (supposedly, gcc supports the #pragma as of some version or other, so I may not even need to change it later in order to support non-VS compilers). 

That was not to be the end of my odyssey, however.

It Hurts When I Pee…er… It Hangs When I Load

Zip file and jpg texture loading works, at this point. Unfortunately, it also blocks the main game thread and hangs the game until done. While that might work okay for files that can be loaded one time at start up, it obviously won’t work out well for comic books, since you presumably want to be able to switch what you’re reading on the fly.

That meant I needed to thread away the zip file reads. Luckily UE4 comes with a nice handy asynchronous IO system built in: FIOSystem. 

To fire off an async read, you simply get the singleton FIOSystem with FIOSystem::Get() and then call LoadData on it, like “FIOSystem::Get().LoadData()”. You pass in a file name, offset into the file, a size of bytes to read and a destination buffer.

I couldn’t figure out a clean way to check the status of these requests, so I simply wrote a couple of special bytes to the end of my destination buffer, and then check them in the timer I use to check all the requests. If the bytes are not equal to my special values, the buffer is read and can be operated on.

It still wasn’t enough – the decompression was still causing the game thread to block and hang.

Thanks to Rama’s Multi-Threading Tutorial and some digging into FulfillCompressedRead (which is called when you perform an FIOSystem::LoadCompressedData – which unfortunately only works on .PAK files, more on that later), I was able to set up a threaded decompression task. 

After a (compressed with zip) chunk of file data is loaded from the above described process, a thread is fired off which will decompress the data into an output buffer (passed as a pointer in the thread init). Unfortunately, mip map generation for the texture as still hanging the main game thread.

I moved that into the decompression thread and changed to code to generate a texture directly from mip data (memcpy’d in to the mip buffer, rather than copied byte by byte) and it works! Finally, zero-hitching texture loading from a zip file on disk, during game time (i.e., not restricted to editor-only).

There remained a bug in that the blueprint library which exposes these calls for getting a texture was not cleaning up the cache properly if a game was stopped but the editor wasn’t closed down. That was an easy fix, and I can happily say that it all works.

Now starts the process of extending out my current BP based comic book handling functionality (i.e., get textures, set them, next/prev etc.). 

Native Engine Support?

As I alluded to above, it would actually be only a minor extension for the engine to support compressed reads from zip files, rather than only from pak files. 

In particular, two main things need to happen:

1) FulfillCompressedRead needs to check the file extension, and skip the PAK file header check if the file does not end in .pak. Or there needs to be another parameter for LoadCompressedData in FIOSystem to specify that directly.

2) The async thread class that’s used would need to be extended so it could use the inflate() functions of ZLIB, rather than just simply uncompress().

That’s pretty much it. I may actually take a stab at doing this myself, but for now what I have works okay, so engine level improvements are on the back burner. It would also help if someone from Epic could chime in about how they feel on this sort of extension and whether it actually would fit and make sense or not.


I haven’t had time to get a video, and to be honest it’s not that terribly impressive since it just looks like the texture suddenly is applied to the flat plane there, so I’m just going to show a screenshot I took when it was still hanging the game thread when loading the textures.

VR Comic Book Reader Progress - The cover page of Prophet (2012) loaded into UE4 at runtime.

The cover page of Prophet (2012) loaded into UE4 at runtime.

Storyteller Alpha 0.3 Released – Performance improvement, fixes and environment additions

Storyteller: Fireside Tales is an immersive VR (works on monitor too) audiobook player.

Storyteller: Fireside Tales is an immersive VR (works on monitor too) audiobook player.

Get it here:

Download: Storyteller: Fireside Tales – Alpha 0.3 Build (IndieDB)
Download: Storyteller: Fireside Tales – Alpha 0.3 Build (Mediafire Mirror)


Updates/New Features – 0.3 Alpha

  • Got rid of tesselation on character.
  • Hid character until DK2 arrives for proper leaning/head rotation.
  • Revamped level with less meshes and better/faster geometry
  • Added distant birds
  • Added ambient morning sounds
  • Selecting a book  that is currently already playing will simply pause it now (this is an effect of the below fix).
  • Added batch files for selecting different UE4 options that might be useful for getting extra performance for Oculus Rift users.

Bug Fixes

  • Fixed an issue that would cause weird behavior in the menu system when switching to a different book.

Keybinds/How to Use

F1 – Reset HMD (for Oculus Rift)
Spacebar – Pause/Play current book
Enter – Create bookmark at current time. Note: This does not currently save per-book. So you could do weird things like make a bookmark that’s greater than duration of the audio. I don’t really need bug reports for this case – I know it’s there.
Right/Up Arrows – Cycle bookmarks. This will skip to the first bookmark, and so on, until it loops bookmarks.
Escape – Opens or closes the floating books menu (you can exit from the menu, just hover over the book in the center column, bottom row).

VR Dev Entry 13: UE4 Console Commands List

UE4 Console Commands!

Cymatic Software

Hey Rifters,

Its time to get Unreal, again. Unreal Engine 4 now has an absurdly awesome subscription plan, 20 bucks a month for full access to the engine – including source code. So far, VR compatibility is built in, the Rift is detected automatically when the game is full screen. Nuts.

A couple of useful things about UE4 in my short term playing around with it:

Are you having issues packaging your project for Windows? Perhaps getting an error like

MainFrameActions: Packaging (Windows): RunUAT.bat ERROR: AutomationTool was unable to run successfully. MainFrameActions: Packaging (Windows): BUILD FAILED

Looks like you need to install Visual Studio first:

  • Download and install Visual Studio Express 2013 from here
  • Close and restart UE4
  • Open and Build Project
  • Package Project for Windows

Also, support has not yet listed all the console commands for UE4. You can get them by making your Output Log visible (Window>Output…

View original post 889 more words

Storyteller: Fireside Tales – Alpha 0.2 Build Released



Storyteller: Fireside Tales is an immersive VR (works on monitor too) audiobook player.

Storyteller: Fireside Tales is an immersive VR (works on monitor too) audiobook player.





Yesterday was a long day – I spent essentially every moment from arriving home from work until the time I went to sleep at 6:30AM working on improving the build for Storyteller. 

Here’s the download, if you just want that (bug fix and new feature list below)

Download: Storyteller: Fireside Tales – Alpha 0.2 Build 

Updates/New Features

  • Added tesselation to the player body and head – I don’t know if this is really doing much since the model isn’t really set up for it, so let me know your feedback, as it’s a ~10-15 FPS hit over turning it off. I can also turn it down more, as it’s on pretty high right now.
  • Added some dripping effects for the puddles, as well as sounds. I tried to make the sounds for the drips low enough that they sound good but are not distracting.
  • Fog!
  • Reflection capture probes. These should make everything look a bit nicer and don’t cost much.

New Menu System

  • Instead of one large book, which had a convoluted method for determining what word was being looked at, I’ve switched to using an array of 9 books floating in front of the player.
  • Text his hidden by default – when you look, it appears and starts to (smoothly – I hated that ticking fade in the first build) fade to the activation/highlight color from the default color.
  • The activation time is now 4s. With the smoother fade between colors, I felt this time was also a nicer feel. Long enough to not accidentally activate something, but shorter than the 5s wait from before.
  • The logic and code behind how the timer for fading works, as well as for activating a book, is far cleaner and more efficient than before. 
  • It’s overall a lot less buggy and feels much nicer to use.

Text shows up when looking at a book.

Text shows up when looking at a book.

A shot of the menu books when nothing is selected.

A shot of the menu books when nothing is selected.

Bug Fixes

Thanks to kind testers on Reddit, I was able to narrow down and quickly fix several issues related to running the game on the Rift. 

  • Resolution was stuck at 1280×720, windowed. This is bad. This kills the Rift.
  • In addition, the build was a Shipping version, which means no console when pressing ~ (tilde key) in order to force it to a different resolution or fullscreen.
  • The build was using a .pak file, which, while it does result in a nice awesome small little package for your game, also makes it a pain to change settings in the (extensive) INI files.
  • An issue with the way the camera was setup was (unbeknownst to me, as I had not had the debug rendering enabled in a while) causing the raycasts for menu selection to be extremely strange, basically causing the beginning point to swing wildly up and down (it was parented to a bone and getting animation, d’oh).

[UPDATE] Storyteller Test Alpha is Live! – New build is being uploaded now

New build is being uploaded now, as there was a major showstopper problem (configuration issue) as well as an annoying bug (menu items would only activate after looking at them once, then looking away, and back if you had used the menu and already activated something).

These issues are now fixed from what I can tell (hard to say with the Rift without having my DK2 to test with – it now runs at 1080p, so at least there’s that). 

I’ve also included Teddy0k’s Scalability Launcher as I seem to get weird performance sometimes with this build when looking at the player’s chopped-off neck (in a newer build I will make it so it limits that for non-Rift users, if there are any hehe). 


I finally have a build packaged and ready. Here’s a bit of an update about why it wasn’t done yesterday:

It took considerably longer than I’d hoped to get a build (I was anticipating yesterday shortly after work). Part of that was finishing up a few remaining issues, adding reverb (it sounds neat! if anyone knows about audio and is willing to help me customize the settings, please let me know), and lots of testing.

The other part of it was me being dense and trying to minimize the assets in the build, pretty much unnecessarily because UE4 handles that when packaging.

Finally, I ran into some goofy issues with the packaging that was causing it to fail (I’m going to be making a blog post with UE4 packaging tips soon).

But after working on it from the time I got home at 5PM to when I finally slogged off to bed at 3AM, the packaged build works.

One thing I’m not sure of is how the resolution will work out – I tried to get it to automatically set to 1920×1080, but it seems like it’s getting some other res from somewhere.

Please let me know if you’re unable to run it at native res so I can get a new build up.

App Link – Storyteller: Fireside Tales ALPHA  – See update above! New build going up soon.

I’m putting this down here rather than with the other links because I want to note that this is mostly untested, especially with the Rift. I don’t have a DK1 and my DK2 order has not arrived.

That said, it should be compatible with Direct to Rift, and is built against the 0.4.1 SDK. I don’t know if timewarp will work out of the box.

I plan to provide a build with the console enabled and without all the config files in a .pak later on today, which will hopefully help testing.

Thanks for your patience everyone, and helping to test! I hope you like it.



  • F1 – Reset HMD (I don’t know if this works)
  • Spacebar – Pause/Play current book (I think it might not default to anything, so if nothing happens when you press Spacebar, select a book on the menu first).
  • Enter – Create bookmark at current time. Note: This does not currently save per-book. So you could do weird things like make a bookmark that’s greater than duration of the audio. I don’t really need bug reports for this case – I know it’s there but can’t fix it until I get home today.
  • Right/Up Arrows – Cycle bookmarks. This will skip to the first bookmark, and so on, until it loops bookmarks.
  • Escape – Opens or closes the menu-book (you can exit from the menu, just hover over the Exit text).

To use the menu, just look at one of the titles or the Close or Exit buttons (Close closes the menu-book, Exit closes the program down completely).

It takes 5s to select an item on the menu book (I’ll be tweaking this). The text will change colors each second to indicate this.

Once an item has been selected in that way, if it’s an audiobook title, it will start playing and the menu-book will close.

Storyteller (immersive VR audiobook player) Quick Update

Got Unreal Engine 4.3.1 with 0.4.1 SDK support built last night, fixed the storyteller’s hair and other materials, and improved the randomized lip syncing so that there are definite pauses.

I also investigated how the Couch Knights setup is done so I can implement that tonight along with Rift camera support. Other than that, fixing the bookmarks/keybinds for commands (pause/play/bookmark), as well as setting up a skip forward/back, and the audiobooks I’ll include with the player, and I’m just about ready to release.

So probably tomorrow, as I’ll be working on the mentioned list of stuff tonight and imagine it will take another night’s work to actually package it up.

Announcing Storyteller: Fireside Tales

Work on Dungeon Survival hasn’t stopped, though I have been taking a bit of a break before I power on into the next development sprint. Right now the project is in a state halfway between prototype gameplay features and more concretely implemented ones, and will require quite a bit of not-so-fun rewriting work to integrate those features that are still in the prototype stage.

During my break, in addition to playing a lot of Mass Effect 3 (never finished it) I’ve also quickly whipped up a demo for an idea I had while listening to an audiobook in the dark while dozing off for a nap.

Storyteller: Fireside Tales

Storyteller is an immersive VR audiobook player. Load up an audiobook (.ogg format only for now) and it will play as if the narrator character were reading to you.

Teaser Screenshot for Storyteller: Fireside Tales

Teaser Screenshot for Storyteller: Fireside Tales

Storyteller will be released with the first environment, Fireside Tales (a hermit’s cave dwelling) sometime this week (with DK1/DK2 support).

The fully-functional demo version, including several public domain audiobooks (H. P. Lovecraft mostly) will be completely free.

For future versions with updated features (multiplayer w/ positional voice chat through Mumble, .mp3 support etc.) and environments will likely be an inexpensive commercial release ($5-10 – with all future updates/environments for free with purchase).

Progress Since Last Time

The Dungeon Survival Project continues to progress…. 

Along with various smaller fixes and tweaks which I don’t remember well enough to go over in detail, this is what I’ve put into the game since the last post on the blog here.

  • Two-handed pickup animation and code setup for the player (to throw barrels)
  • Creating a “flee” state for the AI, so that rats that have been attacking run away faster than the normal walk speed
  • Setting up flee mode so that cowardly/non-aggressive rats will skitter away when the player nears
  • Rats will also jump when Move Tos have failed. This is the same jump code I use to make the rat launch forward at the player when attacking. It works surprisingly well at getting the rats to unstick when they’ve become caught on the navmesh.
  • Throwing or dropping heavy objects on the rats will kill them (this is just a “side effect/emergent gameplay” of the other code I implemented – and illustrates just a little more of my approach to bringing roguelike-esque gameplay into 3D).
  • Rotation and location offset system for pickup actors – this is so that a designer (me) can position a given item relative to the player’s hand in a more pleasing way. 
    Offsets also mirror correctly to the opposite hand.
  • Created two hand pickup animation (not hooked up, though two-hand pickup gameplay functions).
  • Created more pleasing rat-death-pose with separate static mesh, to avoid the corruption issue I mentioned previously that was apparently caused by importing the skeletal mesh as a static (it ended up having the wrong number of collision volumes, would fail an assert and crash).

As a side effect of the if-stuck-then-jump portion of the AI, the cowardly rats get startled and jump into the air before fleeing.

An amusing issue has cropped up with the flee state: due to the rat speed being 4x normal walking speed (to give them the appearance of rapidly running off), they also cause massive impact forces. 

When the rats hit a barrel or other physics obstacle while moving, they send it flying at breakneck speed. 

I witnessed one rat commit rat suicide while I was testing by fleeing away from me head first into a barrel, which rocketed up into one of the walls and then smashed the rat and killed it instantly. 

Of course I’ll be tweaking that down, which was needed to reduce the amount of force the rats push the player with anyway. 

Now that cowardly rats work, and can flee, I’m going to re-enable the randomization of rat behavior (cowardice and aggression). 

Hooking up the rat death animation, putting in some blood effects etc. is the next on my list. After that comes the hunger/starvation/eating portion of the AI.

Unfortunately, despite talking about the player’s kick attack a bunch, I realized I don’t actually have a kick animation like I thought, so that is going on the back burner. I may implement a simple animation that just lerps the leg out into a static pose, but it will look bad.

Finally, I also realized what I need to set in MotionBuilder in order to actually have it save the rotations of bones in a keyframe. That one had me frustrated for a quite a while. 

Things are slowly becoming more fun. Tossing rat corpses around, or chucking a barrel onto an attacking rat, are really fun. 

Optimizing Unreal Engine 4 asset cooking. CRC.

Pablo Zurita posts another in his series of excellent Unreal Engine 4 performance optimization articles.

Pablo Zurita's blog

As I was working on the GPU particle system on Unreal Engine 4, I had to build my own scene. The process of baking the raw assets to be properly consumed by the engine is called “cooking” in Unreal Engine 4’s lingo. I found myself cooking assets quiet often but one thing I noticed was that I found that the cooking process took a while to determine which assets needed to be cooked. The reason I found that was because I would try to cook the assets without actually saving my changes. While this may not seem like a big deal, it is especially annoying for me since I had a pretty bad experience working with the build system at Dreamworks R&D. The build system would take more than 3 minutes to determine that nothing had to be built, and I’m talking about code and not assets. So I decided to…

View original post 736 more words