Unity Live Training Method

Hello Unity (builders, users, teachers)!

Hello Adam and Mike, (I've heard your voices a lot over the past few months!)

I have an issue with the way that in general, the live training is carried out. I have not yet been in "live" training but have been watching the archive videos, (although I do intend to see how it goes on the 12th December).

Before I explain my issue, I feel I should give a bit of background on who I am, in the hope you can see my point of view.

I have been programming in a range of languages from QBasic back in the early 90s up to doing web development as my full time job using PHP and various related languages and databases. I am very competent with script coding. My personal specialty is code security, as the internet is an immensely insecure playground.

In the world of web architecture I have spent many years doing things poorly, and then spent several more recent years shocked at what I used to think was good programming, I am now even more shocked at things like StackOverflow being awash with poor methodologies and bad approaches to problem solving. Bad meaning inefficient, unadaptable, insecure, etc. Anyhow, in summary, the internet is very forgiving for mistakes (oh PHP, you beautiful fool), but the problem is that with many, many people these mistakes become habits and bad habits leave problems, corruptions, security loopholes and a mentality that if it's good enough it doesn't break, it's good enough not to need improvement.

"Good Enough" is never how things should be done. "Good Enough" is no longer how I work at all.

Anyhow, I have been off and on toying about with Unity for a year or two, and finally a couple of months ago I got the time, and the energy to actually saturate myself with the tutorials and the archive live trainings to get my head into the depths of how Unity works.

I ultimately have a very clear and very precise idea for a game I would like to create (and possibly, if it's any good and positively reviewed by friends, release. At that point I would be looking to buying Unity subscription).

Ok, that's me.


Now, I've been watching the tutorials, and then moving on to the live training archives. I feel there is a consistent element that comes across which is the reason for this post. When explaining something in a live training, there is a constant element from the training tutor (whomever it be) that there is a time pressure, that certain aspects can't be explained because of time, or that best practises are not bothered with due to it would take a little bit longer than a "good enough" method .

I have seen in various videos from both Mike and Adam (admittedly some going back as far as 2014) numerous different ways of setting up pseudo:singleton GameManagers, as well as varying descriptions of what a Singleton is. I have seen a very good setup for a singleton GM by Adam which trumped the previous best method I had copied down from a previous video, but this method had absolutely no explanation beyond what amounted to "use this, it's great, it's the way to do it!". Why?

There are now a huge archive of tutorials but each one has a focus but the parts that are not "in focus" are often rushed, poorly or inefficiently programmed, or otherwise not explained by the tutor with more than a passing comment. This means that the tutorials -while very good in general-, always have significant parts of them which are under par.

Some example instances of this would be:

• Lack of using Getters and Setters
• Lack of using singletons and/or wide varieties in how these singletons are structured
• Not using object pooling. I watched so many archive videos and built various self-training/testing games before I even realised that you could object pool in Unity!

Unfortunately I don't believe people can always destinguish which parts of a video are best practise on-topic parts and which parts are just there to make the tutored topic parts work,


So, my request is can you consider for future Training sessions adding "breathing space" to the timescale, so that you then have the time to a) describe to people who may not know, how to do things the best way, and b) explain more about various aspects of the code generated which is not the centrepoint of the tutorial.

I realise this adds a further issue of timescale to the tutorial topics, but rather like a film with too many storylines, the tutorials can be more of a rolling series, say 4 tutorials to build a basic game, yes you can do it in one, but doing it in 3.5 (and with some free time for comments and explanations) means there's the time to then go through each part so you can show people the best way (or at least, a better way) we should be using the opportunities that Unity presents to us. Each tutorial can then specialise on a certain aspect of the development, such as object pooling in one video, and game management class in another, etc.

I do also realise that people watching the videos can be of any skill level so it's hard to adapt to a specific skill level and I don't want you to adapt the videos to my skill level, but to simply try to set your video code to be of a uniform level, so you don't have a construction that is 20% awesome (the topic of the video) and 40% ok and 40% underpar but good enough.

I feel that unfortunately it is only due to my day job working with code and my knowledge that people will do things just good enough, that I can see so many code aspects from the Live Trainings that can give people a false sense of the correct way of doing things. I see a number of poor habits that I would fall into approaching Unity Live Training as a code newbie. (And things I have such as not using object pooling!)

----------------------------------

On another slightly related note. Could you possibly get out the habit of naming variables after their types? It's easy on the brain but it makes code memory and code writing horrific, when I see I have an error on my `gameManager` , because it should be `GameManager`, and it takes me seconds longer to understand the scripts on your tutorial videos because I have to mentally work out if the words are types or variables, yes there's a case difference on the first letter but when reading a tutorial video screen full of MonoBehaviour code, it's not a clear differentiation. Word repetition causes word meanings and sentence syntax to be easily lost and takes longer to mentally process.

I personally [not professionally] use the system of "the", so you would have in a tutorial:

• public static GameManager gameManager;

I would have:

• public static GameManager theManager;

and then you can far more easy [and more quickly] see what text is the type and what text is the variable name, in any context.


----------------------------------------

While I have raised two issues here, I would like to say that overall I am very grateful for the videos and the work everyone puts into them, and I do find them generally extremely beneficial. Thank you.

I will finish with a poll. Please vote!

Thanks

Martin

 

That's the funny thing about "make a complete game" books and videos - people buy them, request them, write nice comments; but, as you note, they aren't great ways to learn. I don't fault the Unity team - they started out with the best ways first: decent documentation on Particles, cameras ... each individual part; and the Script Reference section explaining everything a programmer needs to know. Then they started this Forum and Unity Answers. But enough people still want UTube videos, so they may as well make their own.

The other funny thing is just about videos. Some are good, like showing how to find all the little things on your screen (it's easier to show rotating/snapping the xyz gadget then describing it.) But most things aren't good to teach with a video. I think they seem better since they're higher-tech, or people believe that stuff about being visual or auditory learners. And to an extent, watching a video is entertainment - like watching "This old House" to inspire yourself to redo the kitchen.

Learning scripting from a "make a complete game" video is just going to be rough, like Final Fantasy 10 not using the Sphere Grid. If you look at the stickies, the Unity team first tells you to read a C# book (disclaimer - I can't recommend the particular book they do.)