Closing a browser tab should not erase four hours of progress. That seems obvious, yet plenty of browser games treat loc

ಬ್ರೌಸರ್ ಟ್ಯಾಬ್ ಅನ್ನು ಮುಚ್ಚುವುದರಿಂದ ನಾಲ್ಕು ಗಂಟೆಗಳ ಪ್ರಗತಿಯು ಅಳಿಸಿಹೋಗಬಾರದು. ಇದು ಸ್ಪಷ್ಟವಾಗಿ ಕಂಡರೂ, ಅನೇಕ ಬ್ರೌಸರ್ ಗೇಮ್‌ಗಳು localStorage ಅನ್ನು ಕೇವಲ ಒಂದು ಸಣ್ಣ ವಿಷಯವೆಂದು ಪರಿಗಣಿಸುತ್ತವೆ. ಒಬ್ಬ ಆಟಗಾರ ಹೆಚ್ಚಿನ ಸ್ಕೋರ್ (high score) ಸಾಧಿಸಿ, ತಮ್ಮ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಬದಲಾಯಿಸಿ, ಮರುದಿನ ಬಂದಾಗ ಅಲ್ಲಿ ಏನೂ ಇರುವುದಿಲ್ಲ. ಅದಕ್ಕಿಂತ ಕೆಟ್ಟದಾಗಿ, ಒಂದು ಪ್ಯಾಚ್ (patch) ನಂತರ ಅವರು ಮರಳಿದಾಗ, ಅವರ ಯಂತ್ರದಲ್ಲಿರುವ ಸೇವ್ ಫೈಲ್ ನೀವು ಈಗ ಕಳುಹಿಸಿರುವ ಕೋಡ್‌ಗೆ ಹೊಂದಿಕೆಯಾಗದ ಕಾರಣ ಗೇಮ್ ಎರರ್ ತೋರಿಸುತ್ತದೆ. Phaser 4 ನಲ್ಲಿ ಸರ್ವೈವರ್-ಸ್ಟೈಲ್ ಶೂಟರ್ ಅನ್ನು ನಿರ್ಮಿಸುವುದು ಎಂದರೆ ನಿರಂತರವಾಗಿ ಬರುವ ಶತ್ರುಗಳ ಅಲೆಗಳನ್ನು ಎದುರಿಸುವುದು ಎಂದರ್ಥ, ಆದರೆ ನಿಜವಾದ ದೀರ್ಘಕಾಲದ ಬೆದರಿಕೆ ಎಂದರೆ ನಿಮ್ಮದೇ ಮುಂದಿನ ಅಪ್‌ಡೇಟ್‌ಗಳು.

ಹೆಚ್ಚಿನ డೆವಲಪರ್‌ಗಳು ಒಂದು ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು ಪಡೆದು, ಅದನ್ನು JSON.stringify ಮೂಲಕ ಹಾಕಿ, localStorage ಗೆ ಸೇರಿಸುವ ಮೂಲಕ ತಮ್ಮ ಮೊದಲ ಸೇವ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ನಿರ್ಮಿಸುತ್ತಾರೆ. ಲೋಡ್ ಮಾಡುವಾಗ, ಅವರು ಅದನ್ನು ಪಾರ್ಸ್ ಮಾಡಿ ಗೇಮ್‌ಗೆ ನೇರವಾಗಿ ನೀಡುತ್ತಾರೆ. ಇದು ಮೊದಲ ದಿನ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಆದರೆ ನೀವು ಒಂದು ಹೊಸ ಸೆಟ್ಟಿಂಗ್, ಹೊಸ ಅನ್‌ಲಾಕ್ ಫ್ಲಾಗ್ ಅಥವಾ ಮೂರನೇ ಹಂತದ ನೆಸ್ಟೆಡ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಸೇರಿಸಿದ ತಕ್ಷಣ ಇದು ಮುರಿದುಬೀಳುತ್ತದೆ. ಮರಳಿ ಬರುವ ಆಟಗಾರನ ಬಳಿ vignette ಪ್ರಾಪರ್ಟಿ ಇಲ್ಲದ ಹಳೆಯ ಸೇವ್ ಫೈಲ್ ಇದ್ದರೆ ಮತ್ತು ನಿಮ್ಮ ಹೊಸ ಕೋಡ್ ಅದು ಇರಬೇಕೆಂದು ನಿರೀಕ್ಷಿಸಿದರೆ, ನೀವು ನಿರೀಕ್ಷಿಸಿದ ಬೂಲಿಯನ್ (boolean) ಬದಲಿಗೆ undefined ಸಿಗುತ್ತದೆ. ಇಂತಹ ಡಜನ್ಗಟ್ಟಲೆ ಹೊಸ ಫೀಚರ್‌ಗಳನ್ನು ಗಮನಿಸಿದರೆ, ಇದು ನಿಮ್ಮ ಅತ್ಯಂತ ನಿಷ್ಠಾವಂತ ಆಟಗಾರರಿಗೆ ಮೊದಲು ತಲುಪುವ ಡಿಬಗ್ಗಿಂಗ್ ದುಸ್ತರವಾಗುತ್ತದೆ.

ಕೇವಲ ರ ಕಲ್ವ ಆಬ್ಜೆಕ್ಟ್‌ನಿಂದಲ್ಲ, ಒಂದು ಕಾಂಟ್ರಾಕ್ಟ್‌ನಿಂದ ಪ್ರಾರಂಭಿಸಿ

ನೀವು localStorage ಅನ್ನು ಮುಟ್ಟುವ ಮೊದಲೇ, ನಿಮ್ಮ ಕೋಡ್‌ಬೇಸ್‌ನಲ್ಲಿ ಒಂದು ಡಿಫಾಲ್ಟ್ ಸೇವ್ ಸ್ಕೀಮಾವನ್ನು (default save schema) ವ್ಯಾಖ್ಯಾನಿಸಿ. ಅದು ಐದು ನಿಮಿಷಗಳ ಹಿಂದೆ ರಚಿತವಾಗಿದ್ದರೂ ಅಥವಾ ಐದು ತಿಂಗಳ ಹಿಂದೆ ರಚಿತವಾಗಿದ್ದರೂ, ಪ್ರತಿಯೊಂದು ಸೇವ್ ಫೈಲ್ ಗೌರವಿಸಬೇಕಾದ ಒಂದು ಕಾಂಟ್ರಾಕ್ಟ್ ಎಂದು ಭಾವಿಸಿ. ಸ್ಪಷ್ಟವಾದ ಆರಂಭಿಕ ಹಂತವು ಹೀಗಿರಬಹುದು:

const defaultSave = {
  highScore: 0,
  settings: {
    screenShake: true,
    vignette: true
  }
};

ಈ ಆಬ್ಜೆಕ್ಟ್ ನಿಮ್ಮ ಸೋರ್ಸ್ ಕೋಡ್‌ನಲ್ಲಿ ಇರುತ್ತದೆ. ಗೇಮ್ ಪ್ರಾರಂಭವಾದಾಗ, ಈ ರೂಪವು ಯಾವಾಗಲೂ ಲಭ್ಯವಿರುತ್ತದೆ. ಇದು ನಿಮಗೆ ಒಂದು ಬೇಸ್‌ಲೈನ್ ನೀಡುತ್ತದೆ. ಅಲ್ಲದೆ, ನೀವು ಏನನ್ನಾದರೂ ಸೀರಿಯಲೈಸ್ (serialize) ಮಾಡುವ ಮೊದಲು ಅದರ ರಚನೆಯ ಬಗ್ಗೆ ಯೋಚಿಸಲು ಇದು ನಿಮ್ಮನ್ನು ಪ್ರೇರೇಪಿಸುತ್ತದೆ. ನೀವು ಈ ಹಂತವನ್ನು ಬಿಟ್ಟು, ಆ ಸಮಯದಲ್ಲಿ ಅನುಕೂಲಕರವೆನಿಸುವ ಸ್ಟೇಟ್ ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು ಸುಮ್ಮನೆ ಸಂಗ್ರಹಿಸಿದರೆ, ಹಳೆಯ ಸೇವ್‌ಗಳು ನಿಮ್ಮ ನಿರೀಕ್ಷೆಗಳಿಗೆ ಹೊಂದಿಕೆಯಾಗದಿದ್ದಾಗ ಅಸಂಗತ ಕೀಗಳು (inconsistent keys), ಕಾಣೆಯಾದ ಫೀಲ್ಡ್‌ಗಳು ಮತ್ತು ಸೈಲೆಂಟ್ ಫೈಲ್ಯರ್‌ಗಳನ್ನು ನೀವು ಎದುರಿಸಬೇಕಾಗುತ್ತದೆ.

