Development Report - 3rd October 2018

Just another week of DevLogs! We’re scarily close to our next deadline and a few things are happening. We're still pulling together all our assets and code together but our vertical slice has a shape. As always if you missed last weeks report you can check that out here.

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

Dev Update - Simone Rizio

For the last 2 weeks I have been working mostly on characters, which included: sculpting, retopologising, UV unwrapping, baking, rigging and animating- what was left of the Engineer (Billie), and then mostly work on the Archeologist. I also did some concepting work for the UI.

Engineer- Billie

After Unwrapping the retopologised mesh of the engineer model (over the sculpt) I then baked a normal map and Ambient Occlusion map for it.

On the left is the mesh that you saw in the last devlog (the retopologized mesh), which has the “fake” detail from the high poly mesh baked onto it, hence having the best of both worlds: usable poly-count for games development and ease-of-use in animation. Whilst 8k is a bit too high (having 4 characters on the screen and at small scale given the far-away-camera-angle:  still (it was my first time retopologizing), it was still definitely very usable to work with for animation and i’m somewhat happy with the results from the bake.

Animations

The animation list for this week was:

-Idle

-Run

-Idle while Aiming

-Shoot

-Rechamber

-Hostage kneel

Here are previous to some of them:

Idle while Aiming

Shoot

Rechamber

*Note: One thing to notice about this rechamber animation is that it is actually incorrect for the type of gun she is holding (Lee Enfield, see video example here:

, time: ~2:44) Notice how he rechambers the gun after each hand with his right hand, and on mine it is the left. This is because the gun is parented to her right hand and as such I cannot move it away from the gun without the gun following the rotation. As a quick fix I used the other hand but this is incorrect because:

• It looks like she is using a shotgun
• It is not easily possible to support such a gun while only holding on with the right hand(its too close to her chest). But it will be reworked later, (the rig has to be fixed and therefore, I think, all the animations) for now it’s fine cause it’s not really noticeable from the camera angle and distance.

Archeologist- Jecinta

I also finished the character work for the Archeologist, Jecinta Hargrove, here is a work-in-progress screenshot of the archeologist sculpt:

This character was also retopologised, UV unwrapped, and baked, see the comparison here:

On this one you can see the vert count for the retopology on this one (3.5k is much better than the previous character that was ~8k).

The braids on this character, however, proved to be quite a challenge and it took a few attempts to finally get a result I was happy with.

I ended up ‘braiding’ some blender curves together, by diagonally crossing them together as straight lines, then joining them together with the ‘F’ button. From here, you can add a curve modifier to create the braid appearance (using those curves), and them you can plug this curve into an array modifier so it can be repeated and changed in size as shown:

Using the array modifier to adjust the amount of braid “weaves” and their thickness.

Using the array modifier to extend the length of the braids using the curve.

And lastly, for animations on this character, I appended the rig from the engineer onto this character and adjusted the skin-weights so these characters can share identical animations for the time-being, but later on, each character will have their own unique animations.

User-Interface

I also did some concept work for the UI sketching ideas of how the layout of UI could look, and adjusting them after feedback, (ignore the text in the top-left).

Concept 1.

First concept includes:

• Objectives (updating at the top, checked and rolled back when completed, eventually removed from screen)
• Skillbook on the top left that can pop-out (like in my previous dev-log example)
• Character portraits, active character shown largest and a basic animation would play to change between them)
• Health orb (like diablo2/ torchlight) as well as actions.

The feedback was that: they wanted less visible on the screen, it looked better when (original example), all characters were on the left next to the health orb/bar.

Concept 2.

-Put objectives and skill books in identical , and much smaller tabs, on the left, which can pull-out when hovered over and then bring up a new screen or box with their respective information.

-Active character has a banner, all characters are shown on the left with the health orb belonging to the active character.

-Actions left and end turn (**should say end phase) are shown together on the right side.

Feedback was:

• Objective and book tabs were a bit too small,
• actions left should be displayed with the portraits.

Concept 3.

• Objective and book tab were made bigger and pushed up the screen so a bit more out of the way
• Health and actions and character portraits displayed altogether
• End phase displayed on the right-side as a sort of isolated button to go to next phase. (End turn was a mistake, ignore that one).

- Simone Rizio - 3d Character artist, Concept artist, Animator & UI Designer

Dev update - Matthew Woods

So the past two weeks have been pretty art orientated for me, from experimenting with aesthetics to texture and lightings tests, as well as beginning work on some of Chris’ enemy models.

For the majority of my weekend? It looked a little something like this

Rinse and repeat. Yep, I mean, I guess I can technically copy a lot of these bricks and stones and repeat them, but I really -hate- obvious repetition in art assets so I always make sure to go out of my way to avoid that as much as possible, even if it  does take me a lot longer.

The end result leaves me seamless textures something to the likes of this

Baked using TexTools- A free UV/Baking (and a lot more) addon for Blender (Use it, it's great, you won't regret installing it) which makes it incredibly easy to bake textures with high levels of AA.

Originally this design was for the walls, although I’m pretty unhappy with how it turned out and I think I will shift this to a floor texture, the alignment of the various bricks doesn’t seem like a sturdy brick wall to me at all.

I did a few more assets over the week, one I was particularly happy with was this design of one of the environmental pillars

I still need to go in and do some adjustments, like making some of the bricks extrude out and shift the rotation of some of them (they’re very straight) - and go back over and do a proper retopo job and bake, but for now the quick and dirty version is usable in game now.

So while sculpting all these stone details does take quite a long time, I needed a solution to create quick textures, so I jumped into Substance Designer for that, and I have a quick little node setup that textures these within minute with a few little bits of tweaking.

I can’t quite remember where I picked up this technique, but it’s incredibly quick and gives some pretty decent results - A quick breakdown of this substance
Inverted normals > split into curvature and curvature smooth nodes > passed into a blend node > a levels node to adjust the blacks and whites > gradient map node > levels to adjust the contrast a little more > final output.

The key part of this graph is the gradient map, which basically takes my grayscale map and applies colour along a gradient scale.

So from the blacks to the whites of the grayscale I set key points that inherit these new colours that I am picking in the gradient bar above.

Really quick and simple! I look forward to playing around with this node graph more to see how much more I can squeeze out of it, because it really is a total time saver.

Aside from environment stuff I did a little more coding, I created animation controllers for the players and enemies - still early scripts but the basic functionality is in there now. Normally my character controllers are rigidbody driven, so I usually just check the rigidbody velocity to see if I should be playing a movement animation or an idle animation, but the characters in this game do not use that, so I needed to come up with a way of triggering the animation. A simple way of checking for movement, and the method I am using at the moment is this small little frame check.

As the lastPos variable will always update after the currentPos, it’s really simple to just check if the current frame position (currentPos) is different to the last frame (lastPos).

Lastly for this week I have started sculpting Chris’ low poly enemy models, trying to keep them as close to his original design but adding a lot of detail to help them really pop within the game environment, this will also make it easier for me to texture, although I like texturing low poly models and doing the details in the textures by hand, it just isn’t going to suit the style if I do that, so I need some high poly detail to work with and colour.

- Matthew Woods - Programmer / Art lead / Environment artist

Dev update - Sam Muller

Hey Pals! Everything works (for the most part)! It’s little old me, Sam Muller, although this week it’s somewhat stress relieved Sam. That’s a lie, there’s always something to worry about with the very limited time we have left for our next big milestone.

Two weeks it’s been since the last update and a small quantity of things have happened. To start off, I think I’ll run, literally zoom, past our playtests:

The game was broken >  We tested level readability > It wasn’t producing the most amazing results (we’re only after the very best, organic and cruelty free results here) > We pivoted last minute > We tested a number of variations of the grid system because we’d had feedback about and issues with this previously > Result!

