Next Revision - Developer’s Log

Not much to report this week. I’ve finished tweaking the models (for the most part, anyway). Now all in-game buildings project a blob texture onto the terrain underneath that tints the terrain, in essence adding ambient occlusion. This improves the overall look of the game as buildings appear to “belong” to the terrain they reside on. I’ve also tweaked all building textures, reducing overly bright areas, changing the hue, desaturating stone walls, redoing normal maps, ambient occlusion, and in some cases — changing parts of the models themselves. All in all, I’ve spent a considerable amount of time being an artist for a while. It was enjoyable, sure — but now it’s time to get back to what I like more. The code!

What’s Phil doing? I have no idea. He hasn’t been online all week. He did add fire and smoke emitters to the forge though. I guess that’s something.

Slacker.

I’m quite the procrastinator. I finally got to point where I can work on proper combat mechanics, AI, equipment, and other fun stuff, and yet here I am, spending my weeks tweaking models. Sigh.

On one hand I’ve added proper support for ambient occlusion maps to R5’s deferred process, allowing AO to come from baked textures rather than from SSAO. On another hand I’ve wasted a couple of days playing with 3ds Max and Photoshop, tweaking things here and there rather than doing something useful. The 3 models I was working on back and forth for the last couple of days do look better as a result, but looking back at the pictures from the beginning of this month I find myself wondering: what was the point of all that? All this effort I’m putting into adding occlusion and greater detail to buildings is pointless. The game will succeed or fail based on gameplay, not on a slightly sharper looking art.

Bah.

Moving on to Phil, he has continued his work on building placement logic, and recently spent some time adding particle emitters to some things, such as the tent camp. Now the camp has a proper campfire, although the smoke emitter still needs work. Slow week.

Once I finish tweaking these buildings (I have to finish what I start! >_<), I’m likely going to be working on walls — art at first, which includes figuring out the system for how each piece will connect to one another, followed by actual prototype models.

The village of Birchwood has been a peaceful farming and mining community nestled in a densely forested valley on the edge of the Renaida province, a good 70 miles away from the closest neighbouring town. It was a frontier settlement, established a couple of years ago when brave pioneers were making their bold ventures into the wilds in search of riches, fame and fortune. Although it was situated dangerously close to the untamed lands crawling with orcs, goblins and other manner of unsavory wild life, the residents of Birchwood enjoyed a rather quiet and peaceful life in their own slice of beautiful countryside they readily called home.

There wasn’t a whole lot to do in the town. The trade with the neighbouring settlements has been on the wane since the autumn’s arrival, and with the unseasonally warm weather holding steady for nearly two weeks the residents spent more time enjoying the outdoors than preparing for the inevitable winter.

The town had everything the people needed. An unusually large town hall often doubled as an inn with more than enough rooms to go around. With the surrounding forest teeming with wildlife the town’s lone farm was more than enough to keep the people well fed, and the blacksmith was supplying the town all the hunting and mining tools they needed. Not that there was much use for the latter, this time of year, of course. It is no wonder then that the miners were often found sleeping under the trees next to the town’s mine in the south rather than working in the dark and stuffy tunnels below.

All was well… until the orcs came.

The townspeople were caught completely by surprise. Why now? What provoked them? The town had no defenses. No barracks, no walls… Just the hastily assembled militia which was hardly a match for the coming onslaught. That’s not to say that they didn’t put up a fight though — far from it. It was their home, after all. It had to be defended, and damned be the odds!

It was not a pretty sight. Screams pierced the air. Chaos broke out within minutes and everyone was left to fend for themselves.

A few tried to form some semblance of organized defense only to be cut down. Some tried to run.

The miners seemed more surprised to be waken from their mid-day slumber than they were to see the orcs. They were the last to fall.

The town seemed lost…

<To be continued…>

I recently came into posession of a nice texture pack (thanks to Rich!) and figured I’d put on my texture artist hat and see what photoshopped combinations of those textures I can come up with that would look nice on DotC’s terrain. Different climates? With terrain textures like these — no problem!

Those of you who pre-ordered the game, the latest build is up that includes the new textures. You can find them in the Resources/Textures/Terrain folder. Feel free to tweak them, replace them, or even create your own for a custom texture pack that you want to play with.

So I’ve added combat to DotC this weekend. Hm. Surprisingly enough it only took one day. It certainly does me wonder what I would be able to do with DotC if it was my full-time project and I had more than 10% of my time to spend on it… But in any case — combat!

