ਬ੍ਰਾਊਜ਼ਰ ਟੈਬ ਬੰਦ ਕਰਨ ਨਾਲ ਚਾਰ ਘੰਟਿਆਂ ਦੀ ਪ੍ਰਗਤੀ (progress) ਮਿਟਣੀ ਨਹੀਂ ਚਾਹੀਦੀ। ਇਹ ਸਪੱਸ਼ਟ ਲੱਗਦਾ ਹੈ, ਫਿਰ ਵੀ ਬਹੁਤ ਸਾਰੇ ਬ੍ਰਾਊਜ਼ਰ ਗੇਮਾਂ local storage ਨੂੰ ਬਹੁਤ ਘੱਟ ਮਹੱਤਵ ਦਿੰਦੇ ਹਨ। ਇੱਕ ਖਿਡਾਰੀ ਇੱਕ ਹਾਈ ਸਕੋਰ ਅਨਲੌਕ ਕਰਦਾ ਹੈ, ਆਪਣੀਆਂ ਸੈਟਿੰਗਾਂ ਨੂੰ ਬਦਲਦਾ ਹੈ, ਅਗਲੇ ਦਿਨ ਵਾਪਸ ਆਉਂਦਾ ਹੈ, ਅਤੇ ਕੁਝ ਵੀ ਨਹੀਂ ਲੱਭਦਾ। ਇਸ ਤੋਂ ਵੀ ਮਾੜਾ ਇਹ ਹੈ ਕਿ, ਉਹ ਇੱਕ ਪੈਚ (patch) ਤੋਂ ਬਾਅਦ ਵਾਪਸ ਆਉਂਦੇ ਹਨ ਅਤੇ ਗੇਮ ਇੱਕ ਐਰਰ (error) ਦਿਖਾਉਂਦੀ ਹੈ ਕਿਉਂਕਿ ਉਹਨਾਂ ਦੀ ਮਸ਼ੀਨ 'ਤੇ ਸੇਵ ਫਾਈਲ ਹੁਣ ਉਸ ਕੋਡ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀ ਜੋ ਤੁਸੀਂ ਹੁਣੇ ਸ਼ਿਪ ਕੀਤਾ ਹੈ। Phaser 4 ਵਿੱਚ ਇੱਕ survivor-style shooter ਬਣਾਉਣ ਦਾ ਮਤਲਬ ਹੈ ਦੁਸ਼ਮਣਾਂ ਦੀਆਂ ਲਗਾਤਾਰ ਲਹਿਰਾਂ ਨਾਲ ਨਜਿੱਠਣਾ, ਪਰ ਅਸਲ ਲੰਬੇ ਸਮੇਂ ਦਾ ਖਤਰਾ ਤੁਹਾਡੇ ਆਪਣੇ ਭਵਿੱਖ ਦੇ ਅੱਪਡੇਟਸ ਹਨ।

ਜ਼ਿਆਦਾਤਰ ਡਿਵੈਲਪਰ ਇੱਕ ਆਬਜੈਕਟ (object) ਲੈ ਕੇ, ਉਸਨੂੰ JSON.stringify ਰਾਹੀਂ ਚਲਾ ਕੇ, ਅਤੇ ਉਸਨੂੰ localStorage ਵਿੱਚ ਪਾ ਕੇ ਆਪਣਾ ਪਹਿਲਾ ਸੇਵ ਸਿਸਟਮ ਬਣਾਉਂਦੇ ਹਨ। ਲੋਡ ਹੋਣ 'ਤੇ, ਉਹ ਇਸਨੂੰ parse ਕਰਦੇ ਹਨ ਅਤੇ ਗੇਮ ਨੂੰ ਕੱਚੇ ਰੂਪ (raw) ਵਿੱਚ ਵਾਪਸ ਦੇ ਦਿੰਦੇ ਹਨ। ਇਹ ਪਹਿਲੇ ਦਿਨ ਕੰਮ ਕਰਦਾ ਹੈ। ਪਰ ਜਿਵੇਂ ਹੀ ਤੁਸੀਂ ਇੱਕ ਨਵੀਂ ਸੈਟਿੰਗ, ਇੱਕ ਨਵਾਂ unlock flag, ਜਾਂ nested configuration ਦੀ ਤੀਜੀ ਪਰਤ ਜੋੜਦੇ ਹੋ, ਇਹ ਟੁੱਟ ਜਾਂਦਾ ਹੈ। ਜੇਕਰ ਵਾਪਸ ਆਉਣ ਵਾਲੇ ਖਿਡਾਰੀ ਕੋਲ ਇੱਕ ਪੁਰਾਣੀ ਸੇਵ ਫਾਈਲ ਹੈ ਜਿਸ ਵਿੱਚ vignette property ਨਹੀਂ ਹੈ, ਅਤੇ ਤੁਹਾਡਾ ਨਵਾਂ ਕੋਡ ਇਸਦੇ ਹੋਣ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਉੱਥੇ undefined ਮਿਲੇਗਾ ਜਿੱਥੇ ਤੁਸੀਂ ਇੱਕ boolean ਦੀ ਉਮੀਦ ਕਰ ਰਹੇ ਸੀ। ਇਸਨੂੰ ਦਰਜਨਾਂ ਨਵੇਂ ਫੀਚਰਾਂ ਵਿੱਚ ਗੁਣਾ ਕਰੋ ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ debugging nightmare ਹੋਵੇਗਾ ਜੋ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਤੁਹਾਡੇ ਸਭ ਤੋਂ ਵਫ਼ਾਦਾਰ ਖਿਡਾਰੀਆਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ।