There we go, very quick zooms.

I confess, I’m writing this DevLog somewhat in advance so whilst I’m mentioning now that the grid system hasn’t yet been introduced to the playable version of the game, it will, hopefully (like seriously please work) be in by the time this DevLog is released. I suppose a lot of things will have but that okay! I can add even more words to the next DevLog!!

Other than that all I really did was correct Matt on his spelling of the word ‘colour’ since he is a true programmer and spells it as the American ‘color’. There were two distinct and definitely equally important reasons for this. One, I struggled with altering this habit and could have used someone calling me out on it. Two, I needed leverage after I woefully misspelled ‘grenade’ as ‘grenede’ in one of the ability panels. This wouldn’t have been a huge issue if we hadn’t of ended up repeatedly using a GIF which had the mistake inherently visible. Seriously, you could get discounted tickets for terrible seats for the show and still see it. Luckily, whilst I still was at the receiving end of a number of INCREDIBLY vicious and cruel jests, I was able to minimize the blow with the claim that English is my seconds language. By definition it is so I’m going to keep using it every time I do something not quite English (like this sentence). Matt, on the other hand, can’t. Thus, like the raptor I am, my claws are out.

Okay, I lied, I suppose I might have done a few other things too. WE HAVE OVER 19,000 LINES OF CODE! I don’t know how that happened but it did. Apparently (Matt gave me that figure, so if it’s wrong blame him) that’s not including any of the third party plugins or base engine code. This is, without a doubt, the largest project I have worked on and so I’ve had to deal with a number of new challenges. Most prominently, keeping track of everything. It’s genuinely the most difficult and demotivating aspect of this project. I feel like that really makes sense considering just how much 19,000 lines is. I do regret not having some sort of organizational structure in place to bookmark each of the mechanics and elements that we developed but I just don’t think I have the time to sift through everything. Realistically, I’d do that while I’m rewriting all of the code, which, mind you, I am already very close to doing.

In the previous DevLog I’d vastly over complicated the method through which monsters were spawning, so I pulled back and reassessed. Currently, the method is based on a system of active rooms. When a character enters a room, it becomes active and therefore so too do it’s spawn points. The game mechanics have also been altered to be more aligned with phase system, that is, when the players are out of turns, the setup phase ends and the battle phase begins. The most important part of all of this is that it makes it a heck of a lot easier for me to wrap my head around everything (considering the amount of sleep I’m getting, it’s hard for me to wrap my head around anything more than a cup of coffee).

I’ve also got the hostage mechanic working which means that they’ll join the party when the player frees them. ALL the core gameplay for the vertical slice in all done. We just need to make it fun! Honestly, that’s a good 90% of the work but heck, I believe, Besides, conceptually it’s all thought out so ABSOLUTELY NOTHING can go wrong. Think we’re going to save balancing for the very last stretch but here’s a GIF showing how overpowered the enemy attacks are ;)

OH MY GRANOLA is layer locking handy. We needed some screenshots in order to apply for something VERY cool (don’t worry I’ll get to it) so Matt threw in the level environment. That’s pretty cool right? It would be, if it wasn’t made up of over 2000 separate objects. EVERY TIME I clicked in the scene view I would hit one of those objects which opened the entire list in the hierarchy. Layer locking genuinely saved my life, 9/10 game developers would recommend (I tried really hard to find a video of the 9/10 dentists would recommend but to no avail, I’M SORRY).

Speaking of Matt and modelling, I ought to be congratulated for my continued encouragement of his work. EVERY SECOND MESSAGE was a picture of his work in progress. At least now I’ve got a nice long list for sayings synonymous with “wow, that’s cool!” Obviously, I’m kidding, I appreciate the updates, they keeps me motivated to continue my own work.

