Enemy Model Sheets - Matt Glen (Concept Art)

In order to take the initial concepts forward into actual 3D models for the game, model sheets are needed to provide a more detailed, multiple-viewpoint display of the characters for the modelers. I started with the main enemy unit, the Golem.

Golem

After creating a front back and side viewpoint for the character, I also added a small drawing of the grotesque faces that adorn the shoulders of these monsters to make that clearer. The main challenges here were trying to make the forms and parts of the concept as clear as possible, as well as ensuring that everything lined up and sat correctly from view to view. The more discrepancies between each image, the harder it would be to model from. I think I've managed to line things up fairly well, so hopefully this should translate well into 3D.


Enchanted Archer

With the Golem and Skulker, I already had one flat, perspective-free view completed before I began the model sheet, but unfortunately my original archer concept didn't work for that, and so I had to do a little bit more work for this one. Luckily the front and back views were so similar that it didn't take too long to complete. This sheet was a little easier to line up than the others, and so it should be a fairly decent guide when it comes to modelling.

Skulker

The final model sheet for the skulker was quite a challenge, essentially because of its compact shape. This meant that the front and back views had to accommodate a great deal of detail in a small area, making it look very bunched up and busy in only a small volume. There was no real getting around this, unfortunately, as the techniques I would normally employ to separate forms and create the illusion of depth would only make it more awkward to use as a modelling reference, which is its entire function. Instead I had to hope the colours and lighting I employed would break up the forms just enough that it was possible to understand what was happening in each viewpoint. I think I've mostly been successful with that, but it is undeniably messy in places and it certainly blends into one homogeneous form on some glances. Maybe one day I'll discover a good way to avoid these problems for a creature like this. The answer may be in a less detailed, simpler line variant of a model sheet that contains only the essential forms.

Hopefully all of these should be useful as references for creating the 3D enemies for our game, and it should be interesting to see how these concepts translate into models.

Coding - AI Iteration 2 and Combat - John Howard

Overview

Firstly its been a while since i've posted basically an entire month! But thats not been a month in vain. Since the last iteration I have decided to do a complete new iteration of the code that I had and put on a moving cube. This is so as to just code the AI without animation so I can focus fully on the code and then move the working code to the golem model when ready.
General Script Iteration
I went through all the scripts mentioned previously within this blog and redid the code from scratch using the previous ones as reference. Mostly nothing was changed with just the few cleanups and the like. The patrol and the search stayed as the last iteration due to having already changed these two scripts to a higher level already.

Animator

Due to the model now being a cube, and no rig, I set up a completely new animator along with unity animation. I gave the model two hands that moved back and forth to show when the AI was moving and a second state that would stop them moving when in combat. The transition between the non-combat and combat states happen when a combat bool becomes true. I also implemented a punch and slam animation. These two movements were chosen due to the group asking for these two attacks. Again two bools are set up ready to call these. Setting up an animator has become an easy enough task for me now however I haven't touched layers yet. But a bit of research into layers via tutorials and the API have cleared this up and suggests the use of layer masks could be a good route to go depending on how the group wants the golem AI to work in combat.

Current AI animator

Combat Scripts

The AI has two attacks a punch, and a slam. With the slam being the more powerful one. Thus I wanted to make it more likely for the AI to use the punch rather than the slam. So I created an array of five ints from 1 to 5. Odd numbers would turn on the anim bool for the punch whilst even numbers would initiate the slam. The slam when called would then have a cooldown preventing it being called until the slam is ready again. This works rather well for an initial setup but again a second iteration of this is needed at least. I'm tempted to move this into coroutine like I did with the other scripts. In all honesty I should really be doing this straight away. But development is development after all. Furthermore the punches and slams do not have triggers for now as I still must wait for the player controller to be setup. I hope this is soon as testing with the rough one I set up is not how the game will actually play.

Modular Testing Continued... - James McAndrew Environment

Looking back on the previous test i had done i wasn't that pleased with the outcome. The reading on the normal map and AO maps didn't work as well as i hoped for. I decided to try again to see if i could get a better result. One of the reasons that this happened was because the low poly version was REALLY low poly, the final low poly wall test was under 100 tris. This meant that everything was squared off. This is why it doesn't look as good as it could.

Before...

After...

With this in mind i took the low poly back into maya and upped the poly count. As this is only a small section of one of the modular walls it doesn't give a true representation of the size or true count to what the wall would be, however for testing, it works well. The final count of the upped low poly model is still only around 1k tris as this will be modular that too too back. The main reason for doing this was because there is one brick that is sticking out of the wall and the squareness of the previous attempt wasn't good enough and didn't look very good. I am happy with the way that this turned out and with more work and expanded to be actual wall size will work well.

