AA shooter: Turrets and particles

With Richard absent this week, I worked on my AA project with the time given. I had a great idea in mind for my two player objects. Player one would have control of a machine gun turret that would fire lots of bullets very quickly, that would be controlled by aiming with the mouse and pressing LMB to fire. Player 2 would have a slower firing but harder hitting rocket launcher that used the Xbox 360 controller, with the right stick aiming and RT firing.

This contrast in weapons means that players will need to co-ordinate themselves and work together in order to win the game and not let the generator be destroyed. The faster firing player 1 needs to worry less about accuracy as they're firing a huge amount of bullets, but also deal less damage, whilst the rocket launcher is slower so needs to be more accurate and packs a much bigger punch as result. 

Picture of turrets next to each other

AA Shooting game: AI path-finding

For my game I'd like to have enemies that move up towards the player from cover to cover, before finally approaching the generator object and attacking it. In order to do this I need to use a navigation mesh and set points for the enemies to move between. I've created an array of points for the enemies to choose from, where they're limited to choosing from groups of four at a time. With the checkpoints set in rows of four, the enemies move from row to row advancing towards the players and generator.

rows of checkpoints

Unfortunately when all areas around the generator are occupied by enemies, even though I tell the next wave to wait until they're free, they try to occupy the spaces and cause a huge stack overload. Hence for now I've been forced to step back from the AI path-finding and had to stick with simply spawning them at set points around the players. I would like to play with this again when I have more time but for now, I have to give up on it.

Dark Arts 4: Statics, XML and Shaders

Static classes cannot be allocated, therefore there can be only one of them in which every method and variable must also be static. They can be used to load in files and store variables from them, such as settings, as well as wrap up methods you know will be needed in multiple places. Static classes are never deallocated which makes them really useful for keeping data around between scenes in Unity, like textures which would save on loading times.

Static class to add and remove textures at will

XML was designed to be easily read by people as well as computers. All XML files must begin with the header of    <?xml version="1.0" encoding="utf-8" ?>    .  From there you have to define an element which will be the name to call when needing the data inside (similar to a class). Inside that other elements can be defined which contain the precise data you require, in the form of a 'Key Value' pair e.g <player lives="3"/>. Every value is recorded as a string.
To use an XML file, you need to first parse it into Unity and then select the base element you want. Then you can walk through any children and use the key/value pairs as needed.

XML parsing class

UI Card Game part 3

The final stage of the game, was the actual game mechanic itself. With the cards randomly shuffling upon starting the game, all I had to do was set the card backs to display as opposed to the front. I needed to set cards to flip upon being clicked and check if it matched the ID of the next card being flipped. If so then the cards needed to remain upright, otherwise flip them back.

To do this I needed a method in the card behaviour that passed the cards information to the game manager upon it being clicked. When two cards have been clicked and passed their information, a co-routine to compare the cards is started. If the two cards match, the tally for pairs needed to win increased, bringing the player one step closer to finishing and they then remain unclickable. If they don't match, both cards are flipped back and made clickable again.

Card game partway through

The final thing to do was provide a win screen when the player matched every card. This was easily done by checking if the pair tally equaled 8 or not. If so then a delegate message is sent to display the win overlay image and I even added music to make it more of a celebration.

Finished game with win display

Dark Arts 3: Delegates and Co-routines

Delegates are used as a reference to a method with specific parameters. We can use them if we have multiple versions of a method that we need to choose from and how to handle each one. To define the delegate all you need is:  public delegate <Type>   MethodName(<Type> variable);
Another good use of delegates is a messaging system between classes. A list of delegates can be created as a way to keep track of the receivers, that way we always know where the message will be going. The 'listeners' can then chose whether or not they act on the message depending on what it is.

Example of using delegates for message system

A co-routine is a method that can be paused and continued later. This is very useful to script events and create situations where something is waited for or triggered at a certain time. Using a co-routine that contains yield is what causes it to continue in the next frame from where it left off in the last one, rather than starting from scratch. This is what I've done in order to fade out the bullet holes in previous projects I've done so it's good to find out I did it to a proper standard. A co-routine can also be stopped at any time but only by calling it's name, giving you even greater control on how it carries out.