I also got a hefty amount of shader work done! Matt told me how nice it was to program again after a two week break so I decided to divert my attention to something, anything, other than programming in an attempt to replenish my work ethic. I also spent a little too long on twitter after I found a bunch of amazing VFX artists, namely Joyce and Gregory. Really, what the means for you is that you get to enjoy a whole bouquet of GIFs (let’s be real, that’s the best gift anyone could ask for).

I wanted to make something to replace the depth shader I current have for the deactivated rooms (picture) and ended up following Joyce’s tutorial on world point shaders. My ability to program in CG is pretty limited and I am very comfortable in Shaderforge, so I went about converting Joyce’s code into Shaderforge nodes. I feel like doing it this way allows for me to slowly develop an understanding of the CG language. Here’s the result:

It’s pretty bland right? That’s because I haven’t assigned any of the properties yet. I also haven’t had ANY fun with it yet. Since it’s in Shaderforge, I can very readily mess around with and iterate upon it with relative haste, which resulted in this:

That’s moving based on the radius slider of the shader so there isn’t any animation when it’s static. I wanted to play around with it a little more to give it some extra life and movement. As such, I took what I learnt from the water shader in the last DevLog and experimented with it:

I’m a huge fan of the liquid style effect, especially when it gets really small and looks like it spluttering. Although, a very sad although, I don’t think it’s all that appropriate for the aesthetic of our game, the one in the GIF prior seems to be much more well suited. I’m trying to hold back the tears…

I also wanted to add a level up mechanic so that the slice had a bit more of a weighty feel and brought a few elements of the metagame in. So, in the spirit of making the shaders, I made the visual effect first before even remotely contemplating the code implementation. Ha, I promise I can make healthy and beneficial decisions! Obviously, having played RuneScape way tooooooooooo much in my youth, I instantly think of fireworks signifying a level up. I did think about doing something different but I wanted to put pen to paper rather than looking up a Royal Library of Alexandria’s worth of inspiration. I did, however, come across a neat little tutorial by Random Art Attack. Eventually, I got this effect:

There are probably a few minor things I still want to fix with it but I think for the most part it works. Or at least, as with seemingly all of my visual work this week, I thought it might. I got a second opinion from Matt (Is it just me or have I been mentioning him a LOT this week?) who said it “looks like fireworks” and “certainly draws attention”. *Cough cough* To me, the sounds exactly like the requirements for a level up (I’m kidding with that passive aggression, it’s totally fine). In fact, he showed me a pretty dope effect made by Katerina V, which turned out to be much more along the lines of what I was originally thinking:

Oh by the way, that cool thing I mentioned WAY earlier? We got accepted to playtest our game publicly at ACMI (the Australian Center for the Moving Image)! Aside from actually trying to garner some useful information from playtesting a few hundred people, it offers me some pretty good bragging rights ;)

I’m going to call it there for this week, I hope yours is as positive as mine has been!

With love, always, Sam <3

Dev update - Chris Smith

This week's dev log entry spans over the prior two weeks and covers the conceptualisation of the last two enemy types planned for completion before the end of the official university year. The two types consist of a final basic enemy type changed to a ranged flying unit and an end of level main boss.

During our travels the team came across the image above. Although the colour pallet is a little too colourful for Harrowing in the lights colour scheme the style and design suites our own themes well and was considered with iterations that it may be a good launching point for a potential boss like enemy type.

The design when I first saw it immediately conjured up thoughts of the design style similarly to those seen in the anime Gurren Lagann (Pictured above). A large humanoid figure with two faces. A face in the standard location on the head and a much larger face which makes up the chest. If the design features was combined with the design styling I have been exploring recently then it was suspected that a interesting and unique enemy boss design would come of it.