Try/Catch ಬಳಸಿ ಸುರಕ್ಷಿತವಾಗಿ ಲೋಡ್ ಮಾಡಿ

ಲೋಕಲ್ ಸ್ಟೋರೇಜ್ ಒಂದು ಡೇಟಾಬೇಸ್ ಅಲ್ಲ. ಇದು ಬ್ರೌಸರ್‌ನಲ್ಲಿರುವ ಒಂದು ಸ್ಟ್ರಿಂಗ್ ಕ್ಲೋಸೆಟ್ (string closet) ಇದ್ದಂತೆ, ಮತ್ತು ಅಲ್ಲಿ ಏನೂ ಇರಬಹುದು. ಬಳಕೆದಾರರು ಮ್ಯಾನುಯಲ್ ಆಗಿ ಮೌಲ್ಯವನ್ನು ಎಡಿಟ್ ಮಾಡಿರಬಹುದು, ಅರ್ಧಕ್ಕೆ ನಿಂತ ರೈಟ್ ಆಪರೇಷನ್ ಇರಬಹುದು ಅಥವಾ ಬ್ರೌಸರ್ ಎಕ್ಸ್‌ಟೆನ್ಶನ್ ನೀವು ಬಳಸಿದ ಕೀಯಲ್ಲಿ ಕಸವನ್ನು (garbage) ಹಾಕಿರಬಹುದು. ನೀವು ಆ ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ಹೊರತೆಗೆದು JSON.parse ಗೆ ನೀಡಿದಾಗ, ಕೇವಲ ಒಂದು ದೋಷಪೂರಿತ ಅಕ್ಷರವು ಹಾರ್ಡ್ ಎಕ್ಸೆಪ್ಶನ್ (hard exception) ಉಂಟುಮಾಡುತ್ತದೆ. Phaser ಗೇಮ್‌ನಲ್ಲಿ, ಅನ್‌ಹ್ಯಾಂಡಲ್ಡ್ ಎರರ್ ನಿಮ್ಮ ಬೂಟ್ ಸೀಕ್ವೆನ್ಸ್ ಅನ್ನು ಸ್ಥಗಿತಗೊಳಿಸಬಹುದು ಅಥವಾ ಆಟಗಾರನನ್ನು ಬ್ಲಾಂಕ್ ಸ್ಕ್ರೀನ್‌ಗೆ ತಳ್ಳಬಹುದು.

ನಿಮ್ಮ ರೀಡ್ ಮತ್ತು ಪಾರ್ಸ್ ಲಾಜಿಕ್ ಅನ್ನು ಯಾವಾಗಲೂ try/catch ಬ್ಲಾಕ್‌ನಲ್ಲಿ ಇರಿಸಿ. ವಿಫಲವಾದಲ್ಲಿ, ನಿಮ್ಮ ಡಿಫಾಲ್ಟ್ ಸ್ಕೀಮಾವನ್ನು ಬಳಸಿ. ಗುರಿ ಸರಳವಾಗಿದೆ: ಸೇವ್ ಫೈಲ್ ಓದಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಇಡೀ ಸೆಷನ್ ಅನ್ನು ಕ್ರ್ಯಾಶ್ ಮಾಡುವ ಬದಲು ಆಟಗಾರನನ್ನು ಹೊಸ ಬಳಕೆದಾರನಂತೆ ಪರಿಗಣಿಸಿ. ಈ ಒಂದು ಅಭ್ಯಾಸವು ಹವ್ಯಾಸದ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳನ್ನು ಪ್ರೊಡಕ್ಷನ್-ಗ್ರೇಡ್ ಬಿಲ್ಡ್‌ಗಳಿಂದ ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ. ಇದನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳಲು ಯಾವುದೇ ವೆಚ್ಚವಿಲ್ಲ ಮತ್ತು ಇದು ನೀವು ಪುನರಾವರ್ತಿಸಲು ಅಸಾಧ್ಯವಾದ ನಿಗೂಢ ಬಗ್ ವರದಿಗಳಿಂದ ನಿಮ್ಮನ್ನು ರಕ್ಷಿಸುತ್ತದೆ.

