If it’s free, open source and you want it to be a community effort, how about working with Chris and all the other contributors on the docs? We have some great contributors on the class reference, but for now it’s mostly Chris and I + Juan from time to time. And there’s a lot of ground to cover. Sadly a lot of fellow writers/instructors seem reluctant to contribute to the official docs. But we have contributors who proof every page so that’s a guaranteed bonus. If you want to put it up on your website, do an extended version etc. I don’t think Akien would be against it. Just gotta ask. Chris worked and is working on the GDscript intro, but if you ask him he may leave it to you and move on to something else or you could add an extra guide for newcomers in code. Same with me: if you want to take responsibility for the OOD guide go ahead and I’ll work on another topic, or we can split the work, or work hand in hand – however you’d like. In any case everyone would be glad to have you helping with the docs. And you’re free to take on as little or as much as you want! From: Ivan Skodje [mailto:ivanskodje@xxxxxxxxxxxxxx]
Sent: 17 October 2017 07:32
To: tutors@xxxxxxxxxxxxxxx
Subject: Re: [godot-tutors] Looking for peer reviewing of teaching material. Very nice. :)
I spent entire yesterday travelling (forgot keys at work, 2,5h wasted on more travelling. Woops!).
I hope to setup a repo or something (considering google docs) to give everyone access for C & C. I will also welcome contributions towards making it a great one. :)
It is my intention to make this freely available once the course is ready (it will be free, of course).
A lot of work remains, as I need to do a lot of Godot-studies, and polls/questions on Facebook.
I would like to see a community effort for these tutorials/guide to Godot.
I imagine once all is done and well, that a PDF version will be created of the course, but we will see.
-------- Original Message --------
On Oct 17, 2017, 07:14, < nathan@xxxxxxxxxxx> wrote: Same here! Well reviews on the official docs already eat a lot of time so I’m not always available but all it take is one serious review once. For the official docs, I also have to do a series that introduces Godot’s core concepts and how you apply object oriented design to it. We discussed it months ago with Lars and the Kickstarter backers requested the topic. Chris Bradfield (KidsCanCode) is working on the intro to GDscript part. Again, for the docs. In either case, it’s no big deal if our work overlaps considering there’s a big lack of content on the subject and different users will appreciate different teaching styles. The docs are text, and a bit formal now we introduced writing guidelines. Lars definitely is the man to get feedback from about structuring your code. As a designer I just learned to patch up “code that works” and move on. It’s a common recommendation for gamedev. Juan himself always recommends it! Lars shows how to write code that works, about as fast, but that doesn’t break and feel like a mess a few weeks later 😉. Be it for teaching alone your project structure and understanding every single decision you took is essential. That’s why now we’ll have separate demos for the docs and the legacy demo pack. Kind regards, Nathan 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
|