Co-routine that fades and resets colour

UI Card Game Part 2

With the main menu sorted from last week, the next objective was actually adding cards to the game scene. Rather than layout every card individually and be limited to the space available, we were taught a clever way to set up the scene so that cards are generated upon playing the game. In order to do this I needed to add a background to the game scene, which is what would control the card position and generation for me. The component that allows me to preset the positions and spacing of the cards is a 'Grid Layout Group', which has cell sizing and spacing values. I needed to add a few cards initially and set the cell size to fit the card, then adjust the spacing to my liking. From there I set the starting position (top left), alignment (middle centre) and constraint count i.e. number of rows(4).

Components in the background object

Once the card layout was done I could clear all cards off the scene and start on the generating scripts. To start a card face is needed so we created a card model class that creates the variables, then a behaviour class which assigns them to the card. The next step was having a game controller that creates a grid list for cards to be generated into and then fills it. However this on it's own would put each matching pair together, so we need something to shuffle the cards around. We were provided with a complex method that made use of the generics we were taught two weeks ago by Richard. The method uses the 'RNGCryptoServiceProvider' class which is essentially a random number generator. From what I can gather, it uses this to generate a byte for a box position and then assign a card to that space. The finished product of this week is a game screen filled with shuffled cards.

Shuffled cards in game

Shuffling code

Dark Arts 2: Singletons and Entities

In the second of our dark arts sessions we were taught about the uses of singletons and entities in our coding. As I've already covered the singleton pattern in Java, it was simple recap when Richard talked about how to use it, however it was very useful to see the examples he gave of where in a game it could be used such as for UI managers. The singleton pattern is where you set something up that is only created once and called anytime it's ever needed. This stops multiple copies of the same object from being instantiated, lowering the amount of errors you could get and also keeping memory management tidier. The downsides are that it isn't thread safe and everything can access it, which is just as useful as it is a liability.

How to instantiate and keep an singleton

Virtual methods were the second subject Richard covered, which are methods a class can essentially inherit from, unless the method is overwritten. Essentially it allows you to write one class with a lot of methods in for a variety of objects that will use them, but be able to change it for each object if needs be. The base class is essentially the game entity with all other classes using it if they require the methods.

Example of two classes using a base class but one overriding the method

UI Card Game

Over the next 3 weeks I'm going to be taught how to use the UI system in Unity to it's full capabilities. The game is a simple copy of a card matching game where you flip the cards to try and find the pairs. This first week covered the basics of the new Unity canvas system and how to make a menu from it. The first step was to add the background for our menu that everything else will be laid on top of. I needed to play around with the anchoring to make sure the background covered the whole screen upon playing the game.

The next focus was adding buttons so the player can navigate from the main menu to the actual game.
Buttons in Unity 5 are far easier to use because they come with a preset OnClick() section. All I had to do in order to make a working button was create a script containing no more than:

public void LoadLevel(int _levelIndex)
    {
        Application.LoadLevel (_levelIndex);
    }

This is all that is needed to create a loading button. I checked the build settings so I new which scene had which number, then added the script and game number into the button script. When I started up the game and pressed play, it took me straight into the game scene. I then just needed to position the button using anchors again then add a title and I had finished the main menu.

Finished menu screen

Dark arts 1: Generics

This week we had the first of our ‘Dark Arts’ sessions with Richard Weeks. Richard is head of a company called Total Monkery that operates from Plymouth and we’ve been lucky enough for him to come in and teach us some industry standard programming methods. Having somebody who runs his own company and has experienced the games industry first hand come in to teach us is an excellent opportunity. While what I’ve learnt so far at University has been essential, Richard is going through ways to make Unity work in ways it normally wouldn’t, hence why these are called ‘Dark Arts’ sessions.

