Thursday, 3 March 2016

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.

Sunday, 28 February 2016

Game Combat update (3.0)


I started a new project again, Starting new projects ocassionally re writing the scripts from the beginning is incredibly tedious but it does fix all the errors I come across.

With this version I will be tackling the problem of the state machine, making the game operate better and smoother while keeping it cleaner.

Character: Starting over.

After speaking with my group and my tutor, I discovered that the method of modeling I had been following (with the intent to smooth it closer to the end) was not efficient or particularly usable.


I had one of two options: To try and use the mesh I had made and edit it into a higher resolution model by adding edge loops and smoothing. Or I could make a second attempt and learn from my mistakes.

I decided that a second attempt would be more beneficial, as it would allow me to practice my modeling and save me time trying to iron out errors in my first mesh.

Tuesday, 23 February 2016

Games Production - Spring Submission (M2/5)

For our second milestone in Games Production, the 'vertical slice' grey box had to have been constructed. As I had already modelled simple grey box elements for the first milestone, I set out detailing a major game component; the level's environment.




Before I started constructing the environment base, I tried to find tutorials on how to model and shape a natural landscape; our game being in a rural medieval country. However, I came across scarce content and without knowing it, began modelling inaccurately from a large plane.




After asking my lecturer around the issue, he suggested that I model the terrain in flow with the player's path and route to the end of the level. One way of doing this (saving time not starting from scratch again) was to use the Quad draw tool on top of the previous map using another feature that makes the surface 'live'.




Above is the result of going over my previous environment with the quad draw 'player's path' method. I was very pleased with the smooth results; although it took quite a fair amount of time adding in all the quads and edge loops. Overall the outcome was successful and I also had as a corollary effect, less of a polygon/tris count.




Here is the fixed final map in Maya. Beforehand, with older environments open and enclosed, there were issues surrounding the baking of navigation's around ray-casting (within the game engine Unity).




Nevertheless, I was happy to see that after the topology correction, the navigation mesh worked wonderfully and the player's character could walk up the elevations and across the bridges.




Above is a simple scene in Unity at Uni, testing the map. This basically involved running about the environment and trying the isometric perspective camera settings; while using scripts given to me by the game designers in our group.




The next step involved making DirectX11 Shaders in the Hypershade editor in Maya. To allow the Viewport 2.0 to function as it would look like in-game, I had to switch a few settings around in the Preferences, something of which I had not done in over a year! All that was left to do for the map, was to add attributes such as the TGA image files enabling the texture to be seen in the scene.




Here is a step by step of the progress of one of the trees in our game. I started off from an extended cylinder, adding edge loops and then extruding on the z axis. To give the trees more character, instead of just all perfectly edged branches, I moved some vertices slightly.




I had to create a wide range of trees for our game as the environment is in the country. Here are the nine models I made in a stylized medium topology design.




I scaled the trees as roughly as I could against the human height reference. I also made sure to alternate between different perspective views to give the unique characteristics of each tree.




There were many ways in which I could have created the leaves on the trees. As our game will have a stylized approach, I thought of several forms and shapes. After finding an image of a low poly geometry forest, I found a good example in the shape of a sphere.




Towards the elevated section at the end of the vertical slice, the trees scale up to convey the monumental and vast journey of the heroine/character. Above is the large oak tree I made to represent this.




As the season of our game is in autumn, I made sure to include some trees that have no leaves for authenticity.




Something that I learnt at the end of modelling the trees, was I had left the UV unwrapping to the last minute which was a major error in my work flow. This then led to hours and hours of sewing edges and unfolding after automatic unwrapping. This was a good lesson for the future to make sure I work alongside the sub-tasks while building that could crop up and cause trouble.




Above is a diagram of the trees I made together with the examples below them. Although this part of the modelling was very challenging I taught myself a lot from it for later constructing.

Monday, 15 February 2016

Character: Smoothing Things Out

I found that smoothing my model had the tendency to thin out the limbs as well as lose some of the definition in places such as the face and hands. to combat this I used the Crease tool to sharpen the edges around certain points. Retaining the edge even after smoothing. The smoothed model is a lot more eye-pleasing than the smoothed mesh.


Friday, 12 February 2016

Character: Modeling 1

Getting the base sketch for the model sheet, I was able to start the character model. I needed to import the references onto an image plane and align them to ensure that the side, forward and back views all aligned. After setting up the reference on it's own locked layer. I made the torso out of a sub-divided cylinder and used more cylinders for the arms. Extruding the cap faces to make the neck, hands and feet.




After making a humanoid box-creature, I cut across the stomach and limbs in order to add more definition to the mesh. I don't need to add too much as the model will be smoothed later.

Tuesday, 2 February 2016

Character: Starting the Base Model

I used a reference from the internet alongside photo reference while waiting for the concept of the main character, So I could start modeling a basic shape that would become the main character. This took some time as I'm not very efficient with Maya but I hope that this role will help develop my 3D modeling skills over the course of the project.

What I will need to do is model, texture and rig at least two characters (a human and a monster) but I intend to modify these models to create NPCs and enemy variants.




I hope to get the finalised model sheet soon, as I will not be able to accurately model the character.