As we are having floating bridges in the game i also worked on a quick mock up of what one of the section might look like. This isn't the final look of these sections because some of the mapping didn't work due to the high poly being too far from the low poly. This test gave me a lot of insight as to how to do these modular walk way properly. In this model the dirt and mud underneath are combined with the bricks on the top. I found that this wasn't the best way to do this for multiple reasons. To give a rough guide to what these modular section may look like however this worked well. I would also like to add some small roots and stone sticking out of the mud to make it look like its been ripped from the ground.  

One of the main things that i am not sure how to do well is the modular cave like parts of the level. This is because unlike walls there aren't any really parts to join together. I will be speaking to Ewan at a later date to find out how to do this properly. Despite this i went ahead and tried to model a rough rock that could be used in a modular environment. The rock itself looks pretty good however i don't think it would work with other modular rocks on the same kind.

To get a better modular look i think that i need to make them more square and less rounded because rounded stuff doesn't combine that well.

--------------------------------------------------------------------------------------------------------------------------

Art Bible - Matt Glen (Concept Art)

This post contains all of the pages from our group Art Bible. The idea of this is to give a rough overview of the art style, design decisions and technical specifications that go together to make up the aesthetics of our game.

Hopefully this document will be a useful reference point for anything relating to the aesthetic of the game.

Character Movement - Jack Schular Animation/VFX

These clips are of the movement animations to be used to test the character in unity. Overall I am quite happy with animations as this is the first time I have created a 3D walk and run cycle. Because of how the character controller is being coded I have had to strip the root transformation from the animations as they do not work with the character controller. In my next pass of these animations I want to make them flow smoothly with correct weight shifts and smaller details such as the toes curling during the movement.

Character Ideas - Matt Glen (Concept Art)

The main character in our game is going to be a sort of martial arts, fighting wizard. He needs to look physically imposing, but also mysterious and mystical. Our project Manager put together the initial concepts for our main character and the direction we wanted to go in with him. Based on these, I created a few variations to help settle on the final look.

After putting these together and discussing the designs with the group, it was felt that the character needed roughing up a bit, as well as the inclusion of runic tattoos to help indicate a magical element.

These aren't particularly detailed character studies, and they are not entirely indicative of the final look of the character, but they should help us to see what it is we want to include in the character and what to avoid. Having certain optional details like a possible cloak helps to try out ideas and see what is potentially possible. In this instance, something more akin to the furthest right is probably a little closer to how the final character will look.

Initial Rig Test - Golem - Jack Schular Animation/VFX

I initially had problems with rigging the golem with a humanIK rig. The rig would not function properly as the model was initially posed in a relaxed A pose. After sending it back to be reposed in a T pose with palms straightened fingers pointing along the x axis the humanIK control rig was functioning properly.

The original conept of the golem was designed to walk upright but due to the proportions of the legs being so small compared to the shoulders I thought that this posture did not fit the concept of a golem. I looked at real footage of gorillas as they have similar proportions to the golem model I was given. I decided that I would use individual animal charactaristics and movements to each of the 3 enemies.

It turned out to be very hard for me to recreate a golems movement in key frames in the video above are my intial test where I was working out how the golem will shift his weight through the different speeds of movement. I plan to make the shoulders rise an fall as the golem puts weight on each arm and focus the movement heavily on him using his arms as propulsion. I will also have to make it flow far more smoothly for the final animation.

Coding - Search Iteration - John Howard

Task

To update and fix the search function to work in a more logical manner.

Overview

Fixing the search function was the next most important area of code for now. I decided to approach this similarly as the patrol was done. Using coroutines that are called within the transitional states within the core state machine. By doing it like this I can again take the code through a step a time and only call the parts that are needed. Firstly the movement to the last sighting has to be completed first and I simply do this by calling a void for one frame that sets the nav.destination to the last sighting transform. Then the search routine is started. The corotuine cannot move through its next destination setter unless the AI is within a certain distance of its current destination. And before even this I call a Randon.range which tells the rotuine how many times to run before returning to patrolling. I feel this is a much more reliable way of timing the routine rather than a timer+1 per frame and also a less messy one. The new point is simply generated by a Random.range of z and x added to the current transform of the AI. This point is then fed into the nav.destination again. This repeats for the amount of time set in the initial time caller as mentioned earlier.

Search Code

Thoughts

This works a lot better than the original setup and whilst it takes a lot of code from the initial one it calls it in a more logical format and allows a better ease of control to a developer changing values. I am quite happy with how this code turned out and shall most likely leave this iteration as is for now.