Creators – Week 6

This week we started a new project, a top-down game where we’ll be feeding food to hungry animals who are rushing at us.

We had another asset bundle to download to get the assets we will be using for this project. It’s available on our Teams site.

Upon importing the asset bundle, we start with a basic scene which has three planes, two black ones flanking one with a grass texture. The asset bundle contains a total of four suitable textures for the ground and we had a look at those, and saw how to use them.

The asset pack also contains prefabs, these are pre-made combinations of Unity objects, ready to use. We had a look at some these prefabs by clicking once on them and viewing the preview at the bottom of the inspector. We also saw how double-clicking on them opens the prefab in the game view for editing and how using the back arrow at the upper-left returns us to the scene.

We brought in three animals, a human and a slice of pizza (scaled up by 3 or 4 to make it visible), laid out roughly as shown below:

Making the Player Move

We made a Scripts folder and added a new C# script called PlayerController.cs. At the top, we added two properties:

    public float horizontalInput;
    public float speed = 10.0f;

And Update() we changed to the following:

    void Update()
    {
        horizontalInput = Input.GetAxis("Horizontal");
        transform.Translate(Vector3.right * horizontalInput * Time.deltaTime * speed);
    }

Now, when testing, we see the player can go side-to-side, but it can also go completely off screen! How do we limit this? We do that by adding an if statement; this allows us to check if something is true, and then do something only when it is true.

First we added a new property to the top of the class:

    public float xRange = 10.0f;

This represents the range (between -10 and +10) that we want to confine the player’s position to.

In Update(), after the transform.Translate(), we add the following code:

       if (transform.position.x < -xRange)
        {
            transform.position = new Vector3(-xRange,  transform.position.y,  transform.position.z);
        }

What does this say? If the x part of the players position gets smaller than -xRange (-10) (meaning it goes too far to the left), then we change the player’s position so that the x part is exactly -xRange (-10).

When we test now, we’ll find that we can move as far right as we want, but when we move left, once the player’s x position gets to -10, we can’t move any further.

It’s easy now to add in the same check for the right-hand-side. We can copy-paste the last block of code and make a few small changes to the copy:

        if (transform.position.x > xRange)
        {
            transform.position = new Vector3(xRange, transform.position.y, transform.position.z);
        }

So, the less-than (<) changes to greater-than (>) and -xRange (-10) changes to xRange (+10) in two places.

Now the player is constricted in two directions.

Making a Moving Pizza Prefab

To make the pizza move we make a new C# script called MoveForward.cs and attach it to our pizza slice. In this script we have one property:

    public float speed = 40.0f;

And a single line in Update():

        transform.Translate(Vector3.forward * Time.deltaTime * speed); 

We make a new folder called Prefabs and then just drag our pizza slice from the Heirarchy into it. We now have a prefab of the moving pizza slice. We can delete the instance of the pizza slice in the scene; we’ll be spawning them automatically later.

And Finally…

We looked into spawning the prefab on a regular interval from the player’s position. That’s not part of the final game, but it was just to illustrate making an instance of a prefab from code.

The code for this week’s project is on our GitHub, as always. There is also small additional project there called “ScriptableObjects for a Recipe System” which is demonstrating a way to define ingredients and recipes and was in response one if our ninja’s queries. To download our stuff from GitHub, you can just click on the green button and choose “Download ZIP”

Note that this ZIP file will contain all our projects for the year!

Creators – Week 5

This week we turned our original scene, a truck driving down a straight road. into a two-player racing game around a curved track.

We deleted the road and crates from the old scene, imported a track asset from our Sharepoint site and moved our truck to be on it.

Fixing The Camera

The truck still drives, just as before, as it has the PlayerController component attached, but the camera, while it follows the truck, doesn’t behave as we’d like. It’s always looking in the same direction. We’d like it to point in the same direction as the truck itself.

The easiest way to achieve this is to remove the FollowPlayer script from the camera, and make it a child of the truck directly. We do this by dragging it onto the truck in the hierarchy:

We then select the camera, reset it’s transform component and tweak the Y (height), Z (distance back-and-forward along the truck) and X-rotation (tilt of the camera up and down) while keeping an eye on the camera preview (bottom right-hand corner of the game view) until we’re happy with the alignment.

Fixing the Controls

The controls on PlayerController are set to always use the input axes called “Horizontal” and “Vertical”. If we put two trucks in our scene now, they’d move together, even if one player was using the WASD keys and the other was using the arrow keys.

To fix this, we first update PlayerController.cs. We add two new public variables at the top:

    public string HorizontalAxis = "Horizontal";
    public string VerticalAxis = "Vertical";

And then down in the code where the “Horizontal” and “Vertical” were used explicitly, we replace them with the names of these two variables:

        // Get the player input
        horizontalInput = Input.GetAxis(HorizontalAxis);
        forwardInput = Input.GetAxis(VerticalAxis);

Everything behaves the same as before, but now, looking at the inspector, we can see that we can easily tell PlayerController to use other axes instead of these ones.

The Input Manager can be found under the Edit | Project Settings menu. In there are all the axes currently defined. Note that it’s not usual to see a few duplicates in this list; Unity will always pick up the first one matching the name it’s looking for and ignore the others. The number of axes defined is at the top. We increase the number by four (4) to allow us to make four new axes. In my case this meant changing the number from 18 to 22. Note that the four new axes created start out as copies of the last one in the list.

Open each of these last four axes in turn and name them “Horizontal P1”, “Horizontal P2”, “Vertical P1” and “Vertical P2”. We then need to set the negative button and positive button values on each of them like this:

Axis NameNegative ButtonPositive Button
Horizontal P1ad
Horizontal P2leftright
Vertical P1sw
Vertical P2downup

Close the Project Settings and select the truck. In the Inspector for PlayerController, change Horizontal Axis to “Horizontal P1” and change Vertical Axis to “Vertical P1”. Test the game, note that the truck now only moves in response to the WASD keys.

Fixing the Camera

The camera on the truck fills the screen when it draws, we want it to only draw to the left-hand side of the screen. To to this, select the camera and in the inspector change the Viewport Rect settings like this:

Look at the Game view, the camera’s only drawing to the left hand side of the screen, this is because we’ve set W (meaning width) to a half.

Adding the Second Player

Select the truck in the hierarchy, right-click and chose “Duplicate”. This makes a copy of the truck, including all its components and children. It doesn’t look like that though because they’re right on top of each other. Separate them by moving the copy a bit. I suggest using the overhead view for this.

Rename the trucks “Player 1” and “Player 2”.

We just need to tweak “Player 2” a little bit. Select it and change the PlayerController to use the axes “Horizontal P1” and “Horizontal P2”. Then select it’s camera and change the Viewport Rect making X = 0.5. This means that not only is it half width, but it also starts drawing at half way across the screen,

Play the game. Player 1 should draw on the left side of the screen and be controlled by the WASD keys. Player 2 draws on the right and is controlled by the arrow keys.

Code for This Week

Updated code is on our GitHub repo: https://github.com/coderdojoathenry/Creators-2022. It also includes some camera switching code that I briefly demonstrated, but was too complex to finish in time.

Creators – Week 4

This week we took a pre-made scene with some problems and set out to fix them.

The first two issues were that the plane was flying backwards and at great speed. The initial challenge was to identify what was making the plane move. Looking at the plane, called Player in the scene, in the inspector, we could see it has a script component called Player Controller X added to it.

Double-clicking on the name of the script file (PlayerControllerX.cs) in the inspector allows us to open it. The code for moving the plane is in the Update() method:

        // get the user's vertical input
        verticalInput = Input.GetAxis("Vertical");

        // move the plane forward at a constant rate
        transform.Translate(Vector3.back * speed);

        // tilt the plane up/down based on up/down arrow keys
        transform.Rotate(Vector3.right * rotationSpeed * Time.deltaTime);

We need to concentrate on the line that starts transform.Translate(…). The comment above it says “move the plane forward”, but the line itself is specifying Vector3.back as the direction of movement. Changing this to Vector3.forward makes it move in the right direction. The plane is still much too fast though. This line is asking the plane to move the distance specified by the speed parameter (by default 15m) every frame. What we need to do is to multiply here by Time.deltaTime, the amount of time since the last frame, to convert this movement into 15m per second, not per frame. Here’s the corrected line:

        // move the plane forward at a constant rate
        transform.Translate(Vector3.forward * Time.deltaTime * speed);

The next problem is that the plane turns on its own. In fact, although we’re gathering the value of the “Vertical” input axis in the code, pressing the arrow keys does nothing. We can identify the line of code that’s making the plane turn:

        // tilt the plane up/down based on up/down arrow keys
        transform.Rotate(Vector3.right * rotationSpeed * Time.deltaTime);