ਇੱਕ ਕੰਟਰੈਕਟ (Contract) ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਨਾ ਕਿ ਇੱਕ Raw Object ਨਾਲ

localStorage ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ, ਆਪਣੇ codebase ਵਿੱਚ ਇੱਕ default save schema ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਇਸਨੂੰ ਇੱਕ ਕੰਟਰੈਕਟ ਵਜੋਂ ਸਮਝੋ ਜਿਸਦਾ ਹਰ ਸੇਵ ਫਾਈਲ ਨੂੰ ਪਾਲਣ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਚਾਹੇ ਉਹ ਪੰਜ ਮਿੰਟ ਪਹਿਲਾਂ ਬਣਾਈ ਗਈ ਹੋਵੇ ਜਾਂ ਪੰਜ ਮਹੀਨੇ ਪਹਿਲਾਂ। ਇੱਕ ਸਪੱਸ਼ਟ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇ ਸਕਦਾ ਹੈ:

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

ਇਹ ਆਬਜੈਕਟ ਤੁਹਾਡੇ source code ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ। ਜਦੋਂ ਗੇਮ ਬੂਟ ਹੁੰਦੀ ਹੈ, ਤੁਹਾਡੇ ਕੋਲ ਹਮੇਸ਼ਾ ਇਹ ਸ਼ੇਪ (shape) ਉਪਲਬਧ ਹੁੰਦੀ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਇੱਕ baseline ਦਿੰਦਾ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਕੁਝ ਵੀ serialize ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਢਾਂਚੇ (structure) ਬਾਰੇ ਸੋਚਣ ਲਈ ਵੀ ਮਜਬੂਰ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਇਸ ਕਦਮ ਨੂੰ ਛੱਡ ਦਿੰਦੇ ਹੋ ਅਤੇ ਸਿਰਫ਼ ਉਹੀ state object ਸਟੋਰ ਕਰਦੇ ਹੋ ਜੋ ਉਸ ਸਮੇਂ ਸੁਵਿਧਾਜਨਕ ਹੋਵੇ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਅਸੰਗਤ keys, ਗੁੰਮ ਹੋਏ fields, ਅਤੇ ਚੁੱਪਚਾਪ ਹੋਣ ਵਾਲੀਆਂ ਅਸਫਲਤਾਵਾਂ (silent failures) ਬਣ ਜਾਣਗੀਆਂ ਜਦੋਂ ਪੁਰਾਣੀਆਂ ਸੇਵ ਫਾਈਲਾਂ ਤੁਹਾਡੀਆਂ ਉਮੀਦਾਂ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀਆਂ।

Try/Catch ਨਾਲ ਰੱਖਿਆਤਮਕ ਲੋਡਿੰਗ (Defensive Loading)

