Replies: 4 comments 7 replies
-
|
The obvious downside is that any change to the player scripts that requires corresponding changes to the scenes will have to be made across all scenes in lockstep. For instance, using the new |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I totally agree. This is separate but related to having behavior components for more flexibility. For the minimum viable product of the game we tried our best to make the important scenes "moddable" (like player, guard, etc) by exporting as many properties as possible and even proxied inner properties of the scene's nodes (like the SpriteFrames of an AnimatedSprite2D inside the scene). I think we did it that way by following the requirement of adding "templates", and probably based in our experience in the Moddable Platformer and Moddable Pong projects. But StoryQuest creators have shown how limited is it to change the visuals but not the hitbox of a character. |
Beta Was this translation helpful? Give feedback.
-
|
If they were to get their own separate copy of a character .tscn, would the script it uses be a copy of or the exact same script shared between it and the lore based storyweaver.tscn? I am just thinking if they want to adjust resources like the collision shape, for example, they'd likely also like to mod aspects of the script. This would give them all the functionality of the character scene without anything tying them back to it, right? If that's the case, will the script they get for their separate player scene still contain all the variables exported to the inspector that allows them to lightly adjust scene mechanics and behavior as they can in the current templates? I would imagine that would all be the same as it is simply part of the script, yes? If so I think this could be a good improvement towards really giving them their own character or component through and through - as opposed to a character still sharing resources underneath the hood. |
Beta Was this translation helpful? Give feedback.
-
|
I decided to try doing this, but start small and move the
However I realised that I would have to extend the copying tool to handle this new case where, after duplicating scene A as A', in scene B we have to replace instances of A with A' before saving that as B'. This is trickier than the other cases we handle so far because we need to handle the replaced node having properties set on it, child nodes (e.g. the Player scene instances have Camera2D children), signal connections, etc. I found which is exactly what we do not want! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
We currently have a single player scene, at
res://scenes/game_elements/characters/player/player.tscn. By default it has a generic/template appearance, placeholder name, etc. with various properties to customise it. In the main game, we override the Player Name in every scene to StoryWeaver (in theory!) and set the Sprite Frames property to make it look like StoryWeaver; in Stella and the Missing Star, in each level we set its name to Stella and adjust its SpriteFrames; and so on.(We use the same approach for enemies, hint signs/bonfires in the sequence puzzle, etc.; everything I am writing applies to those too but I'll talk only about the player by way of a concrete example.)
I think this approach is flawed. As soon as you need to customise something that is not exposed as a property on
player.gd, then the "correct" thing to do in this model is to use "editable children"; but it's much easier to click through to theplayer.tscnand edit it directly. We saw many people doing this while building a StoryQuest with a custom character, adjusting the hitboxes etc. for their character and inadvertently breaking StoryWeaver in the process. Even if you do use editable childen, if you try to edit the collision shape, you are still actually editing the resource in the canonicalplayer.tscn. You have to remember to Make Unique on the shape before editing it. This is very easy to get wrong.It's also error-prone if you want to change a property of the playable character across many scenes. If we decide to rename “StoryWeaver” to “Storyweaver”, or change their speed, then we would have to edit the Player node in 9 scenes; this number will only go up.
And if we want to add logic that is specific to StoryWeaver – such as outfit customisation – we would have to do this in a way that is generic across the player-characters in every StoryQuest.
I think we should take a different approach:
storyweaver.tscnscenestella.tscnscenetemplate_player.tscnsceneThese scenes would reuse the same set of scripts, but otherwise be completely separate.
Then, to make a custom player for your StoryQuest, you would duplicate
template_player.tcsn(which would duplicate all the collision shapes, etc. contained within the file!), and then modify that. We could even go so far as to define the template's SpriteFrames as a resource embedded in that scene, rather than saved to a separate.tresfile, so then the template would be self-contained except for the assets it references.(StoryWeaver would keep their separate-file spriteframes.)
We would then remove the top-level
sprite_framesproperty that proxies to the internal PlayerSprite, because you would set the frames there directly.I think this would be less error-prone and more flexible. Thoughts?
Beta Was this translation helpful? Give feedback.
All reactions