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.

Quick and Dirty Razer Hydra Support in UE4 Blueprint

Edit: To use the calibration feature, stand in a t-pose (arms at shoulder level extended to either side) and press the calibration button (start by default).

It doesn’t matter what pose your character is in during calibration as long as they are generally standing.

Many thanks to Getnamo for his Razer Hydra (info and download) plugin and excellent help figuring out how to set this up (more detail about calculations). I was definitely overcomplicating things.

Copy the Hydra Plugin into your project dir and enable it in the Plugins menus, restart.

Make a new BP derived from HydraPlayerController. I called mine DHydraPlayerController, D being for Dungeon (Survival).

Go to World Settings and set the game mode override settings to use your HydraPlayerController BP you just made.

GameMode Override settings for Hydra player controller.

GameMode Override settings for Hydra player controller.

Event graph for Hydra player controller.

This is in the Hydra player controller. Notice the variables there and the function Calibrate Hydra (I use start, easy to find on the controller). The base offset one is just a static 40 in Z, it doesn’t change. I could use a float but I plan on doing a more thorough calibration step in the future to get more exact mappings, so I’m leaving it as a vector for now. The midpoint we calculate.

Event graph for Hydra player controller.

Event graph for Hydra player controller.

Next comes the Calibrate function, also in the controller:

Calibrate function in Hydra player controller.

Calibrate function in Hydra player controller.

Next we’re going into the character’s animation blueprint

Open your character's animation Blueprint.

Open your character’s animation Blueprint.

First, add these variables

Character anim Blueprint variables.

Character anim Blueprint variables.

Then create this (looks messy but is simple). Pull off the character node to get the controller.

Set positions in the animation Blueprint event graph. Pull from the character node to get the Controller.

Set positions in the animation Blueprint event graph. Pull from the character node to get the Controller.

The last step is to set up something like this in the AnimGraph. Ignore the wiring that goes off screen, it’s just doing a static rotation to fix the default hands for my particular character.

Set up the hand IK using the animation blueprint variables from before.

Set up the hand IK using the animation blueprint variables from before.

I’m using component space for the IK target positions.

I’ll be porting this in a more polished state into the VR Game Templates by Mitch (of Team Metatron).

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. 

Last Night’s Progress

So my Razer Hydra arrived and I spent a little bit of time trying to set it up via Getnamo’s Razer Hydra plugin for UE4, which is awesome! I was able to quickly get it passing values into the game.

The problem lies in transforming the controller position from base-station-relative space to the game’s world space (or the character’s local/component space, even).

After toying with it for a bit I could get it to almost work, but for now I’m setting that aside until Mrob76u, author of the Ultima Underworld VR Remake can share his setup.

I got back to working on the base gameplay and made some decent progress.

Progress towards the gameplay video:

  • Health, damage, and death for the rats
  • Crushing/impact damage for the rats so that the player jumping onto them causes damage
  • Rats spawn a rat corpse item that the player can pickup (and eat), on death
  • Rats take damage from fire
  • Fixed a couple of misc. bugs
  • Fixed throwing force so that throwing a torch is satisfying

Here’s the list of remaining stuff to do from last time, some of which I’ll hopefully get to tonight.

  • Kick attack for the player
  • 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
  • Blood effects on damage for the rat attacks, and also when the rats are damaged
  • Hunger/starvation code and an eating AI for the rats.

Quick Update – Progress Towards Gameplay Demonstration Video

Since the weekend I’ve been making rapid progress on the rat enemy and its AI behavior.

Here’s what was done yesterday:

  • Implemented rat attack routines
  • Set up jump and lunge forward functionality for attack
  • Jump bite animation during attack
  • Cowardice and aggression system – some rats will not attack, or will attack and run away
  • Dealing damage reduces aggression (taking damage will increase cowardice, but that’s not in yet) so that rats do surprise attacks and skitter away

Progress is steady towards the state I’d like it in for the gameplay demonstration video, but there’s still a lot to do, including:

  • Health, damage, and death for the rats
  • Kick attack for the player
  • 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
  • Blood effects on damage for the rat attacks, and also when the rats are damaged
  • Crushing/impact damage for the rats so that the player jumping onto them causes damage
  • Hunger/starvation code and an eating AI for the rats.