ಹಳೆಯ ಡೇಟಾವನ್ನು ಡಿಫಾಲ್ಟ್‌ಗಳೊಂದಿಗೆ ವಿಲೀನಗೊಳಿಸಿ

ಪಾರ್ಸ್ ಯಶಸ್ವಿಯಾಯಿತು ಎಂದಾಕ್ಷಣ ನೀವು ಸುರಕ್ಷಿತರಾಗಿದ್ದೀರಿ ಎಂದರ್ಥವಲ್ಲ. ಪಾರ್ಸ್ ಮಾಡಿದ ಫಲಿತಾಂಶದಿಂದ ನಿಮ್ಮ ಡಿಫಾಲ್ಟ್ ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು ಎಂದಿಗೂ ಸಂಪೂರ್ಣವಾಗಿ ಬದಲಾಯಿಸಬೇಡಿ. ಆ ಹಳೆಯ ಸೇವ್ ಫೈಲ್‌ನಲ್ಲಿ ನಿಮ್ಮ ಇತ್ತೀಚಿನ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಇರಲಿಕ್ಕಿಲ್ಲ. ಅದು screenShake ಅನ್ನು ಸಂಗ್ರಹಿಸಿರಬಹುದು ಆದರೆ vignette ಇರಲಿಕ್ಕಿಲ್ಲ. ನಿಮ್ಮ ಗೇಮ್ ಲಾಜಿಕ್ ಇತ್ತೀಚಿನ ಅಪ್‌ಡೇಟ್‌ನೊಂದಿಗೆ vignette ಇರುತ್ತದೆ ಎಂದು ಭಾವಿಸಿದರೆ, ನೀವು ಮತ್ತೆ undefined ಎರರ್‌ಗಳ ಬೆನ್ನಟ್ಟುವ ಸ್ಥಿತಿಗೆ ತಲುಪುತ್ತೀರಿ.

ಬದಲಾಗಿ, ಲೋಡ್ ಮಾಡಿದ ಡೇಟಾವನ್ನು ನಿಮ್ಮ ಡಿಫಾಲ್ಟ್‌ಗಳೊಂದಿಗೆ ವಿಲೀನಗೊಳಿಸಿ (merge). ಬೇಸ್‌ಲೈನ್ ಸ್ಕೀಮಾ ಮೇಲೆ ಉಳಿದ ಮೌಲ್ಯಗಳನ್ನು ಪದರಗಳಾಗಿ ಹಾಕಲು Object.assign ಬಳಸಿ. ಡಿಫಾಲ್ಟ್‌ಗಳು ಪ್ರತಿಯೊಂದು ಕಾಣೆಯಾದ ಜಾಗವನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ತುಂಬುತ್ತವೆ. ವರ್ಷ ಎರಡು ರಲ್ಲಿ ನೀವು ಸೇರಿಸಿದ ಹೊಸ ಪ್ರಾಪರ್ಟಿಗಳು ಡಿಫಾಲ್ಟ್ ಆಬ್ಜೆಕ್ಟ್‌ನಿಂದ ಅವುಗಳ ಆರಂಭಿಕ ಮೌಲ್ಯಗಳನ್ನು ಪಡೆಯುತ್ತವೆ. ಆಟಗಾರನು ನಿಜವಾಗಿಯೂ ಬದಲಾಯಿಸಿದ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪ್ರಾಪರ್ಟಿಗಳು ಅವರ ಸಂಗ್ರಹಿಸಿದ ಆದ್ಯತೆಗಳೊಂದಿಗೆ ಅಳವಡಿಸಲ್ಪಡುತ್ತವೆ. ಇದರಿಂದ ಎಲ್ಲರಿಗೂ ಲಾಭ. ಮರಳಿ ಬರುವ ಆಟಗಾರನು ತನ್ನ ಹೈ ಸ್ಕೋರ್ ಅನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತಾನೆ ಮತ್ತು ಗೇಮ್ ಯಾವುದೇ ತೊಂದರೆಯಿಲ್ಲದೆ ನೀವು ನಿನ್ನೆ ಸೇರಿಸಿದ ಹೊಸ ಟಾಗಲ್ ಅನ್ನು ಬಳಸಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.

