simple nodes for base implimentation

[Shadowblitz16]

can we get the following nodes?
GameObject2D
GameObject3D

these nodes would simply only be a 2d/3d transform, a enabled property and components

the main reason for this suggestions is so that we can use a ecs workflow and static utility functions to implement our own behaviours and logic.

[Xrayez]

Godot is not Unity? 🙂

Do you simply suggest creating an alias class for Node2D (or Spatial/Node3D):

class_name GameObject2D extends Node2D

Or maybe:

class_name GameObject2D extends Node

export(Transform2D) var transform

I personally already have exactly those classes implemented, but for gameplay needs, not necessarily as base types, those kind of classes could create conflicts with existing projects, so the shortcomings far outweigh the added benefit IMO.

But... This would make sense to implement if you were to develop a game framework using GDScript, yet godot-next is not a game framework, and these are typically already tailored to specific genres of games anyway, see https://github.com/godotengine/escoria for instance.

I haven't researched extensively on this topic, but I suppose nobody has created a more general-purpose game framework yet in Godot because it's simply difficult to come up with something which could be useful for everyone, especially if this needs maintenance.

[Shadowblitz16]

Godot is not Unity but that doesn't mean multiple scripts aren't better then a single script.
my issue is I want to be able to add my own components from scratch with the utility suggestion and manage them through godots gui.

[willnationsdev]

my issue is I want to be able to add my own components from scratch with the utility suggestion and manage them through godots gui.

You will be able to do exactly this with Andrea Catania's ECS module (source, example).

[cgbeutler]

@Shadowblitz16, If you want ECS for performance, then this may be the wrong place. Andrea Catania's ECS module is gonna be WAAAY better for the simple fact that it's a module, not an add-on. A module is in C++ and gonna be a LOT faster. ECS usually has a lot of tricks to speed-boost in ways that GDScript probly can't quite provide.

If what you want is a position component (not for ECS performance, but just component-style dev) then would @Xrayez 's code snippets work?
If not, then I don't know what you are picturing and you may need to mock up the code yourself and share it. Code is King!$$

[Shadowblitz16]

@cgbeutler I was thinking more of how unity did it with a oop/ecs hybrid

[cgbeutler]

I see, so not performance so much. I think most of the folks on this repo are more into the "Godot way," so you maybe may have to spearhead this one yourself, just fyi.
The sad fact of code is that only someone who really wants it will find the time to write it. If that's not you, then it may end up like a majority of feature requests do... [longing look out the window as I await g4... instead of helping write it]

[Shadowblitz16]

@cgbeutler its hard for me to write a plugin for me due to godot not being statically typed by default.
I can't ever seem to get good autocomplete so I have to look up things in the docs and then godot doesn't even let me statically type some things.

also there is the fact that anything in gdscript isn't really a new object.

this all adds up to make godot really hard to work with and extend.

[cgbeutler]

I get that. It can be tricky. I definitely use a lot of strange tricks to get autocomplete. That's an area that is being slowly improved.

I guess I am just trying to manage expectations. There are only 4-ish people writing NExt. Those four have a ton going on, since they help with Godot, too. If none of them need the thing you propose, they may never get around to it.

[Shadowblitz16]

@cgbeutler ya I understand