It’s that time of the week again and we’re back with another development report! This week saw a number of changes going into the main build, from UI to game mechanics in preparation for this weeks playtest. Development has also continued on main backend systems to bring the games mechanics together cleanly, and the art team has been focusing on working on getting the first of the character and enemy models ready to be put into the game. A lot of work this week went into bringing the battle phase of the game up to a more playable stable level for our current batch of playtests, but as always if you missed last weeks report you can check that out here.

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

Dev update - Matthew Woods

What a long tedious week it has been working on the skill system! I’m going to go into a bit of depth of what I learnt this week, and break down what I found to both work and not work in terms of building a working flexible skill system for Harrowing in the Light.

My first mistake with trying to design this system is that I was asking my programming to account for way too many variables at any given time. My original idea was to create a robust class that contained data relating to a couple of core variables, such as: skillName, skillDescripion, skillGraphic and skillCost. The skill name and description are pretty obvious, just string variables to hold data that can be read by the UI tooltips and such, the skillGraphic I use just to store graphic sprites based off of the skillName (but of course, then file names need to match skill names 100%, which isn’t really a problem, but something to note).

While all this data was useful and worked for what I wanted it to do, when it came to calling a function from within that class that was flexible enough to handle a wide range of different game logic, I started running into issues.

Firstly I wanted to be able to pass in a skill parameter from the characters skill variables, which was fine, it worked, it would change the skill variable by an amount and return it thus updating the characters skill stat, but I was hard-coding these input parameters. I also wanted to pass in multiple parameters, but sometimes skills only required one parameter, not three, or five. While I was still speculating on possible skills for the game, I was trying to design a system based on unknown and yet to be thought of concepts of skills, this was leading to more issues than solutions as I continued to work on creating a robust skill system.

It took me awhile to figure it out, but I came to the conclusion that I was just asking my code to do too much and be too flexible, from one function and not really breaking the code up into viable sections. While the core functionality of the skill class worked, providing basic data to the skill UI icons (graphics, and text name/descriptions) I kept rotating around this idea that I could get it all working based around one function.

And simply put, that is just not the case, it won’t work and it’s more complicated, time consuming and ends up having a lot of redundant reference calls that just creating a bunch of specialized skill functions that perform the action that is required and tailored to the specific task.

So going back I’ve started redesigning this part from the ground up, keeping the core functionality of the skill class (name, desc, icon, cost) but creating unique functions for each skill. But while I was flailing around with my previous design, I did learn a lot about programming, and have begun adapting this into the new design. So what did I learn that was useful? Well, inheritance for starters, I vaguely had an idea of what it meant to use inheritance in C#, but never really found a reason to put it into practice and I was definitely not using it when I started designing this system. However now reading up on it, learning more about it and realising that each of the skills needs a handful of the same variables, inheritance has become a key part of the design. Let’s take a look at the base level of how I’m setting up the skills now.

As we can see the BuffSkill class is inheriting the properties of the base Skill class, this is good because now I have a place for the buff skill to hold its own logic separate to that of say a active battle ability function. But just like a battle skill, it shares the same variables from the Skill class, much easier, much simpler.

From here I am going to take a scriptable object approach after watching Matthew Schell’s talk on scriptable objects (great source of information on the subject, recommend!) and how they work, I feel they will be a perfect fit for what I am trying to achieve within Unity. This will allow me to create easy access in the unity inspector to handle skill names, descriptions, the buff increase variables numbers, etc, without making redundant messy code that is trying to do too much all at once.

So while I’ve gone around in circles quite a bit this week, I feel I am now at a place of understanding where I can apply all this new knowledge to make a great functional system for the game, while keeping it as performant as possible.

- Matthew Woods - Programmer / Art lead / Environment artist 

Dev update - Sam Muller 

Can we just appreciate how short a week is? It feels like it’s only been a few hours since the last update, like I’ve taken a nap and woken up on the same day but apparently it’s one whole, single week later. Maybe time is just a conspiracy, OH MY GOSH, YOU’RE IN ON IT AREN’T YOU!? I’m Sam Muller, although I might be more aptly known as sleepy Sam for this week.

Regardless of the fact that last weekend was non-existent, I somehow managed to do some things, real emphasis on the ‘o’ in that some. I also promised in last week’s DevLog that I would talk about our game’s definition a little more and my D O U B T S. So! I’m going to write a brief change log, show some GIFs, explain some of it and then jump into the real stuff (I was going to say ‘meaty stuff’ there but then I felt like I’d have to make some witty comment about vegetarianism… it’s also not that great of a word, not a fan of the ‘eaty’ sound).

Change Log:

• Made the background black so it looks like something big changed!
• Added an exclamation point and tooltip to indicate where the enemies would come from!
• Removed the grenade display in the top right!
• Added a spiral indicator as a replacement of the grenade indicator!
• Disabled the retreat button!
• Added damage indicators for both the enemies and players!
• Built the framework for a tier system for the torches!
• Implemented the midpoint circle algorithm for UI display of the torch radius!
• Increased the grenade cooldown!
• Added functionality to monster health!
• Removed monster instant kill!
• Added to monster attack delays!
• Added player attack functionality!
• Made the torches bobble when clicked (I’ve been playing a heck of a lot of Hidden Folks!)
• Added a floor indicator for the grid tiles!
• Added a slow down when using the grenade ability!
• Implemented a toggle for the grenade slowdown for A/B testing!
• A bunch of little, less important changes (I changed some 10s to 1s, riveting)!

Sorry, I felt like adding exclamation points made it seem more exciting. Wait sorry, exciting! There are only really two points I want to talk about. The first! The Midpoint Circle Algorithm! It’s a cool little mathematical equation that lets you draw a circle based on what I like to call pixilatuality (maybe I should change it to pixility), that is, the resolution you’d like to rasterize it in. I’d like to explain it in more layman's terms but the truth is I can’t; I implemented the function and it kind of just… worked. It looks cool as a GIF though!

While it is twice the resolution of the grid squares (the grid squares are two of the texture squares, confusing!), I don’t really need to change it that much, it’s quite placeholdery right now and will be substituted with a cool shader later (I get to do that and am !EXCITIED!). I can tell that you’re definitely wondering why it’s there then… Simple, it’s representative of the fact that the torch range exists within the context of the grid system. I just wanted to see if it was possible and, more so, if it could be readily implemented. Yes and yes!

The Second! Wow so many exclamation marks! Which reminds me; this is called an interrobang (thank you Netflix for providing me with so many trivial pieces of information). The second is this little spiral indicator. I made it from a PNG sequence rendered from After Effects (I struggled to make it in there as it was) and VERY hackily implemented it, only to find out (urgh, thanks Matt <3) that there’s a smöll feature built into Unity which does exactly that. So here’s Sam Small Suggestion™ for this week: if you ever need anything radial, copy this:

Change the Fill Amount to alter the radial effect, yes, it CAN be called through a script and yes, you can put WHATEVER source image you want in! Use it for timers, backgrounds or even throw a post-processing shader on it and have a field day.

*End of Sam’s Small Suggestion™*

Lucky for us, Anna Tito provided Matt and me with some insight into understanding our own programming knowledge, alongside a review of some of our code. While I was terrified (and rightly so, the amount of times I was calling GetComponent and FindGameObjectWithTag was enough to make even the most non-confrontational of programmers question whether our game would run), it was actually pretty handy and gave a heads up that we were writing pretty *okay* code. Both Matt and I consistently complain about how there is no benchmark to compare our understanding to, so I think we undersell ourselves. Evidently, it’s WAY too easy to get caught up with fancy words, abstract comments and someone’s Unity forum rant.

I’m just going to defend my use of GetComponent and FindGameObjectWithTag for one, maybe two sentences here:
1.       It’s easy.
2.       I had to get something playable in a very short time.
3.       Okay three; I haven’t had a chance to go back a rewrite it yet.

Sadly, I don’t have any amazing suggestions for videos to watch or further reading this week :( I suppose that means you don’t have any homework! Wow, okay, don’t get so excited.

D O U B T S

I’m a little concerned about copyright and the like so I’m just going to steal photos from the press kits of the games I’m going to reference!

There’s a lot of ambiguity around the definition for any game genre but, even then, I don’t know how appropriate the use of ‘tower defence’ is for the definition for our game. Granted, I do think the lines start to blur once you move into 3D territory but we’ll hold off on that for the time being… When I say two dimensional tower defence you might visualize something like Bloons TD 5:

Or, a personal favorite of mine, Infinitode:

There’s an element of uniformity to it right? The enemies have a path they take to get to an objective and the player attempts to prevent them from reaching it through the placement of buildings. Pretty standard (that’s not to say all 2D tower defence games are but I’m doing selective research here to argue my point, as nearly every internet based argument seems to do), but what happens when you move to 3D?

That’s where things start to get a little more interesting, take Orc’s Must Die 2:

While the player is presented with a controllable character, the enemies are still taking (some sort of, loosely defined) path to get to an objective, as the minimap in the top right suggests, and there are still buildings you can place, which in this game’s context are traps. The use of the character is really interesting and, I personally think, it adds a lot of depth to the game, making the enemy waves much more interesting and providing the player with a greater sense of agency. It’s all in real time too, which adds an element of logical uniformity. However! I still think it is, in its own right, a tower defence game.

So where does that our game sit in relation to that? It is inherently evident that whilst our game has some form, it hasn’t taken shape yet, like a block of wet cement on a rather warm day. As we’re headed toward our first milestone, Harrowing in the Light needs to be, somewhat, representative of the final product. As such, we’re at a cross roads, at the neck of a bident, either we knuckle down (+15 attack points), pull out our 3 piece set of Bosch chisels (not sponsored) and begin to detail what we have or we hunker down (+25 defence points) into the realm of a tower defence.

The problem. Our first room is a rectangle, it has a few obstacles here and there but for the most part it is cubic. It doesn’t give a representative figure for the path the enemies are going to take. Yes, our rooms are going to be MUCH (like a heck of a lot) larger but currently my thoughts on solving this involves introducing a UI representation of the path the enemies are going take, as you might have seen that in my UI sketch in the first DevLog. What I believe will make it interesting is that it will dynamically change as you interact with the set up phase, for instance, you place a torch and suddenly the path transforms into something entirely different, ruining your entire strategy. Now you have to decide if you’re going to play into the new path or spend an action removing the torch. WE HAVE ONE WEEK and I’ve got a few other commitments so I don’t realistically see that happening but it is an idea worth holding onto, maybe we should just bump up the room size?

The problem number two. The enemy objective isn’t set in stone (no, not even wet cement), it alters (or at least, is supposed to) based on what is closest and its priority. Now this is intentional, the idea is that you need to decide whether a path altering element is protected enough, lest it be destroyed in the battle phase. There’s levels to this too, rather than being destroyed, torches are extinguished and certain characters will have abilities to relight them in a pinch. But heck, that’s all cool and stuff, the enemies still don’t have that classic tower defence objective. I’m all for pushing the boundaries, although I feel like it needs to be merited. Currently, it’s planned that the characters will become possessed when they ‘die’ and that the enemies can then escape through the use of the characters body, think Undertale and the monster’s power gain from humans. Does that then classify the room’s exit as an objective? Heck, I don’t know. What I do know is that it’s not evident enough and we need to address it.

I might just leave it there. I could go more in depth into a few more nuanced elements but I’m sure I’ve kept you for long enough. Hopefully, even without the homework, you’ll have something to think about! :)

