Development Report - 19th September 2018

We’re back again with another week of devlogs! We’re moving incredibly fast towards some of our deadlines, and new opportunities are popping up for us, some of these we will be talking about in depth. At this stage of development we’re at the point where we’re pulling together all our assets and code to start shaping our vertical slice. 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, Instagramor Facebook!

Dev update - Sam Muller

Ahhhhhhhhhhhhhhhhhh! One spook please!

Hey! It’s me, Sam Muller, back once again with a little (like my DevLogs are ever little) development update. Sadly I’ve only really had the weekend+ (the days after the weekend) to work on Harrowing in the Light but I’ve done a few things and tried to do a heck of a lot more. I really did try but omrrggrrd do things not work out sometimes…

It all started on Sunday when, although I knew exactly what I needed to do, I wasn’t keen on programming. Now, I should mention that we are close to having a working thing, not as close as I would like to be (that ship sailed a while ago) but close. Matt and I had gone over the specifics of our vertical slice the Thursday prior and so, in my mind, it wound be smooth sailing (maybe we could catch up to the ship). Hip. Cool. Right?

We’ve been presented with an opportunity to maybe show Harrowing in the Light in a public space with the goal of playtesting. AMAZING. BUT. We need screenshots. Whelp. So far, our game is about as visually interesting as a dystopian concrete jungle. That is, our (in engine) art is an amalgamous (whoa, that’s not actually a word, wild) grey blob. Don’t worry! Last week and, more so, this week was Matt’s very much intended work time for the level (you can read his DevLog for more on that). So yeah, we had planned for that.

With that in mind, it doesn’t sound quite as bad when I tell you that I spent the ENTIRE weekend making SUPER COOL visual effects. I guess part of me wanted to fill out the scene a little more and give Matt’s level some of the justice it deserves. Another part of me wanted to appease you, dear reader, with a pleasant array of GIFs. But it was mostly, definitely, 100 - 0.01 percent because I did not want to code. Besides, like I said before, it’ll be easy. I had Monday night to worry about it.

When I still wasn't in the appropriate headspace come Monday, being the AMAZING, diligent team member I am, I trekked on... and instantly got stuck. Turns out, programming the stages and objectives was a little more high concept than I was prepared for. That’s fine. I was thinking about it during the day and had already become aware of this inevitably. It just meant I had to put on a pot of coffee when I got home. Easy.

Out comes the trusty notebook. You’d know the one if you read last week’s DevLog ;). Matt had finished an unsculpted version of the level by this point (totally another reason I didn’t do this over the weekend) and pushed it through with a few reference images of where the events would happen based on what we had discussed. Into the notebook it went.

I had something to work with. Headfirst, I went in. Since we had the luxury to write some nicer code in the weeks prior I adopted a unique naming style for everything new that I wrote (DELETE_fileName). I didn’t know what I was doing so I knew I’d have to go clean it up later. For now, it just needed to work.

It did, almost. The structure I was using, albeit horrible, was functional. I began fantasizing about adding full implemented battles before I hit the hay. My little sailboat was riding in the wake of the ship which sat on the distant horizon, it was in sight.

Then the thunder rolled in.

My mainsail had torn. The pleasant breeze was absent in the presence of the stormy winds. The movement grid was causing issues as prevalent as the thunder and lightning (very, very frightening). I was familiar with these waters and was not yet prepared to surrender my vessel to its seas.

Into its depths I dove.

It took me two hours before I resurfaced. I was broken and defeated, fearful to interfere any further. After all, these waters were under the jurisdiction of the pirate king Matt. In my final push for survival, I sent him an SOS and my current coordinates in the form of a Unity Collaborate push, only to withdraw from the stiff sea breeze and salty air, hopeful that my boat won’t stray further from its course.

Of course, you may be wondering why it was so desperately important that this be finished in one night. We wanted to, needed to, playtest the following day. Matt did come to my rescue; he’d been having the problem previously. I managed to scrape something together but I am not, in the slightest, pleased with it. Hey, on the bright side, I’m better prepared to try again. I’m just really, BIG emphasis on the really, worried about time. I confess I might be a little unmotivated by the crunch ahead, but I know that, once I start, all of the forces will be hard pressed to stop me. It’s a challenge after all, how could I possibly decline?!

Yay! That’s done! Now it’s time to digress from the drama and showcase some GIFs! All things considered, I regret nothing; making the following effects was a lot of fun and has helped keep my, very finite, sanity.