The first session covered generics. This allows us to make custom types for classes, methods and variables which has lots of uses. When used for a class, it allows the user to get the variables and constructors, meaning you can create objects in the generic class from another. When using a generic method, the type of object you want to pass in must be specified before the parameter, this way a single generic method can perform an operation on many varying data types. One example (shown below) is a method to create entities where a list of different entities can all be passed in. Dictionaries can use generics to form lists with a variety of different types by having a generic key with a corresponding value.

In an example we were shown, one method assigned class types and names, while the other passed in a large variety of different types of entities.This is something I could use in my game to make it less prone to errors and easier to work with as a whole.

Entity inheritance example

Brand New Game Idea

Following on from my demo session on Monday, the last person to go over my game was my module instructor. When he played through my game he started talking about an entirely different game concept to the one I'd planned and constructed. Rather than talking about my original idea of the western themed target based shooter, he brought up the idea of an anti-aircraft style shooter. My characters are locked in place so can't move, yet can still look around and shoot from those positions. He said this reminded him of an AA turret style and that idea would probably be far more interesting and immersive. Originally I was skeptical of this idea but the more I thought about it and went over it in my mind, the better it was sounding and I've now decided to take this concept forward as my new game.

The new idea revolves around each player being in command of a turret and trying to defend a generator from swarms of enemies. Player 1 will control a machine gun turret which fires very fast but doesn't do a huge amount of damage. Player 2 will control a cannon like turret which fires slower than player 1 but packs a much bigger punch with it's shots. Both players must defend the generator from oncoming waves of both ground infantry and air forces. Infantry will be easier to kill, therefore there will be a lot more of them rushing the player, whilst aircraft are far tougher and in fewer numbers. If the enemy destroys the generator it's game over.

AA gun appearance I want to recreate

For extra mechanics I thought about airdrops every now and again to buff the players or hinder the enemy in some way shape or form. These will float down from the sky and players must shoot them before they land in order to activate it. On top of these, players will level up based on how many enemies they've killed. Leveling up allows players to add extra weapons, increase their fire rate/damage and increase the generators strength for example. I will be going through the entire design process for this game shortly in order to come up with a more refined and complete plan.

Airdrop that players can receive 

I think this game concept will be more successful because it's far more immersive for players compared to my original idea. I liked the Western game but I could see how people could become bored very easily, especially since I made it quite slow and the need for precision is necessary. This new idea is much faster paced and has far more explosions, which everybody loves in games. I was sold by what little my instructor suggested and feel what I've built on top of this is nothing but an improvement.

Demo Results

So Monday marked the first presentation of our games for the development module so far. For the past 2 weeks or so I've been working on a variation of the Western themed shooter that I've been designing. The mechanic of target shooting has stayed the same however I've chosen to lock the player in place and situate both players next to each other. I made this change because if both players could see each other then I would need to spend a lot of time making character models and animations. Locking the players in place together meant I could have a nice looking game without the need to make character models.

In preparation for the game demo I made a google form with some questions on it to record peoples feedback for my game. I asked questions about everything I'd currently implemented such as the characters shooting ability, the targets and the dual wield power-up.

Character Shooting - Overall the feedback for the shooting was that to firing was too slow, even   though it was meant to represent a revolver, and that the aim sensitivity was far too high. Changing each of these is very simple and just involves adjusting a few variables in the inspector. Other feedback around the character was that UI elements were too small to notice.

Targets - The size of the targets was commended however many people said adding a variety of sizes worth different points would be a good idea, which is something I was planning to do. Moving targets was also something that was suggested that I'd planned to do meaning I'm along the right track in terms of targets for the game. The only suggestion I hadn't planned was to vary the spawn rate throughout the game. Either a random time generator or perhaps more spawning as time goes up to ramp up the pressure of hitting them.

Re-sized targets

Dual Wielding - A common comment about this idea is that the controls are confusing. I'd set it up so that LMB fires the right hand weapon, like in most games but then RMB fires the left gun when active. This was a bad move because it confused most people, even myself at times. A few comments suggested sticking to LMB alternating the shots rather than 2 separate buttons which I agree with. One person suggested adding tougher targets to make use of the extra fire power which I quite liked the idea of.

Enjoyed - People seemed to enjoy the whole concept of shooting targets in a shooting range style.

