Games Production - Spring Submission (M3/5)

Our third milestone required a working build with core gameplay. We also tested other team's games in our Year and gained valuable feedback on certain aspects with what to improve on for our next milestone aims.

After finishing the nine different tree models for our game, I started placing them into a scene into Unity so I could then build the nav mesh collider. This would then act as a barrier and limit the player from being able to walk all over the environment. As I went along duplicating the trees, I was also thinking about composition and whether the camera panning would clip with the edge of the map (or with the tree border edge).

Once I had placed enough trees in as a guide, I took an ariel top down shot of the map and brought it into Maya. I did this by resizing a plane and adding in a JPEG image of the map for reference for the nav mesh collider. Above is the first stage of a very long and unexpected process where I did not correctly make the nav mesh barriers. I originally thought to build a wall to prevent the mouse click (ray cast) from landing outside of the player area.

Here, I took another ariel view of the final walls in Maya. After this I then had to combine an outer wall cube with the inside, as I thought that was what was causing the nav mesh bake to be wrongly place out. 

As you can see I have no idea why I did this as I basically made more clutter atop the mesh.

I imported these into Unity to test out again with the map and as expected the 'roof' of the nav mesh barrier became another base. On playing the game, the orthographic camera kept interfering with the walls and I suddenly realised (along with some help from our group's game designer) what I then had to do.

Back in Maya, I selected in the side view, all the faces from the Boolean difference and then deleted the map. This then gave me a height elevation blueprint that I could use.

Above is the result of cutting away the mesh walls from a fill hole action and a clean-up of faces with more than four sides. From this, I could then judge (if it worked in Unity) how much longer I would have to spend on this whole task; as all I would have to do is quad draw a topology correct one atop in 'make live' mode.

After some tweaking of several features in the inspector tab in Unity, I managed to get the nav mesh base to work with the point and click controls!

Here I took a shot of one of the major fix's I had to mend at the bridge which was a separate object to the map when I Booleaned it back in Maya.

I spent around four hours working on the final nav mesh base seen above and below. All I had to do was neaten up the clean-upped one. I did this by popping in and out of quad draw and extruding the paths in make-live surface mode which snaps the faces to a corresponding one.  

Here is a before and after, side by side of the collision mesh bases. I highlighted the correct one to the right.

And finally the baked nav mesh atop the map in Unity. This whole process has taught me a lot, before going into something I have not done before, for the future and that independent learning can be helpful some times and not with others.

Character: Face Remodeling

After creating my new mesh, I was far happier with it than the previous one, it looked a lot more organic without the sharper edges from the lower-poly model. 

However, something that I was not entirely happy with was the face. The human face is a complicated thing to model due to the proportions and detail involved. Therefore I ended up re-making the face several times before getting a result I was happy enough with to use for now. 

Also, my materials got mixed up in the process of tidying up my materials (as I had to re-apply the textures for the reference planes several times) and my default texture was from one of the reference images. it looked... Weird. But kind of cool.

Paper Prototype

Myself (James) and Prem sat down and paper prototyped the combat system for our game.

 
(Example 1.)

We started by trying to figure out ways to re-invent our combat system. At the time the turn based combat in our game was based on a system where the player rolls a dice, the value of the roll would be checked against the value of the enemy dice roll, and should the value be greater than the enemies value then the player would hit and cause a set amount of damage.

Prem suggested the addition of a Stamina bar, which we both agreed would help bring a little more skill into the game. I suggested that the Stamina bar should never have a value over 100, where the Health bar would, perhaps, increase through level ups the Stamina bar wouldn't.

 With a Stamina bar more attacks where added, attacks which had been implemented before but had yet to be different to one another through our original combat system; attacks such as Light Attack and Heavy Attack.

We started talking about how we would calculate damage, we came up with the idea that the damage the player does would be calculated by the value of the dice roll multiplied by a value I.E. You roll a D20 (Dice 20) and you roll a 13, if it was a Light Attack then we would multiply that value by 2 so the damage calculation becomes an equation like this: 13x2 = 26 so with that roll a Light Attack would do 26 damage. This would then give value to the dice the player collects and adds a trade off between dice; D6's have a smaller rang but have a greater consistency in rolls, D20's have high values  for more powerful attacks but the range is vast and the consistency of getting above average rolls would be less. Example 1. shows the results we had through play testing, however more play testing will be needed when the system is implemented into the game.
Weapons that the player collects would add a base additional damage boost to the dice roll I.E. You roll a 12 and the sword has a +5 on it so the roll value would equal 17.

We agreed that every action should cost the player Stamina, Heavy Attacks would inherently cost more than Light Attacks. Defending would reduce the damage taken in the turn but would cost Stamina; whilst this makes sense, after thinking about it there would be little benefit to defending rather than just healing. We believe that Healing won't be conducted through an item but rather would cost the player a turn and would have the results affected the same way as attacks I.E. The value of the dice roll will be multiplied and will heal the player that amount, the Heal option would also regenerate Stamina; the trade off is that you won't be able to attack and the enemy would get a free attack on you. So it makes sense to have Defend reduce incoming damage and have a stamina cost but then I believe it would become a dud option, it would never be used as there would be no benefit. You Defend, lose Stamina and reduce incoming damage but then lose a turn to attack so all you've done is stall. I think we should change it so that Stamina is regenerated somewhat through Defending to make it a valuable option, or alternatively we could remove the option to Defend entirely and just have a base reduction to damage through the Player's armour. This is something I will need to discuss with the team and Prem.
There is an option to run away but to discourage fleeing we agreed that running away should have a Stamina cost during combat, at first we thought 50 points of Stamina would be needed to run away but Josh, our GUI artist, pointed out that that is potentially too high an escape bar and that we should think about lowering the value to a more reasonable value such as 25. However many of these values are subject to change when we play test the system for balancing.

(Example 2.)

(Example 3.)

Prem and I also spoke about how the Health bar would function in the GUI (these sketches are based off of the concepts we have received from our GUI artist). We eventually decided that to achieve the effect we like in our GUI concepts, where there are arrows pointing towards a central heart and they have a gradient of colour from red to green from the inside going out to the edges; there would need to be a bar sprite with arrow holes cut out, then there would be a green bar and a red bar, one on top of the other beneath the bar with the arrow cut outs. as the player lost health the red bar would remain the same size but the green bar would start to shrink, revealing the red bar beneath through the arrow cut outs.