Conversation

eli, shadow domme

Edited 5 months ago
godot liveposting
Show content

i’m currently in the process of rewriting my prototype as gdscript and this language is somehow both too pedantic and too loose at the same time. type “hints” are actually runtime errors if it receives something it doesn’t expect, but this can be fixed by just Removing The Type Hint ??? why

worse yet are the array type hints. if i have the following

var nums: Array = [1, 2, 3]

this is somehow different from

var nums: Array[int] = [1, 2, 3]

and if i want to coerce one to the other?

var nums: Array = [1, 2, 3]
var nums_int = nums as Array[int] # runtime error
1
0
3
re: godot liveposting
Show content

so in godot’s fairness, i really love how quickly the game launches compared to unity. no compilation time, no waiting on domain reloads. it just opens. love that

i’m still having a hard time adjusting to the one script, one node design but i think i can eventually get used to that. i can’t say i enjoy the cognitive load (or performance burden) of a deeply nested scene graph though.

1
0
2

eli, shadow domme

Edited 5 months ago
re: godot liveposting
Show content

as far as i can tell, the one node, one script thing encourages some kinda shitty habits that i didn’t have a problem with in Unity or any ECS architecture. for example, code reuse comes from one of three things: a child node, a global/autoload, or inheritance. splitting every shared functionality into a shared node feels like overkill sometimes, especially when it comes to trying to make those nodes communicate. i don’t want to have to connect a bunch of signals for what could have been a simple function call

globals/autoloads are Okay but not always the most ergonomic. (i’m also lumping a class with static methods into this approach). like, it just feels kinda dirty to do it this way.

# node_ext.gd
class_name NodeExt extends Object

static func find_child_type(node: Node, variant: Variant) -> Node:
  # blah blah find node


# other_node.gd
func some_fn():
  var found_node = NodeExt.find_child_type(a_node, CustomVariant)

like yeah this gets it done but i just kinda hate doing it this way. c# at least has extension methods

// nodeext.cs
public static class NodeExt {
  public static Node FindChildType<T>(this Node node) {
    // blah blah find node
  }
}

// othernode.cs
public void SomeFn() {
  var foundNode = aNode.FindChildType<CustomVariant>();
}

and inheritance just kinda sucks, so i feel like i’m only left with one option for code reuse in godot lmao

1
0
1
re: godot liveposting
Show content

also a minor gripe, type hinting is Really Fuckin’ Annoying when i have to import all my other scripts in order to hint with them. why ??

const Player = preload("res://src/player.gd") # okay but what the fuck is this

func damage_player(player: Player):
  player.apply_damage(5)
1
0
1
re: godot liveposting
Show content

@rowan you can get around that with class_name

kind of sucks that name is just global (even across addons) and you don't get namespaces. doesn't tend to be a big issue though

1
0
1
re: godot liveposting
Show content

@Ry oh thank you! 💜 i haven’t been sure when to use class_name since i was running into issues with it and autoloads (apparently having an autoload with a class_name causes a name conflict??)

1
0
0
re: godot liveposting
Show content

@rowan i think it creates a global variable with the autoload's name and that might conflict with the class_name you gave it if that's the same (which it probably would be!)

i use class_name fairly liberally. all the "core" game classes like characters, items etc have it, as well as pretty much all resources

0
0
1