We needed to start with a small introduction for our vertical slice. I tried to write a few short sentences to give an overview of the location, characters and objective. I couldn’t come up with anything that didn’t sound generic, which is definitely me being hypercritical, so I settled for something short:

1926. They’re gone. Save them. Be wary.

It still feels a little generic but heck, it sets the tone for the objective of the vertical slice, that is, rescuing a hostage. I’d been experimenting with some particle effects before I jumped onboard this project:

I admit, I’m especially proud of this due to it being one of the rare visual effects that I’d developed without instruction or inspiration. It was just me having a little fun, testing my (incredibly limited) knowledge. I adapted it to look at the cursor and disappear when the user clicks:

The problem is that the effect is incredibly performance intensive. It’s understandable, the visual above consists of 1000 particles per second, each with a lifetime of 5 seconds, which, through the use of basic arithmetic (yes, I can do mathematics), means there up to 5000 particles on screen, slightly more when the next text begins to generate. Whilst this is fairly manageable for most computers (even after adding trails), it’s not visible enough, which definitely hinders accessibility. Adding more particles isn’t an option, so I started experimenting with showing the text mesh:

Pretty cool right?! Hahaha, of course I get excited about my own work... At this point I wasn’t content with it yet; I still thought it looked WAY too much like the generic Unity plastic.

Time to get some shaders in there...

I’ve got two designs and currently I’m more sold on the later one (it looks more like the text itself is blowing away) BUT the readability is definitely better on the first, so I’ll need to keep it in the back of my mind and playtest, playtest, playtest it:

The other thing I did was get some of the ground work in for a umber of water effects. The below is nowhere near complete but it’s already looking something like waterfall. I followed, the incredibly talented, Filo’s super amazing documentation of their process for making a waterfall.

I definitely want follow up with the (godlike) mesh effects Filo uses (current that’s just three planes) but I’ll be using the fountain mesh Matt makes. It’s been a very long time since I’ve touched Shaderforge but I’m genuinely amazed at how quickly I picked it up again. That splash effect at the bottom? Made from this perlin noise texture:

NEXT LEVEL ;)

I feel like I need to apologize for all the self praise, I’ll validate it by saying that I feel like I just need to boost my own ego after failing so miserably this week!

NOW TIME FOR ME TO GET BACK TO WORK! You’ve stolen enough of my time (it’s definitely the other way around)...

Have one appreciation from me, with love, always, Sam <3

Dev Update- Simone Rizio

This week i spend the majority of my time working on the characters for the game !

It was my first time retopologize a mesh so it was a pretty long week of understanding how to do so, and getting it done. Not to mention, I haven’t really sculpted much before either.

Here is the first pass (for now) of the engineer !

Of course this mesh, which has 130k + verts,  (as per needed for digital sculpting) and will not be optimal in a game and  will be troublesome to animate at that vert count. From here, the solution is to retopologize the mesh in Blender, to achieve the same silhouette as what has been created by the sculpt but at a much lower vert count. From here I can unwrap it and bake the details on as a normal map. To retopologise, I simply just starting with a plane, and changed the "snap element" to face, so i could quickly snap verts to the faces of the mesh underneath, as to sort of trace over it. This method of retopology on organic models proved to be very tedious as I had to do it almost plane-by-plane at some points. In time I might become more proficient at it as I keep doing the other characters, or may choose to use an external program.

Nonetheless, the retopologised mesh came to be somewhat successful :

As shown, the vert count dropped to just over 4 thousand verts, which will be a lot easy to work with in terms of animation, UV mapping and its overall optimisation for the game. From here I have unwrapped the character which is ready to have the high-poly sculpt baked onto it!

The unwrapped character ready for baking.

Following on from this character, I have also started preparing Jecinta Hargrove (the archeologist) 's 3d character model.

Aside from having her boots fixed and adding in her hair and bag, she will be ready very soon for sculpting and the same workflow as the engineer. However, due to the difficulty of retopologizing organic models in Blender by using just a snap functionality, it is very time consuming and  tedious so I have decided to use an external retopology program to aid in saving hours and hours of hand-made retopology work so I can move through the character progress much more quickly. I think I will used Retopoflow.

Work in progress of Jecinta's low-poly model.

I have been thinking about a few ways to prepare Jecinta’s braided hair as a model (seen here):

I have a few ideas how to accomplish so stick around for next time to see where Jecinta’s progress goes as well as the (hopefully!) finished progress of Billie the Engineer!

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

Dev update - Matthew Woods

This week I have been working on level design, from layout and enemy paths, mission objectives and blocking out the 3D graphics for the in game level.