Local storage ਕੋਈ ਡਾਟਾਬੇਸ ਨਹੀਂ ਹੈ। ਇਹ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਇੱਕ string closet ਹੈ, ਅਤੇ ਕੁਝ ਵੀ ਉੱਥੇ ਜਾ ਸਕਦਾ ਹੈ। ਉਪਭੋਗਤਾ ਨੇ ਮੈਨੂਅਲੀ ਕਿਸੇ ਮੁੱਲ (value) ਨੂੰ ਐਡਿਟ ਕੀਤਾ ਹੋ ਸਕਦਾ ਹੈ, ਇੱਕ ਅਧੂਰੀ ਲਿਖਣ ਦੀ ਪ੍ਰਕਿਰਿਆ (write operation) ਵਿੱਚ ਵਿਘਨ ਪਿਆ ਹੋ ਸਕਦਾ ਹੈ, ਜਾਂ ਕਿਸੇ ਬ੍ਰਾਊਜ਼ਰ ਐਕਸਟੈਂਸ਼ਨ ਨੇ ਉਸ key ਵਿੱਚ ਕੂੜਾ (garbage) ਪਾ ਦਿੱਤਾ ਹੋ ਸਕਦਾ ਹੈ ਜਿਸਦਾ ਤੁਸੀਂ ਦਾਅਵਾ ਕੀਤਾ ਸੀ। ਜਦੋਂ ਤੁਸੀਂ ਉਸ string ਨੂੰ ਵਾਪਸ ਕੱਢਦੇ ਹੋ ਅਤੇ ਉਸਨੂੰ JSON.parse ਨੂੰ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਸਿੰਗਲ ਖਰਾਬ ਅੱਖਰ (corrupted character) ਇੱਕ hard exception ਪੈਦਾ ਕਰਦਾ ਹੈ। ਇੱਕ Phaser ਗੇਮ ਵਿੱਚ, ਉਹ unhandled error ਤੁਹਾਡੀ boot sequence ਨੂੰ ਫ੍ਰੀਜ਼ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਖਿਡਾਰੀ ਨੂੰ ਵਾਪਸ ਇੱਕ ਖਾਲੀ ਸਕ੍ਰੀਨ 'ਤੇ ਸੁੱਟ ਸਕਦਾ ਹੈ।

ਹਮੇਸ਼ਾ ਆਪਣੇ read ਅਤੇ parse logic ਨੂੰ try/catch ਬਲਾਕ ਵਿੱਚ ਰੱਖੋ। ਅਸਫਲਤਾ ਹੋਣ 'ਤੇ, ਆਪਣੇ default schema 'ਤੇ ਵਾਪਸ ਆ ਜਾਓ। ਟੀਚਾ ਸਧਾਰਨ ਹੈ: ਜੇਕਰ ਸੇਵ ਫਾਈਲ ਪੜ੍ਹਨਯੋਗ ਨਹੀਂ ਹੈ, ਤਾਂ ਪੂਰੇ ਸੈਸ਼ਨ ਨੂੰ ਕ੍ਰੈਸ਼ ਕਰਨ ਦੀ ਬਜਾਏ ਖਿਡਾਰੀ ਨਾਲ ਇੱਕ ਨਵੇਂ ਉਪਭੋਗਤਾ ਵਜੋਂ ਪੇਸ਼ ਕਰੋ। ਇਹ ਇੱਕ ਆਦਤ ਸ਼ੌਕੀਆ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ production-grade builds ਤੋਂ ਵੱਖ ਕਰਦੀ ਹੈ। ਇਸਨੂੰ ਲ

ਇਹ ਤੁਹਾਨੂੰ ਦੋ ਵਿਹਾਰਕ ਲਾਭ ਦਿੰਦਾ ਹੈ। ਪਹਿਲਾ, ਤੁਸੀਂ ਕਦੇ ਵੀ ਗਲਤੀ ਨਾਲ v2 ਲੌਜਿਕ ਨਾਲ v1 ਬਲੌਬ (blob) ਨੂੰ ਪਾਰਸ ਨਹੀਂ ਕਰੋਗੇ। ਦੂਜਾ, ਜੇਕਰ ਤੁਸੀਂ ਚਾਹੋ ਤਾਂ ਤੁਸੀਂ ਮਾਈਗ੍ਰੇਸ਼ਨ ਕੋਡ ਲਿਖ ਸਕਦੇ ਹੋ। ਬੂਟ (boot) ਹੋਣ 'ਤੇ, v1 ਦੀ ਜਾਂਚ ਕਰੋ। ਜੇਕਰ ਇਹ ਮੌਜੂਦ ਹੈ ਅਤੇ v2 ਨਹੀਂ ਹੈ, ਤਾਂ ਪੁਰਾਣੇ ਡੇਟਾ ਨੂੰ ਨਵੇਂ ਢਾਂਚੇ ਵਿੱਚ ਮਾਈਗ੍ਰੇਟ ਕਰੋ, ਇਸਨੂੰ ਨਵੀਂ ਕੀ (key) ਵਿੱਚ ਲਿਖੋ, ਅਤੇ ਅੱਗੇ ਵਧੋ। ਜੇਕਰ ਤੁਸੀਂ ਮਾਈਗ੍ਰੇਟ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦੇ, ਤਾਂ ਘੱਟੋ-ਘੱਟ ਪੁਰਾਣੀ ਕੀ ਸਟੋਰੇਜ ਵਿੱਚ ਬਿਨਾਂ ਕਿਸੇ ਨੁਕਸਾਨ ਦੇ ਰਹੇਗੀ ਜਦੋਂ ਕਿ ਤੁਹਾਡਾ ਨਵਾਂ ਕੋਡ ਇਸਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਦੇਵੇਗਾ। ਕਿਸੇ ਵੀ ਤਰੀਕੇ ਨਾਲ, ਵਰਜ਼ਨਿੰਗ (versioning) ਚੁੱਪਚਾਪ ਹੋਣ ਵਾਲੇ ਡੇਟਾ ਖਰਾਬ ਹੋਣ (silent corruption) ਤੋਂ ਬਚਾਉਂਦੀ ਹੈ।

