Re: [godot-tutors] Looking for peer reviewing of teaching material.

[Lars Kokemohr <lars@xxxxxxxxxxxx>]

You know that you can treat me as a volunteer by default when it comes to tutorial peer reviews.
If you send me an email to tutorialconsulting@xxxxxxxxxxxx it's sorted into a dedicated folder so it's less likely that I'll miss it.

I have been working on something similar to your first course recently because this year my introductory course to Godot is quite late in the semester and the students are expected to be working on their projects before that.
I am not sure whether I will have the time to finish it with all the other lectures I need to prepare, but at least I can relate to what you plan to do.

I agree that object orientation should be the first topic. I would also advise to explain base classes and members (isA- and hasA-relationships) in the scene hierarchy first, because it will be easier to follow for many beginners, but also because I think it's important to establish that declaratively constructing the scene in the hierarchy should be your goto solution, not rewriting stuff on your own using GDscript.
Writing imperative script code is more intuitive for most people, but it's not as easy to read as a clean hierarchy and it has technical drawbacks as well.

So I was planning on explaining that scenes don't "exist" right away, but that they are classes and only define what an object would look like if you were to create one using that scene. Next I would explain that the root node defines what the scene "is", so it's
a) like a starting point that you later modify to your needs and
b) telling the engine what this thing can be used in place of. E.g. if you create a scene with a Sprite as a root node and an AnimationPlayer as a child node it can be used to replace any Sprite in the game, because all the functionality of the Sprite is inherited.
Next I would explain that child nodes define what the scene "has" and demonstrate that when you instantiate a scene in another scene all you see is what the scene "is", i.e. the root node with its name and all of its attributes, but by default none of its child nodes, since they only modify its behavior.

With that start it's much easier to explain the structure of a GDscript file to people that aren't necessarily as much into texts as programmers are, because now you can relate to the scene structure. The extends-line says what the object is, lines starting with var tell what it has and lines starting with func define what it can do, which you can't edit in the scene hiearchy, so that's the reason to use GDscript at all.

The same way scenes don't exist until you create objects from them functions don't run until you call them. You create objects by telling the engine which scene to start with in the project settings and you tell it which functions to call by putting them into one of the predefined callbacks.

So I would leverage all those parallels to make the concepts more visual and to be able to explain them twice in different ways, so that people who wouldn't understand it based on the text alone get a second perspective.

Cheers,
Lars

Am 16.10.2017 um 06:45 schrieb Ivan Skodje:

I have been on and off working for material for a Godot Engine Fundamental course (3.0).

The plan is to create 3 courses, where the first course is dedicated to learn Programming with Godot Engine / GDScript. Not very exciting, but very fundamental and important - especially if you are new to programming. Here you will learn the basics about variables, OOP, and so on. This does include theory on each topic, and not just "teach by example".

The second course will be dedicated teaching basic game development principles with Godot Engine. Nothing fancy, but you will get your feet wet and learn what you need to make your own 2D games.

The third course will be dedicated to 2D and 3D game development. This will be a bit more advanced, but we will go more in depth and work towards developing a "bigger game".

---
Why am I posting about this? Because I care that the learning material is excellent. I want people to be safe about learning good coding. Good working principles.
What I would like to ask of every single one of you, are volunteeers to peer review the materials, during and after creation.

Lately I have been busy due to getting a new job - dedicating my own time to learning everything I need in order to do a great job at ... my job. 

Now I am finally ready to go back in Godot, and - I figure while I spend 3 hours on the train rides, to write material for the course. 

Volunteers willing to review the material will get access to a Trello board, where I will post the content as I go. (I could go for Google Docs, but... well - let us try first and see how it goes).

Thoughts? Theories? Game theories? :P

Vennlig hilsen,
Ivan Skodje

http://ivanskodje.com