Object.assign ಒಂದು ಶಾಲೋ ಮರ್ಜ್ (shallow merge) ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ನೆನಪಿಡಿ. ನಿಮ್ಮ ಸೆಟ್ಟಿಂಗ್ಸ್ ಆಬ್ಜೆಕ್ಟ್ ಕಾಲಾನಂತರದಲ್ಲಿ ಆಳವಾಗಿ ನೆಸ್ಟೆಡ್ (deeply nested) ಆಗುತ್ತಾ ಹೋದರೆ, ನೀವು ಆ ಒಳಗಿನ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಎಚ್ಚರಿಕೆಯಿಂದ ನಿರ್ವಹಿಸಬೇಕಾಗಬಹುದು. ಆದರೂ, ತತ್ವವದು ಒಂದೇ: ಆಟಗಾರನ ಡೇಟಾ ನಿಮ್ಮ ಡಿಫಾಲ್ಟ್‌ಗಳನ್ನು ಅಲಂಕರಿಸಬೇಕೇ ಹೊರತು, ಅವುಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬದಲಾಯಿಸಬಾರದು.

ನಿಮ್ಮ ಕೀಗಳನ್ನು ವರ್ಷನ್ ಮಾಡಿ

ಬ್ರೌಸರ್‌ಗಳು ಹಳೆಯ ಲೋಕಲ್ ಸ್ಟೋರೇಜ್ ಎಂಟ್ರಿಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಅಳಿಸುವುದಿಲ್ಲ. ನೀವು ನಿಮ್ಮ ಡೇಟಾ ರಚನೆಯನ್ನು ತೀವ್ರವಾಗಿ ಬದಲಾಯಿಸಿದರೆ, ಹಳೆಯ ಫಾರ್ಮ್ಯಾಟ್ ಅನ್ನು ಕೈಬಿಡಲು ನಿಮಗೆ ಒಂದು ಸ್ವಚ್ಛವಾದ ಮಾರ್ಗ ಬೇಕಾಗುತ್ತದೆ. ನಿಮ್ಮ ಸ್ಟೋರೇಜ್ ಕೀಯನ್ನು ವರ್ಷನ್ ಸಫಿಕ್ಸ್‌ನೊಂದಿಗೆ ಹೆಸರಿಸಿ. bitSurvivorsSave_v1 ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ಅದು ಯಾವ ಸ್ಕೀಮಾ ಆ ಫೈಲ್ ಅನ್ನು ಬರೆದಿದೆ ಎಂಬುದನ್ನು ನಿಮಗೆ ನಿಖರವಾಗಿ ತಿಳಿಸುತ್ತದೆ. ನಂತರ, ನೀವು ಪ್ರೋಗ್ರೆಶನ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬದಲಾಯಿಸಿದಾಗ ಅಥವಾ ಪೂರ್ಣ ಇನ್ವೆಂಟರಿ ಸಿಸ್ಟಮ್ ಅನ್ನು ಸೇರಿಸಿದಾಗ, bitSurvivorsSave_v2 ಗೆ ಬದಲಾಯಿಸಿ.

