This post is mirrored from our site.
After a bit of devlog silence, Devlog 12 finally is here, showing off several new monsters, features, and tools. Development is starting to get up to speed, with more planning and focused goals. If you missed our last devlog, be sure to check it out! And without further ado, let’s begin.
Kimashi
While not implemented into the game just yet, the Kimashi is way too excited to not post about. This creature is formed from wood and vines, with a glowing magical heart.
This is by far my favorite monster so far, and we have some pretty fantastic gameplay ideas for him. He’s planned on being a ranged enemy, with a teleport ability that can be canceled if timed correctly. We also plan on adding Kimashi Hives, which is a very exciting prospect indeed.
Caruntak
This horrifying beast is a high level crocodile-like creature that runs very quickly, and even leaps toward their prey.
Hangback Melee AI
One annoyance of Melee AI is having too many enemies fight the player at once. Before, if there were 10 melee fighters targeting someone, there would be 10 melee fighters attacking their target all at once. This is really gross and not fun at all. The solution was to introduce a well known trick, which I will call the Hangback action.
If you’ve ever watched a Kung Fu movie, you’ll know exactly what this is – even if there are dozens of enemies, only a few will attack at once – the others will simply hang back and look scary.
Not perfect, but surprisingly good for such a simple implementation. I really like how dynamic it is, with different targets flowing in and out. However, this could end up being a bit confusing, so we’ll see. The biggest issue is how npc’s don’t avoid each other, making a sort of mangled mess.
Directional Damage Indicator
To make fighting in first person a little less confusing, I also added a simple directional damage indicator.
Moonsap Mushrooms
wp-block-quote wrote:“Deep within the danger of mire, marshes and monsters, the Wetland holds a great secret – one of the Moonsap. The natives drink it to speak with their gods, but we have other uses for such a commodity. Here, the glowing secretion is worth more than gold, with rich clambering over each other like dogs to get a taste of the sap.”
Mahgo Ki
The first Moonsap Mushrooms have been modeled and added to the game, alongside several other large mushroom varieties. The former’s sap and veins glow magically, and the sap itself is harvestable.
Leveled Systems
To aid in world building, I’ve finally implemented a feature I’ve been wanting to add for years now – the leveled cells. Individual cells are tagged as different levels. Ardenfall’s level cap is 30, and thus cells are leveled 1-30.
By default, NPCs, Containers, and other leveled objects will simply spawn with the level the cell has. Alternatively, the developer can either define an offset (aka cell level + 1) or a set level value.
This not only allows for easy to manage scaling for npc’s, but also has made the next feature a truly useful tool: the leveled list. In a previous post I had shown off the item list graph, which allows for logical item list generation. I’ve finally added a “leveled” node, which picks an input depending on the requester’s (npc, container, player) level.
This allows not only for leveled armor and weapons (being able to add the same list to differently leveled npc’s), but also leveled loot for both npcs and containers.
Starting Location
I’ve finally added systems that allow the player to create a character. Currently, the settings only includes race, gender, and stats. Later on I will implement body changes (skin/hair color, etc), as well as other role-play features. For now though, it does the job!
Animation Tool Window [Technical]
One major annoyance in the Unity pipeline was animation clip authoring – specifically, event management. Events are handled with string ID’s, and a handful of pluggable value types. The problem is, this means you have to memorize all of the events incorporated in the engine, as well as have heavy restrictions on what you can even do.
Enter the Animation Tool Window. This tool will completely replace the animation object editor, and will allow animation clip management, as well as event addition and authoring. It’s still in its infancy, but I have very high hopes for this project. Even better, the visual tool will allow us to add gizmos, or whatever else we wish. This is fantastic for attacking events and such!!
Foliage System v2 [Technical]
After a lot of consideration, I decided to implement a complete replacement for the current foliage system, choosing to drop my personal foliage renderer for GPU Instancer, which acts as the renderer on top of my own editor. Currently this only supports trees, but I’d like it to support grass and details as well, finally releasing me from the shackles of unity details.
The new foliage system decreases framerate, but most importantly heavily decreases vertex count during a render. It only took a few days to implement, and it forced me to build better painter tools as well, so it’s a win-win!
Breaking the Game [Technical]
As I’ve mentioned in other posts, I’ve been working on getting interiors, which are by far the most computationally expensive component of the game, optimized enough to even be used in small numbers. I generally met my goal, however I wondered if my optimizations would scale to say… a city. And thus, I threw together a “city” of dozens of houses, and compared the stats of lights enabled versus using my light culling feature:
In this test, I got over 5000 batches with the light culler disabled, and 250 batches with it enabled. A massive, massive improvement! It also removed 2 million tris, although the optimized value is still quite high, being at 1 million. This is mostly due to shadows, so I’m unsure if I’ll be able to whittle this down much.
This test did not include many trees, which a lot of cities will have – a fully forested area is rather expensive, costing around 10 fps. However, with the new foliage system it helps a lot.
In short, we’re on the right track. Naturally, a city would most likely not look like this, but have occlusion culling, and have walls separate key areas to reduce visible objects. Regardless, I think there’s a lot more to do in regards for optimizing rendering – nearly all of the framerate is dedicated to rendering, and framerate being 60fps on my machine on max settings isn’t the best.
Memory Solutions [Technical]
One big flaw in Ardenfall’s engine design has been memory management. Mainly, the fact that the entire world is loaded into memory at once. This is due to the prefab chunk system. The easiest solution is the one I’ve decided to take now – for non-debug builds, use scenes instead of generated prefabs. This introduces new problems, such as a lack of stripped chunks, but that could be solved with yet another batcher. And of course the other problem is build times. Luckily I’ve purchased a new CPU recently, which has boosted the build times using scenes from over 3 hours to merely 30 minutes. The latter is definitely a reasonable time for a non-debug build, so I am happy with this.
Thanks Unity
Another issue that has been plaguing me was the issue of some mysterious massive textures in memory. I finally found the problem, with it being how Unity handles grass textures. The temporary solution was to merely shrunk the grass textures down, which dropped the memory usage from around 2gb to less than 1. Not too shabby. Funnily enough, this solution also makes loading the entire world into memory not much of an issue, since nearly all of said memory was actually this grass issue. Nearly all being literally 7 gigs of grass texture atlasses generated by Unity internally, all in memory at once. Absolutely classic. Fixing this also build “boot” times MUCH faster, even in prefab mode.
End Log
And that is that! I hope you enjoyed this Devlog! If you did, be sure to check out our Discord Server, as well as follow our Twitter. I’d love to hear your thoughts on the project!
