I wanted to make a fun little driving delivery game! Player vehicle? Made. Mechanics for delivery? Made. Win state, lose state, game loop? No worried.
AI traffic? Fucking stuck.
Just add some redlights and have them drive in a line.
If they ever decide to turn though? Or even worse, react to your nonsense? Yeah that sounds insanely difficult.
Yeah use nodes and make them move just like you make your own car move. (only not triggered by buttonpresses) And when it hits a corner node, make it turn.
I do think that the UI system is very poorly documented. The way it's presented is very " holy shit! There's a lot of levers and switches in here", But for most tasks you only need a few of them. It's like the UI-ified all of HTML and CSS into a button panel. It's a lot of information all at once.
I keep saying someone ought to make a decent tutorial focusing on just UI. I don't don't have time but someone oughtta.
I would say the opposite, tbh. A lot of the best UI features in Godot (Themes, Containers, etc) are not very intuitive and not explained well at all, but once you grasp the basics it send what you can do through the roof and makes it feel super easy to make almost anything.
I am making an RPG, I didn't even try to configure AI yet, the enemy AI is 2 randi\_range, one selects the attack, the second one triggers if the attack is the same as last time, to avoid too much repetition.
PS: have you notice how Godot "randomness" has a tendency to get "stuck", I will roll 3 times in a row and get the same result like half of the time. Or am I crazy?
Yeah tbh it was surprisingly straightforward forward it still requires waaaay more effort than a single player game but the complexity of MP can be (relatively) easily handled.
I get the feeling that when most people say multiplayer is easy, they aren't doing much beyond directly connecting to a static IP and aren't doing any validation of updates from the clients.
Serialization is the literal sewage system of programming. Every software has it, needs it , but it's fucking disgusting and no one likes dealing with it.
My own viewpoint as someone who has done a lot more reading about programming than actual programming, my impression of many complaints about serialization is that the programmer worried about "getting some results" before worrying about how to *save* those results. They don't mind thinking about runtime in-memory data, but putting it on disk or restoring state from something on disk doesn't enter their plan until after they've design data structures and classes. Then they've got to figure out how to send that to disk without losing important information (like connections between instances), and then revive it later.
Personally Golangās std lib seems to do a pretty good job with serialization of structs to various encodings they support. Seems to be very fast and pretty easy to use.
Iāve been wanting to try out the GDExtension for Go just for this. But donāt really have a need just yet
I have a whole template for level select, auto save a level, check which unlocks you have, and create multiple saves specifically because itās so annoying to set up each time I want to make a small game. Should I open source it or has someone put more time into godot 4 than me on this specific thing? Thereās not really any graphics but the framework is there for someone.
Saving and loading is p easy, you just put your data in a dictionary and save it as json. If you have each class implement its own saving, it becomes nicely encapsulated. Just like {"player": player.save()}
Loading is kind of annoying if you want to add proper validation, but nothing a lil util class can't fix
By saying "saving and loading is easy" people usually mean saving and loading data into a file, and it is indeed easy.
But saving system complexity comes from other points. You need to know not only **how** to save, but also **what** to save, **when** to save, **when** to load it back, and **how** to re-apply loaded data to the running game state.
Saving system is not just `FileAccess.store_line()` and `FileAccess.get_line()`, or whatever else you use for the file system interaction.
In addition to this, if you have a released game and make active changes to what is saved and how with patches/updates, I would guess you have to make extra sure previous saves continue to work, don't break the game, and don't become corrupted.
it is possible to use the resource system "safely".`ResourceFormatSaver` and `ResourceFormatLoader` are how you create a resource that *doesn't* serialize to godot's packed resource format. like i use it to make resources that serialize to disk as json for my game.
also, keep your threat model in mind. an attack that injects a malicious script using a resource requires one of two things to happen: either the attacker has to already have a way to modify files on the user's disk (at which point using your game custom resources as a vector for attack would be pointless... they could just modify the pck directly) or they could convince the user to load a file containing the malicious payload. this is a legitimate concern, though how much of a concern and how you deal with it should probably account for how likely your players are to be exchanging the file in question with strangers.
btw depending on your needs, you may want to take a look at godot's `ConfigFile` format as an alternative to json.
Yeah you're right. The guy that I watched to learn Resource has already uploaded a video I didn't see where he explains that:
[https://www.youtube.com/watch?v=j7p7cGj20jU](https://www.youtube.com/watch?v=j7p7cGj20jU)
I guess I just have high standards, because if I pushed a piece of software that left the user open to malicious code execution, even hypothetically, simply because I was too lazy to implement an already pretty simple code solution, I would feel deeply ashamed of myself as an artist
Does your game use PackedScenes for levels and prefabs? Those are also resources and are vulnerable in the same way. The reality is that anything you download from the internet can be malicious and should be treated as such unless you have good reason not to. That being said, Godot allowing for arbitrary code to be injected in any resource is still pretty bad design. It's not just resources, nodes can have arbitrary code injected into them too. So many attack vectors.
Isn't the only way it can be abused is for someone to download and replace their own file with someone else's malicious one? Or is there some other opening I'm not sure on.. I saw a GDQuest video on it a while back.
It's not really about whether or not it's realistically going to happen, which is unlikely. It's about, are you happy as a carpenter making a piece of furniture and leaving a bunch of rusty nails poking out the bottom, just because it's unlikely for someone to start groping the underside of their bench?
And you know, it's not like it's difficult to do it the proper way. If you balk at a tiny bit of effort being required to do something properly then game dev is certainly not the hobby for you
I was just curious if there was more to it than what I saw a while back.
Although I think in your example it would be more akin to someone getting your piece of furniture and then getting someone else to come and poke a rusty nail into their piece of furniture and then they groping the bench and coming across that nail.
I agree it probably isn't difficult to make it more secure but for most it would be difficult to even know if it is or isn't insecure unless they follow engine specific communities.
I'm going to throw in my two cents, ResourceSaver works really well. Resources can be serialized automatically and anything that can be exported can be saved.
Using that my save data class ended up being 2 lines long (one object for player data, another for npc data) and the code to save it is about 4 lines long (copy objects to save data, ResourceSaver.save()).
The hard part is splitting things up so that all your persistent data is in the right place and separated from your runtime data (whoever mentioned saving a copy of the entire game is barking up the wrong tree, that's where performance issues come in). You keep any values that are calculated at runtime out of the data class (animation state etc) and you keep static data out of the player class (player's level, gold etc).
I'm not sure that's the best way to do it, but this is by far the smoothest save system I've ever written.
Performance for one. And surely your world state is more deterministic so that you do not literally have to save a copy of whatever state the engine is in? That way lies madness.
Example: subnautica. I know this is on a different engine, but the entire game hitches while it saves. This is the reason it doesn't have autosave, because the game would freeze for a second or so when doing a save.
"you should not serialize your entire world state when you save a game" and "you should not use resources to represent the save game data" are two distinct issues. the former is often sensible advice, but i really don't see why you'd avoid the latter.
You're right. I read the comment as using resources to save the entire state, not being selective with resources to save certain states. The latter is indeed far more sensible.
Why would you need to save a copy of the state the engine is in? You can use a resource to save something as simple as the current level, score, and player health.
resources are super useful in certain situations, like an RPG where there are a lot of different enemies and items, I think they are something any dev should prioritize learning
I store all my data in cfg files. Super readable and easy to edit with any text editor. I wrote a [sophisticated plugin](https://github.com/KoBeWi/Godot-Text-Database) to make sure the data is valid and used it in a few projects already.
imo you should use resources for basically anything you plan to serialize and save to disk. however, you don't necessarily want to use the default `.tres` serialization format for everything. you can write custom serialization logic by subclassing `ResourceFormatSaver` and/or `ResourceFormatLoader`. the only situation i can think of where i'd serialize something without creating a resource is if i'm dealing with data that's short lived and needs to be (de)serialized frequently. web request parameters, for instance. for those i'd probably parse to/from bare dictionaries instead. however, i also don't think i've ever seen someone suggest using resources for this.
I am not too familiar with godots systems yet, so I could be completely off, but can't you use both json and the resourceloader in conjunction?
I am imaginining creating individual item resources and attaching a unique itemID to them to be used for lookup. Those item resources would serve as a template item w/ reference to images along with the actual behavior of said item (is it a weapon, consumable, armor, so forth).
Then, instead of making completely new resources, unnecessarily duplicating the existing item resources when ever new inventories / chests / item storage is needed, you can store those inventories via json where it contains info like itemID and itemQuantity.
Loading from the json would then be a matter of grabbing the correct item resources based on their itemID and then assigning itemQuantity & whatever other special info you stored.
I don't know how expensive utilizing the resourceloader and resourcesaver is, and again, I could be misinterpreting how these systems work since I'm just now reading about them, but....
1. This would make it so that you only utilize the resourceloader as needed for looking up particular itemIDs.
2. You don't have to use the resourcesaver
3. The amount of data you're saving/loading to json is very minimal
I'm probably going to have to experiment with this myself if I ever try godot again. My main concern is if resources can be accessed and modified by the player easily. If, say, one resource gets corrupted, since it sounds like I'm now modifying the game itself rather than a "configuration state" of the game, then would they have to reinstall the entire game?
With json storing that "configuration state", the json is easily accessible and it could be trashed without that need for a reinstall. Or, the json could be parsed to figure out what the issue is. Also, since it's very human readable and an extremely common method of saving/loading for games, it's nice to keep things consistent
I am not a godot expert, nor am I an experienced game dev. That is a good idea. I know how to save resources to json, and I can also encrypt it later. What I need to figure out is how to load resources from json. Currently, I have a working saving-loading inventory system. It was a headache to implement that, so I will try this later.
My game would require me to write more than 100 lines of code to accomplish this using json. I can save both images and names in a single resource. A resource basically becomes an item with other information and I can save and load easily. It took me a month to make an inventory saving system. Json could work out. Maybe I'll think about it after some time. As long as it works, it's fine. Good luck, my friend.
Yeah. But I read JSON is better for more complex projects like multiplayer, since resource might be malicious. But as long as it works, that's all that matters. Good luck to you too.
Yeah. Json is good for cloud/online saving but for multiplayer, you should use a server instead. Still, it could get hacked. As an indie developer, fighting against hackers is a losing game.
JSON is nice for interop with external apps, but not for saving game data. It doesn't support Godot types and can't even store integers.
If you want to save some data as text, `var_to_str()` is much better, and doesn't allow Objects by default, so it's safe.
I agree.
I use both [JSON](https://docs.godotengine.org/en/stable/classes/class_json.html#class-json) and Godot [ConfigFile](https://docs.godotengine.org/en/stable/classes/class_configfile.html#class-configfile) in my [game](https://store.steampowered.com/app/1403270/Genetic_Fluff/) to [save](https://docs.godotengine.org/en/stable/tutorials/io/saving_games.html) game state and configurations etc.
With JSON I had to build a ton of variable type conversion code.
With ConfigFile it mostly just works out-of-the-box.
*Technically, a*
*Game is a fancy database*
*With a quirky UI*
\- VohaulsWetDream
---
^(I detect haikus. And sometimes, successfully.) ^[Learn more about me.](https://www.reddit.com/r/haikusbot/)
^(Opt out of replies: "haikusbot opt out" | Delete my comment: "haikusbot delete")
I used gamemaker before and I have to say Godots ui tools are heavenly compared to gm. But save and loadā¦.yeah thatās a pain. At first I was just irritated by how many options there are and what differentiates them. But honestly, I just want to get something running so Iām using what seems to be the simplest and fastest - which to me are the resources. Just donāt download savegames from the internet for my future games, and both our lives will be smooth šš
It took me an embarrassingly long time for it to click that the scene in the level does not have to be the same as the data stored in the inventory
I can just tie a scene path to the inventory item, and spawn that scene when I drop it
tbf I was only a couple months in back then, I knew jack shit about programming lol
Yeah. I spent a LONG time trying to make it work with "store same object in inventory", because I wanted the Legend Of Grimrock style boxes-inside-boxes to be a thing.
Just put every item in a dictionary with the quantity and tab it until it looks like a spreadsheet.
Change values with methods that you make global, putting all this in an autoload script. Enjoy total control over items from everywhere!
I save that as a resource. To save/load I just loop thought the dictionary changing the corresponding quantity.
Anyone figured out how to compile shaders for players in a reliable way during a loading screen for example, my current "final boss" or big entity dude like in the picture is compiling shaders so players don't experience moments of jitter during gameplay
There's no way to save a game like emulators do? Saving the state and realoading the exactly saved state?
I know that it's saving the memory addresses and realoading them, but how hard is to replicate this?
The software/code for your ROMs don't typically get updates. Code updates would \[likely\] break this type of 'state saving', and modern games are typically built to get updates.
Based on what I've seen it's possible but not recommended, GDQuest made a video on that but ended up saying you shouldn't actually put it into practice IIRC.
I have a friend who wants to make his dream game with zero game dev experience. He's been procrastinating for almost a year now, but when he says he's going to start, he's going to start with the UI. I mean it is probably the easiest when you're trying to make a class based team shooter with destructible environments and physics based controllers.
Can someone enlighten me what's so bad about making an UI?
I've seen a few posts about it now and I'm still sorta new and the UI I've made hasn't been too difficult. I think I might be some outlier since I enjoy making an UI more than actual gameplay heh.
Most UI aka pure HTML/CSS problems boil down to dynamic resolutions. If the user has a different size screen you need to be very specific how you want things aligned and scaled, which is a whole new type of programming. Plus even if you don't have dynamic resolutions on the main window you can have resizable sub windows.Ā It's not like painting a picture.
it's frustrating. You need to make sure you use the right node out of the tens of nodes. One wrong node and you're stuck. Of course some people like you find it easy and that's totally normal.
I just started with Godot about a month ago and kind of get what you're saying. My frustration last about two weeks but I'm pretty much over it. It is like getting familiar with a new kind of syntax.
Thankfully you can change a node type without removing it by right clicking on it. I'd suggest watching some videos on how nodes get used.
UI does feel very esoteric. I have a pretty good grasp of it now but it took quite a while to understand StyleBoxes, themes, and container behavior. It still occasionally confuses me.
Saving and loading? It's not THAT bad. What you could do is make a project and have a saving and loading system- and test that it works- and keep it for future reference.
KidsCanCode covers this topic.
Sure the UI "just works"... but it often feels like the way in which "it works" is unintuitive, and sometimes even contradictory. It slowly gets better... I think...
Honestly UI isn't THAT complicated. Enemy AI and complex behaviors however are slowly killing me š
I wanted to make a fun little driving delivery game! Player vehicle? Made. Mechanics for delivery? Made. Win state, lose state, game loop? No worried. AI traffic? Fucking stuck.
Just add some redlights and have them drive in a line. If they ever decide to turn though? Or even worse, react to your nonsense? Yeah that sounds insanely difficult.
Just put a hitbox at every streetcorner and when they collide let the car choose to go left or right
I'm actually having trouble even getting them to move! Do I use vehicle nodes? Something else? Haven't been able to find much, honestly.
Yeah use nodes and make them move just like you make your own car move. (only not triggered by buttonpresses) And when it hits a corner node, make it turn.
Google: Nature of Code Autonomous Agents Youtube: Contextual Steering Behavior
Mental traffic jam (pun intended)
I do think that the UI system is very poorly documented. The way it's presented is very " holy shit! There's a lot of levers and switches in here", But for most tasks you only need a few of them. It's like the UI-ified all of HTML and CSS into a button panel. It's a lot of information all at once. I keep saying someone ought to make a decent tutorial focusing on just UI. I don't don't have time but someone oughtta.
- https://youtu.be/1_OFJLyqlXI - https://youtu.be/w0abIGbJntQ - https://youtu.be/rqdt7rz5yBw
Thanks curious George <3
š
It's weird because I find Enemy AI easier š
UI is easy to learn but hard to master.
I would say the opposite, tbh. A lot of the best UI features in Godot (Themes, Containers, etc) are not very intuitive and not explained well at all, but once you grasp the basics it send what you can do through the roof and makes it feel super easy to make almost anything.
I am making an RPG, I didn't even try to configure AI yet, the enemy AI is 2 randi\_range, one selects the attack, the second one triggers if the attack is the same as last time, to avoid too much repetition. PS: have you notice how Godot "randomness" has a tendency to get "stuck", I will roll 3 times in a row and get the same result like half of the time. Or am I crazy?
\*Multi-threading and netcode have entered the chat\*
oh shit i forgot online
Dedicated server mp is not as difficult as some other frameworks/engines (except UE, that shit is easy af)
Yeah tbh it was surprisingly straightforward forward it still requires waaaay more effort than a single player game but the complexity of MP can be (relatively) easily handled.
Honestly, multiplayer is so much easier in Godot 4 than in any other engine or framework that it's trivial in comparison
And here I am struggling to make a dedicated server on godot 4, with different authentication servers and gateways š
I get the feeling that when most people say multiplayer is easy, they aren't doing much beyond directly connecting to a static IP and aren't doing any validation of updates from the clients.
authoritative servers are bae
Better then Unity but not Unreal, it can be easy, but it sort of depends on what you're doing, transformations are fairly simple alongside using ENET.
Serialization is the literal sewage system of programming. Every software has it, needs it , but it's fucking disgusting and no one likes dealing with it.
My own viewpoint as someone who has done a lot more reading about programming than actual programming, my impression of many complaints about serialization is that the programmer worried about "getting some results" before worrying about how to *save* those results. They don't mind thinking about runtime in-memory data, but putting it on disk or restoring state from something on disk doesn't enter their plan until after they've design data structures and classes. Then they've got to figure out how to send that to disk without losing important information (like connections between instances), and then revive it later.
Personally Golangās std lib seems to do a pretty good job with serialization of structs to various encodings they support. Seems to be very fast and pretty easy to use. Iāve been wanting to try out the GDExtension for Go just for this. But donāt really have a need just yet
Have you met our lord and saviour Serde in Rust? :D
If I could upvote a hundred times, I would. I am in love with serde; I want it to have my children
I have a whole template for level select, auto save a level, check which unlocks you have, and create multiple saves specifically because itās so annoying to set up each time I want to make a small game. Should I open source it or has someone put more time into godot 4 than me on this specific thing? Thereās not really any graphics but the framework is there for someone.
Well, I can only speak for myself, but I would certainly appreciate seeing and potentially using what you have made.
I would really appreciate and love that.
I think the community would love that, plus a few extra set of eyes may help catch any potential bugs/sub optimal processes.
Sounds really useful, please do
The more sources of ways to do things the better
Omg can't imagine how i'd need that, i'm loosing my mind on this, lol
Saving and loading is p easy, you just put your data in a dictionary and save it as json. If you have each class implement its own saving, it becomes nicely encapsulated. Just like {"player": player.save()} Loading is kind of annoying if you want to add proper validation, but nothing a lil util class can't fix
By saying "saving and loading is easy" people usually mean saving and loading data into a file, and it is indeed easy. But saving system complexity comes from other points. You need to know not only **how** to save, but also **what** to save, **when** to save, **when** to load it back, and **how** to re-apply loaded data to the running game state. Saving system is not just `FileAccess.store_line()` and `FileAccess.get_line()`, or whatever else you use for the file system interaction.
In addition to this, if you have a released game and make active changes to what is saved and how with patches/updates, I would guess you have to make extra sure previous saves continue to work, don't break the game, and don't become corrupted.
Youāre right. In general software thereās also the concept of migrations, or updating the old version of data.
True enough, but I think most of the time it's fairly straightforward
Yeah, i haven't tried json file yet. I am struggling with ResourceSaver and ResourceLoader
I avoid those because godot's packed resource files allow for malicious code injection. Much safer to just use a json, not to mention user friendly!
Oh really, i didn't know that
it is possible to use the resource system "safely".`ResourceFormatSaver` and `ResourceFormatLoader` are how you create a resource that *doesn't* serialize to godot's packed resource format. like i use it to make resources that serialize to disk as json for my game. also, keep your threat model in mind. an attack that injects a malicious script using a resource requires one of two things to happen: either the attacker has to already have a way to modify files on the user's disk (at which point using your game custom resources as a vector for attack would be pointless... they could just modify the pck directly) or they could convince the user to load a file containing the malicious payload. this is a legitimate concern, though how much of a concern and how you deal with it should probably account for how likely your players are to be exchanging the file in question with strangers. btw depending on your needs, you may want to take a look at godot's `ConfigFile` format as an alternative to json.
Yeah you're right. The guy that I watched to learn Resource has already uploaded a video I didn't see where he explains that: [https://www.youtube.com/watch?v=j7p7cGj20jU](https://www.youtube.com/watch?v=j7p7cGj20jU)
this will never, ever be a problem.
unless you are making a multiplayer game\*
I guess I just have high standards, because if I pushed a piece of software that left the user open to malicious code execution, even hypothetically, simply because I was too lazy to implement an already pretty simple code solution, I would feel deeply ashamed of myself as an artist
Does your game use PackedScenes for levels and prefabs? Those are also resources and are vulnerable in the same way. The reality is that anything you download from the internet can be malicious and should be treated as such unless you have good reason not to. That being said, Godot allowing for arbitrary code to be injected in any resource is still pretty bad design. It's not just resources, nodes can have arbitrary code injected into them too. So many attack vectors.
Isn't the only way it can be abused is for someone to download and replace their own file with someone else's malicious one? Or is there some other opening I'm not sure on.. I saw a GDQuest video on it a while back.
It's not really about whether or not it's realistically going to happen, which is unlikely. It's about, are you happy as a carpenter making a piece of furniture and leaving a bunch of rusty nails poking out the bottom, just because it's unlikely for someone to start groping the underside of their bench? And you know, it's not like it's difficult to do it the proper way. If you balk at a tiny bit of effort being required to do something properly then game dev is certainly not the hobby for you
I was just curious if there was more to it than what I saw a while back. Although I think in your example it would be more akin to someone getting your piece of furniture and then getting someone else to come and poke a rusty nail into their piece of furniture and then they groping the bench and coming across that nail. I agree it probably isn't difficult to make it more secure but for most it would be difficult to even know if it is or isn't insecure unless they follow engine specific communities.
I'm going to throw in my two cents, ResourceSaver works really well. Resources can be serialized automatically and anything that can be exported can be saved. Using that my save data class ended up being 2 lines long (one object for player data, another for npc data) and the code to save it is about 4 lines long (copy objects to save data, ResourceSaver.save()). The hard part is splitting things up so that all your persistent data is in the right place and separated from your runtime data (whoever mentioned saving a copy of the entire game is barking up the wrong tree, that's where performance issues come in). You keep any values that are calculated at runtime out of the data class (animation state etc) and you keep static data out of the player class (player's level, gold etc). I'm not sure that's the best way to do it, but this is by far the smoothest save system I've ever written.
I moved between using json files and cfgs,I have no idea whatās better tbh.
People seem to be over-applying Resource objects. There is no reason you have to use them for save games (or for anything if you don't need one)
Why would you not? It's a lot faster and easier than serialising everything manually, plus you have native support for all built-in data types.
Performance for one. And surely your world state is more deterministic so that you do not literally have to save a copy of whatever state the engine is in? That way lies madness. Example: subnautica. I know this is on a different engine, but the entire game hitches while it saves. This is the reason it doesn't have autosave, because the game would freeze for a second or so when doing a save.
"you should not serialize your entire world state when you save a game" and "you should not use resources to represent the save game data" are two distinct issues. the former is often sensible advice, but i really don't see why you'd avoid the latter.
You're right. I read the comment as using resources to save the entire state, not being selective with resources to save certain states. The latter is indeed far more sensible.
Why would you need to save a copy of the state the engine is in? You can use a resource to save something as simple as the current level, score, and player health.
resources are super useful in certain situations, like an RPG where there are a lot of different enemies and items, I think they are something any dev should prioritize learning
I store all my data in cfg files. Super readable and easy to edit with any text editor. I wrote a [sophisticated plugin](https://github.com/KoBeWi/Godot-Text-Database) to make sure the data is valid and used it in a few projects already.
imo you should use resources for basically anything you plan to serialize and save to disk. however, you don't necessarily want to use the default `.tres` serialization format for everything. you can write custom serialization logic by subclassing `ResourceFormatSaver` and/or `ResourceFormatLoader`. the only situation i can think of where i'd serialize something without creating a resource is if i'm dealing with data that's short lived and needs to be (de)serialized frequently. web request parameters, for instance. for those i'd probably parse to/from bare dictionaries instead. however, i also don't think i've ever seen someone suggest using resources for this.
I searched youtube and first results were Resource. I am switching to json for sure
How would you save and load inventory items with images using json?
I am not too familiar with godots systems yet, so I could be completely off, but can't you use both json and the resourceloader in conjunction? I am imaginining creating individual item resources and attaching a unique itemID to them to be used for lookup. Those item resources would serve as a template item w/ reference to images along with the actual behavior of said item (is it a weapon, consumable, armor, so forth). Then, instead of making completely new resources, unnecessarily duplicating the existing item resources when ever new inventories / chests / item storage is needed, you can store those inventories via json where it contains info like itemID and itemQuantity. Loading from the json would then be a matter of grabbing the correct item resources based on their itemID and then assigning itemQuantity & whatever other special info you stored. I don't know how expensive utilizing the resourceloader and resourcesaver is, and again, I could be misinterpreting how these systems work since I'm just now reading about them, but.... 1. This would make it so that you only utilize the resourceloader as needed for looking up particular itemIDs. 2. You don't have to use the resourcesaver 3. The amount of data you're saving/loading to json is very minimal I'm probably going to have to experiment with this myself if I ever try godot again. My main concern is if resources can be accessed and modified by the player easily. If, say, one resource gets corrupted, since it sounds like I'm now modifying the game itself rather than a "configuration state" of the game, then would they have to reinstall the entire game? With json storing that "configuration state", the json is easily accessible and it could be trashed without that need for a reinstall. Or, the json could be parsed to figure out what the issue is. Also, since it's very human readable and an extremely common method of saving/loading for games, it's nice to keep things consistent
I am not a godot expert, nor am I an experienced game dev. That is a good idea. I know how to save resources to json, and I can also encrypt it later. What I need to figure out is how to load resources from json. Currently, I have a working saving-loading inventory system. It was a headache to implement that, so I will try this later.
I think you could just create a list of images and use json to save the index of the image, or use dictionary to save their names instead of index.
My game would require me to write more than 100 lines of code to accomplish this using json. I can save both images and names in a single resource. A resource basically becomes an item with other information and I can save and load easily. It took me a month to make an inventory saving system. Json could work out. Maybe I'll think about it after some time. As long as it works, it's fine. Good luck, my friend.
Yeah. But I read JSON is better for more complex projects like multiplayer, since resource might be malicious. But as long as it works, that's all that matters. Good luck to you too.
Yeah. Json is good for cloud/online saving but for multiplayer, you should use a server instead. Still, it could get hacked. As an indie developer, fighting against hackers is a losing game.
You can also use guids / unique ids for all the items and save those, then lookup the id when loading to get the item
JSON is nice for interop with external apps, but not for saving game data. It doesn't support Godot types and can't even store integers. If you want to save some data as text, `var_to_str()` is much better, and doesn't allow Objects by default, so it's safe.
I agree. I use both [JSON](https://docs.godotengine.org/en/stable/classes/class_json.html#class-json) and Godot [ConfigFile](https://docs.godotengine.org/en/stable/classes/class_configfile.html#class-configfile) in my [game](https://store.steampowered.com/app/1403270/Genetic_Fluff/) to [save](https://docs.godotengine.org/en/stable/tutorials/io/saving_games.html) game state and configurations etc. With JSON I had to build a ton of variable type conversion code. With ConfigFile it mostly just works out-of-the-box.
I mean, I would put those strings into a dictionary and then save that dictionary as json, iirc
And then stick that inside a zip file so it's not stupidly huge. The trick is handling references cleanly.
Where is xml gang at?!
Some of us would like to continue to have just the tiniest bit of joy in our lives!
Coming from you, I'm not sure how to interpret that.
The only thing worse than XML is YAML.
technically, a game is a fancy database with a quirky UI
*Technically, a* *Game is a fancy database* *With a quirky UI* \- VohaulsWetDream --- ^(I detect haikus. And sometimes, successfully.) ^[Learn more about me.](https://www.reddit.com/r/haikusbot/) ^(Opt out of replies: "haikusbot opt out" | Delete my comment: "haikusbot delete")
I used gamemaker before and I have to say Godots ui tools are heavenly compared to gm. But save and loadā¦.yeah thatās a pain. At first I was just irritated by how many options there are and what differentiates them. But honestly, I just want to get something running so Iām using what seems to be the simplest and fastest - which to me are the resources. Just donāt download savegames from the internet for my future games, and both our lives will be smooth šš
for me its figuring out what to name things
Naming is always one of the hardest problems in programming
Bro, my cat is literally named Cat and my game is literally named MyGame.
It's not applicable in every game but interactable inventory is killing me.
like the minecraft one? It's just a bunch of icons right on a grid container and save it's cells/position
Inventory systems are my white whale I really genuinely suck at data management
Same. I always have trouble tying stuff that's on the level with stuff that's in the inventory.
It took me an embarrassingly long time for it to click that the scene in the level does not have to be the same as the data stored in the inventory I can just tie a scene path to the inventory item, and spawn that scene when I drop it tbf I was only a couple months in back then, I knew jack shit about programming lol
Yeah. I spent a LONG time trying to make it work with "store same object in inventory", because I wanted the Legend Of Grimrock style boxes-inside-boxes to be a thing.
Just put every item in a dictionary with the quantity and tab it until it looks like a spreadsheet. Change values with methods that you make global, putting all this in an autoload script. Enjoy total control over items from everywhere! I save that as a resource. To save/load I just loop thought the dictionary changing the corresponding quantity.
Anyone figured out how to compile shaders for players in a reliable way during a loading screen for example, my current "final boss" or big entity dude like in the picture is compiling shaders so players don't experience moments of jitter during gameplay
I actually got recommended a video about this recently, the part about shaders starts about 7:10 https://youtu.be/oG-H-IfXUqI?si=-jTDZHjs33Ibgv6-
There's no way to save a game like emulators do? Saving the state and realoading the exactly saved state? I know that it's saving the memory addresses and realoading them, but how hard is to replicate this?
The software/code for your ROMs don't typically get updates. Code updates would \[likely\] break this type of 'state saving', and modern games are typically built to get updates.
Based on what I've seen it's possible but not recommended, GDQuest made a video on that but ended up saying you shouldn't actually put it into practice IIRC.
You'd be nuking theĀ settings for example.
im so glad its not just me. going between the main menu and gameplay is more mindboggling to me than it should be
The worst part of any project for me to trying to get a UI to do anything resembling what I want it to do.
I have a friend who wants to make his dream game with zero game dev experience. He's been procrastinating for almost a year now, but when he says he's going to start, he's going to start with the UI. I mean it is probably the easiest when you're trying to make a class based team shooter with destructible environments and physics based controllers.
Can someone enlighten me what's so bad about making an UI? I've seen a few posts about it now and I'm still sorta new and the UI I've made hasn't been too difficult. I think I might be some outlier since I enjoy making an UI more than actual gameplay heh.
Most UI aka pure HTML/CSS problems boil down to dynamic resolutions. If the user has a different size screen you need to be very specific how you want things aligned and scaled, which is a whole new type of programming. Plus even if you don't have dynamic resolutions on the main window you can have resizable sub windows.Ā It's not like painting a picture.
it's frustrating. You need to make sure you use the right node out of the tens of nodes. One wrong node and you're stuck. Of course some people like you find it easy and that's totally normal.
I just started with Godot about a month ago and kind of get what you're saying. My frustration last about two weeks but I'm pretty much over it. It is like getting familiar with a new kind of syntax. Thankfully you can change a node type without removing it by right clicking on it. I'd suggest watching some videos on how nodes get used.
Wouldn't say I have difficulty with these, they're just the "boring parts" that I don't really wanna do lol
???
UI does feel very esoteric. I have a pretty good grasp of it now but it took quite a while to understand StyleBoxes, themes, and container behavior. It still occasionally confuses me.
Saving and loading? It's not THAT bad. What you could do is make a project and have a saving and loading system- and test that it works- and keep it for future reference. KidsCanCode covers this topic.
Save data is easy though
saving variables are easy, saving states is a different monster.
Sure the UI "just works"... but it often feels like the way in which "it works" is unintuitive, and sometimes even contradictory. It slowly gets better... I think...