Once that list is done, I’ll be moving on to work on expanding the level, adding more items, and some traps. The level and traps work will complete the features I want to have for the video I plan to make.

I estimate 1-3 weeks for those features, depending on setbacks or delays.

As an aside, my Razer Hydra arrived from eBay today, so I’ll be jumping into making that work in the game at some point soon.

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

On Networking Destructibles in UE4

One gameplay mechanic (which will be expanded more as time goes on, into a generic system for flammable items) currently in Dungeon Survival is a destructible barrel ‘filled with’ (spawns) oil.

This uses UE4‘s built in NVIDIA APEX Destruction.

As any UE4 dev that has played around with destructibles will know, the actual destruction event doesn’t network “automatically” in any way – even if damage or collision events are.

That presents a problem.

What happens currently – you can enable movement replication on the destructible actor. This works well (probably not as well over the network), all the way up until the thing breaks, at which point the oil spill is placed in a totally different spot on the client and server.

Now I should point out that technically, my destructible barrel isn’t using the destruction system the “right way”. For something like a barrel which you want to accumulate damage and break, there is a built in impact system. Unfortunately, I was not able to tune that to act how I wanted – a predictable amount of hits to fracture the barrel.

So right now instead the barrel is set to generate hit events. I check to see how strong the hit was, and if it’s over a certain threshold, I apply some damage to the barrel, which is set to fracture if a certain amount of accumulated damage is ever applied.

Because of this particular setup, the way to network it is quite clear – handle not only the damage, but also the fracture event and spawning the oil slick on the server, replicated to the client.

In this fashion the server will determine where exactly the spill is placed, even if the client’s destructible fractured in a slightly different position.

I’ll be updating this post later with screenshots demonstrating the problem, though for now fixing it is a Backlogged task.

Quick Update – I’ll Let Trello Do the Talking


4.3 preview migration. There weren’t too many. First I fixed errors caused by 4.2.1 -> 4.3 preview migration. There weren’t too many.

Trello Task - Then the Inventory Overhaul - it now supports equipping into both hands, and support for defaulting into either as well.

Then the Inventory Overhaul – it now supports equipping into both hands, and support for defaulting into either as well.

Trello Task - Finally I spent the rest of my time unsuccessfully trying to find out why the particle effect for the oil spill does not light up on remote clients. So that's on the plate for today as well.

Finally I spent the rest of my time unsuccessfully trying to find out why the particle effect for the oil spill does not light up on remote clients. So that’s on the plate for today as well.

Porting up to Unreal Engine 4.3 – Setbacks Caused by Boneheadedness

Click image for source! (Credit goes to the artist! Not affiliated with the project - used for blog enhancement purposes)

Facepalm – Whiterun Guard


Progress has been swift but not without setbacks, as with the problems I encountered moving my project from UE4 4.2.1 to 4.3 preview.

I decided to port up to it because it offers some particular functionality I required, namely the On Actor Fracture event.

I use this to figure out when the destructible oil barrel has cracked open, to spawn the oil spill (which as described previously (under Other Stuff That’s Done) – can be lit by throwing a torch onto it, or other on-fire item). There are some other improvements I wanted access to, but that was the reason for switching now.

Unfortunately I made a bonehead move and converted a copy of the project, started working immediately on adding new stuff (torch throwing, barrel breaking spawn oil spill etc.) without actually checking to make sure that everything worked properly otherwise.

It did not.

The plan for last night had been to take a short video of how the gameplay with the oil barrels and throwing torches was shaping up, but instead…

I spent last night debugging the things that were wrong I had missed, mostly related to the item pickup/drop functionality over the network. My plan for today is to finish up going through the 4.2.1 source blueprints and make sure everything is intact and correct.

What seems to have happened is that the conversion didn’t actually get all the blueprint nodes and variables, and in some cases changed the options of other nodes (raycast was set up to show debug, despite debug being off in the 4.2.1 project).