ಇದು ನಿಮಗೆ ಎರಡು ಪ್ರಾಯೋಗಿಕ ಪ್ರಯೋಜನಗಳನ್ನು ನೀಡುತ್ತದೆ. ಮೊದಲನೆಯದಾಗಿ, ನೀವು ಎಂದಿಗೂ ತಪ್ಪಾಗಿ v1 blob ಅನ್ನು v2 ಲಾಜಿಕ್‌ನೊಂದಿಗೆ ಪಾರ್ಸ್ ಮಾಡುವುದಿಲ್ಲ. ಎರಡನೆಯದಾಗಿ, ನೀವು ಬಯಸಿದರೆ ಮೈಗ್ರೇಷನ್ ಕೋಡ್ ಅನ್ನು ಬರೆಯಬಹುದು. ಬೂಟ್ ಆಗುವಾಗ, v1 ಇದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಅದು ಇದ್ದರೆ ಮತ್ತು v2 ಇಲ್ಲದಿದ್ದರೆ, ಹಳೆಯ ದತ್ತಾಂಶವನ್ನು ಹೊಸ ರಚನೆಗೆ ಮೈಗ್ರೇಟ್ ಮಾಡಿ, ಅದನ್ನು ಹೊಸ ಕೀಗೆ ಬರೆಯಿರಿ ಮತ್ತು ಮುಂದುವರಿಯಿರಿ. ನೀವು ಮೈಗ್ರೇಟ್ ಮಾಡಲು ಬಯಸದಿದ್ದರೆ, ಕನಿಷ್ಠ ಹಳೆಯ ಕೀಯು ಸ್ಟೋರೇಜ್‌ನಲ್ಲಿ ಯಾವುದೇ ಹಾನಿಯಿಲ್ಲದೆ ಇರುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ ಹೊಸ ಕೋಡ್ ಅದನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ. ಯಾವುದೇ ರೀತಿಯಲ್ಲಿರಲಿ, ವರ್ಷನಿಂಗ್ (versioning) ದತ್ತಾಂಶವು ಮೌನವಾಗಿ ಹಾಳಾಗುವುದನ್ನು ತಡೆಯುತ್ತದೆ.

ಉಳಿಸುವುದನ್ನು (Saving) ಅದೃಶ್ಯಗೊಳಿಸಿ

ಪರ್ಸಿಸ್ಟೆನ್ಸ್ (Persistence) ಉಸಿರಾಟದಂತೆ ಅನಿಸಬೇಕು. ಆಟಗಾರ ಇದರ ಬಗ್ಗೆ ಎಂದಿಗೂ ಯೋಚಿಸಬೇಕಾಗಿಲ್ಲ. ನಿಮ್ಮ ಸೆಟ್ಟಿಂಗ್ಸ್ ಮೆನುವಿನಲ್ಲಿ 'Apply' ಬಟನ್ ಅನ್ನು ಸೇರಿಸಬೇಡಿ. 'Apply' ಬಟನ್‌ಗಳು ಅಡಚಣೆಯನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ ಮತ್ತು ಬಳಕೆದಾರರು ತಮ್ಮ ಆಯ್ಕೆಗಳು ನಿಜವಾಗಿಯೂ ಉಳಿದಿವೆಯೇ ಎಂದು ಚಿಂತಿಸುವಂತೆ ಮಾಡುತ್ತವೆ. ಆಟಗಾರ ಮೂರು ಆಯ್ಕೆಗಳನ್ನು ಬದಲಾಯಿಸಿ (toggle), 'Apply' ಒತ್ತಲು ಮರೆತು ಟ್ಯಾಬ್ ಅನ್ನು ಮುಚ್ಚಿದಾಗ, ಇವು ದತ್ತಾಂಶದ ನಷ್ಟಕ್ಕೆ ಕಾರಣವಾಗುತ್ತವೆ.

ಇಂಟರಾಕ್ಷನ್ ನಡೆದ ಕ್ಷಣದಲ್ಲೇ ಸೇವ್ ಮಾಡಿ. ಸ್ಕ್ರೀನ್ ಶೇಕ್ ಅನ್ನು ರದ್ದುಗೊಳಿಸಲು ಆಟಗಾರ ಚೆಕ್‌ಬಾಕ್ಸ್ ಕ್ಲಿಕ್ ಮಾಡಿದಾಗ, ತಕ್ಷಣವೇ ನಿಮ್ಮ write ಫಂಕ್ಷನ್ ಅನ್ನು ಕರೆಯಿರಿ. ಆಟ ಮುಗಿದು ಅಂತಿಮ ಸ್ಕೋರ್ ಲೆಕ್ಕಾಚಾರವಾದಾಗ, 'game over' ಸ್ಕ್ರೀನ್ ಅನಿಮೇಟ್ ಆಗುವ ಮೊದಲೇ ಹೊಸ ಹೈ ಸ್ಕೋರ್ ಅನ್ನು ಬರೆಯಿರಿ. ಇವೆಂಟ್-ಡ್ರಿವನ್ ಸೇವಿಂಗ್ (Event-driven saving) ನಿಮ್ಮ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಊಹಿಸಬಹುದಾಗುವಂತೆ ಮಾಡುತ್ತದೆ, ಏಕೆಂದರೆ ಸೇವ್ ಯಾವಾಗಲೂ ದತ್ತಾಂಶವನ್ನು ಬದಲಾಯಿಸಿದ ಕ್ರಿಯೆಯ ಪಕ್ಕದಲ್ಲೇ ಇರುತ್ತದೆ. ನೀವು ಯಾವುದೇ ಸೆಂಟ್ರಲ್ ಬ್ಯಾಚಿಂಗ್ ಫಂಕ್ಷನ್ ಅನ್ನು ಹುಡುಕಬೇಕಾಗಿಲ್ಲ ಅಥವಾ ಹಳೆಯ ಸ್ಟೇಟ್ (stale state) ಬಗ್ಗೆ ಚಿಂತಿಸಬೇಕಾಗಿಲ್ಲ.