ਸੇਵਿੰਗ ਨੂੰ ਅਦਿੱਖ ਬਣਾਓ

ਪਰਸਿਸਟੈਂਸ (Persistence) ਸਾਹ ਲੈਣ ਵਾਂਗ ਕੁਦਰਤੀ ਮਹਿਸੂਸ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਖਿਡਾਰੀ ਨੂੰ ਇਸ ਬਾਰੇ ਕਦੇ ਵੀ ਸੋਚਣ ਦੀ ਲੋੜ ਨਹੀਂ ਪੈਣੀ ਚਾਹੀਦੀ। ਆਪਣੇ ਸੈਟਿੰਗ ਮੇਨੂ ਵਿੱਚ 'Apply' ਬਟਨ ਨਾ ਜੋੜੋ। 'Apply' ਬਟਨ ਰੁਕਾਵਟ ਪੈਦਾ ਕਰਦੇ ਹਨ ਅਤੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਇਹ ਚਿੰਤਾ ਕਰਨ ਲਈ ਸਿਖਾਉਂਦੇ ਹਨ ਕਿ ਕੀ ਉਨ੍ਹਾਂ ਦੀਆਂ ਚੋਣਾਂ ਅਸਲ ਵਿੱਚ ਸਹੀ ਤਰ੍ਹਾਂ ਸੇਵ ਹੋਈਆਂ ਹਨ ਜਾਂ ਨਹੀਂ। ਜਦੋਂ ਕੋਈ ਖਿਡਾਰੀ ਤਿੰਨ ਵਿਕਲਪਾਂ ਨੂੰ ਬਦਲਦਾ ਹੈ, 'Apply' ਕਰਨਾ ਭੁੱਲ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਟੈਬ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਇਹ ਡੇਟਾ ਦੇ ਨੁਕਸਾਨ ਦਾ ਕਾਰਨ ਵੀ ਬਣ ਸਕਦੇ ਹਨ।

ਜਿਸ ਪਲ ਇੰਟਰੈਕਸ਼ਨ (interaction) ਹੁੰਦੀ ਹੈ, ਉਸੇ ਪਲ ਸੇਵ ਕਰੋ। ਜਦੋਂ ਖਿਡਾਰੀ ਸਕ੍ਰੀਨ ਸ਼ੇਕ (screen shake) ਨੂੰ ਡਿਸੇਬਲ ਕਰਨ ਲਈ ਚੈੱਕਬਾਕਸ 'ਤੇ ਕਲਿੱਕ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਰੰਤ ਆਪਣੇ write ਫੰਕਸ਼ਨ ਨੂੰ ਕਾਲ ਕਰੋ। ਜਦੋਂ ਰਨ ਖਤਮ ਹੁੰਦੀ ਹੈ ਅਤੇ ਅੰਤਿਮ ਸਕੋਰ ਜੁੜ ਜਾਂਦਾ ਹੈ, ਤਾਂ 'game over' ਸਕ੍ਰੀਨ ਦੇ ਐਨੀਮੇਟ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਨਵਾਂ ਹਾਈ ਸਕੋਰ ਲਿਖੋ। ਇਵੈਂਟ-ਡਰਿਵਨ (Event-driven) ਸੇਵਿੰਗ ਤੁਹਾਡੇ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਅਨੁਮਾਨਯੋਗ ਰੱਖਦੀ ਹੈ ਕਿਉਂਕਿ ਸੇਵ ਹਮੇਸ਼ਾ ਉਸੇ ਐਕਸ਼ਨ ਦੇ ਬਿਲਕੁਲ ਕੋਲ ਹੁੰਦਾ ਹੈ ਜਿਸਨੇ ਡੇਟਾ ਨੂੰ ਬਦਲਿਆ ਹੈ। ਤੁਹਾਨੂੰ ਕਦੇ ਵੀ ਕਿਸੇ ਕੇਂਦਰੀ ਬੈਚਿੰਗ ਫੰਕਸ਼ਨ ਨੂੰ ਲੱਭਣ ਦੀ ਲੋੜ ਨਹੀਂ ਪਵੇਗੀ ਜਾਂ ਪੁਰਾਣੀ ਸਟੇਟ (stale state) ਬਾਰੇ ਚਿੰਤਾ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਪਵੇਗੀ।

