gdquest-demos / godot-kickstarter-2019 Goto Github PK

Lately I'm leaning towards not using any convention to distinguish between public & pseudo-private members/variables apart from the ones that come as guidelines & necessary from Godot. I mean the virtual functions of course (_ready, _process etc.), but also functions "expected" to follow this convention like functions that link to signals: func _on_some_node_signal().

Apart from these I don't really see any benefit from playing the public/pseudo-private game. If I were to force someone to work with a particular interface (API), I'd do it differently. I'd use a parent/child node relationships, where the parent will expose the API while the child/children nodes implement the nitty-gritty stuff. Of course, there's no real way to prevent anyone from accessing the child properties/methods directly, but I think it's a much better way than relying on this public/pseudo-private convention.

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)

Learn to create a character for a game in a 3rd person view, be it a platform game or an action-adventure game, with the free game engine Godot.

Audience

This course is for people who have some experience with Godot.

Pitch

Create an add-on widget to edit and format text more efficiently in Godot.

Problem

I'd like us to produce more tutorials and sometimes have text on screen, or to create rich slideshows. Having to switch to external bbcode editors all the time is a pain.

Also, the RichTextLabel and TextEdit nodes don't work like paragraphs or containers in html, so using an external editor, you still have to copy the text over to Godot to see if it looks good.

To work productively, I need to be able to:

• Wrap selected text with bbcode tags or to remove them: bold, italic, and color only to start with.
• Force the text box (RichTextLabel or TextEdit) to resize based on its content
• Undo any operation

That would cover all the bulk of the time-consuming work I had to do formatting text on Godot slides and the GDScript tutorial.

We could then reuse this along with the GDquest theme and other widgets in all our tutorials.

Tasks

1. #28 Resize text boxes button
2. #29 BBCode editor

Code a professional side view 2d game character with the Free game engine Godot! Learn the fundamentals you need to code solid movement for platformers, action-adventure, and Metroidvania games.

Audience

This course is for people who have some experience with Godot.

You will learn to

• Code character movement a side-scrolling game
• Create a hook mechanic
• Use steering behaviors
• Code a Hierarchical Finite State Machine

The 2D Platformer is the first demo to be reworked into the Best Practices guidelines as discussed in #56.

The work-in-progress project can be found on the feature/demo-platformer-2d branch.

I've made some notes of the changes I'd like to implement. Feedback is welcome!

General

• Code adheres to Guidelines
• Port to 3.2
• Restructure project folders
• Allow for Hidpi
• Smaller stage with less scenes. (There are a lot of scenes which might be overwhelming for beginners)
• Add fail state and win state
• Remove TilesetEdit scene.
• Remove the rotated Still platforms in favour of using the TileMap. (Having to manually place Still platforms to be pixel perfect seems redundant with a TileMap)

Player

• Player movement is too floaty / slidy. Make it more responsive. (Will look at other examples of responsive platformers to try and emulate them.)
• Add jumping_weapon and falling_weapon animations
• Add longer jump when jump button held down. Allow for hops.
• Move touch UI out of Player Scene or remove the touch controls in favour of a separate demo.
• Change Bullet to have more impact. (Have it be a laser instead?)

Enemies

• Improve death animation.
• Damages the player when Player contacts them. (Reset scene on contact?)

Moving Platforms

• Use Path2D for movement? (Doesn't behave well with sync_to_physics)

Bugs

• Player slides along moving platforms
• Shooting occasionally doesn't work when the button is pressed. (After several jumps, the first shot doesn't fire. Issue with having it in _phyisics_process?)
• Player slides to the left / right upon landing when jumping against a wall.
• Bullets can be shot inside walls if right next to them
• Bullets are able to be shot into the walls at a distance. (Looks like the high speed of them could be a cause)
• Player slides down slopes slightly when jumping on a slope. This is a known issue in Godot (30777)

Create a Platform Game Character with Godot could use some more assignments to complete the course.

For each assignment:

1. Create a git branch in the corresponding chapter with the solution
2. Write the assignment