Just in case you weren’t wondering, the exclamation mark count is 35! 36 now. For reference, Moby Dick had 1,683!

…37.

I appreciate you, I hope you have an absolutely wonderful day and with love, always, Sam <3

Dev update - Simone Rizio

For this week I am working on modelling the female base for the engineer character, Billie. This is her turn around views I drew, you may have seen them a few weeks back. I use them in Blender to model on top of, it helps me layout the character’s anatomy and potentially clothes as I model.

Here is the incomplete work so far, this week I focused on topology on the female model, try to improve the flow of edge-loops around the body of the model. This is important because, as this character is going to be used for animation, the way the lines flow are involved in the way the body deforms in the case of poses and movement. I am mostly a 3d artist for animals, so understanding the flow around a human body was particularly interesting and fun to learn.

From this point, of course I will work on the head of the character, at a most basic level as this female base will be interchangeable between this character (Billie, the engineer and, Jecinta the Archeologist). The head will be modelled separately and attached to the neck when complete, so to not cause complications when trying to extrude a head out of the neck. Of course the male base is up next shortly after this.

I am also one to mostly model in Maya 2016, so the switch to Blender was at first daunting, but I’ve really enjoyed using its tools and modifiers. In the case of this model, I did my best to achieve the shape and flow I was aiming for while keeping the polycount as low as I could (here: 1,595 verts).

Front view, displaying edge-flow, still need some adjustment on arms and hand re-work. Mostly happy with all else. 

Back view, same areas as front need adjustment, need better topology for elbow area when used in animation. Maybe some better flow around the back could be good.

- Simone Rizio - Concept artist/ 3d artist /Animator/ UI Lead

Dev update - Christopher Smith

Week 3 has consisted with myself advancing one of the previously concept designs into the modelling phase. The design that was agreed to and locked off by the rest of the team which then allowed me to produce a isometric version of the design that was cleaner and further expanded the details that will be needed to be known when I move the design into the 3d realm.

The design is that from one of the Humbled concept designs. In this design I focused on two elements with an Arabian feel. The first was the head were inspired by images of Lawrence of Arabia and the second was a vale similar to what is worn by belly dancers. I feel what makes this effective is that traditionally the two items do not have very much connection with evil or demonic powers. But when placed on something that is evil or deformed it visually indicates corruption of something that originally and regularly is quite innocent. A good example of this is in the Stanley Kubrick film The Shining with the famous scene of the two young girls in the hallway.

With the isometric final complete I moved onto modifying the modelling the details into the base mesh I have been working on the last couple of week. The main difficulties encountered with the process is getting the design while keeping in mind the T pose. Especially around the hips and legs due to the odd permanently hunched over pose of the design. A large majority of the work was spent around the head and shoulders.

To help keep poly counts down I wanted to integrate the head shroud into the main mesh instead of creating a parented object. This would make things a little easier when it came to animation as well. Again like the previous weeks I continued to remove more and more polys out of the mesh with the count now dropping to about 2200 and that is still with the introduction of the head shroud. Next up rigging and animating.

Lawrence of Arabia

https://www.spectator.co.uk/2017/03/will-the-tide-ever-turn-on-lawrence-of-arabi...

Belly Dancer Shroud

http://www.missbellydance.com/Belly_Dancer_Face_Veil_Fatina_Veil_p/fv.htm

 Hallway scene from "The Shining"

"The Shining" (1980) - Stanley Kubrick

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