You really need a team of more people, this is without a doubt the best Godot tutorial channel on the platform. You do it like nobody else can, these tutorials are able to cover a broad range of things with just a one hour video and tackle many of the problems a developer might face while trying a daunting task all while explaining it in a way that anybody can understand. Keep up the good work it will pay off!
Thanks a lot, I'm really glad the videos are useful! They are lot of work to make, so its about one video per month give or take (I have a full-time job and a few other obligations, so I can only do this in my spare time). Right now this channel makes about enough money per month to pay for the internet bill (which is great, I don't complain), but given that, I don't see me hiring any external help anytime soon.
Really appreciate it, thanks a lot! I'm a bit reluctant on doing anything "monthly" like a Patreon or UA-cam members. This is really a hobby project I do in my spare time. I have a full time job and other obligations, so time is the limiting factor here. Getting some financial help would allow me to shift priorities more towards the channel but this is something that takes time to implement and I don't want people to be disappointed when they do a monthly thing and I still only put out videos at the same pace as before. That being said, if you'd like to support me financially, I have a Ko-Fi (ko-fi.com/derkork) and I just have enabled the "Super Thanks" feature here. It also helps to spread the word :-). Thanks again!
For whoever is in charge of this channel I hope you know in all my years of programming (there are many) this has to be one of the absolutely clearest teaching documents I’ve ever seen in my life. Thank you.
Most people writing tutorials for topics like this would do a single solution and call it a day. Even for other programming/gamedev products. But you're always so careful to explain the cost and benefit of different solutions so we can use what works for our project and preferences. It's a sign of a true teacher!
Yeah. Which really is how all learning resources should be. So much (not just for Godot, but everything) is just what's available and step by step instructions, when what's important is the "Why" and how it works. The architecture and internal process on a bigger scale, even the Godot Documentation rarely shows that.
For compatibility on new changes to the save game structure, a nice approach used by databases is to have a migration table. When you create a save data file, you also store a version numer of the current Save Data structure. So each time you need to change the structure, you increment the version and create a migration function who convert the previous version to the newer one. That way, for example, if the user had a very old save data, the system will read what version is, and will loop for each migration function executing their converter until the save data is upgraded to the newest version. But yeah, it's a long topic to talk about ^^
Really enjoying your video's. One of the things I HATE about most of the Tutorial/Course content out there is they teach you the simplest way to achieve the result depicted in their description/thumbnail and call it a day, scoop up the ad revenue and they are happy. What I'm enjoying about your content so far is that you do the above, show how to achieve something... Then explain why it's not the right way to do it and expand on it, and show the "proper" way. I don't want to learn quick hacks, I want to be taught the right way to do stuff. Keep at it :)
Yeah, huh. This video plus the accompanying article must be the best piece of game development teaching material I've ever seen. You have introduced crucial topics that I never came across when I was doing research for a save/load systems in Unity games I worked on in my whole career, and explained them with just the correct amount of detail: enough to not leave any holes, not too much to ramble on and just bloat the video length. Furthermore, you have taught about problems I've been aware of but never had the time nor organically came across to figure out full solutions to before. I started watching this video, very new to Godot but curiously looking into getting fluent there, and I've found the language and phrasing used very easily understandable from my transferrable knowledge in Unity. Even better, I was exhilarated watching this with all the care and best-practices put into making the video: you have delineated chapters! You introduce what you're talking about, in which order, before you go into it. As I was watching it, some questions popped up in my mind, and you answered every one of them before the end of the video, fully understanding what is needed and what all the common problems and blind spots are! I was exhilarated about this, and this is the most excited I've been about learning anything in probably four or five years if not my entire career.
There are lots of Godot tutorials out there. Also many very good Godot ones. Haven't seen, though, any as elegant, entertaining, detailed and well structured as yours
Man, how many ways have we seen this content tackled over the years by other Godot content creators? Thanks @Godotneers for breaking down the big ones, as well as covering benefits and drawbacks of each. Certain to use this video as a reference again in tandem with your written documentation and plugin. Thank you!
Out of all the tutorials about saving/loading this one is the best and it isn't even a competition. You helped me actually understand what the heck I was doing with saving and loading
I'm floored, this is easily the BEST tutorial I've ever seen for Godot, maybe even any tutorial ever. I come away from this video with a confidence of knowledge that I simply did not have an hour ago. I learned exactly why certain methods are used and the direct consequences of every step of the most basic implementation to the more robust ones. Pardon the language but great fucking job wow.
Another option besides json or custom resources is to store it as a ConfigFile. It's human readable, supports Godot data types, and comes without the overhead of custom resource classes.
Amazing video. I think this is actually one one the most important Godot videos I have watched in my journey to learn godot. Saving was always a huge problem and you not only show what methods exist, why some are inferior (and in what situations it would still be OK to use them) and give a optimized generic solution for making saving easier. Thank you!
The best tutorials for Godot. I was having really hard time with GUI and only after your tutorial on that subject everything was clear finally, the best part is that I watched that tutorial 3 month ago and everything is still clear. Same goes for all other tutorials here! You have a really great talent for lecturing and thank you for making all of this.
This is by far the best tutorial on saving and loading in Godot that I have seen. You not only showed the solution, but you actually explained it. You're great.
Your videos on Godot are easily and by far the best there are. I'm awed by how well explained everything is. I've already made a full game and I still watch these to gain a deeper understanding of everything. And they're just simply enjoyable to watch.
After watching I think I'm glad I stuck with the JSON approach, its portable between languages, you can encrypt it if you want only the determined players to cheat, and if its a multiplayer game you can keep the valuable data server side. You may have to massage typed data, but everything has tradeoffs. Currently I'm using a single JSON file to manage my players Options menu settings, no one cares if these are edited so I haven't played with encrypting yet.
Yes, if you want to interact with other systems not written in Godot going with JSON is definitely easier as it has widespread support across many languages. As you said, everything is a tradeoff in the end. That's why I tried to show the most common solutions I have come across and then everyone can decide what fits their use case best.
Amazing channel! Beginning my godot journey and for the first time as a solo dev after doing some projects in teams as an 2D/3D artist. Excited to finally do everything and your channel will be such a big help on this solo dev journey!
Just saw this in my recommendations today and I’ve been looking at tutorials to learn Godot. Aside from GDQuest this is another awesome channel showcasing how Godot. I’ll have to come back later to learn. But this will help a lot when setting up a save system. And one explaining in every detail to help newcomers and such. I wish more tutorials were like this. They just jump right into doing it without explaining and showing the steps properly that I just copy and not learn how to do things.
Thank you so much for not only this video, but all your work getting into the nitty-gritty details of Godot. I don't think i'm exaggerating when I say your content is a huge boon to Godot and it's adoption for people who want to use Godot seriously for making games. Keep up the great work!
Your videos are my favorite godot tutorial videos I have found and it has resparked my urge to learn Godot. I really appreciate the time and effort you put into these videos. Can't wait to see more!
This is excellent! As others have said, I appreciate the way you walk the viewer through successively more complex solutions. I was able to follow along using my in-progress project to get my load/save system off the ground. Really good stuff - thank you!
This tutorial is absolutely fantastic! I love it! In my past few projects, I always worked with dictionaries and faced the same problems you mentioned. However, the new system with resources was so easy to set up. I LOVE IT!
I've been using Godot from time to time for quite a while, yet I managed to learn few tricks I wasn't aware before You're a natural teacher I might add, is hard to make videos like this and avoid sounding monotonous and yet you nailed it pretty well
There are not enough thumbs up for me to show you how much I appreciate you sharing your knowledge so openly and in a way that makes sense, covers all aspects, and is entertaining as well! Absolutely amazing video, thank you, thank you, thank you!
This is truly gold, paused examples, clear situations and solutions. One of the best tutorial I've ever seen for programming videogames since I started with Unity to Godot today. You even wrote an article and an addon.
This is a must watch video if you are trying to pick up skills in Godot... Logically presented and informative about the considerations to be made about the process of saving games. Great work on this...
I would just like to thank you for being so thorough in your explanations of Godot! I really REALLY appreciate that you go into the reason behind all your decisions in these videos. Keep up the fantastic work!
I just want to say your channel really saved me, I was struggling to find a good tutorial but yours is just the right length and all the information I need, thank you very much for your hard work
I'm at the 25th minute and you already amazed me. I thought the tutorial would stop at JSON, which, by the way, is more than enough for many games... I'll keep watching. Congratulations on the depth of your tutorials
didn'f finish this video yet but omfg that's so much better than most other tutorials, you actually go slowly enough and get into stuff instead of glossing over it and assuming we're 100% used to coding terminology, so my brain can process stuff you're saying. i even feel like watching all of your other videos just to see if i've missed some other stuff about Godot
Thank you for these videos, they are very helpful. I love that you show common mistakes/problems and also teach how to look up information in the documentation.
Words can't describe how helpful your tutorials are! Thank you so much! I never understood saving and loading and there weren't many tutorials on the internet so this video was super informative! Definitely gonna stick around to see more!
Another fantastic tutorial! Very easy to follow and I feel like I understand the implications (pros vs cons) of the different save game approaches. Thanks very much for making these! Looking forward to the next one!
You are a real one. I can tell that you actually use Godot instead of just reading the docs and cobbling together a quick tutorial. If you have time, I would love some more info on interactable objects with a PhysicsObject2D (pushing boxes and such). All the tutorials on them are kinda short sighted on solving a simple issue, instead of fully understanding the problem.
Thank you so much for these quality tutorials! You are a great teacher. More tutorials should explain using trial and error, especially simulating the mindset of a beginner. You are really good in what you are doing.
I really appreciate your explanation of this topic! In addition to great information about Godot built in resources for saving and loading which I am still learning, I think this is a fantastic video for developing an intuition about the pros and cons for different approaches for our own games. This is so helpful! Looking forward to reading the article you linked as well :)
Riveting video, teeming with priceless knowledge and delivered with engaging flair. An exceptional resource for anyone seeking profound understanding. Excellent. Score 10/10.
This is fantastic. Every time I saw something I would want to improve and questions would be about to come up, you were already answering them. The only thing I would have liked in addition was how to handle multiple saves. But that's a minor aspect I'm sure I can get through UI.
You see 1 hour long video about saves and first thing comes to mind is "maaan this is gonna be 90% filler content, saves can't be that hard, right?" Turns out it's a fairly deep topic, the video is packed to the brim with useful info, easy to digest and very entertainment, congratulations!
So helpful and valuable. Just made my way through your whole backlog and hope to see more...amazing quality of information and presentation. Thank you!
Just wanted to say thank you for being an excellent teacher :) also, you sound almost exactly like Brackeys, which is a compliment by the way! Both of you have great voices and are excellent teachers 😎
Best Godot tutorials in the universe. Fun to watch, informative and comprehensive. ... I just wish it had more C#. That said, everything will translate well to C# so don't listen to me. Just keep doing what you do :)
I am not hating on this video, it is well explained. There still is an issue I want to talk about. Every game needs a same system, other than very few exceptions. What I don't understand though, is why this process doesn't have a standardized system within Godot, when everybody needs to do it anyway. Like, Godot has access to all the nodes and scripts, thus all information. Of course positions should be saved in every game, so that can 100% be handled automatically, unless specified. It writes all the info in a standardized way into a desired file format. If we are afraid that the file size would be too great if we stored all variables of all objects at all times, why not have a section in the inspector that lists all variables where we can tick, which variables should be saved and which shouldn't. Then we simply have a function to call for saving, which writes the information to a file in a standardized way that is native to the godot saving system and loading, which then automatically sets the variables to the saved information and we are done. I don't see why for more complicated games, where I have hundreds of different variables I have to save, I have to manually organize my save file around those and have to add custom code for every single variable for both saving and loading. Then also create custom resources for every single entity that needs some sort of save. I don't see why there couldn't be native save and load code in the node class for godot. This is coming from somebody btw, who has written custom save systems for games programmed games outside of game engines. Because the reason I choose engines is because it should standardize processes every game needs anyway. For the sake of convenience. Why would this part, which basically every game needs be excluded and every single dev has to write their own custom save system for their game. This seems like a massive time sink for no reason.
I agree that having "batteries included" would be nice there is a huge variety in the way in which games are working and finding a savegame approach that works universally for every game looks like an impossible task to me. It's not just saving and loading the data itself but especially in the restore phase you have to run some game specific logic to put the world back into the state it was. You also probably don't want to save each and every variable in the game (that would be basically a memory dump of the running game). This is surely possible to do but would create humongous saved game files. Another thing that a generic system will have a really hard time with is catering for saved game migrations. That being said, if you have some experience with the matter you could write an addon and publish it in the asset library. I don't think the Godot devs will ever add something like this to the core as they tend to keep everything out of the core that can be done in an addon.
@@godotneers Is the last sentance you said true? If it is, then I don't understand it. Isn't Godot made in Godot? What couldn't be an addon then? That doesn't really make much sense to me. I thought the features of the engine were determined by what the people who are part of the development think would be valuable to enough users and are voted to be implemented because of that.
Well I'd argue that a generic save game system counts as "complex canned solution". It will have a lot of moving parts to cater for a lot of games and will inherently have a lot of complexity. If you have a look at this document docs.godotengine.org/en/stable/contributing/development/best_practices_for_engine_contributors.html then based on the information there I'd say the chances of such a system materializing in the engine core are very slim. That being said, I'm not a Godot engine developer so what I think about things is ultimately irrelevant. If you'd like some official feedback on your idea I'd suggest you open up a feature proposal here: github.com/godotengine/godot-proposals/issues/new?assignees=&labels=&projects=&template=feature_proposal.yml . Then the Godot team and others can discuss it and maybe it even gets some traction, you never know.
Yes indeed. It's not going to stop a determined person (as they could just save a new hash of the modified file) but it will make it harder for the average person to mess with the save files.
Thank you so much, it's really too easy explained and with lots of examples, issues and resolves. Your voice is also cool! I hope you'll continue to make tutorials. I would buy your courses if you make them😁
absolutely phenomenal video. question: if you have an object that stores some other object in a variable, what's a good way to save/restore that? e.g. if a torpedo locks on to a particular fish, you save/load and the torpedo remains locked on to that very same fish
IIt's definitely doable but it will become a little bit more complex. I discussed this with a friend and we came up with three ways of doing this. In either way you will need a third phase for the loading which runs after all the nodes have been restored, because only then you can re-establish any link between the restored nodes. This can be just another game event, so you could add an `on_after_game_loaded` function to the nodes that need to re-establish links. Now onto the three ways from simplest to most complex: 1. If you have a detection area and a stable rule to lock onto targets, you could just get all the enemies in your detection area and then lock on one depending on the ruleset. This could work for towers in a tower defense game. If the rule is that the tower always locks onto the enemy with least health, then in the `on_after_game_loaded` function the tower could look at the enemies in its detection area and pick the one with the least health and restore would be done. 2. If you don't have the luxury of a stable rule or a detection area (which is your torpedo example), then you need to have some way to identify the target node to lock on after loading. Because you cannot use node paths (as they are dynamic and not predictable at runtime) you would need a different way of identifying it. One way would be to save/load an ID value with each node that can be targeted. Then you could put all nodes that can be potentially targeted by a torpedo into a group (e.g. `targetable`). Now when the game is saved, the torpedo stores the ID of its current target in its saved data and all nodes that can be targets also store their IDs. When the game is loaded, the targets restore their IDs, and the torpedo restores the ID of its target. In the `on_after_game_loaded` the torpedo now walks over the `targetable` group and finds its target node by comparing its restored target ID with the node's ID. This is pretty easy to implement but conceptually I don't really like it because now all the targets need to know that they are `targetable` and need to manage an ID which they themselves don't use. 3. You could add a generic linking system to the SaverLoader. The SaverLoader knows all the nodes that will be saved because it calls each node. Now we could add a dictionary to `SavedData` which is called `links`. There each node can add links to other nodes. E.g. the torpedo could add an entry "target" : _my_target_node. Now the SaverLoader would need to keep track which SavedData originated from which node. Once all the nodes have returned their SavedData object, the SaverLoader can post-process them and replace the reference to the node, with a reference to the SavedData object of the node. So in our torpedo example it would change the "target" entry so it now points to the `SavedData` object that was created by the target of the torpedo. When restoring, the SaverLoader will walk over all `SavedData` objects as usual, instantiate the nodes and then modify the links dictionary to again contain the actual nodes. And only then it would call the `on_load_game` method of each node. The torpedo can than pick its target node from the `links` dictionary in the `SavedData` object it gets for restoration. This approach is a bit more complex to implement as you need to do a bit of bookkeeping in the `SaverLoader` but it has the advantage that you don't need to mark nodes with an ID and that targets don't need to know about being `targetable` by a torpedo. So I think in the long run this will be more scalable than 2. I hope this gives you some ideas on how to do it. Enjoy making your game!
You are doing great stuff and you also good at teaching. Your videos always inspires me to learn more, develop more. Thanks for sharing and looking forward more content from you.
Thanks a lot for your videos, they're always some of the most clear and complete out there, and have helped me a lot with learning how to use Godot! Are you planning on making a video about option menus? So far I've seen a few tutorials on changing resolution/sound/etc, but they often don't explain why they're doing things the way they are, so I don't really know what the "proper" way to handle all of this is.
You really need a team of more people, this is without a doubt the best Godot tutorial channel on the platform. You do it like nobody else can, these tutorials are able to cover a broad range of things with just a one hour video and tackle many of the problems a developer might face while trying a daunting task all while explaining it in a way that anybody can understand. Keep up the good work it will pay off!
Thanks a lot, I'm really glad the videos are useful! They are lot of work to make, so its about one video per month give or take (I have a full-time job and a few other obligations, so I can only do this in my spare time). Right now this channel makes about enough money per month to pay for the internet bill (which is great, I don't complain), but given that, I don't see me hiring any external help anytime soon.
@@godotneers Have you considered creating a Patreon?
@@cakemonitor842 great suggestion, I would definitely subscribe.
Or youtube sponsorship, if you can do so. Really great content and I would like to support its creation.
Really appreciate it, thanks a lot! I'm a bit reluctant on doing anything "monthly" like a Patreon or UA-cam members. This is really a hobby project I do in my spare time. I have a full time job and other obligations, so time is the limiting factor here. Getting some financial help would allow me to shift priorities more towards the channel but this is something that takes time to implement and I don't want people to be disappointed when they do a monthly thing and I still only put out videos at the same pace as before. That being said, if you'd like to support me financially, I have a Ko-Fi (ko-fi.com/derkork) and I just have enabled the "Super Thanks" feature here. It also helps to spread the word :-). Thanks again!
For whoever is in charge of this channel I hope you know in all my years of programming (there are many) this has to be one of the absolutely clearest teaching documents I’ve ever seen in my life. Thank you.
Most people writing tutorials for topics like this would do a single solution and call it a day. Even for other programming/gamedev products. But you're always so careful to explain the cost and benefit of different solutions so we can use what works for our project and preferences. It's a sign of a true teacher!
I love that you show the logical steps through implementations. It really helps to see WHY certain techniques will paint you into a corner.
Yeah. Which really is how all learning resources should be.
So much (not just for Godot, but everything) is just what's available and step by step instructions, when what's important is the "Why" and how it works. The architecture and internal process on a bigger scale, even the Godot Documentation rarely shows that.
For the ResourceSaver you can change the file type from "tres" to "res" to save it in binary format.
For compatibility on new changes to the save game structure, a nice approach used by databases is to have a migration table. When you create a save data file, you also store a version numer of the current Save Data structure. So each time you need to change the structure, you increment the version and create a migration function who convert the previous version to the newer one.
That way, for example, if the user had a very old save data, the system will read what version is, and will loop for each migration function executing their converter until the save data is upgraded to the newest version.
But yeah, it's a long topic to talk about ^^
Excellent notice and suggestion!
14:48: Quick tip for faster access to the user data for your current project: menu bar at the top of the screen, Project - Open User Data Folder.
It's a good day when there is a new Godotneers video :-)
it is so true!
Really enjoying your video's. One of the things I HATE about most of the Tutorial/Course content out there is they teach you the simplest way to achieve the result depicted in their description/thumbnail and call it a day, scoop up the ad revenue and they are happy.
What I'm enjoying about your content so far is that you do the above, show how to achieve something... Then explain why it's not the right way to do it and expand on it, and show the "proper" way. I don't want to learn quick hacks, I want to be taught the right way to do stuff. Keep at it :)
Yeah, huh. This video plus the accompanying article must be the best piece of game development teaching material I've ever seen. You have introduced crucial topics that I never came across when I was doing research for a save/load systems in Unity games I worked on in my whole career, and explained them with just the correct amount of detail: enough to not leave any holes, not too much to ramble on and just bloat the video length. Furthermore, you have taught about problems I've been aware of but never had the time nor organically came across to figure out full solutions to before. I started watching this video, very new to Godot but curiously looking into getting fluent there, and I've found the language and phrasing used very easily understandable from my transferrable knowledge in Unity. Even better, I was exhilarated watching this with all the care and best-practices put into making the video: you have delineated chapters! You introduce what you're talking about, in which order, before you go into it. As I was watching it, some questions popped up in my mind, and you answered every one of them before the end of the video, fully understanding what is needed and what all the common problems and blind spots are! I was exhilarated about this, and this is the most excited I've been about learning anything in probably four or five years if not my entire career.
The best Godot channel around hands down!
There are lots of Godot tutorials out there. Also many very good Godot ones. Haven't seen, though, any as elegant, entertaining, detailed and well structured as yours
Man, how many ways have we seen this content tackled over the years by other Godot content creators? Thanks @Godotneers for breaking down the big ones, as well as covering benefits and drawbacks of each. Certain to use this video as a reference again in tandem with your written documentation and plugin.
Thank you!
Out of all the tutorials about saving/loading this one is the best and it isn't even a competition. You helped me actually understand what the heck I was doing with saving and loading
I absolutely love your videos and how in-depth they get, please keep making these!!
the fact that you made that add on is amazing you are such an amazing teacher and person
I'm floored, this is easily the BEST tutorial I've ever seen for Godot, maybe even any tutorial ever. I come away from this video with a confidence of knowledge that I simply did not have an hour ago. I learned exactly why certain methods are used and the direct consequences of every step of the most basic implementation to the more robust ones. Pardon the language but great fucking job wow.
Another option besides json or custom resources is to store it as a ConfigFile. It's human readable, supports Godot data types, and comes without the overhead of custom resource classes.
@winstoneyallow Do you know of anyone walking through this possible way of doing save and load?
Amazing video. I think this is actually one one the most important Godot videos I have watched in my journey to learn godot. Saving was always a huge problem and you not only show what methods exist, why some are inferior (and in what situations it would still be OK to use them) and give a optimized generic solution for making saving easier. Thank you!
The mic audio improvement is heaven man. These tutorials are so incredible it makes long listening so much more enjoyable. Thank you!
The best tutorials for Godot. I was having really hard time with GUI and only after your tutorial on that subject everything was clear finally, the best part is that I watched that tutorial 3 month ago and everything is still clear. Same goes for all other tutorials here! You have a really great talent for lecturing and thank you for making all of this.
This is by far the best tutorial on saving and loading in Godot that I have seen. You not only showed the solution, but you actually explained it. You're great.
Your videos on Godot are easily and by far the best there are. I'm awed by how well explained everything is. I've already made a full game and I still watch these to gain a deeper understanding of everything. And they're just simply enjoyable to watch.
Very comprehensive yet perfectly paced and structured. Tip top!🤟
Glad this has been useful! Thank yu you very much for your support!
After watching I think I'm glad I stuck with the JSON approach, its portable between languages, you can encrypt it if you want only the determined players to cheat, and if its a multiplayer game you can keep the valuable data server side. You may have to massage typed data, but everything has tradeoffs.
Currently I'm using a single JSON file to manage my players Options menu settings, no one cares if these are edited so I haven't played with encrypting yet.
Yes, if you want to interact with other systems not written in Godot going with JSON is definitely easier as it has widespread support across many languages. As you said, everything is a tradeoff in the end. That's why I tried to show the most common solutions I have come across and then everyone can decide what fits their use case best.
Amazing channel! Beginning my godot journey and for the first time as a solo dev after doing some projects in teams as an 2D/3D artist. Excited to finally do everything and your channel will be such a big help on this solo dev journey!
This is by far the best video on the subject that I've seen. I'm immensely glad to have come across this video
Just saw this in my recommendations today and I’ve been looking at tutorials to learn Godot.
Aside from GDQuest this is another awesome channel showcasing how Godot.
I’ll have to come back later to learn.
But this will help a lot when setting up a save system. And one explaining in every detail to help newcomers and such.
I wish more tutorials were like this. They just jump right into doing it without explaining and showing the steps properly that I just copy and not learn how to do things.
Thank you so much for not only this video, but all your work getting into the nitty-gritty details of Godot. I don't think i'm exaggerating when I say your content is a huge boon to Godot and it's adoption for people who want to use Godot seriously for making games. Keep up the great work!
Your videos are my favorite godot tutorial videos I have found and it has resparked my urge to learn Godot. I really appreciate the time and effort you put into these videos. Can't wait to see more!
I like that you explain why we do things rather than just giving us the solution because that is so helpful!
This is excellent! As others have said, I appreciate the way you walk the viewer through successively more complex solutions. I was able to follow along using my in-progress project to get my load/save system off the ground. Really good stuff - thank you!
I was literally looking at downloading the Godot Safe Resource Loader plugin before I watched this video! You the man!
This tutorial is absolutely fantastic! I love it! In my past few projects, I always worked with dictionaries and faced the same problems you mentioned. However, the new system with resources was so easy to set up. I LOVE IT!
I've been using Godot from time to time for quite a while, yet I managed to learn few tricks I wasn't aware before
You're a natural teacher I might add, is hard to make videos like this and avoid sounding monotonous and yet you nailed it pretty well
This is the best tutorial I've ever watched period. It's very clear and I managed to learn a lot ! Thanks a lot for all the work you put in !
There are not enough thumbs up for me to show you how much I appreciate you sharing your knowledge so openly and in a way that makes sense, covers all aspects, and is entertaining as well! Absolutely amazing video, thank you, thank you, thank you!
This is truly gold, paused examples, clear situations and solutions. One of the best tutorial I've ever seen for programming videogames since I started with Unity to Godot today. You even wrote an article and an addon.
This is a must watch video if you are trying to pick up skills in Godot... Logically presented and informative about the considerations to be made about the process of saving games. Great work on this...
I would just like to thank you for being so thorough in your explanations of Godot! I really REALLY appreciate that you go into the reason behind all your decisions in these videos. Keep up the fantastic work!
Mate, you are a national treasure! The explanation was spectacularly done, excellent pacing and detailed information. Thank you for your hard work.
I just want to say your channel really saved me, I was struggling to find a good tutorial but yours is just the right length and all the information I need, thank you very much for your hard work
Actually going through ALL the possible options instead of just one, and actually going through all the pros and cons, very nice. Very nice indeed!
Wow great work. Your doing great things for Godot developers!
I'm at the 25th minute and you already amazed me. I thought the tutorial would stop at JSON, which, by the way, is more than enough for many games... I'll keep watching. Congratulations on the depth of your tutorials
didn'f finish this video yet but omfg that's so much better than most other tutorials, you actually go slowly enough and get into stuff instead of glossing over it and assuming we're 100% used to coding terminology, so my brain can process stuff you're saying. i even feel like watching all of your other videos just to see if i've missed some other stuff about Godot
The article on save game compatibility is exceptional.
Fantastic work!
What an absolutely solid tutorial. Thank you very much!
Amazing work. Very impressed by your channel. Please keep going. Your work is leading to great things for you and everyone else. I'm sure of it!
Love how you explain the naive approaches and showcase the downsides. Easily one of the most valuable Godot education channels ✨
At first blush I thought "What could possibly take an hour to explain about save/load?!" An hour later, I appreciate your thorough approach.
I have about 350 variables I need to save and load. so 20:33 to 26:00 helped me a ton. (I'm making an app to help with my job lol). Thank you so much!
Thank you for these videos, they are very helpful. I love that you show common mistakes/problems and also teach how to look up information in the documentation.
these are the most useful and well put together tutorials I've seen online, for Godot and perhaps for anything else!!
Thanks for the video; your tutorials are some of the best I have ever seen.
Words can't describe how helpful your tutorials are! Thank you so much! I never understood saving and loading and there weren't many tutorials on the internet so this video was super informative! Definitely gonna stick around to see more!
Awesome vid as always, great job with the compatibility doc and the code exec addon
Another fantastic tutorial! Very easy to follow and I feel like I understand the implications (pros vs cons) of the different save game approaches. Thanks very much for making these!
Looking forward to the next one!
Man, someone should make a statue of you. This was excellent. Thank you so much for all the detail!
this was more complicated than i thought it was going to be but it was a very detailed, i loved it
You are a real one. I can tell that you actually use Godot instead of just reading the docs and cobbling together a quick tutorial. If you have time, I would love some more info on interactable objects with a PhysicsObject2D (pushing boxes and such). All the tutorials on them are kinda short sighted on solving a simple issue, instead of fully understanding the problem.
Thank you so much for these quality tutorials! You are a great teacher. More tutorials should explain using trial and error, especially simulating the mindset of a beginner. You are really good in what you are doing.
such a great tutorial, really appreciate it
This video and your resources video taken together has completely changed the way I use Godot.
I really appreciate your explanation of this topic! In addition to great information about Godot built in resources for saving and loading which I am still learning, I think this is a fantastic video for developing an intuition about the pros and cons for different approaches for our own games. This is so helpful! Looking forward to reading the article you linked as well :)
Riveting video, teeming with priceless knowledge and delivered with engaging flair. An exceptional resource for anyone seeking profound understanding. Excellent. Score 10/10.
This is fantastic. Every time I saw something I would want to improve and questions would be about to come up, you were already answering them. The only thing I would have liked in addition was how to handle multiple saves. But that's a minor aspect I'm sure I can get through UI.
Wow, the best Tutorial on a SaveLoad System ever. I love it!
Thank you! It is so understandable and detailed. Perfect tutorial!
You see 1 hour long video about saves and first thing comes to mind is "maaan this is gonna be 90% filler content, saves can't be that hard, right?"
Turns out it's a fairly deep topic, the video is packed to the brim with useful info, easy to digest and very entertainment, congratulations!
These videos are pure gold. So easy to follow. Thanks Godotneers!
Excellent video. I like that you compared several common ways of handling save data.
Your tutorials are so interesting and useful that I can't stop watching till the end
Finally, Mr. Godotneers has uploaded the most detailed tutorial video one month later. Always enthusiastic and healthy, Mr. Godotneers❤👍
So helpful and valuable. Just made my way through your whole backlog and hope to see more...amazing quality of information and presentation. Thank you!
Just wanted to say thank you for being an excellent teacher :) also, you sound almost exactly like Brackeys, which is a compliment by the way! Both of you have great voices and are excellent teachers 😎
Best Godot tutorials in the universe. Fun to watch, informative and comprehensive. ... I just wish it had more C#. That said, everything will translate well to C# so don't listen to me. Just keep doing what you do :)
As a beginner finally at the stage where i need to tackle saving and with a lot of stuff to save this is very good. My brain hurts but its good.
I am not hating on this video, it is well explained. There still is an issue I want to talk about. Every game needs a same system, other than very few exceptions. What I don't understand though, is why this process doesn't have a standardized system within Godot, when everybody needs to do it anyway. Like, Godot has access to all the nodes and scripts, thus all information. Of course positions should be saved in every game, so that can 100% be handled automatically, unless specified. It writes all the info in a standardized way into a desired file format. If we are afraid that the file size would be too great if we stored all variables of all objects at all times, why not have a section in the inspector that lists all variables where we can tick, which variables should be saved and which shouldn't. Then we simply have a function to call for saving, which writes the information to a file in a standardized way that is native to the godot saving system and loading, which then automatically sets the variables to the saved information and we are done. I don't see why for more complicated games, where I have hundreds of different variables I have to save, I have to manually organize my save file around those and have to add custom code for every single variable for both saving and loading. Then also create custom resources for every single entity that needs some sort of save. I don't see why there couldn't be native save and load code in the node class for godot. This is coming from somebody btw, who has written custom save systems for games programmed games outside of game engines. Because the reason I choose engines is because it should standardize processes every game needs anyway. For the sake of convenience. Why would this part, which basically every game needs be excluded and every single dev has to write their own custom save system for their game. This seems like a massive time sink for no reason.
I agree that having "batteries included" would be nice there is a huge variety in the way in which games are working and finding a savegame approach that works universally for every game looks like an impossible task to me. It's not just saving and loading the data itself but especially in the restore phase you have to run some game specific logic to put the world back into the state it was. You also probably don't want to save each and every variable in the game (that would be basically a memory dump of the running game). This is surely possible to do but would create humongous saved game files. Another thing that a generic system will have a really hard time with is catering for saved game migrations. That being said, if you have some experience with the matter you could write an addon and publish it in the asset library. I don't think the Godot devs will ever add something like this to the core as they tend to keep everything out of the core that can be done in an addon.
@@godotneers Is the last sentance you said true? If it is, then I don't understand it. Isn't Godot made in Godot? What couldn't be an addon then? That doesn't really make much sense to me. I thought the features of the engine were determined by what the people who are part of the development think would be valuable to enough users and are voted to be implemented because of that.
Well I'd argue that a generic save game system counts as "complex canned solution". It will have a lot of moving parts to cater for a lot of games and will inherently have a lot of complexity. If you have a look at this document docs.godotengine.org/en/stable/contributing/development/best_practices_for_engine_contributors.html then based on the information there I'd say the chances of such a system materializing in the engine core are very slim. That being said, I'm not a Godot engine developer so what I think about things is ultimately irrelevant. If you'd like some official feedback on your idea I'd suggest you open up a feature proposal here: github.com/godotengine/godot-proposals/issues/new?assignees=&labels=&projects=&template=feature_proposal.yml . Then the Godot team and others can discuss it and maybe it even gets some traction, you never know.
You could also save hash values of save files then check against them during load to make sure no external changes were made.
Yes indeed. It's not going to stop a determined person (as they could just save a new hash of the modified file) but it will make it harder for the average person to mess with the save files.
Thank you so much, it's really too easy explained and with lots of examples, issues and resolves. Your voice is also cool! I hope you'll continue to make tutorials. I would buy your courses if you make them😁
Love this channel!!! Thank you so much!
Спасибо!
Thank you very much for supporting me!
OMG, compatibility part is really helpful which I just meet that. Thank you!
"Like" right away, "Subscribe" way sooner than I would have thought. Thank you, this is exactly what I'm figuring out.
absolutely phenomenal video. question: if you have an object that stores some other object in a variable, what's a good way to save/restore that? e.g. if a torpedo locks on to a particular fish, you save/load and the torpedo remains locked on to that very same fish
IIt's definitely doable but it will become a little bit more complex. I discussed this with a friend and we came up with three ways of doing this. In either way you will need a third phase for the loading which runs after all the nodes have been restored, because only then you can re-establish any link between the restored nodes. This can be just another game event, so you could add an `on_after_game_loaded` function to the nodes that need to re-establish links. Now onto the three ways from simplest to most complex:
1. If you have a detection area and a stable rule to lock onto targets, you could just get all the enemies in your detection area and then lock on one depending on the ruleset. This could work for towers in a tower defense game. If the rule is that the tower always locks onto the enemy with least health, then in the `on_after_game_loaded` function the tower could look at the enemies in its detection area and pick the one with the least health and restore would be done.
2. If you don't have the luxury of a stable rule or a detection area (which is your torpedo example), then you need to have some way to identify the target node to lock on after loading. Because you cannot use node paths (as they are dynamic and not predictable at runtime) you would need a different way of identifying it. One way would be to save/load an ID value with each node that can be targeted. Then you could put all nodes that can be potentially targeted by a torpedo into a group (e.g. `targetable`). Now when the game is saved, the torpedo stores the ID of its current target in its saved data and all nodes that can be targets also store their IDs. When the game is loaded, the targets restore their IDs, and the torpedo restores the ID of its target. In the `on_after_game_loaded` the torpedo now walks over the `targetable` group and finds its target node by comparing its restored target ID with the node's ID. This is pretty easy to implement but conceptually I don't really like it because now all the targets need to know that they are `targetable` and need to manage an ID which they themselves don't use.
3. You could add a generic linking system to the SaverLoader. The SaverLoader knows all the nodes that will be saved because it calls each node. Now we could add a dictionary to `SavedData` which is called `links`. There each node can add links to other nodes. E.g. the torpedo could add an entry "target" : _my_target_node. Now the SaverLoader would need to keep track which SavedData originated from which node. Once all the nodes have returned their SavedData object, the SaverLoader can post-process them and replace the reference to the node, with a reference to the SavedData object of the node. So in our torpedo example it would change the "target" entry so it now points to the `SavedData` object that was created by the target of the torpedo. When restoring, the SaverLoader will walk over all `SavedData` objects as usual, instantiate the nodes and then modify the links dictionary to again contain the actual nodes. And only then it would call the `on_load_game` method of each node. The torpedo can than pick its target node from the `links` dictionary in the `SavedData` object it gets for restoration. This approach is a bit more complex to implement as you need to do a bit of bookkeeping in the `SaverLoader` but it has the advantage that you don't need to mark nodes with an ID and that targets don't need to know about being `targetable` by a torpedo. So I think in the long run this will be more scalable than 2.
I hope this gives you some ideas on how to do it. Enjoy making your game!
Yeahhh this is exactly what I need, thank you.
This tutorial is SO GOOD!
Another absolutely awesome video, thank you so much !
Thanks!😁
Thank you very much for supporting me! 😁
I'm very happy that I subscribed to your channel. I'm learning so much about Godot.
You are doing great stuff and you also good at teaching. Your videos always inspires me to learn more, develop more. Thanks for sharing and looking forward more content from you.
Excellent video! Thanks so much. Big help for me as a solo indie dev.
Great to see Godot's rising
Btw, your 23th like
Thank you, it's Helps a lot
Thanks!
@NexhamTube thank you very much for your support!
Thank you much for this video and all your tutos.
This is the one I was looking for.
Another great video and then I even learn more in the comments. Thank you for your hard work and knowledge!!!!
Thanks a ton for these videos, they are incredible. Im working through all of them and the one's I've watched have been very helpful.
It Helps me a lot 🥰 | I was frustrated with my godot | THanks for this wonderful Explanation :)
Thanks a lot for your videos, they're always some of the most clear and complete out there, and have helped me a lot with learning how to use Godot!
Are you planning on making a video about option menus?
So far I've seen a few tutorials on changing resolution/sound/etc, but they often don't explain why they're doing things the way they are, so I don't really know what the "proper" way to handle all of this is.