*.Saving Scripts - Different from Video

Unity Courses Ask
#1

It appears that importing the current Inventory.zip files introduces a new set of *.saving scripts vs overwriting what’s in there. This is preferable actually because it doesn’t overwrite what you already had. But it seems to introduce a problem in that now you have two sets of savings scripts and only one set is referenced in your scene.

I watched a video ahead and it’s not addressed. Here is what I did.

  1. I changed the references of my pre-existing RPG files to “using GameDevTV.Saving”
  2. Then I manually merged in whatever comments and changes I previously had in my own copy of RPG.Saving files to be in GameDevTV.Savings (question on this below)
  3. Then I redid the references in my scene Character prefab to SaveableEntity.cs and SavingSystem prefab to SavingSystem.cs

Question

  • what’s a good practice when you want to modify code that you get from an asset pack? Should you copy it in your own folder and then change it and then refer to your modified version? Or should you modify the one in the asset pack folder? I did the latter one, but I think it poses risks that your stuff may get overwritten, so as I think through what I did, I think I have to undo it.
#2

Hmmm OK… after seeing what’s going on a few videos down in Equipable Stats Modifiers, I am now increasingly thinking I want to move the scripts from the GameDevTV.* namespace into my own namespace.

I’m basically going to treat the scripts in the GamedevTV.* namespace as starter code for my own project than an immutable library.

If there’s some future bad consequence I’m not foreseeing, please let me know.

#3

I thought there was a lecture explaining the reason for the move in the namespace, it might have been in one of the earlier sections.

Personally, I recommend sticking with the GamedevTV.Saving namespace, and switching your other classes to the GamedevTV.Saving. This keeps the relationship between the GamedevTV outer namespace and the RPG outer namespace one way (RPG depending on GamedevTV, not the other way around.

#4

Yes - thanks for reminder - they are generic and reusable for other games so I guess that makes sense. I was also worried about an asset (re)import overwriting any of my changes but I guess the solution is to still keep it in a separate namespace.

Back to the original question on good practices for modifying code from asset packs.

Would you say that same thing for someone who wants to make major changes to scripts in the inventories name space? The inventory scripts are great and very powerful but I’m increasingly seeing the need to make changes to support the desired mechanics in my game.

I noted we already copied over the GameDevTV.UI.Inventories prefabs to our own Game folders and modified them directly. I made major changes to those prefabs already and plan to make more. An asset import looks like it would destroy our changes. I think the right answer is to create new original prefabs?

#5

I actually strongly advice building your own prefabs, with a Canvas scaler set to 1920x1080. If you take a look at the Canvas Scaler on the prefabs included with the game, they are an aspect ratio that is more of a square. I learned the hard way when I used the prefabs in a built player that the Inventory window gets totally messed up with the scaling.

In both Dialogues and Quests and Shops and Abilities, we’ll make changes to Inventory. The trick is to ensure that the changes still leave GamedevTV.Inventories not dependent on anything in the RPG namespace.

In fact, in Dialogues and Quests, we accidentally put the Conditions (you’ll get it when you get there) in the RPG.Dialogues namespace. In Shops and Abilities, Sam moves it to GamedevTV.Utils which is the most logical place for it so that Inventory and Equipment can use the interface without referencing the RPG namespace. Keeps the GamedevTV namespace portable.

#6

Yup! I actually set it to 2028x1536 which is the size of an ipad mini, which is my target device. I tested it and it scales just fine to 1920x1080 and 4k.

Got it! This is exactly what I needed to know. I’ll hold off on my major surgery until post course.

#7

Ah - before I forget. For anyone reading this - note that you’ll have to reattach SaveableEntity to your character prefab and SavingSystem to your SavingSystem prefab should you go the recommended route to use the GameDev.TV namespace version of the scripts.

After you do, go to your Player prefab variant and make sure that you manually key in “Player” as the Unique Identifier in the SaveableEntity in the inspector. If you don’t you’ll get weird effects!

#8

I would like to add to that that you’ll need to delete any existing save files as well. Since we’re in the prototyping stage, this shouldn’t anger playtesters too much (if you’re sending the files to playtesters, use the Json saving system instead anyways)

#9

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.

Privacy & Terms