ಈ ವಿಧಾನವು ನಿಮ್ಮ ಮಾನಸಿಕ ಮಾದರಿಯನ್ನು (mental model) ಸರಳಗೊಳಿಸುತ್ತದೆ. ಪರ್ಸಿಸ್ಟೆನ್ಸ್ ಎಲ್ಲಿ ನಡೆಯುತ್ತದೆ ಎಂಬುದು ನಿಮಗೆ ನಿಖರವಾಗಿ ತಿಳಿದಿರುತ್ತದೆ: ಟೋಗಲ್ ಅನ್ನು ನಿರ್ವಹಿಸುವ ಕಾಲಬ್ಯಾಕ್‌ನಲ್ಲಿ ಮತ್ತು ಸಾವು ಅಥವಾ ಅಂತ್ಯವನ್ನು ನಿರ್ವಹಿಸುವ ಫಂಕ್ಷನ್‌ನಲ್ಲಿ. ಕೋಡ್‌ಬೇಸ್‌ನಾದ್ಯಂತ ಯಾವುದೇ ನಿಗೂಢ ರೈಟ್ಸ್ (mystery writes) ಇರುವುದಿಲ್ಲ.

ನಿಮಗಾಗಿ ಒಂದು ರಿಸೆಟ್ ಬಟನ್ ನಿರ್ಮಿಸಿ

ನೀವು ಡೆವಲಪ್‌ಮೆಂಟ್ ಸಮಯದಲ್ಲಿ ನಿಮ್ಮ ಸ್ವಂತ ಸೇವ್‌ಗಳನ್ನು ಹಾಳು ಮಾಡಿಕೊಳ್ಳುತ್ತೀರಿ. ನೀವು ತಪ್ಪು ದತ್ತಾಂಶವನ್ನು ಬರೆಯುತ್ತೀರಿ, ಎಡ್ಜ್ ಕೇಸ್‌ಗಳನ್ನು (edge cases) ಪರೀಕ್ಷಿಸುತ್ತೀರಿ ಮತ್ತು ಶೀಘ್ರವಾಗಿ ಕ್ಲೀನ್ ಸ್ಟೇಟ್‌ಗೆ ಮರಳುವ ಅಗತ್ಯವಿರುತ್ತದೆ. ಡಿಬಗ್ ಮೆನುವಿನಲ್ಲಿ ಅಥವಾ ಗುಪ್ತ ಕೀ ಕಾಂಬಿನೇಷನ್‌ನಲ್ಲಿ ರಿಸೆಟ್ ಬಟನ್ ಅನ್ನು ನಿರ್ಮಿಸಿ. ಆ ರಿಸೆಟ್ ಬಟನ್ ಈ ಕೆಳಗಿನ ಕ್ರಮದಲ್ಲಿ ಎರಡು ಕೆಲಸಗಳನ್ನು ಮಾಡಲಿ: ನಿಮ್ಮ ಇನ್-ಮೆಮರಿ ಸ್ಟೇಟ್ ಅನ್ನು ಡಿಫಾಲ್ಟ್ ಸ್ಕೀಮಾಗೆ ರಿಸೆಟ್ ಮಾಡಿ, ನಂತರ ತಕ್ಷಣವೇ ಲೋಕಲ್ ಸ್ಟೋರೇಜ್‌ಗೆ ಬರೆಯುವ ಅದೇ ಸೇವ್ ಫಂಕ್ಷನ್ ಅನ್ನು ಕರೆಯಿರಿ.

