Gdscript cheat sheet: What am I missing?

[u/redfoolsstudio_com]

I have created a beginner level cheat sheet for beginners using Godots GDScript. I will be giving this out to my students who take my Godot courses.

Any recommendations to add or modify anything listed?

[u/feuerpanda]

There is this cheat sheet that i downloaded a while ago that i like

[u/RefrigeratorIll7433 → u/feuerpanda]

From where?

[u/feuerpanda → u/RefrigeratorIll7433]

I could just say "this subreddit" and would not be more helpful. If i knew, i would have posted it.

[u/feuerpanda → u/feuerpanda]

related: found it https://www.reddit.com/r/godot/comments/1c1n8by/made_a_little_cheat_sheet_for_my_friends_to_use/

[u/DongIslandIceTea]

• Avoid calling float a decimal type, because that's an actual type in many other programming languages and very different from float. This may confuse people coming from such languages.

• Type your arrays. Not just Array but Array[int]. Array's primary use case is a collection of one single type, do not put different types into arrays. Use classes or dictionaries for that instead. ["Tom", 21, true] and person[2] = false are unclear, {"name" = "Tom", "age" = 21, "alive" = true} and person["alive"] = false are obvious and a class defining those variables is even more robust.

• Don't type enums as int, type it the actual type of the enum, in the case of your example MyEnum.

• Avoid NodePath when you can. Just hold references to the node directly. Outside of some editor plugins directly interacting with arbitrary paths, there is rarely a good reason to hold a NodePath as they are brittle and unsafe.

• TileMap is deprecated, use TileMapLayer instead.

Other than that, I'm not sure how useful an endless list of repeated "Just call TypeName.new() to make a new TypeName" can really be, it's the same for all types really. I'm not even sure why you'd want to, for example, create a new InputEvent, you usually just recieve them from the input system. You shouldn't be calling new() that often anyways, usually types that are commonly instantiated via code have a static factory method or constructor that is far friendlier and more useful.

[u/the_horse_gamer → u/DongIslandIceTea]

also use PackedInt32Array or PackedInt64Array when possible. they are faster to iterate and require less memory.

their main disadvantage is they don't contain many convenience methods like map, but that could change in the future.

if you're unsure, just use an Array[int]. the difference shouldn't matter for most games.

[u/gebstadter]

at a glance, the Signal example does not really make sense (you aren't getting back a Signal from the connect method as your example suggests); the enum example seems misleading since you generally would not want to directly access an enum value as an int but rather would prefer to keep it as the MyEnum type; the Tween example is quite egregious since the tween documentation explicitly states that tweens created directly via Tween.new() are not valid for tweening (and they should instead be created via node.create_tween())

[u/stalker2106]

One should not instantiate Sprites, Textures or Animations unless specific runtime use case. I think it doesnt fit into a cheatsheet for "basics". Most of this sheet is just showing default constructor for common classes. I'd say this approach doesnt give cheat sheet vibes. The goal for these documents is usually to provide non-trivial yet easy to use language features or syntaxic sugars, one liners...

Anyway thats a good start, now make it better!

[u/SectorHour3423]

There's also %unique_button

[u/vanit]

Might be worth tracking any gotchas you encounter, some that come to mind:

• Forgetting to change CharacterBody2D to "floating"
• Mixing keyed frame and frame_coord in AnimationTree
• AnimationTree state advancements lagging a frame if you don't call advance(0) yourself

[u/Dreamerc11]

The part where you share the document with us for free😁

[u/manuelandremusic]

If you’re using a newer Godot Version, don’t use TileMap. It’s deprecated. Instead use TileMapLayer. And use Vector2i to access tiles on it.

[u/HoveringGoat]

use @export for anything that otherwise would have a hard coded path string. @export is amazing.

[u/the_horse_gamer]

prefer Resources over dictionaries for stats or settings. you get type safety, autocompletion, cleaner code.

[u/TemporalCatcher]

I know you’re trying to be brief, but dictionaries being good for stats and settings does not even begin to describe how powerful it can be. The cool thing about the key-value pair is that you can only have 1 of a given key. In most cases your key will be a string, but it is just as useful when the key is something else.

Say you are playing a game on a 2D grid, and you made it so no square can have more than one unit, you can use a dictionary to hold a Vector2/Vector2i as a key and a unit as a value. This way if you need to see if a unit is on a particular square, instead of asking every unit what’s your square, you can check if a square is occupied, if it is, check who is on it. Of course a downside is every time a unit moves you must make sure to remove the old key and add a new key.

So if I were to add, dictionaries can be used for easy lookups.

[u/OverbakedPenguin]

The need for the existence of this