Orcs and peasants will now fight each other. All NPCs maintain an aggro list and will switch targets if one exceeds a certian threshold. They also periodically scan the near vicinity for enemies and when one is found, it’s placed on the aggro list. The NPC will then run up to the enemy and start attacking. There is no “lose aggro” mechanic right now (well, there is, but it’s commented out), so the NPCs currently chase their targets forever. Stats are currently not implemented (strength, constitution, and such) — but health, attack speed, weapon damage, armor mitigation, as well as offense / defense skills all work fine. Health regeneration is working well — it kicks in 5 seconds after the combat ends. Combat experience gain is also working perfectly, and scales with the difficulty (easy targets give less experience, difficult targets — more). Experience scales with grouping in mind and gives an appropriate bonus that makes taking on more challenging encounters as a group more desireable, but not overly so. I’ve coded it all in with a future RPG / MMO in mind, although I have zero plans (or time) for either. Good to have the mechanics in place though, isn’t it?

Speaking of mechanics — experience is a bit different in DotC than typical games, mainly because there simply isn’t any. All skills in DotC will be improved by using them, including combat. What this means is that each time an NPC gets hit, its defense gets improved. Likewise each time the NPC attacks something, its offensive skill gets a slight boost. Win enough fights and the NPC becomes noticeably more powerful than others of its kind. I’ve had a lot of fun with this system earlier and kept spawning peasants and orcs until I managed to get one orc’s skills so high that he was able to take on 3 peasants at once and still won. Fun stuff!

Now, on the client side there is still work to be done. Scrolling combat text works just fine, showing all incoming and outgoing damage as well as dodge / blocks. The NPCs also visibly attack each other and play appropriate dodge/block/hit animations as needed. That’s all just peachy. What I’m not quite content with is the fighting distance. Since I don’t visibly move NPCs closer to each other they are essentially swinging at the empty air in front of their opponent — and that’s something I really need to improve one way or another.

But hey, good start, I would say.

On Phil’s side of things, he’s been working on building placement and managed to get placeable buildings into the game complete with the smooth placement and rotation logic. Actual placement validation is not yet in, but seeing buildings in-game was almost as satisfying as levelling my orc on those poor hapless peasants.

Almost.

With shadows out of the way my focus has once again shifted fully to Defense of the Citadel. Ghislain finished a second creature recently — an orc, and although he came fully rigged and animated, I chose to redo the process. Not that Ghislain’s work was bad, mind you — quite the opposite, but I felt I could come up with something that would be more tailored toward R5.

R5’s animation system is a bit different than most engine’s. Take Unity, for instance. You drag in an FBX exported at 25 frames per second and it imports it as-is. In order to speed up or slow down the animations you would have to adjust the animations themselves prior to export. (Edit: Neil clarified that you can indeed adjust animation clip’s play speed in Unity) All interpolations between keyframes are also linear-based — which is not noticeable when the framerate is so high. This is how most game engines do things, and it’s not surprising that pretty much all artists are trained to go down that path.

It’s all fine and dandy, and R5 supports all that just fine, with an added benefit of being able to easily slow down or speed up any animation clip at will. But where’s the challenge in that? Sure, anyone can create a 600+ frame animation, but doing more with less has always been the way of R5. Where R5’s animation system truly shines is its ability to create silky-smooth animations with only a couple keyframes by using spline-based keyframe interpolation. The peasant model was an example of that in the past, and it’s exactly that biped that I chose to use for the orc.

With all the standard animations already present (walk, run, several idles, attacks, etc), all I had to do was re-rig the orc with that biped (rigging was done in Blender, but I work with 3ds Max), then adjust individual animations in order to make them more… orc-ish. Somehow along the road I ended up patching the mesh itself here and there, adding triangles here, re-triangulating polygons there… One night turned into two, then three… 5 days later I was content with the result.

72 frames of animation in total that contain: looping idle, 5 active idles, walk, run, enter combat, combat idle, leave combat, 4 different attacks, dodge, block, hit, death, and 2 poses affecting hands (holding a weapon, holding a torch). 21 animations, 72 frames, and the animations feel more fluid than what was accomplished with 10 times the number keyframes.

One last neat feature. I didn’t want to modify all 72 frames to make them “orc-ish”. I instead took the first frame (starting idle) and modified it with how it would be if I was animating a hunched-over muscled orc rather than a skinny peasant, saving it as the very last frame. I then simply calculate the difference between the first frame and the last frame when loading the skeleton and apply this difference to each keyframe. End result? Hunched-over orc with no additional work.

