We’re verging on the end and so many things are happening, will we finish in time? You decide!

Or don’t, since this rests entirely on our shoulders. As always, if you missed last weeks report you can check that out here. We're also showing our game for a playtest at ACMI! If you're Melbourne based and have time on the 20th of October, come have a look!  Here are the event details.

You can keep up to date with all things Harrowing in the Light over on our Twitter, Instagram or Facebook!

Dev Update - Sam Muller

There’s not a heck of a lot of time left to do all the things! I’m about to reach the stage of the mad and unprecedented motivation, it often comes around at this point in the timeline. Say what you will about crunch (I agree, it is terrible) but if it’s for work that can be done but doesn’t need to be done then I’m going to do my best to get all of it finished.

Oh heck, I’m Sam Muller by the way! My life might be chaos but I can’t have my DevLog losing it’s single semblance of uniformity.

Ironically, I didn’t actually get much done last week. I closed off the last DevLog with the level up shader and that’s about all I got done (and even then I’m not content with it). You see, I was house sitting the entire time and didn’t have direct access to a workstation. Amongst the other work I was doing, Harrowing in the Light got pushed somewhat to the side... In favor of Kiki, a four month old cross between a Labrador and Poodle. Yes, don’t worry, I have a picture:

There’s a doggo in my DevLog!

Now you might be thinking; “What? Sam’s DevLog is going to be less than a thousand words?!” That’s totally understandable. (Un)fortunately, that’ll never happen. I’m striving to get a final push of work in in order to top this up a little more, like a perfectionist bartender who is pouring into a broken glass. If that fails, then I might start to talk about the broader strokes, direction and current state of our (very not) little game. The (absolutely) hilarious hyperlinks and unnecessary metaphors will do the rest…

So how about that level up shader? What’s still wrong with it? Well, this was my initiation into the combination of tailor made shaders and particle systems. As such, I’ve hit one of those seemingly bottomless rabbit holes where I’ve convinced myself that there must be a better way to do things and thus invested too much time figuring it out. ‘Things’ in this context is singular and refers to a fade out effect as the particles move further away from the player.

The answer always seems to be right around the corner. Surely another five minutes wouldn’t hurt? Two hours later, I’m back at square one convinced that the time I’ve spent has made me better equipped to trek on. Besides, if I’ve already spent this long on it, what’s another five minutes? It’s a true case of Gambler’s fallacy. Although not really because this isn’t based on chance. Now that I say that, maybe learning things is entirely based on chance?

Right, yes, the shader! Here it is:

Well. Here it would be if I REMEMBERED TO PUSH! I’ll post an update right here when I get my hands on it…

[UPDATE 11/10 4:46PM]

I also made a neat little range indicator because the previous one was a little blugh. I pulled my inspiration from League of Legends since it’s really simple and effective effect. Again, I’d totally show you buuuut it was also a part of the missed push.

I’ll put it right HERE.

[UPDATE 11/10 4:46PM]

Outside of that, I’ve been working on a bunch of quality of life changes in preparation for the final sprint. Most notably, this neat little feature:

It isn’t super evident in this GIF but being able to click to select a character was definitely a feature that should have been added in on day one. Heck, even our original prototype had it! I guess it was one of those things that just got pushed off to the side. You might also notice that there’s a smöll little action bar below the health now too! One excite!

There are so many little things I’ve made here and there over the past few weeks that I just haven’t had a chance to implement yet. As a result, I’ve been directing the majority of my focus towards this. I REALLY ought to be developing the dynamic enemy attacks but that’s at this weird point of being almost finished, like the last treat on a communal plate. Shame on me if I were to be the one who finishes it (the irony here is that I’m the only one working on it). I’m just not quite ready yet. It reminds of a moment that was in avideo Matt shared discussing the evolution of the XCOM prototype. Specifically this moment (I definitely did not spend more time than I have available in my life trying to find that).

Besides, I made a nice little spreadsheet to keep myself (and Matt) in check!

I reserve right to use the excuse that English is my second language (the clause can be found in last week’s DevLog) because there are definitely a few in there.

Hip, I might just stop spewing (as many) words in your general direction and instead show you a few GIFs of the things I ended up implementing. First off is the health orb! To get this finished I added a layer of foam at the top, a reference to the currently selected character’s health and an animation to adjust it’s fill.

I also did some work on the grenade ability, specifically reworking the indicator and adding a range limit to it. I still need to add a explosion effect and some travel time but it’s (mostly) functional and looks a heck of a lot better than it used to!

Like everything, it could probably still use a little more work but I’m calling it there for the time being, in fear of getting TOO invested.

We’re still not as close with having all the UI in as I would like but I think we’re at point where we know what it’ll look like. As such, I decided to mock up another concept before I started to box out the key features in Unity, you’ll have to excuse the drawing, my pen tablet is not as agreeable as it used to be in it’s younger days:

It’s based entirely of the concepts Simone did last week (which you can find in this DevLog) but I’m trying to focus more on the idea of what the aesthetic quality will be rather than the layout since great UI is typically entirely cohesive. I'm thinking that when the player hovers over the portrait a little window slides up showing all of their stats and abilities.

Okay, fine! I’ll go back to work!

Hoping that everything is AMAZING and with love, always, Sam <3

Dev update - Christopher Smith

With the completion of the conception phase seen in last week's dev log for the boss unit. This week's dev log will be covering the production phase for the mesh of the boss unit that will be featured at the end of the currently constructed vertical slice.

