-
-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A wizard plugin system to generate custom scenes. #65
Comments
With the script class system, it is now already possible to create nodes that "become" a scene for you. You can even export settings on the node for a "simple node interface", as you describe, that can then execute configuration on the generated scene for you. Basically, this proposal violates the "can it be worked around with a few lines of script". If we added a built-in system for installing scenes as globally recognized types, just like script classes (and believe me, I already went WAY deep down this route. See godotengine/godot#22181 for more details on the PR), this whole process adds a ton of bloat to the editor and complicates the script class system into a giant headache. If you define a globally recognizable name for a scene, then you run into issues where a scene and a script can actually share a name (e.g. my_class.gd which is also the root node of my_class.tscn, both of which are named "MyClass"). You then have to decide on how to accommodate the possibility of a name being either a script or a scene (tons of logic gets more complicated everywhere) or you have to create namespaces between scripted types and scene-based template types. And all of this complexity goes down the drain if you just don't do this and instead tell people to write a short |
If you still wanted to have a scene template system that was editor-only and existed separately from the CreateDialog and other editor tools, then that is something you could make as a plugin with a custom Dock or something, but it wouldn't really be suitable for being in the main engine repository. I think you'd ultimately be doing a whole lot of work for extremely minimal benefit though, considering how easy it is to write a Edit: So, the good news is: "Yay, the engine can already pretty easily do what you want! No need to make any changes and you can get started on exploiting this feature right away!" <- should be the takeaway from all these comments. |
Sorry, I'm a bit confused here :P. Isn't a scene already a node? Or am I missing something |
@girng OP means something similar to making the scene show up as an option in the CreateDialog (making a scene display itself as an available type) and users somehow being able to configure the way it is instantiated (i.e. have a constructor). Which is effectively what you can use a Node script class for. |
This might be useful for things like whether you want to setup basic stuff like camera, basic character controllers, background etc (things that are almost game-agnostic to begin with). This could as well speed up some testing of the engine. |
This is something that can already easily be done with a regular script.
If you mean testing the wider engine, then that's what the demo projects are for. If you mean allowing someone to quickly and easily test a scene with different pre-defined, but similar, configurations, then that's what scene inheritance and exported properties are for. And if someone wants to instantiate these scenes from the CreateDialog under a presumed name, then that's what the All of these are things that can easily be achieved with just a bit of script code in the existing system, so it doesn't warrant the development of an entirely new feature. I don't see it being a significant usability improvement to deserve it either. The one thing I could see being examined further, which is beyond the scope of this proposal, is having a scene's root node's script class ALSO be the tool generator script in such a way that instantiating the script at design-time or run-time would both safely create an instance of the scene. I have discussed problems with that in the "ability to link scene to script" ticket from godotengine/godot that I linked earlier though. |
It seems to me that Godot project templates haven't received more attention by developers: The problem with those is that they are still treated as regular projects that you need to tinker with and figure out the internals of. What if I don't need that particular feature present in a project template? A simple wizard could ask you if you need certain things, and strip unneeded scenes and scripts, or use a different set of textures etc.
XY Problem. 🙂 |
cc @ca3games Is OP's real question then about making a template creator that allows one to customize what features are included in a template project? Cause if so, that wasn't communicated very well. For that, you'd need to be able to set certain flags in a project file and then conditionally load in different assets based on those flags, which would be presented as options in the Project Manager then. I think OP needs to narrow in on exactly what changes / what kind of workflow they actually want to see and then update the Issue to demonstrate that information. Otherwise, we are just spinning our wheels trying to read their mind and wastefully tossing ideas around. |
What I mean is a basic window sort of wizard that generates a scene based on some custom scene you have set up as similar to maybe unity prefabs, which generates a newer scene based on some parameters from (export) variables. |
Sorry, english isn't my native language, so maybe I'm not explaining it properly my idea. Imagine if you made a basic enemy on your game, then you simply want to remake said complex scene with a few changes to let's say the animations, like a platformer enemy who has the same behaviour but a few diferent changes, then you simply with one click generate new variations. Imagine if you could then have a hierarchy of wizards who can then simply generate a basic template scene with just one click, maybe even generating an entire game with just a mere wizard who controls other wizards. |
Okay, so, if I'm understanding this right...
This system you are referring to is the node-scene system, which is a main marketing point of Godot Engine and already exists. The "wizard" you are referring to is the entire Godot Editor. Scenes can inherit from each other. Inherited scenes function exactly the same way as what you are describing. lol If someone created a highly customizable template project, and then had a bunch of configuration options in the root node of the main scene for that project, where those options manipulated how the rest of the project worked entirely, then it would be exactly this "1-click"-ish "Game generating system" thing. |
maybe, my idea is mostly to auto generate similar scenes based on maybe a configuration script who handles the generation of said scene using some basic window wizard, it would be good to automate repetitive task, maybe you're creating a similar game and you want to reuse code and scene structures very easily. |
@ca3games Yes, what you are describing is very doable using the scene system with a tool script on the root node. And maybe an EditorPlugin that registers an EditorInspectorPlugin, if you really wanna customize the editing experience of the Inspector. |
Yeah, I think is very doable, but not sure how dificult it would be, at least for guys that are more on the art side than code. Would make godot much better for newbies. |
Well, the only "code" you would have to write is the actual logic to conditionally do something. Have exported bool variables and use if statements to only do a behavior if it is true. Export a script to decide what kind of class to instantiate where. Export an int to decide how many of something is done. The "wizard" is literally just the Inspector showing you properties for the root node of the scene that changes it's behavior in response to all this stuff. There aren't any changes to the engine needed to make the process any easier. |
Sure, my idea isn't something that requires some complex stuff to add to the engine, and maybe my idea doesn't really need any radical change to the core engine. |
Can't this be done by instancing a child scene when a developer creates a new scene? |
@girng Yes. The "wizard plugin" is the Inspector. The "system to generate custom scenes" is the scene inheritance system. Edit: If I had the power to close the Issue, then I would have already done it. XD |
I'll close this proposal due to lack of support. This functionality can also be provided using third-party assets on the asset library. |
Describe the project you are working on:
2D action games, like a 2D fighting game, with multiple similar characters.
Describe how this feature / enhancement will help your project:
Will make it easier to reuse or change scenes, maybe make a wizard tool to easily make templates for making one click games.
Show a mock up screenshots/video or a flow diagram explaining how your proposal will work:
Basically allow to turn a scene into a node, that allows a wizard to generate said scene based from a few configuration clicks.
Basically you can make an scene with lots of custom nodes and let a basic configuration, maybe, not even a wizard, but a simple node interface, similar to how unity asset store assets and scripts and prefabs works.
That way, scenes can be more easily created, and will allow to reuse said scenes or code very easily to newbie players. Maybe even making a plugin sort of system, similar to VST in a DAW.
Describe implementation detail for your proposal (in code), if possible:
If this enhancement will not be used often, can it be worked around with a few lines of script?:
The point of this idea is that scenes, could work in conjuntion with configuring other wizard scenes, so that way you could even reuse and easily create with a wizard an entire game.
Maybe there will be a plugin to easily generate a platformer scene, and there will be a metroidvania character plugin, and there's on top a full metroidvania wizard screen on top of both wizards.
Is there a reason why this should be core and not an add-on in the asset library?:
The asset library could then be more usefull by letting the user download the VST/plugins/wizards made by other users.
The text was updated successfully, but these errors were encountered: