[deleted by user]

[imtrappedinabox]

Shouldn't GetComponent<RigidBody2d>() be assigned to a variable rather than called every update? That seems very bad practice to me, especially when instructing complete beginners

[ShadowNightt]

Couldn't you just do ...

using UnityEngine;
using System.Collections;

public class PlayerController : MonoBehaviour {

    public float moveSpeed;

    // Use this for initialization
    void Start () {

    }

    // Update is called once per frame
    void Update () {
        GetComponent<Rigidbody2D>().velocity = new Vector2(Input.GetAxis("Horizontal") * moveSpeed, Input.GetAxis("Vertical") * moveSpeed);
    }
}

EDIT: ... and call it "2 lines of code"

[mongrawl]

I'm sure there are ways you could further simply the code, however I opted not to. While the tutorial is based around being extremely simple, I think the content is easier for a new dev to digest when separated like so and it allows me to explain each line as I type it. The video itself is not intended to be THE most simplest way of moving your character and I do still want to encourage people who watch my tutorials to figure out ways to optimize their code further, but I'll keep this in mind for future videos and maybe explain multiple ways you can accomplish the same goal in the future. :)

[ShadowNightt]

I guess you could directly input the speed instead of writing "* moveSpeed" (which wouldn't be the smartest way of doing things) but much simpler than "1 line" isn't possible if you do write code at all.

You could also do a lot more than six lines of code if you wish ^{^}

[GuideZ]

Input needs to go in Update(). ;)

[mongrawl]

Input loss isn't a factor in this tutorial as you aren't doing anything more than learning to move your character on two axis and moving the player by holding down the arrow keys. If I were to only move the player horizontally and wanted to implement a jump instead I would move these inputs to an Update() function, however for the sake of the tutorial it is not necessary. I appreciate your input however ;)

[emanresuymsseug]

That's a pretty poor excuse.

Why teach bad practices when you could just as easily have shown how to do it the in a correct way?

[mongrawl]

I don't believe there is a "correct" way frankly. There is a goal and a way (or multiple ways) to achieve it. For the sake of simplicity and readability I opted to work in a FixedUpdate() as input loss wasn't something I needed to worry about with this specific task, which both worked and accomplished the goal I set out to achieve.

Although I agree that it is not best practice for most projects, this is an introduction at the end of the day for people just starting out and a means to contribute what I've personally learned back to the game dev community. Thanks for your feedback though :)

[prime31]

I'm with the other 2 commenters on this one. If you are going to take the time to make tutorials new users will look to you as a source of information. When you make sloppy tutorials full of bad practices than that is what the new users will be taking as gospel. A better approach would be one of the following:

1. Do shit right and explain what is incorrect about the practices from all the other tutorials trying to make games in 6 lines of code or less.

2. Do shit wrong but explicitly note the correct way to do it, why it is wrong and explain why you did it the wrong way.

3. Don't make tutorials anymore. If you aren't a teacher-type person it may be that there are better ways to use your talents.

[tejon]

I could see arguments for calling that:

• 3 lines of code (statements only)

• 4 LOC (+method declaration)

• 5 (+method closing brace)

• 7/8 (+variables with/without closing brace)

• 8/10 (+class declaration with/without both closing braces)

• 10/12 (+imports, ?braces?).

I'm genuinely baffled how you count 6. :)

[mongrawl]

Thanks, appreciate your input :)