This week we did a review of everything we’ve covered so far in Unity this year. It was a really usefully exercise as we ramp up to doing our own projects. People talked about their project ideas and I even got so see a few things running. I was impressed with the ingenuity and inventiveness. As I explained, over the coming few weeks, I won’t be presenting much in the way of new material. We will instead concentrate on getting our projects running and polishing them to the best of our ability.
I presented a couple of small sample projects intended to inspire game project ideas. The first was a top-down, single-keyboard, two-player game where two cars complete to drive a ball into their opponent’s goal area. If this sounds familiar, then you’ve heard of Rocket League. This low-rent version I dubbed “Sprocket League”. It can be downloaded from here. It uses the car from Standard Assets, slightly modified to allow the input axes to be defined in the inspector so that each can be controller independently. The red car uses the arrow keys and the blue keys uses WSAD for movement. To make it into a full game some means of keeping score and timing the game would be needed.
I also posted a basic sliding tiles game based on 2048. It is intended to show that we can achieve a 2D game appearance, even while using the 3D elements we have been working with. Although the basic game mechanics are there, it would ideally need a lot of work to bring it up to a reasonable standard. The real game provides a lot more visual feedback to the user than this version. Again, it can be downloaded from here. For those that recall, my broken attempt at making the tiles animate can be enabled via the “Show Me The Broken Movement” checkbox on the GameController object.
Best of luck working on your projects over the next two weeks and I’ll see you all when we return!
This week and part of last week we created a piano! The initial keyboard looked like this:
Each white and black key is a separate SPRITE. We began by drawing the white Middle C SPRITE which has two costumes. The first costume is white and the 2nd is a different colour (you choose) that flashes up when the SPRITE is CLICKED. This helps us to see which sprite is responding to the click.
This week in Scratch advanced we took on the ambitious task of writing a general-purpose 3d wireframe engine. The goal here was to build an engine that we could use to view any structure in 3-dimensions as though we had x-ray vision. We didn’t really know how it might turn out but were delighted with the results! If you just want the code, skip to the bottom!
We didn’t quite know how to start this so we Googled 3D and Wireframe, and we found this article on wikipedia that really helped us understand what it was:https://en.wikipedia.org/wiki/Wire-frame_model
It was a thrill to have such significant games industry figures come to visit us on Saturday. The mentors, dads and dad-mentors were probably the most excited; Wolfenstein 3D, Doom and Quake were probably the most exhilarating games of our generation.
I was unsatisfied with how much benefit people were getting from continuing with the Tanks tutorial and I decided that we’d looked at it enough. Partially because I know some people want to implement shooting for their own projects and partially because one of our guests had invented the entire first-person-shooter genre, I decided to do a project to demonstrate different ways of implementing shooting in a game.
Please excuse the tinny sound; I was using the computers built in microphone.
There are two main ways to handle shooting: ray-casting and physics-based projectiles. We’re going to do both so lets discuss them in turn.
Ray-casting
Ray-casting uses mathematics to determine if a target is in our cross-hairs and, if it is, registers a hit instantly. It’s a good technique to use where the bullet is very fast moving and distances are relatively short. Regardless of action movie tropes, nobody is dodging a fast-moving bullet in real-life!
In Unity the Physics class contains several Raycast methods (documentation here). They all look along a line from a point and return ‘true’ if that line crosses through a Collider. The specific version we’re using can fill in a RaycastHit object with information about what it hit, if it hit anything.
To determine if we hit anything we must:
Find the position and forward direction of the FPS Camera. This represents where we are and where we’re looking towards.
Call Physics.Raycast with this information. If it didn’t cross any colliders, then we are finished.
If it did hit something, then we check to see if that object is a target. We have tagged all target objects in the scene as “Target” so we can easily check this.
If it is a target, we perform the effect we want. In this case, we push the target away from us with force applied to its RigidBody . In another case, we might want to actually destroy the GameObject instead.
Physics-based projectiles
A physics-based projectile is actually an object in the scene. It has a Collider so that it can detect collisions and a RigidBody so that it is affected by physics.
In many cases of physics-based projectiles, the Collider is simply a trigger and once an collision is detected, an effect, such as reducing the target’s health, is applied to the target.
Our specific physics-based projectile weapon is a cannonball. In this specific case, we actually allow the cannonball to hit the target and the physics engine takes care of the effect (knocking the target away).
The general steps that we need for physics-based projectiles are:
Find the position and forward direction of the FPS Camera. This represents where we are and where we’re looking towards.
Instantiate an instance of our projectile prefab. Position it so that it’s slightly in front of us and not intersecting with the FPS Controller’s own Collider.
Give the projectile some forward velocity.
Either:
Have the projectile detect collisions and perform an appropriate effect on the target, or
Simply allow the physics engine to take care of the impact.
The cannonball prefab has a small script attached to it. It detects collisions. Once the first collision is detected, a coroutine is launched. This coroutine waits for two seconds and then destroys the GameObject. This means that cannonballs have a limited life-span and don’t end up littered all over our level.
Area-effect weapon
We have also implemented an area-effect weapon, namely a grenade. In many ways it is similar to the cannonball but we project it with a more modest velocity.
Once created, however, it’s behaviour is very different. A coroutine is launched as soon as it is created. This coroutine waits for a few seconds to mimic a grenade fuse. It then “explodes”.
To explode, the grenade does the following:
Plays an explosion sound on it’s own AudioSource.
Instansiates a particle-effect prefab at the grenade’s location to display an visual explosion effect.
Disables the grenade’s MeshRender component so that he body of the grenade can’t be seen any more.
Uses Physics.OverlapSphere (documentation here) to find all Colliders within a given radius of the grenade
Loops over these Colliders. If the collider is not attached to an active GameObject or if that GameObject is not tagged as a target, we ignore it.
If it is an active target, we use RigidBody.AddExplosionForce (documentation here) to apply an explosion force, emanating from the grenade’s position, to the target.
Two seconds after the “explosion” the grenade GameObject, now invisible, destroys itself to remove itself from the scene. This short delay gives time for scripts to complete and sounds to finish playing.
Please note that although the grenade wasn’t working correctly on Saturday during our session, it’s fully functional now.
Gun selection
Gun selection is handled using the “[” and “]” keys. In the past we have tended to use Input.GetAxis to detect user input. This is good for where we wish to perform an action continuously as long as a key is held down. It’s not so good where we wish to perform a since action in response to a single keystroke. For that, using Input.GetKeyDown (documentation here) is better and that’s what we do.
The selected weapon is stored using an enum. An enum is a special variable type which can only take one of a number of pre-defined values. Since we have a limited list of weapons, three to be exact, this works well for us.
Putting it all together
Our level is a simple terrain. It’s been textured and had trees, grass and a wind zone added to it. There is a simple lake. A few target spheres have been positioned around the map and a box containing a number of small targets has been created as a good place to test the grenade in particular.
A standard first person controller prefab has been added to the scene. Our own GunController script has been attached to it as a component. GunController handles all the aiming and firing of the weapons.
Sound effects for the project are all from www.freesound.org with thanks to the original creators. All other third party assets are from the Unity Standard Assets pack.
Downloading the project
The project can be downloaded from DropBox here. Please ensure you have updated to Unity 5.3.4 before opening this project. Be aware, it’s relatively large at 160MB+.
We are very excited to announce that Brenda and John Romero, who between them have been involved in developing exceptional games such as Doom, Quake, Tom Clancy’s Ghost Recon, and Dungeons & Dragons, will be at CoderDojo Athenry on Saturday 9 April 2016. They will be speaking to us about their extensive experience as leading game developers. They will be joined by their 11-year old son Donovan, who has also started developing games.
Brenda and John have recently moved to Galway from the West Coast USA, and are currently in the process of establishing a game studio, called Romero Games, in Galway. Their brief biographies are below.
Regular attendees at CoderDojo Athenry are welcome to bring a friend if they wish. These talks should be really fascinating for our budding coders and game designers in CoderDojo Athenry, and inspirational for boys and girls alike!
PS: Huge credit to Kieran (lead mentor of the Unity stream) for organising this!
Brenda Romero
Brenda is a game designer, artist, academic, and Fulbright Fellow. She has been in the games industry since the early 1980s. Her credits include such notable games series as Tom Clancy’s Ghost Recon, Wizardary and Dungeons & Dragons. She’s previously sat on board of the International Game Developers Association (IGDA) and chaired several Special Interest Groups (SIGs) including one representing Women in Games.
John Romero
John is best known as the founder of Id software. An exceptional programmer and game designer, he is the inventor of the “deathmatch”. His best known games include such timeless classics as Commander Keen, Wolfenstein 3D, Doom and Quake each of which broke new ground, both in technical and gameplay terms and even spawned new genres.
Additional
John and Brenda are currently in the process of establishing a game studio, called Romero Games, in Galway. Their son Donovan, also visiting us, is writing a game with the help of his Dad and friends and will hopefully be demonstrating it on the day.
CoderDojo Athenry 