This is asking the plane to rotate around Vector3.right (horizontally through the plane) by the number of degrees specified by the property rotationSpeed (with a default value of 100) every second. The multiplication of Time.deltaTIme is what makes it “every second” and not “every frame”, as before. So the plane is turning 100degrees every second, making it do a full loop approximately every three and a half second.

Nowhere here are the user inputs taken into account. How can we use them? Remember that the “Vertical” input axis in Unity works like this:

Input Option 1Input Option 2Axis Value
WUp-arrow+1
<No key pressed><No key pressed>0
SDown-arrow-1

We’re gathering this axis value into a property called verticalInput already, we just need to use it. When multiplied in, it works like a switch. If its off (having the value zero) then no rotation happens. If it’s one or minus one, rotation happens in either a positive or negative direction:

        // tilt the plane up/down based on up/down arrow keys
        transform.Rotate(Vector3.right * rotationSpeed * Time.deltaTime * verticalInput);

Now the plane flys correctly and responds to user input, but the it flies directly into the camera and then can’t be seen any more. First we need to grab the camera and move it to the side of the plane, rotating it around to point at the plane. This is better, but it still doesn’t move. The plane quickly flys beyond the area the camera can see. If we look at the camera in the inspector, we can see that it already has a script called Follow Player X on it:

It has a property called Plane, but nothing’s assigned there. We can set this by dragging and dropping the plane from the hierarchy, or by clicking the small circle icon on the right above and picking the “Player” object from the pop-up list. Running and testing this shows that the camera now follows the plane, but it’s right on top of the plane. It needs to be some distance away. Examining the FollowPlayerX.cs script we see at the top there’s a private property called offset:

    private Vector3 offset;

that is used in the Update() method already:

    transform.position = plane.transform.position + offset;

We just have to give it a value. The easiest way is to change private to public and then specify a value for the offset in the inspector.

The final challenge is to turn the plane’s propellor. Looking in the inspector, we can see this is its own object, a child of the “Player” object:

To make it spin, we can make a simple new script called SpinPropellor.cs and attach it to the propeller. This code works well:

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class SpinPropellor : MonoBehaviour
{
    public float spinSpeed;

    // Start is called before the first frame update
    void Start()
    {
        
    }

    // Update is called once per frame
    void Update()
    {
        transform.Rotate(Vector3.forward * Time.deltaTime * spinSpeed);
    }
}

This is very similar to what we’ve done before, but the axis of rotation is the Vector3.forward here to make the propellor spin in the expected way. I found a value of 1000 or more was good for spinSpeed.

Note that although we’re moving the propellor ourselves, or at least rotating it, that doesn’t interfere with the fact that it’s moving with the plane, because it’s a child object.

Code for this Week

Updated code is on our GitHub repo: https://github.com/coderdojoathenry/Creators-2022 The problems with projects not loading correctly when downloaded has been corrected.

Creators – Week 3

This week we continued our project from last week, looked at three main topics:

  1. Frame rate independence
  2. Creating our own properties on our components
  3. The Input Manager and getting and using user input

Frame Rate Independence

We covered how to make our actions independent of frame-rate. The code:

transform.Translate(Vector3.forward, 20.0f);

moves the object 20m in every frame. As we know, frame-rate isn’t generally consistent between machines. On my powerful laptop, I was getting up to 1400 frames per second at fastest. Most ninjas were getting a few hundred frames per second on theirs.

On the other hand, the code here:

transform.Translate(Vector3.forward, Time.deltaTime * 20.0f);

moves the object at a consistent 20m per second on everyone’s machine. The magic is that Time.deltaTime variable. It is the time, in seconds, since the last frame was drawn. The faster the frame-rate, the smaller this number gets and the result is a consistent 20m per second movement.

Creating Properties on our Components

We can add properties, variables where we can hold and values that we can then use, to our classes by typing a single line into our class definition:

class MyBehaviour : MonoBehaviour
{
  // The new property
  public float myProperty = 1.0f;  

  void Start()
  {
  }
  void Update()
  {
  }
}

Looking at the bits of the line in turn:

  • public – The access modifier. Can be private, internal (which we won’t use) or public. If it’s public we can see it in the inspector, and from other classes. If private we can only see and use it within the class itself.
  • float – The type of value we are storing. A float is a number with a decimal point. An int (short for integer) is a number without one. We might use an int for counting things, but we use floats for real world measures like speeds and positions, etc.
  • myProperty – the name of the variable
  • = 1.0f – Assigning a default value to this property. This portion is optional. the ‘f’ after the number is just a hint to the computer that this is a float value.
  • ; – The standard semicolon to end the line of code.

The Input Manager and Using User Input

Unity’s Input Manager contains the definition of input “Axes”. These can contain many ways of doing the same thing.

The default definition of the “Horizontal” axis means it can be triggered by the keys A and D, or the Left and Right arrow keys or by the joysticks or d-pad on a game controller.

This means input is “abstracted”; we can write our script to respond to input, without worrying how that input is generated.

To get the value of input on an access we need to use code like this:

forwardInput = Input.GetAxis("Vertical");

Here we’re getting the value of the axis called “Vertical” and storing it in a variables called forwardInput.

The value of the vertical axis goes between -1 and 1. Minus one means fully down, zero means no input and one means fully up. Because of this range, we can use this value like a switch, multiply it with other numbers. When there’s no input, it’s zero which will zero out the expression it’s part of.

Here’s the fully updated code for our PlayerController.cs:

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class PlayerController : MonoBehaviour
{
    public float speed = 20.0f;
    public float turnSpeed = 50.0f;
    private float horizontalInput;
    private float forwardInput;

    // Start is called before the first frame update
    void Start()
    {
        
    }

    // Update is called once per frame
    void Update()
    {
        // Get the player input
        horizontalInput = Input.GetAxis("Horizontal");
        forwardInput = Input.GetAxis("Vertical");

        //  Move our vehicle forward
        transform.Translate(Vector3.forward * Time.deltaTime *
                            speed * forwardInput);

        // Rotate our vehicle 
        transform.Rotate(Vector3.up, turnSpeed * Time.deltaTime *
                         horizontalInput);
    }
}

Code for this Week

Updated code is on our GitHub repo: https://github.com/coderdojoathenry/Creators-2022

Creators – Week 2

Hi folks, this week we started our first project. We have a truck that can drive down a road, avoiding obstacles, or maybe not!

We created a new project in Unity, using the default 3D Core template, and called it Prototype 1.

We then downloaded and imported the assetpack from here: [Creators Teams Channel]

The asset pack already included an existing scene, which had a simple environment already. We them dragged in a vehicle and obstacle from the imported assets. Imported assets aren’t just models; they can contain Unity obstacles, such as colliders, already.

To make the truck move, we made a new C# script called PlayerController. The new C# files Unity creates always look the same (apart from the name of the Class, which matches the new file name):

We added the following code to the Update() method to change the transform of the vehicle:

    // Update is called once per frame
    void Update()
    {
        //  Move our vehicle forward
        transform.Translate(0, 0, 1);
    }

The Unity scripting documentation can be found:

https://docs.unity3d.com/ScriptReference/index.html

and the specific page for the Transform component is:

https://docs.unity3d.com/ScriptReference/Transform.html.

This method on the Transform component that we’re calling, Translate() has several forms. The one we’re using here expects us to provide X, Y, Z values. What we’re saying we want to happen is “Change the transform by moving it 1m in Z every frame.

When we run, the car moves very fast off the end of the road. That’s because we’re running at many frames a second. It’s too fast. Next week, we’ll look at making this frame rate independent and controlling the speed.

Finally, I’ve created a GitHub repo for our projects this year. Up-to-date versions of our projects will always be available here after our sessions: https://github.com/coderdojoathenry/Creators-2022

Bodgers – Getting started with Python

Hi Everyone

It was great to get back again with a full year to look forward to and it was also great to see so many people interested in getting involved with CoderDojo Athenry.

In the Bodgers group we got off to a great start, we installed the Mu Python editor, and we wrote our first few programs.

Bodgers

The Mu editor can be downloaded from here: https://codewith.mu/.

You can find our code from last Saturday on the last couple of slides from this week’s notes here: Bodgers Day 1

We also decided we’re going to do a few small projects between now and Halloween and then start on a bigger project after that.

Next week we are going to make a Space Invaders style game, you can find some images for it here: https://www.dropbox.com/home/Bodgers/Space%20invader/Images.

Looking forward to seeing you all next week.

Declan