Firstly I started by discussing with Sam what our plans for objective inside our vertical slice would be, agreeing that we should try as hard as possible to showcase an actual in-game scenario within the slice, we decided to go ahead with the idea of carrying out a rescue mission.

Here’s some quick and dirty mockups through discussion regarding objective, room breakdowns, enemy paths and triggers.

Basically the idea was to have an entrance/first room, a second (final) room with the prisoner to rescue, all the while having battles appear at the correct points (scripted, mostly, but to the representation degree of what we’re aiming for, for now).

So while Sam worked on creating the required code to get this working, I started blocking out the environment. Since our game is so strict by grid spaces my first task was to rough-out the walkable/non walkable areas of the environment.

To make sure everything would be aligned I used pro-builder to quickly block out the environment in terms of grid spaces, here’s a rough look at the walkable and non walkable zones at a very base level.

As we can see the environment is split up into 2 (or three, if you count the entrance separate) ‘rooms’ which are used to lead the player through the mission objective.

With this step done I moved onto roughly blocking out the shapes in the environment, I started with a very, quick and crude sketch.

From here I pretty much just spent most of my time blocking things out and tweaking room sizes, I had my work cut out for me though as the group has decided to apply for ACMIs public playtest session, and as we needed to have screenshots to submit, I wanted to end the week with something decent to show in our application.

Here’s a rough breakdown of my workflow as I blocked out the environment this week.

My method is to check readability between unity with basic lighting direction and character scale, check that the camera is not being blocked by walls or pillars, and keeping track of which ones need to be disabled or see through depending on camera location. While a lot of this work is still basic block shapes, I still try to put parts of detail (that may, or may not stay as I continue to refine my shapes) in sections of environment that I find to hold the most character, and to work on those areas to see how it changes the overall feel and look of the play space.

For this week I managed to block out the first room, and then moved on to making it more presentable for our application to ACMI. This included things like tweaking/adding shadows, post processing, playing with foliage, and some basic materials to get start creating the overall feel of the environment. Not only was this for the ACMI application, but it helps me visualise what is working and what isn’t within the scene, it helps give me focus to what I want to change or what I want to push in new directions.

Here are some final in-engine screens that I ended up with this week.

At the end of this week I think it’s a good time to reflect on the environment, the shapes, and what kind of feel the environment is bringing forward for me to continue work on during the following weeks.

In all, I can say I had a pretty fun week, finally getting to use 3D! I'll leave you with a little fly through.

- Matthew Woods - Programmer / Art lead / Environment artist

Meet Bob Jn. A Scorpio that loves candle light dinners and long walks on the beach. He also likes to wow people with his explosive personality........and by personality I mean body parts. This week's dev log entry is dedicated to "Bob Jn" a suicide unit that will rush the player units and explode in front of their eye.
Bob Jn was conceived last week while I was experimenting with the new design direction. After completing the sketch I considered what roles the little no armed figure could fill. The most obvious was as a suicide unit but in its current state seen in the concept above the readability of its function for its role is not still all that clear. For this I had always considered sticking some kind of sack onto the body that would contain the explosives but I still felt that it was still missing something. It was not until I had discussions with my team that the idea to have an arm that would be specifically used to puncture the sack came to be. This was good because it gave the body parts a identifiable purpose for their existence. With the idea in place a moved rapidly to completing the model.

The model has about 1300 tris which is about the same as the melee enemy model. The sack I wanted to be large and prominent but not cumbersome. What I mean by this is I wanted the weight of the sack to effect the rest of the body but not weigh it down so much that it becomes a burden. In its current design it does not interfere with the legs and in turn its movement.

 
I knew as soon as the idea came up for the arm I wanted it to be oversized and drag on the ground. having this design has two advantages. The first is that when animated the arm will give the model great character and making the movement have more interest. The second is its function. Having the arm so long allows the action of puncturing the sack to occur more easily without stressing the mesh in the arm as much when bending it.

When it came to the animations the main goal was to give the walk cycle (the action the model will be conducting the most) lots of interest. With a fairly basic walk cycle in the legs as a base I gave the core of the body a slight tilt based on what leg the weight was on. That then influences the secondary motions of the sack swaying behind and the arm dragging along the ground to its side. For when "Bob Jn" reaches its target and detonates itself again the action is quite simple. Due to effects taking over the explosion part of the cycle the part of the animation that was really only required was the action of puncturing the sack. Only thing to note here is the small secondary animation after the sack is hit. Both animations will be combined together within the game engine.

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