Remake key official Godot demos

[NathanLovato]

The code and quality level of the official demos varies a lot. They were made quickly overall to just show that some features exist and how they work at a basic level.

The goals of the demos are to:

• Showcase engine features, that is to say give a sense for what Godot can do, so the demos are an asset for communication
• Help people learn these features, so the demos have an educational purpose

Users can get a feel for Godot's power with these demos. If an experienced developer may see the value of a feature showcased in a basic way, a casual user or hobbyist may wrongly feel that Godot sucks because the demo is bare-bones.

The demos' design

Each demo should clearly focus on one feature. The scope of the feature can be one node, one game mechanic, or one system. Examples:

1. KinematicBody2D, make a simple game with a side-view platform character, and another scene with top-down movement, and obstacles, including moving ones
2. Touch gestures, a demo that shows how to detect a gesture, generate an input event from that, and consume it in another node
3. User interface anchors and margins, showing the effect of various layout and anchor menu options

The project

Update key official Godot demos to:

• Show good practices when it comes to Godot and game creation
• Make the demos feel and look both better and more consistent

Create related videos to communicate around changes made to the demos:

• Give an overview of the work being done, i.e. devlog
• Give an overview of the demos and of the features

I'd prefer the videos to give overviews and ease people into using the demos over turning them into step-by-step tutorials, as the demos themselves are meant to be the learning resources. This will keep the videos easy to produce as well, ideally with minimal editing or post-production work.

Tasks

Start with 2 demos you, or the community feels are most important. Write down a short concept/outline for the changes you plan.

Questions

Can we use our GDQuest art style?

We'll use that as a base to create some visual guidelines. Our art style's goals are:

1. Make the visuals appealing, yet fast to make
2. Make the art creation process accessible to non-artists or unexperienced artists who'd like to contribute
3. Use vector whenever possible so the assets are git-friendly
4. Use a visual language that supports the technical demos rather than hide them

Our art is inspired by webdesign and minimalistic mobile games.

Here is an example:

Can we use our code guidelines?

We have set up code guidelines that build upon the official guidelines and make the code collaboration-friendly and robust at the same time. I'd like us to use our guidelines because:

1. We can make the code consistent across demos
2. They put readability above everything else, which is ideal for learning purposes
3. We've spent a lot of time thinking about "best practices" and ways to write solid code in Godot, so they can help people better use Godot

One big question: should we use type hints or dynamic code? Dynamic code looks more accessible at first glance, while typed code catches more errors, provides more warnings, better autocompletion, and should greatly improve performances with upcoming gdscript compiler improvements. But as we're making a contribution to the official demos, we should adapt to the official guidelines (NB: there are none for now)

[NathanLovato]

@razcore-art Jonnhy will take care of this job, but could you tell me what you think about the questions above? In short, do you think we should push our art style in the official demos, and e.g. suggest our code style? It's mostly compatible with the official docs' styleguide anyway, it just goes a little further.

For Johnny: you'll work on this repository directly. While we got informal approval from Juan and Rémi, I still want to double-check if we can go ahead and directly PR/push to the official repo (I'm a reviewer and have commit rights on the demos I think).

[razcore-rad]

So I have a few comments.

One thing we didn't really cover here is the use of comments. In our code guideline we push for minimal comments because they can get out of sync quite fast, but for these demos I think we should use quite a lot of them since they're a tool for education as noted.

All in all I agree with everything @NathanLovato is saying, no surprise here.

Can we use our GDQuest art style? I would say definitely yes as long as Juan, Rémi & whoever else is involved accepts. I think it will create a very nice consistent look. There might be exceptions, depending on the scope of the game. If we look at the Unity learning resources (which are pretty good in my opinion), they don't have a theme for all games. That said, they do have very different projects and some of them "full-blown" games. So with that I'd say:

• for small projects (node demo, mechanic demo, system demo) having a given theme works
• for larger projects (eg. mario clone) it doesn't necessarily work since it's almost a full-blown game

Can we use our code guidelines? I'd say definitely yes, that's the purpose of the guidelines and we discussed integrating them in the Godot docs anyway, that's why we made them compatible with the docs. I would also say type hints all the way for all the benefits it gives, including easier code readability.

[NathanLovato]

How about having docstrings for functions, and inline comments where they're most relevant to the demo? E.g. have comments on move_and_collide for a KinematicBody2D demo, preload and/or load for a demo about loading and managing data, etc.?

[razcore-rad]

Yeah sure, I wasn't talking about a specific type of comment (docstring vs. inline comments). Just generally. I don't have a feel for what they should be yet. After we see it in practice we could develop the topic a bit. I don't think it would take too long to adjust if needed.

[razcore-rad]

By the way, I just remembered.

@johnnygossdev you could start off with the game I refactored to make it easier and take as an example: https://gitlab.com/razcore/godotcon2019. There's 2 branches in that repo master & original. Unfortunately it doesn't really help diff-ing cause they're too different, but you could take a look at them manually and see what's what. The refactored version (master) should already be 100% compatible with our coding guidelines. Only missing part is comment explanations for beginners to learn. Also if you find code that could be improve don't hesitate to tell us.

In that example I used the Events singleton pattern/indea, which isn't really needed though so that's something you might want to change. It was just for the presentation.

[johnnygossdev]

Thanks for this @razcore-art! I've started making notes on the 2D Platformer but will use the project you linked as a reference.

I think docstrings are great. For users not so familiar with GDScript or coding in general, I think more comments are better than less personally.