Once everything is back to normal in the 4.3 project, I’ll be working on overhauling the inventory system.

Here’s the Trello task for that:

Inventory Overhaul Task on Trello

Inventory Overhaul Task on Trello

Once that’s all finished, it’s on to setting up the rat enemy and then the AI for it.

Rats! And You, In Dungeon Survival

Rat Swarm by Jay Odjick

Rat Swarm by Jay Odjick – (Not affiliated with the game – just for looks! All credit goes to the artist!)

Rats are usually boring enemies in fantasy and medieval games, used to introduce new players to combat, and hardly intended to inspire terror. The exception is usually some sort of giant rat, but that too has limited scare factor when the players are used to fighting giant-everything (spiders, wasps, bats, etc.) any of which is more creepy than a giant rat.

In Dungeon Survival, I want rats to be the first enemy players encounter, not because they will be pushovers, but because they will have some interesting mechanics that will heighten their fear factor and hopefully, do justice to how creepy a bunch of rats in a dungeon would be.

In this post I’ll be going over two aspects of rats in the game, though the first will be about the player.

The Kick Attack

Your character will feature a few basic unarmed attacks. I’ll be going over the kick attack now.

* Physics based – It will work by having a physics volume follow the animation of the kick on the character.
* When the volume connects, it will impart damage on the hit actor, as well as an impulse. Any object that responds to physics will fly out.
* Enemies that take enough of an impact on this stage will go into ragdoll mode.

Rat Behavior

One thing that almost anyone instinctively fears is disease, and in the case of rats, that means them crawling onto you.

* Rats will be able to crawl up the character.
* Using hand motion controls (or a contextual punch attack – more on that in another post) the player can slap the rats off, but it has to be done with enough (in game) force to actually move them.
* Similar to the kick attack, a strong enough hit will make the rats ragdoll.

In addition to that, rats and other enemies will take impact damage – so a good kick off a ledge can be a one hit kill if done properly.

(Those readers interested in VR will note that the rat climbing behavior outlined above will be particularly creepy in VR. This is by design.)

Might look something like this.

Swarm of Shadow Rats by Christopher Burdett (again - not affiliated with the project, this is just to illustrate what I mean!)

Swarm of Shadow Rats by Christopher Burdett (again – not affiliated with the project, this is just to illustrate what I mean!)

Plans for Early Access, Modding and the Future

In this post I’m going to cover some of the longer term plans for development of the game and also how I’m going to be making it available for players.

First about the demo/early access situation.

In my own game-playing experience, I find that there are quite a few indie games that are either released or in an early access state that are great but don’t offer enough real meat to the experience. To be expected from alpha/early access games, but it is a lamentable situation.

Especially with co-op games, it’s hard to get friends on board to ultimately run out of content and things to do.

One game that I think did a great job handling early access was TaleWorlds’ Mount & Blade (a game I am particularly fond of).

The initial beta release had enough gameplay to keep folks interested and to grow a vibrant community.

However, M&B didn’t really explode past the initial word-of-mouth popularity until that same passionate community figured out how to mod the game by reverse engineering how various aspects of it worked.

A frenzy of activity was spurred by the first modders, and eventually tools to mod the game more heavily were developed by the community. Finally, some months later TaleWorlds released a more feature complete way of modding the game via the module kit.

To this day M&B has a strong modding community and an active player base.

Moving off of the segue…. What does this mean for Dungeon Survival?

As with many indies, the plan for Dungeon Survival is to ultimately launch a Kickstarter to fund the game’s development out through release. Unfortunately though, that doesn’t jive with my desire to get the game into the hands of players as soon as its fun.

Right now development is focused on building out a 3-level dungeon demo which will show off gameplay in a specific way:

* Basic survival gameplay – eating, drinking, using the environment to kill or avoid enemies. This will be on the first level of the dungeon, primarily (and through the 2nd and 3rd, of course, but the 1st level will be focused on those aspects).

* More advanced inventory and environmental interaction, as well as crafting.

* Finally, the third level will focus most heavily on challenges and puzzles that require the player to use the environment to overcome them, as well as a finale boss fight to get to the exit from the third dungeon level to the fourth (which will be the end of the demo).