Disliked - The things that cropped up the most were the using alternate mouse buttons to fire, the sensitivity and the small UI messages.


Taking everything into account I have plenty to work on to make the game smoother and more enjoyable as a whole a few of which I've already started on. Refining the shooting is the feature because it is the main element of my game.

Re-sized UI text

Xbox Controllers

For my game I need to have different types of input so that two people can play the game at the same time. Obviously for a PC game I’m going to use the mouse and keyboard for one player, then for the other I’m going with an Xbox controller as it’s set up to work well in Unity. Setting the input axes for the controller has been quite simple and I think it’ll be easy to implement the controls into my final game.

To start with I wanted to add movement and look inputs. I discovered that the input manager is already configured to move the player with the left stick which saved me one job, however the right stick look controls needed to be implemented. I needed to create 2 new inputs called Controller look X/Y which were set to the 4^th and 5^th axis respectively. Upon playing the game, right stick caused the player to look around, although the Y axis was inverted so I simply checked the box the reverse it.

Two custom inputs

The other things I wanted to play around with was adding the ability to sprint, crouch and jump from the controller. I decided that the controls I wanted were: pressing in left stick (8 on diagram) would sprint, A (0) would jump and B (1) would crouch. Each of these were surprisingly easy as all I needed to do was add an OR condition to my if statements that check the corresponding action can be performed. This solution means that the player can move with either the keyboard and mouse or controller, so for my actual game I’ll need to add a check at the very start of the movement script to assign each player a single input type rather than the ability to use both.

Xbox controls map for reference in Unity

Leap Controllers

Using the Leap motion controller was definitely a new experience for me. It works by using infrared cameras and registering what objects appear in the way, rendering them into game objects. I personally don’t think I’ll be using them in my game but it was a fun experience and I had a few ideas about what they could be used for nonetheless. We were provided with a Unity project containing lots of different scenes that showed off the Leap’s uses and we were told to have a play around, getting use to this new tool.

The first scene simply showed the users hands and responded to you doing different things like clenching your fist, wiggling your fingers and moving them around. This scene is only to show how the Leap controller registers you, so doesn’t have much to do in it.

Simple hands scene

The next scene allowed me to interact with an object, in this case a flower. The flower grows in the centre of the screen allowing you to pick it and hold it. From there you can move it around to look at it and even pull off petals one at a time. This could be a little fiddly at times and the Leap can be a little temperamental, especially if something is covered from below so the Leap can’t see it entirely. However this was a nice little scene to show some basic interaction.

Scene showing how delicate the Leap can be

My favourite scene was where you had 6 little cubes that you could gently pick up and stack upon one another. Again the Leap could have slight problems of freaking out making it very difficult to stack all of the cubes, but as long as your hand wasn’t too near the tower you would be alright. This example of the ability to move objects around and place them down could be very useful in a two player platform game of some form. 

Tower stacking scene

The final scene was very enjoyable and contained a room full of boxes which the user can scoop up and throw about at will. This is more of an example of mass movement/control over a situation using the Leap. It was quite fun and relaxing to spend a minute or two throwing boxes around and watching them bounce off the walls for a while.

Messy block scene

Fading Bullet holes

When I was playing around with the bullet holes, something I definitely wanted to do was cause them to fade out over time rather than just disappear immediately. The effect is slow and subtle so won't pull people out of the immersion of the game unlike constantly destroying the texture instantly would. After a bit I research I discovered that textures have an alpha setting along with the RGB settings. Alpha is the transparency of the texture, so in order to get my bullet hole texture to fade I needed to adjust the alpha setting over time. The way I thought of doing this was to use the interpolation mechanic I'd been taught the other week, to slowly adjust the setting from max to 0 over the course of three seconds.

Fading alpha interpolation code

After figuring all of this out and getting it to work I added it to my prototype scene to show it off.

Bullet hole partially faded

Pendulums and More Shooting