ਇਹ ਪਹੁੰਚ ਤੁਹਾਡੇ ਮਾਨਸਿਕ ਮਾਡਲ ਨੂੰ ਵੀ ਸਰਲ ਬਣਾਉਂਦੀ ਹੈ। ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਪਰਸਿਸਟੈਂਸ ਬਿਲਕੁਲ ਕਿੱਥੇ ਹੁੰਦੀ ਹੈ: ਉਸ ਕਾਲਬੈਕ (callback) ਵਿੱਚ ਜੋ ਟੌਗਲ (toggle) ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ, ਅਤੇ ਉਸ ਫੰਕਸ਼ਨ ਵਿੱਚ ਜੋ ਮੌਤ (death) ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ। ਕੋਡਬੇਸ ਵਿੱਚ ਕਿਤੇ ਵੀ ਕੋਈ ਰਹੱਸਮਈ writes ਖਿੰਡੇ ਹੋਏ ਨਹੀਂ ਹੁੰਦੇ।

ਆਪਣੇ ਲਈ ਇੱਕ ਰੀਸੈੱਟ ਬਟਨ ਬਣਾਓ

ਤੁਸੀਂ ਡਿਵੈਲਪਮੈਂਟ ਦੌਰਾਨ ਆਪਣੇ ਸੇਵਸ ਨੂੰ ਖਰਾਬ ਕਰ ਦਿਓਗੇ। ਤੁਸੀਂ ਗਲਤ ਡੇਟਾ ਲਿਖੋਗੇ, ਐਜ ਕੇਸਾਂ (edge cases) ਦਾ ਟੈਸਟ ਕਰੋਗੇ, ਅਤੇ ਜਲਦੀ ਨਾਲ ਸਾਫ਼ ਸਟੇਟ ਵਿੱਚ ਵਾਪਸ ਜਾਣ ਦੀ ਲੋੜ ਪਵੇਗੀ। ਇੱਕ ਡੀਬੱਗ ਮੇਨੂ ਜਾਂ ਕਿਸੇ ਲੁਕਵੇਂ ਕੀ ਕੰਬੀਨੇਸ਼ਨ (key combination) ਵਿੱਚ ਇੱਕ ਰੀਸੈੱਟ ਬਟਨ ਬਣਾਓ। ਉਸ ਰੀਸੈੱਟ ਬਟਨ ਨੂੰ ਇਸੇ ਕ੍ਰਮ ਵਿੱਚ ਦੋ ਕੰਮ ਕਰਨ ਦਿਓ: ਪਹਿਲਾਂ ਆਪਣੀ ਇਨ-ਮੈਮਰੀ ਸਟੇਟ (in-memory state) ਨੂੰ ਡਿਫੌਲਟ ਸਕੀਮਾ (default schema) 'ਤੇ ਰੀਸੈੱਟ ਕਰੋ, ਫਿਰ ਤੁਰੰਤ ਉਸੇ ਸੇਵ ਫੰਕਸ਼ਨ ਨੂੰ ਕਾਲ ਕਰੋ ਜੋ ਲੋਕਲ ਸਟੋਰੇਜ (local storage) ਵਿੱਚ ਲਿਖਦਾ ਹੈ।

