Using Scriptable Objects/Resources in Godot
ฝัง
- เผยแพร่เมื่อ 8 ก.ย. 2024
- GDScript is a high-level, dynamically typed programming language used to create content. It uses a syntax similar to Python (blocks are indent-based and many keywords are similar). Its goal is to be optimized for and tightly integrated with Godot Engine, allowing great flexibility for content creation and integration.
Hardware I Use:
Blue Ember Mic: amzn.to/3KN6BtQ
Behringer Q502: amzn.to/3CVZMnI
M1 Macbook Air: amzn.to/3THj4TA
Asus Tuf VG35VQ: amzn.to/3CVV9Kn
GS520 Anvil: amzn.to/3el0ssm
ATH-M40x: amzn.to/3RD5Ndf
APC UPS 1500VA: amzn.to/3B9RDup
Nektar SE25: amzn.to/3BaObQn
North Bayou Monitor Arm : amzn.to/3CW1lSC
GitHub: github.com/new...
Twitch: / newjoker6
Twitter: / newjoker6
Website: portfolio-joke...
Guilded: www.guilded.gg...
Intro Song: NEKTAR by Aim To Head Official
• [FREE] Dark Techno / E...
Your channel is a treasure trove - thank you for putting all of this together!
Appreciate the kind words!
hey man, thanks a lot, other than this one, i havent found any good tutorials on how to use resources, they seem plenty helpful, thanks a lot again
Many thanks dude, it worked perfectly for me!
Thanks I'm moving to godot from unity and this was super helpful but damn you got a huge screen lol I'm jealous
heh yeah I got tired of having a split down the middle of two 1080p screens. So I got a 35" Ultrawide 21:9 aspect ratio 3440x1440 specific Monitor is
Asus TUF Gaming VG35VQ 35” Curved HDR Monitor 100Hz
Used my tax return a few years ago for it lol
I also have one of my 1080p screens vertical beside it and a display tablet below it acting as another screen. Plenty of room for all endeavors lol
All built up slowly over time and the big screen is only because of taxes lol Pricey investment, but I very much enjoy it.
thx for the zoom
Regarding the items in the Card Elements export group, is there any reason you're not using @onready instead of @export?
Personally, I would rather not flood my ready functions unnecessarily.
The benefits of using exports here instead of onready, aside from not adding a bunch of work in the ready function:
- Can rename nodes if need be in your tree without breaking paths
- Can move nodes around in your tree without breaking paths
- You can organize them with your other variables within categories and groups
Personally I don't rearrange or rename nodes in my tree but, apparently enough people did and complained because there is the option of giving a node a unique name now when right clicking it. This is good for those people, but that doesn't help if you end up renaming it so it still has it's downsides that an export doesn't have.
@@GlitchedCode Thanks for the explanation.
Why not inherit scenes?
You could, there are certainly multiple ways to do things. Depending on the situation one approach could be better than another or more reusable.
Pros of using Resources/Objects:
Resources are data-driven making them inherently well-suited for data-driven content like card attributes.
Reusability, you can quickly create a library of card data when you have multiple cards, in this case, with similar attributes.
Centralized management making it easy to tweak and balance without needing to create and open a bunch of scenes.
Serialization makes it easy for saving and loading between sessions
Cons of using Resources/Objects:
You are limited to data. Storing data is the primary use of these objects and once you want to start adding custom behaviors and complex visual elements that extend beyond just data, you will need other scenes/nodes.
-----------------
Pros of using an Inherited scene:
Custom behaviors and interactions that cant be defines through just data alone. You can have a lot more freedom and customizability because of this alone.
Visual representation of things, such as cards, with complex graphics, animations, models, etc can be more easily defined within an inherited scene.
Editor-Friendly which will be easier for designers and artists to both see and manipulate a cards appearance and behavior from the exposed elements in the editor.
Cons of using Inherited scene:
Less data reusability meaning you may need to recreate the same information leading to potential redundancy
The complexity can greatly be increased the more, in this case cards, you add to your game with different behaviors, effects, etc. Managing all of these scenes could become tedious and challenging.
-----------------
Each route to go has their pros and cons and ultimately will be the choice of the developer which way to go. Admittedly I don't use resources in some places where it makes sense. The ideal situation however, would be using a combination of both of these together in your games. The choice depends on your specific needs and the organization of your project.
@@GlitchedCode You can export properties with different default values for inherited scenes, alleviating some cons.
The management part should be tedious either way, or I didn't understand that part correctly.
When it makes sense, you can also inherit scripts and use composition.
Now, it was nice to see the use of customer resources because that's not often demonstrated, and that's a part that is less visible (for obvious reasons).
Nice tutorial.
@@programaths You are right that you can get around most cons. Ultimately it comes down to, especially if you are solo, your own choice. Personally I don't even like exporting variables unless I have to, whereas I know other people that will export every single variable.
Just going to be personal choice. In the end it's just data so you could just use an exported dictionary and avoid resources.
I have seen a few videos talking about how they used resources or why they are great, but I don't think I've seen anyone talk about how to use and create them on a base level. So it became the topic for this video.
That's why it's a good tutorial!
@@programaths Resource is actually a lot more re-powerful than it sounds i recommend you watch godotgamelab(a new channel) in his tutorial series he heavily uses good code architecture( i mean really advanced level) and resources
It will give you a good idea of just how powerful reasources are
How would you randomly select a custom resource (Card Data) and have it populate the Card? Or do you need to build all the cards and then select the card you want? For instance, I want to spawn a card based on a randomly selected Card Data element…
Got it working… Basically created a dictionary where each key is a possible random number (1-100) and set the appropriate.tres to each number.. then the item uses this .tres to create the desired item…. Then the blank card template uses the randomly selected.tres file to fill in the card.
@@richslonaker2768 Awesome! If you wanted to add a card creation mechanic to your game, or create cards on the fly, you could also do that with something like the following:
func createAndSaveCard():
var new_card_data = CardData.new()
new_card_data.name = "New Card"
new_card_data.attack = 10
# To save your custom card as a resource
var save_path = "res://path/to/save/new_card_data.tres"
var error = ResourceSaver.save(save_path, new_card_data)
if error != OK:
print("Error saving CardData resource:", error)
else:
print("CardData resource saved successfully!")
Hello, is there a way to not loss data after I rename variable name?
What are we referring to? If we mean just in the scripts in general you can use find and replace to rename it everywhere. At which point I'm curious how you are losing data.
If this is at runtime, I'm curious about the renaming as I've never heard of this before.