Porting Game to Nintendo Switch

[Tony Li]

If you're using the save system, then add your custom SavedGameDataStorer class to the SaveSystem component's GameObject. The SaveSystem component will call your SavedGameDataStorer's StoreSavedGameData() and RetrieveSavedGameData(). Your SavedGameDataStorer only needs to worry about storing and retrieving it. The SaveSystem component will apply the saved game data after getting it back from RetrieveSavedGameData().

[n_hagialas]

In addition to overriding StoreSavedGameData() and RetrieveSavedGameData(), I ended up overriding Start() into a blank function because it calls LoadSavedGameInfoFromFile(), which has calls to System.IO.

I also did an override on HasDataInSlot(int slotNumber) because it has a call to File.Exists() which is also in System.IO.

Changing these, I was able to get into the main game but it appears like none of the Dialogue System Components are working, i.e. triggers, events, etc. I did see a save file on my device, but I believe that data was just what I had allocated in the Unity Engine. Is there something else that might be happening that I have not yet considered?

Thanks again.

[Tony Li]

Hi Nik,

If your SaveSystem component is on a different GameObject than your Dialogue Manager, make sure your Dialogue Manager doesn't also have a SaveSystem component.

These 3 components act as singletons:

• DialogueSystemController (on Dialogue Manager)
• InputDeviceManager (usually on Dialogue Manager)
• SaveSystem

If there's a SaveSystem on the Dialogue Manager and another on a different GameObject, one of the SaveSystem components will destroy the other GameObject. This means the SaveSystem on the different GameObject could destroy the Dialogue Manager.

If that doesn't help, you're going to have to grab some logs from the Switch. It'll help to make a build in which you've temporarily set the Dialogue Manager's Other Settings > Debug Level to Info.

[n_hagialas]

Updated at end of post:

Hmm, I don't see any issues with multiple of the same Singleton.

I did however see a debug info line about enabling 2D PHYSICS in the Dialogue Systems Welcome screen:
Dialogue System: Dialogue System Trigger is set to a mode that requires a collider, but it has no collider component. If your project is 2D, did you enable 2D support? (Tools > Pixel Crushers > Dialogue System > Welcome Window)

The GameObject does have a 2D trigger component and we can interact with it just fine in Unity and in Windows builds.

Currently, OnUse() DialogueSystemTriggers are working fine, but OnTrigger() based ones are not. We did not have to turn these Welcome checkboxes on for WINDOWS builds, but could this potentially be an issue?

Here's the line in the DialogueSystemTrigger that is causing the warning, but I don't understand, the GameObject has both a Collider2D component and a DialogueSystemTrigger component.

DialogueSystemTrigger Warning

DS_trigger_logwarning.JPG (73.25 KiB) Viewed 248 times

Update:

When I enabled the 2D Physics (USE_PHYSICS2D) option, it allowed the Triggers to work in the build and in the engine!
Curious still why this was not needed for PC builds though.

[Tony Li]

Hi Nik,

Scripting define symbols are defined per platform.

I bet USE_PHYSICS2D was already set for Standalone builds. When you tick a checkbox like USE_PHYSICS2D, the Dialogue System is able to add the scripting define symbol USE_PHYSICS2D only for build platforms that are currently installed in Unity. If you add another platform later (such as Switch), you'll need to tick the checkbox again to add the USE_PHYSICS2D symbol to the Switch platform.