ਜੇਕਰ ਤੁਸੀਂ ਸਿਰਫ਼ ਲੋਕਲ ਵੇਰੀਏਬਲ (local variable) ਨੂੰ ਸਾਫ਼ ਕਰਦੇ ਹੋ ਅਤੇ ਲਿਖਣ (write) ਦੇ ਪੜਾਅ ਨੂੰ ਛੱਡ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਕੁਝ ਵੀ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕੀਤਾ ਹੈ। ਅਗਲੀ ਪੇਜ ਰਿਫ੍ਰੈਸ਼ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚੋਂ ਪੁਰਾਣਾ ਡੇਟਾ ਵਾਪਸ ਖਿੱਚ ਲੈਂਦੀ ਹੈ ਅਤੇ ਇਸਨੂੰ ਮੁੜ ਸੁਰਜੀਤ ਕਰ ਦਿੰਦੀ ਹੈ। ਇੱਕ ਰੀਸੈੱਟ ਜੋ ਪਰਸਿਸਟ ਕਰਨ ਦੀ ਗਲਤੀ ਕਰਦਾ ਹੈ, ਉਹ ਅਜਿਹਾ ਬੱਗ (bug) ਹੈ ਜੋ ਪੂਰੀ ਦੁਪਹਿਰ ਬਰਬਾਦ ਕਰ ਸਕਦਾ ਹੈ। ਇੱਕ ਵਾਰ ਇਸ ਕ੍ਰਮ ਨੂੰ ਸਹੀ ਤਰ੍ਹਾਂ ਸੈੱਟ ਕਰ ਲਓ, ਅਤੇ ਤੁਹਾਡਾ ਟੈਸਟਿੰਗ ਲੂਪ (testing loop) ਪ੍ਰੋਜੈਕਟ ਦੇ ਬਾਕੀ ਹਿੱਸੇ ਲਈ ਤੇਜ਼ ਰਹੇਗਾ।

ਅਸਲ ਸਿੱਖਿਆ

ਸੇਵਿੰਗ ਕੋਈ ਅਜਿਹੀ ਵਿਸ਼ੇਸ਼ਤਾ (feature) ਨਹੀਂ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਅੰਤ ਵਿੱਚ ਜੋੜ ਦਿੰਦੇ ਹੋ। ਇਹ ਉਹ ਬੁਨਿਆਦੀ ਢਾਂਚਾ (infrastructure) ਹੈ ਜੋ ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਤੁਹਾਡਾ ਗੇਮ ਟਿਕਾਊ ਹੈ ਅਤੇ ਖਿਡਾਰੀ ਦੇ ਸਮੇਂ ਦਾ ਸਤਿਕਾਰ ਕਰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਇੱਕ Phaser 4 survivor shooter ਵਾਰ-ਵਾਰ ਚੱਲਣ ਵਾਲੀਆਂ ਰਨਾਂ (runs) 'ਤੇ ਜੀਉਂਦਾ ਜਾਂ ਮਰਦਾ ਹੈ। ਜੇਕਰ ਬ੍ਰਾਊਜ਼ਰ ਟੈਬ ਖਿਡਾਰੀ ਦੀ ਪ੍ਰਗਤੀ ਵੱਲ ਤਾਣਿਆ ਹੋਇਆ ਇੱਕ ਲੋਡਡ ਗਨ (loaded gun) ਹੈ, ਤਾਂ ਉਹ ਅੰਤ ਵਿੱਚ ਵਾਪਸ ਆਉਣਾ ਬੰਦ ਕਰ ਦੇਣਗੇ। ਇੱਕ ਸਕੀਮਾ ਲਿਖੋ, ਗਲਤ ਡੇਟਾ ਤੋਂ ਬਚਾਅ ਕਰੋ, ਬਦਲਣ ਦੀ ਬਜਾਏ ਮਰਜ (merge) ਕਰੋ, ਆਪਣੀਆਂ ਕੀਜ਼ (keys) ਨੂੰ ਵਰਜ਼ਨ ਕਰੋ, ਅਤੇ ਹਰ ਮਹੱਤਵਪੂਰਨ ਇਵੈਂਟ 'ਤੇ ਸੇਵ ਕਰੋ। ਤੁਹਾਡਾ ਭਵਿੱਖ ਦਾ ਰੂਪ, ਅਤੇ ਹਰ ਉਹ ਖਿਡਾਰੀ ਜੋ ਤੁਹਾਡੇ ਅਗਲੇ ਅਪਡੇਟ ਤੋਂ ਬਾਅਦ ਵਾਪਸ ਆਉਂਦਾ ਹੈ, ਤੁਹਾਡਾ ਧੰਨਵਾਦ ਕਰੇਗਾ।