Using the previously mentioned inspiration as a base I referred back to our original style guide for ideas on how to properly meld the design into something that better represented the games overall feel. One such choice deriving from this was the second set of arms. Although at this stage the second set of arms are there as a visual element more than serving any practical use, I always wanted to add the arms to one of the enemy units but just could not find any legitimate reason until now. Additionally the units overall size should be much larger than really anything else on the map. Having the arms on the boss and the overall size of the unit be bigger, visually indicates the units importance and power compared to any of the other units developed thus far.

The newly derived "range" unit has been proposed to replace the "support unit" that can be seen within my previous dev logs. The reasoning for this is to aid the programming side of the development. With only a short period of time remaining the programming side of things will find it difficult at this time to develop new systems to utilise the units purpose. So after some discussion it was decided that the range unit at this time would be a more feasible choice prior to the upcoming deadline. I conceived the design with this fact in mind by having the overall idea of its attack motion being one were the unit will approach the player and drop something from the air to land on the player. In therioury the programming side can utilise already existing enemy attack code and myself can cheat a little and make the attack movements look somewhat new by using new animations.

After the first round of the enemy boss concept was completed I delivered the design to the team for feedback, understanding that the design was not quite at the level where I was wanting it to be at. During the following discussion the idea of replacing the head with a "Puppet master" was proposed. The secondary unit would sit perched atop within its own platform on the boss and wave its arms around controlling the boss like a marionette puppet. I really like this idea thanks to the extra character I can give the entire boss unit when it comes to delivering the animations.

Another change I made compared to the first design was its off arm. I was not that pleased with the idea of the off arm just using a buckler and wanted the arm to do something more interesting. I came up with what I'm calling the mace stamp. A design that can be used to swing or stomp at the player and be placed onto the ground to be used as an additional support leg in times such as when the boss swings its main weapon. Additionally I also added armour pieces for a little extra detail and extra secondary animation movement. This design has really opened the potential for some terrific animation cycles that I'm already developing in my head so watch this space.

The concept for the range unit developed quite rapidly. I of course knew I wanted wings and bat wings suited the games vibe perfectly. I also knew it needed to drop something so some kind of gripping arm design was needed. Other than that I just went freestyle with the rest of the design until something stuck. The design above was the outcome. Although I liked the form and some of the features of the design, a couple of things did not make it work. The wings position I could tell was going to give me problems during the animation cycle and the facial expression did not give the right "vibe" I was looking for in an enemy of this type.

For the second iteration of the range unit design I decided to pull the oddness level back a bit. I moved the wings down onto the back where I knew they would flap more easily and filled the space with horns. Again another design feature derived from the style guide that I always wanted to implicate in one of the units. Additionally I also replaced the mouth by mimicking a similar design to what I used with the suicide unit that I completed last time. This I find works well and aligns it nicely with the overall enemy design.  

The modelling of the range unit came together well and quickly. An indication that my skills using blender are thankfully improving. Overall the tris count is at almost 2700 which is a little more than previous models completed. Mainly due to the extra addition of a set of wings and horns. One aspect that made the modelling process move quickly was how I modelled that arms and legs. I only modelled one arm and replicated that arm to use as the leg. Then due to only modelling one side of the model I mirrored the other to create what you see above.

I took particular time and effort in getting the shape of the wings to look right. I knew that the making or breaking of the animations counted on whether or not the wings moved in a believable fashion. I also took care in ensuring that the arms, legs and head could have enough movement without clipping the wings.

When I came to animating the model I had a main trait that I wanted to display through the cycles. It was one of overall struggle. Due to the large size of the head I wanted to express a sense that its head was a burden to its frame. I did this by posing the model to on purpose give a lopsided look and one were the creature would always be fighting to stay in the air. The enemy will always be in the air flapping its wings, only coming down when it dies.

In total there is six animation cycles that at this time will be used. A standard flying animation cycle, A flying animation cycle while carrying its ball weapon, An animation cycle were it creates its ball weapon, An attack animation cycle were it hurls the ball at the player and two death animation cycles. One while its holding its ball weapon and one without.

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