ನೀವು ಕೇವಲ ಲೋಕಲ್ ವೇರಿಯಬಲ್ ಅನ್ನು ಕ್ಲಿಯರ್ ಮಾಡಿ ಬರೆಯುವ ಹಂತವನ್ನು ಬಿಟ್ಟರೆ, ನೀವು ಏನನ್ನೂ ಸಾಧಿಸಿಲ್ಲ ಎಂದರ್ಥ. ಮುಂದಿನ ಪೇಜ್ ರಿಫ್ರೆಶ್ ಬ್ರೌಸರ್‌ನಿಂದ ಹಳೆಯ ದತ್ತಾಂಶವನ್ನು ಮತ್ತೆ ತರುತ್ತದೆ. ಪರ್ಸಿಸ್ಟ್ ಮಾಡಲು ಮರೆತ ರಿಸೆಟ್ ಎಂಬುದು ಒಂದು ಮಧ್ಯಾಹ್ನವನ್ನು ವ್ಯರ್ಥ ಮಾಡುವಂತಹ ಬಗ್ (bug). ಈ ಕ್ರಮವನ್ನು ಒಮ್ಮೆ ಸರಿಯಾಗಿ ನಿಗದಿಪಡಿಸಿ, ಆಗ ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್‌ನ ಉಳಿದ ಭಾಗದವರೆಗೆ ನಿಮ್ಮ ಟೆಸ್ಟಿಂಗ್ ಲೂಪ್ ವೇಗವಾಗಿ ಇರುತ್ತದೆ.

ನಿಜವಾದ ಸಾರಾಂಶ

ಸೇವಿಂಗ್ ಎಂಬುದು ಕೊನೆಯಲ್ಲಿ ನೀವು ಸೇರಿಸುವ ಕೇವಲ ಒಂದು ಫೀಚರ್ ಅಲ್ಲ. ಇದು ನಿಮ್ಮ ಆಟವು ಸ್ಥಿರವಾಗಿ ಮತ್ತು ಆಟಗಾರನ ಸಮಯಕ್ಕೆ ಗೌರವ ನೀಡುವಂತೆ ಕಾಣುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವ ಮೂಲಸೌಕರ್ಯವಾಗಿದೆ. ಒಂದು Phaser 4 ಸರ್ವೈವರ್ ಶೂಟರ್ ಆಟವು ಪದೇ ಪದೇ ಆಡುವ ರನ್‌ಗಳ ಮೇಲೆ ಬದುಕುತ್ತದೆ ಅಥವಾ ಸಾಯುತ್ತದೆ. ಬ್ರೌಸರ್ ಟ್ಯಾಬ್ ಆಟಗಾರನ ಪ್ರಗತಿಯ ಮೇಲೆ ಗುರಿಯಿಟ್ಟಿರುವ ತುಂಬಿದ ಗನ್ ಇದ್ದರೆ, ಅವರು ಅಂತಿಮವಾಗಿ ಮರಳಿ ಬರುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತಾರೆ. ಒಂದು ಸ್ಕೀಮಾವನ್ನು ಬರೆಯಿರಿ, ತಪ್ಪು ದತ್ತಾಂಶದಿಂದ ರಕ್ಷಿಸಿಕೊಳ್ಳಿ, ಬದಲಾಯಿಸುವ ಬದಲು ಮರ್ಜ್ ಮಾಡಿ, ನಿಮ್ಮ ಕೀಗಳನ್ನು ವರ್ಷನಿಂಗ್ ಮಾಡಿ ಮತ್ತು ಪ್ರತಿಯೊಂದು ಅರ್ಥಪೂರ್ಣ ಇವೆಂಟ್‌ನಲ್ಲಿ ಸೇವ್ ಮಾಡಿ. ನಿಮ್ಮ ಭವಿಷ್ಯದ ನೀವು ಮತ್ತು ನಿಮ್ಮ ಮುಂದಿನ ಅಪ್‌ಡೇಟ್ ನಂತರ ಮರಳಿ ಬರುವ ಪ್ರತಿಯೊಬ್ಬ ಆಟಗಾರನೂ ನಿಮಗೆ ಧನ್ಯವಾದ ಅರ್ಪಿಸುತ್ತಾರೆ.