Continuing on from last weeks work about shooting, we added a few modifications to the scene. The first addition was adding a cross hair so the player could see where they were going to hit when firing. Using the new Unity 5 UI system makes adding text and images to the UI incredibly easy. Rather than having to code the entire object in a script, you can add a canvas to the scene and place an object upon that canvas. For images just move it into the position you want and for text items, do the same them add the text in and even stylise it if needs be. So I placed the cross hair image dead center of the screen, adjusting my bullet spawner to fire at the same point upon clicking.

Cross hair in scene used to destroy block

The second thing added to my shooter this week was a bullet hole upon impact. In order to do this I had to use Ray Casts for the game to judge on whether an object would be hit upon firing. If this is found to be true then a bullet hole will be instantiated at the point of impact giving a more realistic affect to the scenery. To stop graphical glitches, the bullet hole is not applied directly onto the object it hits, but set as a quad 0.01 units in front of the collision point. This stops the created bullet hole and target object from fighting for the same world space and flickering when looked at by the player.

Bullet hole created by bullet collision

When this was all implemented however, I very quickly found that the holes stacked upon one another. On top of this, since they were just placed where there was a collision, if the object the bullet hits gets moved then the bullet hole is left floating in space. To solve the first problem I needed to destroy the bullet holes after a little while to stop them from filling up space, so created a script which waited for 3 seconds after being created, before destroying it. To stop floating holes I had to set the object getting hit as a parent of the bullet hole. This means wherever the object hit goes, the bullet hole will go with it.

Code to create bullet hole and set object collided with as parent

After we finished with the new shooting mechanics, we moved onto something new: pendulums. Making a pendulum was surprisingly quick and easy, since all you need to add to an object is a Rigidbody and a hinge joint. When applying the hinge joint you add the object that will be the connected body and that causes the two objects to act as a hinge. Adding multiple objects in a row and hinging each to the previous one creates a chain that we added a sphere to the end of. After creating a wrecking ball it only made sense to add a wall to knock down with it, which is exactly what I did.

Pendulums swinging to destroy wall

Improving Catapult Mechanic

Whilst the catapult worked perfectly well, a few improvements could be made to make it more efficient/rounded. My first improvement was only allowing the object to aim and jump if the mouse is clicked whilst hovering over the object. In order to do this I needed to register the mouse position upon the person clicking. I set a ray cast to fire from the camera from this point and to see if it hit the box. If so then a Boolean 'hasClicked' is set to true, else it remains false. If the Boolean is true then the player has clicked on the object so can now fire it, otherwise nothing happens.

Object with aim dots showing path

The second improvement was altering the force applied depending on how far back the mouse was dragged. So the object can perform either a large leap, small hop or anything in between. To solve this issue I was required to use a few simple projectile physics equations that determine the distance based on the velocity and gravity. Once the equations have worked out the distance travelled, the position of the dots could be adjusted to create the new flight path of the object. As all of this is in a method called within update, the path will update in real time based on how the player is angling the shot.

Physics equations applied

This way, clicking on the object and moving the mouse to aim and apply force gives the feeling of pulling something back in order to fire the object forward.

Angry Birds and First Person Shooters

In week three we started doing something I've been looking forward to: first person shooters. Whilst we covered an Angry Birds style catapult system as well, the FPS mechanics are what I definitely want to use in my game, so learning about it helped me broaden my ideas for the mechanics I could use. We started the catapult/trajectory mechanic first, so I'll cover that to begin with. The objective was to create an object that, when the mouse was clicked and held, produced dots to show the trajectory of the object. Upon releasing the mouse button the object would be propelled along that path shown. In order to produce the trajectory, we needed to use two equations which calculated the distance the object traveled in both the x & y axis and project the dots along this path.

Trajectory equation code

For the first person shooter project we had to put a first person character controller into the scene and to that we attached a bullet script. This script very simply creates a bullet game object and applies an impulse force, which uses the objects mass and gives realism in the trajectory of the bullet. Initially the code was set to fire on every mouse click, which produces a semi-automatic gun. I changed mine to fire when the mouse button is down which creates a fully automatic gun, albeit an incredibly fast one which I'll need to tone down. To stop the scene from filing with useless bullets after they're fired, the bullets are set to be destroyed after 3 seconds. A pool manager would be far more useful and efficient so I'll work on that in my spare time.