I'll record a video overview of the solution.

Assignment ideas

Intro to Steering Behaviors: Scaring the AIs away

Coding the Flee steering behavior (it's like follow, which is shown in the course, it's just the opposite) and using it to "scare" ais away

Make the leader move away from the mouse

Extra challenge

Combine behaviors! Scare ais away from the mouse when it gets close and use arrive to when the mouse cursor is far enough.
You need to apply weights to each behavior based on the distance to the mouse

The Hook: Air dash

Add an air dash state, with a transition from Air, but not from Hook. The dash is a short forward motion that the player can use to reach a distant platform while in the air. See celeste's dash mechanic.

Final challenge: charged hook

Change the hook's behavior somehow, e.g. add a charged hook mechanic that, after a short amount of time keeping the hook key down, propels the character way past the hook point.

The purpose of this assignment is to challenge the student to go mess with existing states, as it shouldn't be as simple as adding a new node, self-contained script, and FSM transitions: it involves messing with both the Hook and the Player.

Hi, I couldn't able to import any of the projects. It returns back to project list window.

GodotEngine: v3.0.6
OS: LinuxMint

Set up an add-on to place some tools like the color palette #20, and place the docker somewhere on screen. You can add the palette to the docker in #20. You can also code the add-on as part of the GDquest godot theme project: https://github.com/GDquest/kickstarter-quest-3/tree/master/gdquest-godot-theme

Learn to create a 2D platformer with the free game engine Godot.
We pledged to contribute this course to the Godot official learning portal.

Audience

This course is for beginners. It gives quite a lot of details about programming and how Godot work, teaching you some good practices from the start.

What you'll learn

• Code a platform game character that can move and jump
• Kill and stomp enemies by jumping on their head
• Use inheritance to avoid writing code twice
• Use Godot's KinematicBody2D and Area2D nodes
• Create levels with a tileset and tilemap

A free tutorial series to learn new features in Godot 3.1.

This first part focuses on all main new features except 3d stuff.

It was a stretch goal from the Kickstarter campaign.

The full playlist: https://www.youtube.com/watch?v=TjuK1ijv5KA&list=PLhqJJNjsQ7KEN1pQVRD4an4Ykd1i9t3t9

Currently the boundingbox resize plugin takes in account \n to estimate the vertical size of the boundingbox. So if a line is really long, or bigger than the horizontal rect_size it won't skip the line, so the final size is not reflected correctly.

So I'll work on a method to take in account the size of the text when wrapped to also increase the vertical size based on how many lines were "wrapped" to fit the text based on the current width of the rect_size

After worked a bit on ORPG and talking with Nathan I propose these ideas:

• for classes inheriting from Godot objects start with extends ClassName followed by class_name CustomClassName if necessary, without any newline in between, followed by docstring. The argument is we immediately see what the class is named, followed by the purpose, without any interrupts, it just makes sense to me to have it this way. More on this in the list elements below cause it's all connected.

• leave 2 blank lines between functions and member variables as well as docstring. Rationale is, we group together related pieces of code this way and sometimes it makes sense to have blank lines in functions for grouping logic together. With 2 lines in between it's easier to spot function separation:

extends Node
class_name QuestSystem
"""
Docstring here.
"""
# blank line 1
# blank line 2
onready var timer : Timer = $Timer
onready var pivot : Pivot = $Pivot  # custom class

var some_other_var : = Vector2()
# blank line 1
# blank line 2
func _ready() -> void:
    # do ready stuff
    algorithm(f)
# blank line 1
# blank line 2
func algorithm(input: float) -> void:
    if guard:
        return

    # do some actual work
    return out
# blank line 1
# blank line 2
func another_f() -> Vector2:
    return Vector2()

- [ ] leave 2 spaces between code and comments if on same line (like in pep8 Python recommendation):
onready var pivot : Pivot = $Pivot␣␣# custom class, marked here with ␣