Work smart, not hard, right?

Final model, rigged and animated, with armor pieces all being attachable objects using a separate texture I created, complete with a color mask that allows the material color to only affect a part of the texture rather than the whole.

It seems that this past weekend has proven to be quite productive. After making heavy use of my whiteboard I’ve managed to figure out everything I wasn’t quite understanding about PSSMs (which was mainly just how to form a crop matrix properly). With that checkbox marked I was able to implement them in R5 easily enough. The shadow quality gain in DotC was quite impressive, to say the least.

The terrain in DotC is now also drawn using a new class — ModelInstanceGroup. As the name hints, this object allows grouping of similar model instances that belong to it. What this means is that if you have 100 rocks in the scene all using the same material, but not necessarily the same mesh, you can add them as children of a ModelInstanceGroup, and they will be automatically merged into a single mesh, thus reducing your draw calls from 100 to  just 1. The only tricky thing about this is that ModelInstanceGroup only merges models that have 1 limb (meaning simple objects), and those objects have to be static as far as the scene is concerned — meaning they shouldn’t be moved outside the shader. On the bright side it is also capable of octree partitioning, and will happily split up your complex scene into a manageable grid of objects.

For those of you who may remember, DotC’s terrain is created out of thousands of small pieces all coming together into a large terrain — but with the ModelInstanceGroup class this terrain is automatically merged into a partitioned octree, thus reducing the number of draw calls by an order of magnitude.

But anyhow, I digress. PSSM is where the shineys are at.

A while back I’ve mentioned that Phil and I got in touch with two artists — work of one of them you’ve seen (Ghislain created the goblin and the weapons), but not the other one’s. The artist I am talking about is Rich DiGiovanni from www.ancientidolstudio.com. He created an entire set of buildings for DotC but I’ve never felt comfortable showing them because, quite frankly, his work was more advanced than the engine could support at the time. His work looked excellent, no question about it, but I always knew that in my heart I could never call it “complete” until I added the one feature to the engine that would truly show off the awesomeness of his work.

I am talking about shadows, of course. Well, lo and behold, Rich’s work:

I really should update this thing more often. You know I’ve been slackin’ when Phil takes initiative and makes a post instead of me…

After a wide assortment of changes to the engine (95% of which were completely unrelated, but nice nonetheless!), I’ve added shadows to the deferred rendering process in addition to the forward rendering. Deferred path has one major advantage over its forward counterpart — there is no need to create new shaders in order to make things visible with shadows enabled. There are plenty of issues I still need to resolve — such as calculating the light’s volume for the frustum correctly, or setting the bias properly, or adding PSSM… but that’s what tomorrow is for, right? Or the day after? Right? Right!

I have to admit though, shadows had an immediate and very pleasing effect on the look of DotC. I will refrain from posting screenshots of it just yet until I resolve most of the “to do” things noted above, but even in its current state the result was a definite “worth it” in terms of effort spent.

Speaking of “worth it”: Red Dead Redemption was awesome, but the ending… Ugh. The ending!! Why, Rockstar, why!?

Blarg. 10 PM. Couch time.

Oh, and before I forget, here are a couple of screenshots of Dev13 drawing into a deferred target with shadows and SSAO enabled.

After three weeks of no posts there isn’t a whole bunch of news to share. I have been able to (with a little debugging help from Mike) get character portraits working properly. The selected object within DotC will now display a preview of itself in the UI. This will allow the player to visibly see the selected object (and eventually the stats for that object). Next for me is working on the UI so the user is able to specify actions for units such as defending, attacking, gathering, etc.

Mike has been spending his time making random changes in the engine (mostly related to the draw process), simplifying it (even if only in his mind). It’s now possible to set up the draw process inside the configuration file without having to modify the code at all, including setting up post-processing effects for deferred rendering. This means, in theory, that modders could change the entire draw process of DotC — switching from deferred rendering to forward rendering for example, without having to change a single line of code. Might be useful in the long run. Next on his list is finally putting in the buildings created by Rich over at www.ancientidolstudio.com into the game. Either that or adding shadows… or both.

In other news, we’ve received a weapon pack from Ghislain comprised of about 50 weapons and added them to a new stand-alone application — the Weapon Viewer. Below are a pair of videos showing what the weapons look like.

Enjoy!