This demo is what will be shown as part of the Kickstarter campaign, as well as for promotion in general (screenshots, trailer etc.). The game’s art and assets will not be final, and gameplay will not be totally complete. But (hopefully) it will demonstrate what the game is about and be fun.

To that end, my plan is to get:

* Enemies and more environmental gameplay in the game.
* The first dungeon level.
* Some traps.
* More items and gameplay related to items.
* A basic save/load system.

Into the game as rapidly as possible (check out my previous post for info on the current status of the game’s features).

Once those aspects are implemented, I will be getting the first alpha of the demo out to early beta testers for feedback and bug reports.

After a thorough round of testing, the demo will be released for public beta testing. Iteration will continue on that demo, fixing bugs, adding gameplay, and building out the second and third levels of the game.

Once all three levels are in and it’s fun enough to replay for a couple of hours at a time, I’ll be starting up the Kickstarter campaign, and releasing a public demo of all three dungeon levels.

Shorter term I’ll be setting up a page on Indie DB, as well as otherwise promoting the development progress in places that makes sense (Reddit, Unreal forums etc.).

Soon to come in the next few days are video of the current gameplay and some of the first little bit of dungeon level, a sneak-peek of the dungeon level layouts and more.

A Word About Modding

I strongly believe that mods can make or break a game’s success long term, and to that end I plan on supporting both a ton of customization of the game by default, as well as mod support.

Unfortunately, this presents some interesting challenges. Namely, Unreal Engine 4.

As you can imagine, the best way to mod an Unreal Engine 4 game would be to have the engine itself, and the .uassets that make up the game. Unfortunately, there are some legality and practical issues that come into the equation because of this.

For one, as part of the Unreal Engine 4 license agreement, I am unable to ship UE4 editor tools along with my game for modders to use. Nothing unusual about that – after all, they don’t want people using mod tools from a UE4 game to make their own stuff without buying the engine.

Secondly, distributing the game’s assets. There are some issues with this, which I’m not really qualified to speak to. Suffice it to say that there are some restrictions on what can be done.

How do I plan to work around this and support mods for my game?

To start, whereever possible I am going to make the game use plain old data for configuration of items and things like that. So modders will absolutely be able to go in and change values/add new items that utilize the existing gameplay functionality that items will provide.

Most modders should be able to use that to get what they want. It’s when that isn’t enough that things become tricky.

So for those brave modding souls that want to add new interactions and gameplay that are not in the game and supported by the item system already, you’ll need to do essentially 2 things:

* Get an Unreal Engine 4 license – it’s $20, you can get it once and cancel the subscription immediately.

* Download the stuff that makes up Dungeon Survival, or at least, pieces of that stuff.

I don’t think this is too bad, but it’s also not totally ideal. I’d prefer modding tools to be free if possible. Right now I don’t think it’s possible.

However, as mentioned I will support as much modding out of the box as possible, both through in-game options as well as tweaking/adding data through the game files.

The Dungeon Of Death! (and gameplay)

In Dungeon Survival, we must provide a counterpoint at all times to the mundane aspects of survival, maintaining one’s health in an environment of slimy subterranean walls, and avoiding the denizens of such places (or dispatching them with one’s ingenuity).

I am speaking of course of the all encompassing dread reaper: Death!

In other words, the Dungeon Survival project now features death and respawn.

In addition to this, since the last update (which was somewhat out of date) the game has:

Inventory System

This is sort of the basis for much of the game, as most of the objects will be “smart” – with some gameplay associated with how they work or interact with the environment/other objects in an intuitive way. I’ll follow up with a good example of this in a minute.

Items when on the ground are physics objects, much like in the Elder Scrolls series. When picked up, the object is attached to the player’s hand.

Currently, only one item can be carried at a time, not counting the “utility” slot (the right hand – which is at the moment occupied by the torch and isn’t completely hooked into the inventory system). In future, the player will be able to craft pouches which attach to the player and will be able to carry certain amounts of items of their own, depending on size/type.

As with the rest of the game, all of these things are networked for multiplayer – including kicking around physics objects (this may change depending on if it presents problems later) and having it sync to everyone.