Unlike the other models I have conducted during this project this unit was only going to be featured a single time within the level so I was able to afford a little extra when it came to the amount of polygons the mesh was allowed to have. The count ended up at around about 7500. 5500 making up the main body with all its accessories and the remaining 2000 in the additional puppet master that is perched on top.

As touched on in my last dev log the Boss will have quad arms all holding a different random item that all have a different purpose base on the different cycles the boss may conduct during its battle. The two main arms are primary for damage outputs for its attacks. The large spear in one hand will be used as expected to smash its victims with a devastating forward strike while the large mace like object the replaces the hand on the other arm can be used to either crush its opponents or as a extra support that can be placed on the ground while the spear attack is occurring.

The two subsequent smaller arms are mainly used for minor secondary actions rather than damage wielding attracts. In one hand is a small ceremonial knife and in the other is voodoo like effigy. An animation cycle that could explain the purpose of the items could be that the boss would stab the effigy with the knife releasing spirits or summoning some other worldly power. Although how the boss fight will be conducted is still very much being considered this proposed animation cycle would be ideal to use in a case of a battle pause allowing the player to reorganize their units.  

With the puppet master perched within the top of the main body I have had to take into certain considerations when it came to its construction and this is not only for this particular part but the entire rig in general. The problem has originated for the idea that when the boss dies the main body will fall forward and the puppet master will be hurled out of his platform and roll onto the ground. To achieve this it means that the puppet master could not be simply a part of the same mesh as the main body but its own mesh and rig that can move independently form the main body. This may cause me problems that I will have to address during animation.

- Chris Smith - Enemy concept artist / 3D Enemy artist & animator

Dev update - Matthew Woods

For me this week has been quite busy! I have now finished off the last of my university electives, but I had to put a lot of time into them this week, so my progress on HitL was somewhat stunted this week, however that meant I had to spend my time thoughtfully and so I pushed the lighting, environment and enemy textures as far as I could.

Here is the first pass of the environment, the first pass was never intended to be used as a game ready asset of any kind, and I usually start my environments by doing super rough blockouts, in terms of environments with heavy stonework I like to place a lot of tiny detail into the scene to get a feel for how it will read once I begin making my textures.

The second pass is a stripped back version that I use with every intent of being game ready, this includes splitting up the assets into the main chunks and UV unwrapping to start getting my texture sizes across all surfaces. It’s here I take my high poly workflow into a new scene and begin sculpting to bake down to texture detail.

Here’s the second pass of the environment textured with some basic lighting, I went back and changed a lot of the layout to better support enemy pathing through this part of the level.

Aside from the environment work, this week I also put more work into enemy materials and textures and began testing how they would read in the environment, giving the enemy materials an emission map to help pop out their silhouette and draw attention to them within the scene they ended up reading quite easily within the scene with a full post-processing pass. The above image is how the final build will look with lighting and post.

In all it’s a pretty short week for me, most of the work went into texturing and setting up the scene, but I’m feeling like all my environment work is finally paying off!

- Matthew Woods - Programmer / Art lead / Environment artist

Dev Update- Simone Rizio
This week I was working on planning out the textures for the characters, in a way that would suit the environment (style, colour scheme etc). As expected, it took a few tries to adjust the colours so that they didn't like like they were assets from a different game.

Here is a quick concept of how I wanted the the archeologist and the engineer to look :

- Mostly earthy/natural colours (khaki, olive green, brown etc), added some brighter highlights to give the characters some personality, or stand out amongst eachother more easily (more needed at our game's camera angle and distance from the character models).

My first trial on the character textures was to, using the eye-dropper tool in Photoshop, pick the colours from this concept and use them to paint the respective areas on the flat UVs.

Here's the first pass of the character textured using the colours straight from the concept above:

As you can see these colours don't suit the environment at all, and it doesn't quite have the natural look to the clothing that we previously wanted. However the character does stand out (easy to find)  in the environment so that is a good thing. 

From here, the colours were desaturated and altered, to be suit the natural tones in the environment's textures. Additionally, more details were handpainted into the texture such as face details, shadows details in clothes (buttons, folds/creases etc).

Work in progress of texture with colour saturation adjusted from before.

The texture was painted in blender and photoshop, and at first I was texturing over the low poly model in blender but this eventually caused problems as without the details from the high poly sculpt I wasn't able to see (and there fore paint with ease - ) the details that were only present in the highpoly or in this case, the normal map bake.

To fix this I had to include it in the node editor in Blender (while rendering in Cycles), like so: 

On the most left, at the top the texture (the one you can see I'm painting is plugged in at the top, and at the bottom the normal map (not using colour data), is plugged into a normal map vector. In turn all these, are plugged into the diffuse node which allows me to see both at once while painting, and not have to guess where the normal map details are when painting on the low poly model. (At first I have trouble doing this because I have not done it before, and additionally I have not worked in the Cycles rendering side of Blender very much either.)

Engineer base texture, displaying diffuse, normal map and ambient occlusion map.

Archeologist base texture, displaying diffuse, normal map and ambient occlusion map.

When deciding the colours for the archeologist character, I had a better idea on what colour would suit the environment better (darker, more earthy than before, less satured etc). Which is why the colours in this model look drastically different from the colours picked in the concept.

That concept was coloured a bit before the environment was created which is why the colours are being changed so much from there. 

- Simone Rizio - Character Artist/ Concept Artist/ Animator/ UI Lead