Bullet fire code

In order to make the bullets fire from an appropriate position on the player, a gun script is needed which sets the firing position of the bullets to a specific place. In my case I used an empty game object attached to the right side of the player. This makes it look as if the player is firing a gun in their hands. For fun I added a second bullet spawn to the other side of the player to appear like the player is dual wielding the guns. These scripts are something I'll be playing around with a lot in order to get the best feel for my guns in my game.

Shooting block tower

Physics Debugging and Manual Interpolation

Following up from Monday's session, we implemented debugging to see how Unity controls the change in velocity. To do this I added a max speed which, when reached and passed, lowered the speed back below the maximum. The speed was not lowered to a constant however and continues to increase meaning this process happens very quickly multiple times a second. To show this, a line is set to be drawn that shows the direction and magnitude of force. This line appears to vibrate/shake rapidly when the player moves which is the program constantly adjusting the velocity.

Cyan debug line in physics scene

Another thing I added to this weeks work was creating manual interpolation rather than have it bounce back and forth of it's own accord. To do this I only needed to tell the co-routine that it should only operate when a specific button is pressed and held. This sort of mechanic could be used for moving platforms and can even be set up to activate the interpolation upon a single button press, allowing you to make elevators.

Physics and Interpolation

Adding to what we were taught last week about movement, this week we started applying physics to objects and seeing how it caused them to interact. We started off by adding physics to the character in order to make it look like the object is accelerating rather then going straight from 0 to the desired speed.

Code to apply force in direction of movement

We also learnt about interpolation. This is the process of moving an object smoothly between 2 points so it hits every point in between them, rather than jumping from one to the other. In order to do this we needed to learn about 'Lerp'  which interpolates between the two points for us.

Lerp code snippet

Once we had learnt the basics and got a system set up, we started to use co-routines in the interpolation. This is like a separate method that can only progress to the next step once the previous ones have been completed so can be held waiting for a long time until conditions are fulfilled. We used an initial co-routine to send the object from point A to B, then set up a reverse system to move it back.

Initial and reverse co-routines

Shot of interpolation in action

The last thing we were taught was how to make different objects act like they were made of different materials. For example, two materials I made were metal and ice which, when applied to an object, caused it to interact with the environment differently. The metal material had high friction and very low bounciness which made the object slow and heavy whilst moving. The ice material also had low bounciness but in contrast, next to no friction. This caused it to slide around and have other objects slide off of it. Physics materials will be useful if independently moving objects interact because they will make the collision feel more realistic based on the material they're designed to be made of.

Extra Movement Mechanics

In the second session of the first week we were told to add more mechanics to our character controller, so I came up with the ideas of sprinting, jumping, crouching and a mouse follow system. To sprint I simply created a second variable with a greater value than the initial speed, then set that as the speed variable to be used while the shift button is pressed. In order to jump I needed to obtain the objects Rigidbody and apply a force upwards when the appropriate key is pressed. For the crouching mechanic I set the scale on the Y-axis to half upon pressing a button once and to double back upon pressing it again. I also reduced the speed and took away the sprint ability while crouched for realism.

Crouching mechanic code

In terms of the mouse follow, I struggled to make a script for it myself. So I looked on the internet and found a script that works perfectly, then spent time understanding how it works and editing it to make it more unique to me. It involves creating 2 enumerations: MouseX and MouseY, which will control the relevant axis. The script is attached to both the character and the camera with the MouseX setting chosen for the character and MouseY being applied to the camera.

First person mouse follow script

MouseX allows for 360 degree rotation in the X-axis and therefore allows the character to rotate in a full circle. Mouse Y is limited to looking 60 degrees both up and down, creating more realism and stopping strange viewing angles. The reason this setting is applied to the camera is applying it to the character would cause them to rotate in the Y-axis and ruin the other rotations and character movement. Therefore the camera and character rotate independently on different axis but as the camera is a child of the character, it rotates with it in the X-axis.

Unity scene in game showing angled look at object