When picked up, the item is not destroyed – it is taken into the character’s inventory, and attached directly to the hand (or will be “stored” in pouches if available). This is important because the item system in the game will also be persistent – a half-eaten apple will stay half-eaten even when dropped (and as that example implies, the player does not eat food all-at-once). Items will have persistent state.

The above behavior is for the default item type. All specialized item types derive from this type of item and include its behavior (though in special cases they may override it).

As of yet there is only one specialized type – the food item. Which brings us to…

Hunger and Thirst

First, some rationality for even including what some might consider a micro-management gameplay feature.

I’ll always remember my first few forays into the realm of Nethack, that character-based dungeon crawler with timeless charm and a rich set of gameplay.

In particular was when I first made it to level 3 (this was probably not Nethack itself but a derivative, so forgive inconsistencies, those Nethack aficionados in the audience). I had no food. I was dying of hunger, and a dwarf attacked me.

I dispatched the little fellow with little health left to spare, crawled around a corner and took the only option that remained to me. I ate the dwarf.

I ate his corpse and promptly died from dwarf-poisoning.

For those that don’t know – Nethack and its like feature “permadeath”, meaning you must start over if you die. Instead of being (justifiably, since the 3rd level of the dungeon was the farthest I’d ever progressed) irritated, I was cracking up with laughter.

I loved the fact that I was able to improvise in that way and eat the body of a dwarf I’d slain. And even more that it distinguished poison from normal food.

That’s why I wanted to make the Dungeon Survival project in the first place – to capture the magic of the “emergent gameplay” that roguelikes provide, but with a focus on natural interaction with the environment, and on survival gameplay (with, of course, VR heavily supported).

What’s done:

* Hunger ticks town every 5 seconds (numbers here are subject to change with testing).
* When hunger runs out, the starvation meter kicks in. It ticks down ever 5s as well, but at a different rate (you have more starvation meter than hunger meter, but it depletes in larger chunks).
* When your starvation meter runs out, you start to take damage to your health.
* As mentioned before, food items exist and can replenish your food meter.

Thirst and dehyration work in a similar way, but are not hooked up at the moment to aid in testing (and because I haven’t hooked up any drink items, though that doesn’t take much time).

To come:

* Cooking, and uncooked food causing sickness.
* Starvation and eating too quickly after having starved for a while will also cause sickness.
* Poisoned/contaminated food.
* Dehydration and drinking too much water when dehydrated causing sickness.

Other Stuff That Works Now

In addition to all that, I’ve added:

* A proper blend for the torch hold animation, so that you can right click to sheathe/unsheathe the torch. The character’s arm will smoothly blend up and down.

* An oil slick blueprint, which includes an oil decal, trigger volume and fire effects.
* Code so that if the player walks over an oil slick with his torch out, it will light on fire (and does damage).
* A destructible barrel – damage accumulates over time, so that if thrown/hit against stuff enough it will shatter.
* An oil barrel version that spawns an oil slick when it breaks.
* A torch physics item using the inventory system, and the ability to throw the torch via clicking without anything in held in the left hand inventory slot.

This is the sort of “smart object” gameplay I referred to before. Eventually things like the barrel spawning an oil slick, the slick being flammable, and items that have fire lighting the slick up will be generalized so that items will simply be able to specify what types of smart gameplay they use (by both deriving from special item types and settings in those types).

The basis for this system is already in place, and is how the food items work – but currently the torch and barrel do not use the system (that will change).

To come in the short term:

* Thrown torches will light oil slicks on fire.
* Throwing your torch will remove it from your hand,
* Being able to pick up the torch to re-equip it to the utility/right hand slot.
* A two-hand pickup system for picking up things like the barrel (luckily though I’m no animator, I’ve figured out how to build an animation for that and make it work myself).
* Being able to throw two-hand pickup items.
* Kicking/punching physics objects, like the barrel.

After that, I’ll be adding the first enemies to the game (rats!) and building out the first level of the demo dungeon.

Soon I’ll be taking some screenshots and video of the oil barrel gameplay.