• declare explicit onready var types: onready var timer : Timer = $Timer instead of onready var timer : = $Timer. Reason is, Godot doesn't seem to auto-cast to correct type and sometimes we have properties calculated at run-time: onready var size : Vector2 = get_used_rect().size. In this case, because of onready Godot would treat size as Variant without a type hint, so if you have a calculation depending on it: var size_px : = path_finder.map.size * path_finder.map.cell_size it wouldn't know the type, we'd be forced to say: var size_px : Vector2 = path_finder.map.size * path_finder.map.cell_size, but if we explicitly declare onready var types we won't have any trouble with this.

• add discussion about an Events singleton for managing signals easier as a godot specific pattern
• rewrite "It's very easy to imagine how even a simple [...]" above fig. 4
• refactor var_name : type = Type to var_name: type = Type as per GDScript new guideline

• Color palette
• Drawing utilities
• Theme resource

See:

1. Learn Godot: beginners edition
2. Learn Godot: developers edition

Problem

We're going to have a styleguide with fixed colors, but we don't have a convenient way to assign these colors to icons, bars, text, etc.

This goes for tutorial slideshows made in Godot as well as debug interfaces or tools we might create.

Color palette

• Palette widget: should generate a list of buttons from a JSON file.
• Clicking a button should assign the color to the modulate property of the selected node.
• The individual buttons/swatches in the palette shouldn't return color objects! The idea is to reuse the components for other tools, e.g. a RichTextLabel editor, where the color will be a string in bbcode tags. Each button should only return a hex color string!
• The color palette should only be a widget! We should put multiple widgets in a single docker.

NB: No need to support RGBA values, only hex. Note in Godot the hex format is AARRGGBB or RRGGBB: alpha comes first.

Interface

I prepared some UI prototype, see the attached zip : ColorPalette.zip

One gridcontainer per palette section/category. Keep it this simple: no need for a fluid layout or foldable categories. We're only going to have a handful of swatches to start with, making an elaborate UI would be a waste of time at this point.

Krita's palette docker is a good reference for the layout: simple and efficient.

"palette_name" : {
    "category_name": [
        "color_uid" : "ffffff",
        "color_uid" : "000000"
    ]
}

Currently the Bounding Box will make the vertical size of RichTextLabels and TextEdits decrease, even when the current size is bigger, i.e. better fits the content.

Sequel to the 2d Platform game character course #48

A contextual button and shortcut to resize selected TextEdit and RichTextLabel nodes based on their content. It should only show if you have one or more TextEdit or RichTextLabel node(s) selected, and update all selected nodes at once.

• Shortcut support (Ctrl R for refresh/resize?)
• Undo support
• RichTextLabel support
• TextEdit support (for code examples)

It doesn't work in real-time

I tried to hook onto the engine's setters, and I tried adding an extra property to force the node to resize upon setting the text, but the result is buggy. It seems get_content_size doesn't get computed instantly on RichTextLabel

There may be a way to hack realtime resize into TextEdit etc. but I don't think it's worth the work to just save a keystroke. If you make resizing a manual operation, you can use get_content_size as-is. So for this first iteration, a button and keyboard shortcut will do the trick.

A minimal bbcode editor for the active selected RichTextLabel node. A text-box to wrap selected text with tags: bold, italic, or color using the palette widget. The text box only needs to display the raw bbcode string.

No need to support detecting existing tags, removing or moving them. Undo is enough to start with. I'd rather like the tool to be ready soon and hopefully get other users to contribute eventually.

It should support shortcuts for the bold and italic functions. E.g. CtrlB to bold text.

I rarely connect signals through the GUI so I always find myself wondering about the all_small_snake_case when it comes to the signals. I think we can make an exception and use what the GUI offers as default: _on_NodeName_signal_name. I used to write _on_node_name_signal_name, but I think it's easier in this case just to go with something compatible with what the GUI is doing so we'll make an exception from all_small_snake_case.

If someone does end up connecting signals through GUI, he/she'll most likely just accept the default value for the function name, producing _on_NodeName_signal_name.