We’re so sorry for not getting an update out in the last couple of weeks, so to make up for it, we’ll show off quite a lot in this week’s devblog!

Options

Some basic options have been implemented for the game! Things like volume, mouse sensitivity, invert Y, etc are in and functional now. The keybind implementation is still a work in progress, but it shouldn’t take much to finish it up.

Game Over

You can return back to the title screen after you die now. It’ll definitely be expanded, but it’s there for now.

Minimap

Currently, we’re adding some meshes on a separate layer for the camera to render, but for now, a minimap camera has been setup to show the area around you.

Inventory

Another pass has been done on the inventory UI, allowing you to see the description of items and organize it.

Status Effects

Status effects from various sources are now properly displayed below the health of the player.

Cutscenes

Scripted events are working now, allowing us to move the camera around regardless of its position to execute the view required for the event.

A couple of bosses are working now, so here’s a preview of one using the cutscene functionality.

[url=http://imgur.com/zCCUfKG]Cutscene Preview[/url]

Food

You can find delicious and not so delicious food inside the dungeon occasionally now.

Shop

An ominous shop contains a lot of items…

BGM & SFX

Most actions now are tied down to a sound effect, and ambience noise as well as background music will play accordingly to the situations you encounter.

Persistent Progress

We’ve done a small refactor on the player scripts, moving some more stuff into a separate data holder. This allowed us to keep certain items and stats when entering and loading different floors (scenes) in the game. As well, a caching system for pathfinding allows the game to load much faster if the area has been loaded before.

This one’s a bit late, but here’s devblog #8! It isn’t too long though as we’ve been taking care of some paperwork for the company.

Hotkeys

When we first started out, there weren’t that many items to get inside the dungeon, hence, we went with a pretty simple system to just scroll through the items. However, it wasn’t too friendly when we started to get more and more items, and choosing an item became a chore. So, we decided to try out a hotkey system in addition to some sort of inventory, and it seems to be working fine. (WIP UI)

Controller Support

Controllers are partially working now; we know that there’s a lot of different controllers available to plug into your computer though, so we’re developing a keybind system so you can customize the controls to your liking. The only ‘issue’ we have to solve has to do with the UI, therefore we’re going to say yes to controller support for the full release. Disclaimer though, we only have access to PS3/4 & Xbox controllers that we’ve tested with.

Custom Models & Animations

There were some comments about using bought models, and well, we took note of it. We’re not the best 3D artists and animators you’ll find, but we’ve gone and tried our hand at creating some enemies. You’ve probably noticed the blob enemy, that was custom rigged and made, although it’ll likely be changed later. Here’s another model currently finished and animated, about to go inside the engine:

Demos

We’re almost at a point where we’ll need some testing to make sure that the game works fine on your machines, as well as general feedback. A couple of floors are currently being prepared for the demo, and well, once it’s done, the demo will be available for the community to test!

That’s all for this week’s devblog, feel free to leave any comments or feedback!

It was a bit delayed due to Canadian Thanksgiving, but welcome to this week’s devblog! In this week’s article, we’ll explain how the technical aspects of the dungeon creation was done, as well as some other tricks we used to create the structure we have for the game.

Dungeon Generation

When we first set out on this project, we wanted to deliver a fun, interesting experience that gave replayability value without losing level design. Procedural games often use a voxel system to generate the environment, but with that, it doesn’t give a sense of the environment being designed around gameplay. Another challenge we had was introducing progressive story elements into a game that had a procedural structure, so, we’ll be talking about how we developed around these limitations.

To tackle the first part, we decided on room based generation over completely random generation. The difference between the two is connecting a bunch of handcrafted areas together versus defining a floor tile, wall tile, prop tile, and putting them into a configuration based on rules. This puts a bit of a strain on level design, as it requires a lot of rooms to be created for it to feel different, but it’s a small price to pay for better gameplay.

After we chose to go with the room based generation, we made use of DunGen (https://www.assetstore.unity3d.com/en/#!/content/15682).

With DunGen, we decided to go with a dungeon separated into an almost endless (there’s actually a reachable ending) floor structure, which we can continuously add content to. Each floor is given a [Flow] that we define, leaving the majority of the generation to the algorithm but allowing us to input custom events and rooms along the way. By doing this, we can introduce the main storyline through crucial interactions and fights.

Lore is definitely something we want to expand on while the player explores the dungeon, so we created random spawners within the rooms that may spawn lore related things that the player can read. It’ll also take in account the player’s current progression decided by the game, and spawn lore relative to that.

We also extended the same functionality of progression based generation on items and enemies. In addition, we added some options to the spawning system to create enemies based on points we setup previously. It also adds enemies based on the density of enemies after the generation. This ensures that there’s a perfect number of monsters on a floor, and we can increase or decrease that if we ever need to.

One thing that we wanted to have were puzzles that made use of tools available as well as the environment. To “coerce” the player into solving these, we make use of triggers placed inside the rooms for scripted events, where a door may lock behind you, a wall of fire comes creeping up, and other random hazards. As well, we included parameters to each [Archetype] inside DunGen so that only a certain number of puzzle rooms would appear, but the selection would be random as well as the contents. For example, we could have a total of six different puzzle rooms on a floor, but only two would be selected of them all. This would at least give replayability, as well as provide a somewhat different experience for each player.

Scenes & Levels

Miraculously, there’s actually just one scene that’s loaded async over and over again for each dungeon floor! We make use of a database script that grabs references on startup, and we load the appropriate [Flow] when the player transitions onto another floor.

An issue came up with transitioning between floors: how do we preserve the information without a performance cost? To deal with this, we save the random seed when the player moves on from a floor, as well as saving some important aspects and removing them from the [Flow] so they don’t have to repeat the same encounter. Making use of this feature let us to try out a multiset puzzle which required the player to travel between floors, and it’s worked out pretty well.

Optimization on the generation was the next problem to handle. This was the part where the majority of our customization of the generation went. We tweaked the navmesh generation to be faster and run async runtime, so it didn’t slow the game down, but the dungeon generation was still somewhat of a bottleneck. A custom change was making use of a pooling system for the initial generation, then deleting any unused rooms after the generation was finished. It was a boost as whenever the generation failed, it wouldn’t destroy everything and recreate.

General Updates

Bombs are working now on destructible environmental objects!

As well, we’ve implemented some universal behaviours, such as a pressure plate that sends events. Here’s a trap that uses it to pop out spikes.

Thanks for all the support on Steam Greenlight! We’re close to breaking into the top 50, and it wouldn’t have been possible without your encouragement. With determination, we’ve been working on getting more features in, optimizing performance, and getting the game complete.

Environmental Destruction

A feature that we’ve been hesitating to put in was dynamic mesh cutting, due to the lag spike you could experience in the game while it’s calculating it. To get around that, we cut the mesh into pieces before in the editor, save it, and load those deconstructed pieces. This lets us create some unique interactions with the environment, where you could take an object, throw it at a wall, and break it.

Testing on pillars

Also, using the same framework that we’re using for the items, we apply the same logic to those objects, allowing items to drop from things like pots and boxes.

Bombs

To add onto the above, we’re experimenting with bombs inside the dungeon. It seems to be working fine, so we’re tentatively going and starting to create some puzzles based around these placed around.

AI

There was some feedback for the AI not appearing to be good, and we took that into consideration. A couple enemies have very straightforward patterns, so, to ramp up the difficulty, we’re working on some alternative behaviors. By adding a bunch of different options for each enemy archetype, we hope it’ll add to a more exciting experience exploring the dungeon. Also, the enemies now will look at targets of interest! And we’ve added a bit physics based animation, shown below on an enemy we modeled.

Optimization

Our culling solution for rooms is finished! We tried toggling lights on and off, but it didn’t seem to affect the performance too much, so we’re still experimenting with it. An unexpected performance hit was actually in particle systems, and by limiting the active state by view distance, it boosted performance if the procedural generation resulted in too many rooms with particles.

As well, we fixed an issue where placing Terrain objects with rotation enabled would result in upside down Terrains sometimes, which was fun to see, but not fun to play with. We also changed a system to dynamically adjust view distance accordingly – there’s no reason to look 1000 units big in a twisted room of 50 units.

The last notable set of optimizations were done to improve the player experience. We moved the majority of the operations to work async, which means that the game no longer freezes as it creates the dungeon and calculates the navigation mesh.

Floors

Think of a floor like a mini trial – we aim to generate each floor from a large sample of rooms, but it’ll be constructed with a theme and an use of a mechanic to traverse it. This way, we can stagger easier stuff to introduce the player into the game, and easily allow more difficult scenarios to ramp up as progression happens.

Combat

We realized that the combat does need to be upgraded, and we’re taking your feedback into consideration. There was some mention of Dark Messiah, so we’re looking closely at the combat in that game, and trying to apply some of those ideas to Rogue Fantasy. This goes along with the development of the AI, but we’re working hard to deliver a fun experience. One of the things that we’re already toying around with is a shield, and displacements on the enemies to knock them off cliffs and such.

It’s been awhile since our last update, so we’ve got a lot to show off in this devblog!

Arms

We no longer have magical control over all the objects! With a lot of work and a camera setup with some animations, we have animations for all of our actions now. The field of view of the close up camera is different from the field of view of what you can see, and it affects the proportions of the arms and weapon. Animations blend nicely, and locomotion animations are also in as well.

Bow & Arrow

Sword

Potions

Consumables

A bunch of different items have been added in with varying effects, so give them a try with caution!

Crystals

Our current plans for progression include multiple classes and a way to increase your capabilities as you attempt to escape the dungeon that you’re inside. The currency for this is persistent through each playthrough, but there’s a catch: the places where you can gain these upgrades are found inside, and not easily obtained. You never know what may be inside every time you play, so look around carefully!

Weapons

Multiple different weapons each with their own model are found all over the place. From enemies dropping the weapons they wield to shops stocking up, it was a bit overwhelming what to do with each weapon. Hence, we decided to add a durability rating to each weapon, and once it hits zero, it’s broken and unusable. Of course, there are ways to combat this such as stumbling across a blacksmith, or using specific items, but it adds a bit of excitement and planning that we think is nice.

Platforming

Adding a shadow projector helped keep track of where the player was on the platform, and it didn’t affect the performance at all so we kept it.

Fighting

Blocking, attacking, dodging and using the environment – the options for combat by the player increased by quite a bit, and so, the enemy AI was upgraded in response! They’ll act smarter and dodge certain attacks if it’s telegraphed, and their behaviors are different with varying equipment.

That’s it for this week’s devblog – we’re almost done our preparations to put up our greenlight, so please support us if you want to play this game!