ਅਸੀਂ ਇੱਕ ਨੈਟਵਰਕ ਲੇਟੈਂਸੀ ਮੁਆਵਜ਼ਾ ਐਲਗੋਰਿਦਮ ਦੇ ਨਾਲ ਇੱਕ ਮੋਬਾਈਲ ਸ਼ੂਟਰ ਲਈ ਬੈਲਿਸਟਿਕ ਗਣਨਾਵਾਂ ਦੇ ਮਕੈਨਿਕਸ ਨੂੰ ਕਿਵੇਂ ਵਧਾਇਆ ਹੈ

ਹੈਲੋ, ਮੈਂ Nikita Brizhak ਹਾਂ, Pixonic ਤੋਂ ਸਰਵਰ ਡਿਵੈਲਪਰ। ਅੱਜ ਮੈਂ ਮੋਬਾਈਲ ਮਲਟੀਪਲੇਅਰ ਵਿੱਚ ਪਛੜਨ ਲਈ ਮੁਆਵਜ਼ਾ ਦੇਣ ਬਾਰੇ ਗੱਲ ਕਰਨਾ ਚਾਹਾਂਗਾ।

ਸਰਵਰ ਲੈਗ ਮੁਆਵਜ਼ੇ ਬਾਰੇ ਬਹੁਤ ਸਾਰੇ ਲੇਖ ਲਿਖੇ ਗਏ ਹਨ, ਰੂਸੀ ਵਿੱਚ ਵੀ ਸ਼ਾਮਲ ਹੈ। ਇਹ ਕੋਈ ਹੈਰਾਨੀ ਦੀ ਗੱਲ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਤਕਨਾਲੋਜੀ 90 ਦੇ ਦਹਾਕੇ ਦੇ ਅਖੀਰ ਤੋਂ ਮਲਟੀਪਲੇਅਰ ਐਫਪੀਐਸ ਦੀ ਸਿਰਜਣਾ ਵਿੱਚ ਸਰਗਰਮੀ ਨਾਲ ਵਰਤੀ ਗਈ ਹੈ. ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ QuakeWorld ਮੋਡ ਨੂੰ ਯਾਦ ਕਰ ਸਕਦੇ ਹੋ, ਜੋ ਇਸਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੇ ਪਹਿਲੇ ਲੋਕਾਂ ਵਿੱਚੋਂ ਇੱਕ ਸੀ।

ਅਸੀਂ ਇਸਨੂੰ ਆਪਣੇ ਮੋਬਾਈਲ ਮਲਟੀਪਲੇਅਰ ਸ਼ੂਟਰ ਡੀਨੋ ਸਕੁਐਡ ਵਿੱਚ ਵੀ ਵਰਤਦੇ ਹਾਂ।

ਇਸ ਲੇਖ ਵਿੱਚ, ਮੇਰਾ ਟੀਚਾ ਉਸ ਨੂੰ ਦੁਹਰਾਉਣਾ ਨਹੀਂ ਹੈ ਜੋ ਪਹਿਲਾਂ ਹੀ ਹਜ਼ਾਰ ਵਾਰ ਲਿਖਿਆ ਜਾ ਚੁੱਕਾ ਹੈ, ਪਰ ਇਹ ਦੱਸਣਾ ਹੈ ਕਿ ਅਸੀਂ ਆਪਣੀ ਟੈਕਨਾਲੋਜੀ ਸਟੈਕ ਅਤੇ ਕੋਰ ਗੇਮਪਲੇ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ, ਸਾਡੀ ਗੇਮ ਵਿੱਚ ਲੈਗ ਮੁਆਵਜ਼ੇ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕੀਤਾ ਹੈ।

ਸਾਡੇ ਕਾਰਟੈਕਸ ਅਤੇ ਤਕਨਾਲੋਜੀ ਬਾਰੇ ਕੁਝ ਸ਼ਬਦ.

ਡੀਨੋ ਸਕੁਐਡ ਇੱਕ ਨੈਟਵਰਕ ਮੋਬਾਈਲ ਪੀਵੀਪੀ ਸ਼ੂਟਰ ਹੈ. ਖਿਡਾਰੀ ਕਈ ਤਰ੍ਹਾਂ ਦੇ ਹਥਿਆਰਾਂ ਨਾਲ ਲੈਸ ਡਾਇਨੋਸੌਰਸ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦੇ ਹਨ ਅਤੇ 6v6 ਟੀਮਾਂ ਵਿੱਚ ਇੱਕ ਦੂਜੇ ਨਾਲ ਲੜਦੇ ਹਨ।

ਕਲਾਇੰਟ ਅਤੇ ਸਰਵਰ ਦੋਵੇਂ ਏਕਤਾ 'ਤੇ ਅਧਾਰਤ ਹਨ। ਨਿਸ਼ਾਨੇਬਾਜ਼ਾਂ ਲਈ ਆਰਕੀਟੈਕਚਰ ਕਾਫ਼ੀ ਕਲਾਸਿਕ ਹੈ: ਸਰਵਰ ਤਾਨਾਸ਼ਾਹੀ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਦੀ ਭਵਿੱਖਬਾਣੀ ਕਲਾਇੰਟਸ 'ਤੇ ਕੰਮ ਕਰਦੀ ਹੈ। ਗੇਮ ਸਿਮੂਲੇਸ਼ਨ ਇਨ-ਹਾਊਸ ECS ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਲਿਖਿਆ ਗਿਆ ਹੈ ਅਤੇ ਸਰਵਰ ਅਤੇ ਕਲਾਇੰਟ ਦੋਵਾਂ 'ਤੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।

ਜੇਕਰ ਇਹ ਪਹਿਲੀ ਵਾਰ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਪਛੜਨ ਦੇ ਮੁਆਵਜ਼ੇ ਬਾਰੇ ਸੁਣਿਆ ਹੈ, ਤਾਂ ਇੱਥੇ ਇਸ ਮੁੱਦੇ ਬਾਰੇ ਇੱਕ ਸੰਖੇਪ ਸੈਰ ਹੈ।

ਮਲਟੀਪਲੇਅਰ FPS ਗੇਮਾਂ ਵਿੱਚ, ਮੈਚ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਰਿਮੋਟ ਸਰਵਰ 'ਤੇ ਸਿਮੂਲੇਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਖਿਡਾਰੀ ਸਰਵਰ ਨੂੰ ਆਪਣਾ ਇਨਪੁਟ (ਦੱਬੀਆਂ ਕੁੰਜੀਆਂ ਬਾਰੇ ਜਾਣਕਾਰੀ) ਭੇਜਦੇ ਹਨ, ਅਤੇ ਜਵਾਬ ਵਿੱਚ ਸਰਵਰ ਉਹਨਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕੀਤੇ ਡੇਟਾ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ ਇੱਕ ਅਪਡੇਟ ਕੀਤੀ ਗੇਮ ਸਟੇਟ ਭੇਜਦਾ ਹੈ। ਇਸ ਇੰਟਰਐਕਸ਼ਨ ਸਕੀਮ ਦੇ ਨਾਲ, ਫਾਰਵਰਡ ਕੁੰਜੀ ਨੂੰ ਦਬਾਉਣ ਅਤੇ ਪਲੇਅਰ ਦੇ ਅੱਖਰ ਦੇ ਸਕਰੀਨ 'ਤੇ ਆਉਣ ਦੇ ਵਿਚਕਾਰ ਦੇਰੀ ਹਮੇਸ਼ਾ ਪਿੰਗ ਤੋਂ ਵੱਧ ਹੋਵੇਗੀ।

ਸਥਾਨਕ ਨੈੱਟਵਰਕਾਂ 'ਤੇ ਇਹ ਦੇਰੀ (ਪ੍ਰਸਿੱਧ ਤੌਰ 'ਤੇ ਇਨਪੁਟ ਲੈਗ ਕਿਹਾ ਜਾਂਦਾ ਹੈ) ਅਣਦੇਖੀ ਹੋ ਸਕਦੀ ਹੈ, ਜਦੋਂ ਇੰਟਰਨੈਟ ਰਾਹੀਂ ਖੇਡਦੇ ਹੋ ਤਾਂ ਇਹ ਇੱਕ ਅੱਖਰ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦੇ ਸਮੇਂ "ਬਰਫ਼ ਉੱਤੇ ਖਿਸਕਣ" ਦੀ ਭਾਵਨਾ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਇਹ ਸਮੱਸਿਆ ਮੋਬਾਈਲ ਨੈੱਟਵਰਕਾਂ ਲਈ ਦੁੱਗਣੀ ਤੌਰ 'ਤੇ ਢੁਕਵੀਂ ਹੈ, ਜਿੱਥੇ ਇੱਕ ਖਿਡਾਰੀ ਦਾ ਪਿੰਗ 200 ms ਹੋਣ ਦੇ ਮਾਮਲੇ ਨੂੰ ਅਜੇ ਵੀ ਇੱਕ ਸ਼ਾਨਦਾਰ ਕਨੈਕਸ਼ਨ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। ਅਕਸਰ ਪਿੰਗ 350, 500, ਜਾਂ 1000 ms ਹੋ ਸਕਦੀ ਹੈ। ਫਿਰ ਇੰਪੁੱਟ ਲੈਗ ਨਾਲ ਤੇਜ਼ ਨਿਸ਼ਾਨੇਬਾਜ਼ ਖੇਡਣਾ ਲਗਭਗ ਅਸੰਭਵ ਹੋ ਜਾਂਦਾ ਹੈ।

ਇਸ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਕਲਾਇੰਟ-ਸਾਈਡ ਸਿਮੂਲੇਸ਼ਨ ਪੂਰਵ ਅਨੁਮਾਨ ਹੈ। ਇੱਥੇ ਕਲਾਇੰਟ ਖੁਦ ਸਰਵਰ ਤੋਂ ਜਵਾਬ ਦੀ ਉਡੀਕ ਕੀਤੇ ਬਿਨਾਂ, ਪਲੇਅਰ ਅੱਖਰ 'ਤੇ ਇਨਪੁਟ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਅਤੇ ਜਦੋਂ ਜਵਾਬ ਪ੍ਰਾਪਤ ਹੁੰਦਾ ਹੈ, ਇਹ ਸਿਰਫ਼ ਨਤੀਜਿਆਂ ਦੀ ਤੁਲਨਾ ਕਰਦਾ ਹੈ ਅਤੇ ਵਿਰੋਧੀਆਂ ਦੀਆਂ ਸਥਿਤੀਆਂ ਨੂੰ ਅਪਡੇਟ ਕਰਦਾ ਹੈ। ਇਸ ਕੇਸ ਵਿੱਚ ਇੱਕ ਕੁੰਜੀ ਨੂੰ ਦਬਾਉਣ ਅਤੇ ਸਕਰੀਨ 'ਤੇ ਨਤੀਜਾ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨ ਵਿੱਚ ਦੇਰੀ ਘੱਟ ਹੈ।

ਇੱਥੇ ਸੂਖਮਤਾ ਨੂੰ ਸਮਝਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਕਲਾਇੰਟ ਹਮੇਸ਼ਾਂ ਆਪਣੇ ਆਖਰੀ ਇੰਪੁੱਟ ਦੇ ਅਨੁਸਾਰ ਆਪਣੇ ਆਪ ਨੂੰ ਖਿੱਚਦਾ ਹੈ, ਅਤੇ ਦੁਸ਼ਮਣਾਂ - ਨੈਟਵਰਕ ਦੇਰੀ ਨਾਲ, ਸਰਵਰ ਤੋਂ ਡੇਟਾ ਤੋਂ ਪਿਛਲੀ ਸਥਿਤੀ ਦੇ ਅਨੁਸਾਰ. ਭਾਵ, ਜਦੋਂ ਕਿਸੇ ਦੁਸ਼ਮਣ 'ਤੇ ਗੋਲੀਬਾਰੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਖਿਡਾਰੀ ਉਸਨੂੰ ਆਪਣੇ ਆਪ ਦੇ ਪਿਛਲੇ ਰਿਸ਼ਤੇਦਾਰ ਵਿੱਚ ਵੇਖਦਾ ਹੈ. ਗਾਹਕ ਦੀ ਭਵਿੱਖਬਾਣੀ ਬਾਰੇ ਹੋਰ ਅਸੀਂ ਪਹਿਲਾਂ ਲਿਖਿਆ ਸੀ.

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

ਇਸ ਗਿਆਨ ਨਾਲ ਲੈਸ, ਅਸੀਂ ਡਿਨੋ ਸਕੁਐਡ ਵਿੱਚ ਸਰਵਰ ਲੈਗ ਮੁਆਵਜ਼ੇ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ। ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਸਾਨੂੰ ਇਹ ਸਮਝਣਾ ਪਿਆ ਕਿ ਸਰਵਰ 'ਤੇ ਕਿਵੇਂ ਰੀਸਟੋਰ ਕਰਨਾ ਹੈ ਕਿ ਕਲਾਇੰਟ ਨੇ ਕੀ ਦੇਖਿਆ? ਅਤੇ ਅਸਲ ਵਿੱਚ ਕੀ ਬਹਾਲ ਕਰਨ ਦੀ ਲੋੜ ਹੈ? ਸਾਡੀ ਖੇਡ ਵਿੱਚ, ਹਥਿਆਰਾਂ ਅਤੇ ਕਾਬਲੀਅਤਾਂ ਤੋਂ ਹਿੱਟਾਂ ਦੀ ਗਣਨਾ ਰੇਕਾਸਟ ਅਤੇ ਓਵਰਲੇਅ ਦੁਆਰਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ - ਯਾਨੀ ਦੁਸ਼ਮਣ ਦੇ ਭੌਤਿਕ ਟਕਰਾਅ ਨਾਲ ਗੱਲਬਾਤ ਰਾਹੀਂ। ਇਸ ਅਨੁਸਾਰ, ਸਾਨੂੰ ਸਰਵਰ 'ਤੇ ਇਹਨਾਂ ਟਕਰਾਉਣ ਵਾਲਿਆਂ ਦੀ ਸਥਿਤੀ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦੀ ਲੋੜ ਸੀ, ਜਿਸ ਨੂੰ ਖਿਡਾਰੀ ਨੇ ਸਥਾਨਕ ਤੌਰ 'ਤੇ "ਦੇਖਿਆ"। ਉਸ ਸਮੇਂ ਅਸੀਂ ਯੂਨਿਟੀ ਵਰਜ਼ਨ 2018.x ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਸੀ। ਭੌਤਿਕ ਵਿਗਿਆਨ API ਸਥਿਰ ਹੈ, ਭੌਤਿਕ ਸੰਸਾਰ ਇੱਕ ਕਾਪੀ ਵਿੱਚ ਮੌਜੂਦ ਹੈ। ਇਸਦੇ ਰਾਜ ਨੂੰ ਬਚਾਉਣ ਅਤੇ ਫਿਰ ਇਸਨੂੰ ਬਕਸੇ ਵਿੱਚੋਂ ਬਹਾਲ ਕਰਨ ਦਾ ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ ਹੈ. ਤਾਂ ਕੀ ਕਰੀਏ?

ਹੱਲ ਸਤ੍ਹਾ 'ਤੇ ਸੀ; ਇਸਦੇ ਸਾਰੇ ਤੱਤ ਪਹਿਲਾਂ ਹੀ ਸਾਡੇ ਦੁਆਰਾ ਹੋਰ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਵਰਤੇ ਜਾ ਚੁੱਕੇ ਹਨ:

1. ਹਰੇਕ ਕਲਾਇੰਟ ਲਈ, ਸਾਨੂੰ ਇਹ ਜਾਣਨ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ ਕਿ ਜਦੋਂ ਉਸਨੇ ਕੁੰਜੀਆਂ ਨੂੰ ਦਬਾਇਆ ਤਾਂ ਉਸ ਨੇ ਵਿਰੋਧੀਆਂ ਨੂੰ ਕਿਸ ਸਮੇਂ ਦੇਖਿਆ। ਅਸੀਂ ਇਸ ਜਾਣਕਾਰੀ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਇਨਪੁਟ ਪੈਕੇਜ ਵਿੱਚ ਲਿਖ ਚੁੱਕੇ ਹਾਂ ਅਤੇ ਇਸਦੀ ਵਰਤੋਂ ਕਲਾਇੰਟ ਦੀ ਭਵਿੱਖਬਾਣੀ ਨੂੰ ਅਨੁਕੂਲ ਕਰਨ ਲਈ ਕੀਤੀ ਹੈ।
2. ਸਾਨੂੰ ਖੇਡ ਰਾਜਾਂ ਦੇ ਇਤਿਹਾਸ ਨੂੰ ਸਟੋਰ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ. ਇਹ ਇਸ ਵਿੱਚ ਹੈ ਕਿ ਅਸੀਂ ਆਪਣੇ ਵਿਰੋਧੀਆਂ (ਅਤੇ ਇਸ ਲਈ ਉਨ੍ਹਾਂ ਦੇ ਟਕਰਾਅ) ਦੀਆਂ ਸਥਿਤੀਆਂ ਨੂੰ ਸੰਭਾਲਾਂਗੇ. ਸਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਸਰਵਰ 'ਤੇ ਰਾਜ ਦਾ ਇਤਿਹਾਸ ਸੀ, ਅਸੀਂ ਇਸਨੂੰ ਬਣਾਉਣ ਲਈ ਵਰਤਿਆ ਸੀ ਡੈਲਟਾ. ਸਹੀ ਸਮੇਂ ਨੂੰ ਜਾਣ ਕੇ, ਅਸੀਂ ਇਤਿਹਾਸ ਵਿੱਚ ਸਹੀ ਰਾਜ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਲੱਭ ਸਕਦੇ ਹਾਂ.
3. ਹੁਣ ਜਦੋਂ ਸਾਡੇ ਕੋਲ ਇਤਿਹਾਸ ਤੋਂ ਗੇਮ ਸਟੇਟ ਹੈ, ਸਾਨੂੰ ਭੌਤਿਕ ਸੰਸਾਰ ਦੀ ਸਥਿਤੀ ਨਾਲ ਪਲੇਅਰ ਡੇਟਾ ਨੂੰ ਸਮਕਾਲੀ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣ ਦੀ ਲੋੜ ਹੈ। ਮੌਜੂਦਾ ਟਕਰਾਉਣ ਵਾਲੇ - ਹਿਲਾਓ, ਗੁੰਮ ਹੋਏ - ਬਣਾਓ, ਬੇਲੋੜੇ - ਨਸ਼ਟ ਕਰੋ। ਇਹ ਤਰਕ ਵੀ ਪਹਿਲਾਂ ਹੀ ਲਿਖਿਆ ਗਿਆ ਸੀ ਅਤੇ ਇਸ ਵਿੱਚ ਕਈ ECS ਸਿਸਟਮ ਸ਼ਾਮਲ ਸਨ। ਅਸੀਂ ਇੱਕ ਏਕਤਾ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਕਈ ਗੇਮ ਰੂਮ ਰੱਖਣ ਲਈ ਇਸਦੀ ਵਰਤੋਂ ਕੀਤੀ। ਅਤੇ ਕਿਉਂਕਿ ਭੌਤਿਕ ਸੰਸਾਰ ਪ੍ਰਤੀ ਪ੍ਰਕਿਰਿਆ ਇੱਕ ਹੈ, ਇਸ ਨੂੰ ਕਮਰਿਆਂ ਦੇ ਵਿਚਕਾਰ ਦੁਬਾਰਾ ਵਰਤਿਆ ਜਾਣਾ ਸੀ। ਸਿਮੂਲੇਸ਼ਨ ਦੇ ਹਰੇਕ ਟਿੱਕ ਤੋਂ ਪਹਿਲਾਂ, ਅਸੀਂ ਭੌਤਿਕ ਸੰਸਾਰ ਦੀ ਸਥਿਤੀ ਨੂੰ "ਰੀਸੈਟ" ਕਰਦੇ ਹਾਂ ਅਤੇ ਇਸਨੂੰ ਮੌਜੂਦਾ ਕਮਰੇ ਲਈ ਡੇਟਾ ਦੇ ਨਾਲ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ, ਇੱਕ ਚਲਾਕ ਪੂਲਿੰਗ ਸਿਸਟਮ ਦੁਆਰਾ ਯੂਨਿਟੀ ਗੇਮ ਆਬਜੈਕਟ ਨੂੰ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਦੁਬਾਰਾ ਵਰਤਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ। ਜੋ ਕੁਝ ਬਚਿਆ ਸੀ ਉਹ ਪਿਛਲੇ ਸਮੇਂ ਤੋਂ ਗੇਮ ਸਟੇਟ ਲਈ ਇੱਕੋ ਤਰਕ ਦੀ ਮੰਗ ਕਰਨਾ ਸੀ।

ਇਹਨਾਂ ਸਾਰੇ ਤੱਤਾਂ ਨੂੰ ਇਕੱਠੇ ਰੱਖ ਕੇ, ਸਾਨੂੰ ਇੱਕ "ਟਾਈਮ ਮਸ਼ੀਨ" ਮਿਲੀ ਹੈ ਜੋ ਭੌਤਿਕ ਸੰਸਾਰ ਦੀ ਸਥਿਤੀ ਨੂੰ ਸਹੀ ਪਲ 'ਤੇ ਵਾਪਸ ਲਿਆ ਸਕਦੀ ਹੈ। ਕੋਡ ਸਧਾਰਨ ਨਿਕਲਿਆ:

public class TimeMachine : ITimeMachine
{
     //История игровых состояний
     private readonly IGameStateHistory _history;

     //Текущее игровое состояние на сервере
     private readonly ExecutableSystem[] _systems;

     //Набор систем, расставляющих коллайдеры в физическом мире 
     //по данным из игрового состояния
     private readonly GameState _presentState;

     public TimeMachine(IGameStateHistory history, GameState presentState, ExecutableSystem[] timeInitSystems)
     {
         _history = history; 
         _presentState = presentState;
         _systems = timeInitSystems;  
     }

     public GameState TravelToTime(int tick)
     {
         var pastState = tick == _presentState.Time ? _presentState : _history.Get(tick);
         foreach (var system in _systems)
         {
             system.Execute(pastState);
         }
         return pastState;
     }
}

ਜੋ ਬਾਕੀ ਬਚਿਆ ਸੀ ਉਹ ਇਹ ਪਤਾ ਲਗਾਉਣਾ ਸੀ ਕਿ ਇਸ ਮਸ਼ੀਨ ਦੀ ਵਰਤੋਂ ਸ਼ਾਟਸ ਅਤੇ ਕਾਬਲੀਅਤਾਂ ਲਈ ਆਸਾਨੀ ਨਾਲ ਮੁਆਵਜ਼ਾ ਕਿਵੇਂ ਕਰਨੀ ਹੈ.

ਸਭ ਤੋਂ ਸਰਲ ਸਥਿਤੀ ਵਿੱਚ, ਜਦੋਂ ਮਕੈਨਿਕ ਇੱਕ ਸਿੰਗਲ ਹਿੱਟਸਕੈਨ 'ਤੇ ਅਧਾਰਤ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਸਭ ਕੁਝ ਸਪੱਸ਼ਟ ਜਾਪਦਾ ਹੈ: ਖਿਡਾਰੀ ਸ਼ੂਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਉਸਨੂੰ ਭੌਤਿਕ ਸੰਸਾਰ ਨੂੰ ਲੋੜੀਂਦੀ ਸਥਿਤੀ ਵਿੱਚ ਵਾਪਸ ਲਿਆਉਣ, ਇੱਕ ਰੇਕਾਸਟ ਕਰਨ, ਹਿੱਟ ਜਾਂ ਮਿਸ ਦੀ ਗਿਣਤੀ ਕਰਨ, ਅਤੇ ਸੰਸਾਰ ਨੂੰ ਸ਼ੁਰੂਆਤੀ ਸਥਿਤੀ ਵਿੱਚ ਵਾਪਸ ਕਰੋ।

ਪਰ ਡੀਨੋ ਸਕੁਐਡ ਵਿੱਚ ਬਹੁਤ ਘੱਟ ਅਜਿਹੇ ਮਕੈਨਿਕ ਹਨ! ਗੇਮ ਵਿੱਚ ਜ਼ਿਆਦਾਤਰ ਹਥਿਆਰ ਪ੍ਰੋਜੈਕਟਾਈਲ ਬਣਾਉਂਦੇ ਹਨ - ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਚੱਲਣ ਵਾਲੀਆਂ ਗੋਲੀਆਂ ਜੋ ਕਈ ਸਿਮੂਲੇਸ਼ਨ ਟਿੱਕਾਂ (ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਦਰਜਨਾਂ ਟਿੱਕਾਂ) ਲਈ ਉੱਡਦੀਆਂ ਹਨ। ਉਨ੍ਹਾਂ ਦਾ ਕੀ ਕਰੀਏ, ਉਹ ਕਿਸ ਸਮੇਂ ਉੱਡਣ?

В ਪ੍ਰਾਚੀਨ ਲੇਖ ਹਾਫ-ਲਾਈਫ ਨੈਟਵਰਕ ਸਟੈਕ ਬਾਰੇ, ਵਾਲਵ ਦੇ ਮੁੰਡਿਆਂ ਨੇ ਉਹੀ ਸਵਾਲ ਪੁੱਛਿਆ, ਅਤੇ ਉਹਨਾਂ ਦਾ ਜਵਾਬ ਇਹ ਸੀ: ਪ੍ਰੋਜੈਕਟਾਈਲ ਲੈਗ ਮੁਆਵਜ਼ਾ ਸਮੱਸਿਆ ਵਾਲਾ ਹੈ, ਅਤੇ ਇਸ ਤੋਂ ਬਚਣਾ ਬਿਹਤਰ ਹੈ।

ਸਾਡੇ ਕੋਲ ਇਹ ਵਿਕਲਪ ਨਹੀਂ ਸੀ: ਪ੍ਰੋਜੈਕਟਾਈਲ-ਅਧਾਰਿਤ ਹਥਿਆਰ ਗੇਮ ਡਿਜ਼ਾਈਨ ਦੀ ਮੁੱਖ ਵਿਸ਼ੇਸ਼ਤਾ ਸਨ। ਇਸ ਲਈ ਸਾਨੂੰ ਕੁਝ ਲੈ ਕੇ ਆਉਣਾ ਪਿਆ. ਕੁਝ ਸੋਚ-ਵਿਚਾਰ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਦੋ ਵਿਕਲਪ ਤਿਆਰ ਕੀਤੇ ਜੋ ਕੰਮ ਕਰਦੇ ਜਾਪਦੇ ਸਨ:

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

ਤਸਵੀਰ ਵਿੱਚ, ਟਿਕ 30 'ਤੇ ਖਿਡਾਰੀ ਉਮੀਦ ਵਿੱਚ ਇੱਕ ਮਿਜ਼ਾਈਲ ਫਾਇਰ ਕਰਦਾ ਹੈ: ਉਹ ਦੇਖਦਾ ਹੈ ਕਿ ਦੁਸ਼ਮਣ ਕਿਸ ਦਿਸ਼ਾ ਵਿੱਚ ਚੱਲ ਰਿਹਾ ਹੈ ਅਤੇ ਮਿਜ਼ਾਈਲ ਦੀ ਅੰਦਾਜ਼ਨ ਗਤੀ ਨੂੰ ਜਾਣਦਾ ਹੈ। ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਉਹ ਦੇਖਦਾ ਹੈ ਕਿ ਉਸਨੇ 33ਵੇਂ ਟਿੱਕ 'ਤੇ ਨਿਸ਼ਾਨਾ ਮਾਰਿਆ। ਪਛੜਨ ਲਈ ਧੰਨਵਾਦ, ਇਹ ਸਰਵਰ 'ਤੇ ਵੀ ਦਿਖਾਈ ਦੇਵੇਗਾ

2. ਅਸੀਂ ਸਭ ਕੁਝ ਪਹਿਲੇ ਵਿਕਲਪ ਵਾਂਗ ਹੀ ਕਰਦੇ ਹਾਂ, ਪਰ, ਬੁਲੇਟ ਸਿਮੂਲੇਸ਼ਨ ਦੇ ਇੱਕ ਟਿੱਕ ਨੂੰ ਗਿਣਨ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਨਹੀਂ ਰੁਕਦੇ, ਸਗੋਂ ਉਸੇ ਸਰਵਰ ਟਿੱਕ ਦੇ ਅੰਦਰ ਇਸਦੀ ਉਡਾਣ ਦੀ ਸਿਮੂਲੇਟ ਕਰਨਾ ਜਾਰੀ ਰੱਖਦੇ ਹਾਂ, ਹਰ ਵਾਰ ਸਰਵਰ ਦੇ ਨੇੜੇ ਲਿਆਉਂਦੇ ਹਾਂ। ਇੱਕ-ਇੱਕ ਕਰਕੇ ਟਿੱਕ ਕਰੋ ਅਤੇ ਕੋਲਾਈਡਰ ਦੀਆਂ ਸਥਿਤੀਆਂ ਨੂੰ ਅਪਡੇਟ ਕਰੋ। ਅਸੀਂ ਇਹ ਉਦੋਂ ਤੱਕ ਕਰਦੇ ਹਾਂ ਜਦੋਂ ਤੱਕ ਦੋ ਚੀਜ਼ਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨਹੀਂ ਵਾਪਰਦਾ:

• ਗੋਲੀ ਦੀ ਮਿਆਦ ਖਤਮ ਹੋ ਗਈ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਗਣਨਾ ਖਤਮ ਹੋ ਗਈ ਹੈ, ਅਸੀਂ ਇੱਕ ਮਿਸ ਜਾਂ ਹਿੱਟ ਗਿਣ ਸਕਦੇ ਹਾਂ. ਅਤੇ ਇਹ ਉਸੇ ਟਿੱਕ 'ਤੇ ਹੈ ਜਿਸ ਵਿਚ ਗੋਲੀ ਚਲਾਈ ਗਈ ਸੀ! ਸਾਡੇ ਲਈ ਇਹ ਪਲੱਸ ਅਤੇ ਮਾਇਨਸ ਦੋਵੇਂ ਸਨ। ਇੱਕ ਪਲੱਸ - ਕਿਉਂਕਿ ਸ਼ੂਟਿੰਗ ਪਲੇਅਰ ਲਈ ਇਸ ਨੇ ਹਿੱਟ ਅਤੇ ਦੁਸ਼ਮਣ ਦੀ ਸਿਹਤ ਵਿੱਚ ਕਮੀ ਦੇ ਵਿਚਕਾਰ ਦੇਰੀ ਨੂੰ ਮਹੱਤਵਪੂਰਣ ਰੂਪ ਵਿੱਚ ਘਟਾ ਦਿੱਤਾ. ਨਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ ਉਹੀ ਪ੍ਰਭਾਵ ਦੇਖਿਆ ਗਿਆ ਜਦੋਂ ਵਿਰੋਧੀਆਂ ਨੇ ਖਿਡਾਰੀ 'ਤੇ ਗੋਲੀਬਾਰੀ ਕੀਤੀ: ਦੁਸ਼ਮਣ, ਅਜਿਹਾ ਲਗਦਾ ਹੈ, ਸਿਰਫ ਇੱਕ ਹੌਲੀ ਰਾਕੇਟ ਚਲਾਇਆ ਗਿਆ ਸੀ, ਅਤੇ ਨੁਕਸਾਨ ਪਹਿਲਾਂ ਹੀ ਗਿਣਿਆ ਗਿਆ ਸੀ.
• ਬੁਲੇਟ ਸਰਵਰ ਸਮੇਂ 'ਤੇ ਪਹੁੰਚ ਗਿਆ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਇਸਦਾ ਸਿਮੂਲੇਸ਼ਨ ਅਗਲੇ ਸਰਵਰ ਟਿੱਕ ਵਿੱਚ ਬਿਨਾਂ ਕਿਸੇ ਪਛੜ ਦੇ ਮੁਆਵਜ਼ੇ ਦੇ ਜਾਰੀ ਰਹੇਗਾ। ਹੌਲੀ ਪ੍ਰੋਜੈਕਟਾਈਲਾਂ ਲਈ, ਇਹ ਸਿਧਾਂਤਕ ਤੌਰ 'ਤੇ ਪਹਿਲੇ ਵਿਕਲਪ ਦੇ ਮੁਕਾਬਲੇ ਭੌਤਿਕ ਵਿਗਿਆਨ ਰੋਲਬੈਕ ਦੀ ਗਿਣਤੀ ਨੂੰ ਘਟਾ ਸਕਦਾ ਹੈ। ਉਸੇ ਸਮੇਂ, ਸਿਮੂਲੇਸ਼ਨ 'ਤੇ ਅਸਮਾਨ ਲੋਡ ਵਧਿਆ: ਸਰਵਰ ਜਾਂ ਤਾਂ ਨਿਸ਼ਕਿਰਿਆ ਸੀ, ਜਾਂ ਇੱਕ ਸਰਵਰ ਟਿੱਕ ਵਿੱਚ ਇਹ ਕਈ ਬੁਲੇਟਾਂ ਲਈ ਇੱਕ ਦਰਜਨ ਸਿਮੂਲੇਸ਼ਨ ਟਿੱਕਾਂ ਦੀ ਗਣਨਾ ਕਰ ਰਿਹਾ ਸੀ।

ਪਿਛਲੀ ਤਸਵੀਰ ਦੇ ਰੂਪ ਵਿੱਚ ਉਹੀ ਦ੍ਰਿਸ਼, ਪਰ ਦੂਜੀ ਸਕੀਮ ਦੇ ਅਨੁਸਾਰ ਗਣਨਾ ਕੀਤੀ ਗਈ. ਮਿਜ਼ਾਈਲ ਸਰਵਰ ਸਮੇਂ ਦੇ ਨਾਲ ਉਸੇ ਟਿਕ 'ਤੇ "ਕੈਚ ਅੱਪ" ਹੋ ਗਈ ਜਿਸ 'ਤੇ ਗੋਲੀ ਲੱਗੀ ਸੀ, ਅਤੇ ਹਿੱਟ ਨੂੰ ਅਗਲੀ ਟਿੱਕ ਦੇ ਤੌਰ 'ਤੇ ਗਿਣਿਆ ਜਾ ਸਕਦਾ ਹੈ। 31ਵੇਂ ਟਿੱਕ 'ਤੇ, ਇਸ ਕੇਸ ਵਿੱਚ, ਪਛੜਨ ਦਾ ਮੁਆਵਜ਼ਾ ਹੁਣ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦਾ ਹੈ

ਸਾਡੇ ਲਾਗੂ ਕਰਨ ਵਿੱਚ, ਇਹ ਦੋਵੇਂ ਪਹੁੰਚ ਕੋਡ ਦੀਆਂ ਕੁਝ ਲਾਈਨਾਂ ਵਿੱਚ ਵੱਖਰੇ ਸਨ, ਇਸਲਈ ਅਸੀਂ ਦੋਵਾਂ ਨੂੰ ਬਣਾਇਆ, ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਲਈ ਉਹ ਸਮਾਨਾਂਤਰ ਵਿੱਚ ਮੌਜੂਦ ਸਨ। ਹਥਿਆਰ ਦੇ ਮਕੈਨਿਕ ਅਤੇ ਗੋਲੀ ਦੀ ਗਤੀ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਹਰੇਕ ਡਾਇਨਾਸੌਰ ਲਈ ਇੱਕ ਜਾਂ ਕੋਈ ਹੋਰ ਵਿਕਲਪ ਚੁਣਿਆ ਹੈ। ਇੱਥੇ ਮਕੈਨਿਕਸ ਦੀ ਖੇਡ ਵਿੱਚ ਮੋੜ ਆਇਆ ਜਿਵੇਂ ਕਿ "ਜੇ ਤੁਸੀਂ ਅਜਿਹੇ ਅਤੇ ਅਜਿਹੇ ਸਮੇਂ ਵਿੱਚ ਦੁਸ਼ਮਣ ਨੂੰ ਕਈ ਵਾਰ ਮਾਰਦੇ ਹੋ, ਤਾਂ ਅਜਿਹਾ ਅਤੇ ਅਜਿਹਾ ਬੋਨਸ ਪ੍ਰਾਪਤ ਕਰੋ." ਕੋਈ ਵੀ ਮਕੈਨਿਕ ਜਿੱਥੇ ਖਿਡਾਰੀ ਨੇ ਦੁਸ਼ਮਣ ਨੂੰ ਮਾਰਿਆ ਉਸ ਸਮੇਂ ਨੇ ਮਹੱਤਵਪੂਰਨ ਭੂਮਿਕਾ ਨਿਭਾਈ, ਦੂਜੀ ਪਹੁੰਚ ਨਾਲ ਕੰਮ ਕਰਨ ਤੋਂ ਇਨਕਾਰ ਕਰ ਦਿੱਤਾ। ਇਸ ਲਈ ਅਸੀਂ ਪਹਿਲੇ ਵਿਕਲਪ ਦੇ ਨਾਲ ਜਾਣਾ ਖਤਮ ਕੀਤਾ, ਅਤੇ ਇਹ ਹੁਣ ਗੇਮ ਵਿੱਚ ਸਾਰੇ ਹਥਿਆਰਾਂ ਅਤੇ ਸਾਰੀਆਂ ਸਰਗਰਮ ਯੋਗਤਾਵਾਂ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ।

ਵੱਖਰੇ ਤੌਰ 'ਤੇ, ਇਹ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਮੁੱਦੇ ਨੂੰ ਉਠਾਉਣ ਦੇ ਯੋਗ ਹੈ. ਜੇ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ ਕਿ ਇਹ ਸਭ ਕੁਝ ਹੌਲੀ ਕਰ ਦੇਵੇਗਾ, ਤਾਂ ਮੈਂ ਜਵਾਬ ਦਿੰਦਾ ਹਾਂ: ਇਹ ਹੈ. ਏਕਤਾ ਟਕਰਾਉਣ ਵਾਲਿਆਂ ਨੂੰ ਹਿਲਾਉਣ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਚਾਲੂ ਅਤੇ ਬੰਦ ਕਰਨ ਵਿੱਚ ਕਾਫ਼ੀ ਹੌਲੀ ਹੈ। ਡੀਨੋ ਸਕੁਐਡ ਵਿੱਚ, ਇੱਕ "ਸਭ ਤੋਂ ਮਾੜੀ ਸਥਿਤੀ" ਵਿੱਚ, ਲੜਾਈ ਵਿੱਚ ਇੱਕੋ ਸਮੇਂ ਕਈ ਸੌ ਪ੍ਰੋਜੈਕਟਾਈਲ ਮੌਜੂਦ ਹੋ ਸਕਦੇ ਹਨ। ਹਰੇਕ ਪ੍ਰੋਜੈਕਟਾਈਲ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਗਿਣਨ ਲਈ ਕੋਲਾਈਡਰਾਂ ਨੂੰ ਹਿਲਾਉਣਾ ਇੱਕ ਅਸੰਭਵ ਲਗਜ਼ਰੀ ਹੈ। ਇਸ ਲਈ, ਸਾਡੇ ਲਈ ਭੌਤਿਕ ਵਿਗਿਆਨ "ਰੋਲਬੈਕ" ਦੀ ਗਿਣਤੀ ਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ ਕਰਨਾ ਬਿਲਕੁਲ ਜ਼ਰੂਰੀ ਸੀ। ਅਜਿਹਾ ਕਰਨ ਲਈ, ਅਸੀਂ ECS ਵਿੱਚ ਇੱਕ ਵੱਖਰਾ ਕੰਪੋਨੈਂਟ ਬਣਾਇਆ ਹੈ ਜਿਸ ਵਿੱਚ ਅਸੀਂ ਖਿਡਾਰੀ ਦਾ ਸਮਾਂ ਰਿਕਾਰਡ ਕਰਦੇ ਹਾਂ। ਅਸੀਂ ਇਸਨੂੰ ਉਹਨਾਂ ਸਾਰੀਆਂ ਸੰਸਥਾਵਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਪਛੜਨ ਦੇ ਮੁਆਵਜ਼ੇ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ (ਪ੍ਰੋਜੈਕਟਾਈਲ, ਯੋਗਤਾਵਾਂ, ਆਦਿ)। ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਅਸੀਂ ਅਜਿਹੀਆਂ ਇਕਾਈਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ, ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਇਸ ਸਮੇਂ ਤੱਕ ਕਲੱਸਟਰ ਕਰਦੇ ਹਾਂ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਇਕੱਠੇ ਪ੍ਰੋਸੈਸ ਕਰਦੇ ਹਾਂ, ਹਰੇਕ ਕਲੱਸਟਰ ਲਈ ਇੱਕ ਵਾਰ ਭੌਤਿਕ ਸੰਸਾਰ ਨੂੰ ਵਾਪਸ ਲਿਆਉਂਦੇ ਹਾਂ।

ਇਸ ਪੜਾਅ 'ਤੇ ਸਾਡੇ ਕੋਲ ਆਮ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਨ ਵਾਲੀ ਪ੍ਰਣਾਲੀ ਹੈ। ਇਸਦਾ ਕੋਡ ਕੁਝ ਸਰਲ ਰੂਪ ਵਿੱਚ:

public sealed class LagCompensationSystemGroup : ExecutableSystem
{
     //Машина времени
     private readonly ITimeMachine _timeMachine;

     //Набор систем лагкомпенсации
     private readonly LagCompensationSystem[] _systems;
     
     //Наша реализация кластеризатора
     private readonly TimeTravelMap _travelMap = new TimeTravelMap();

    public LagCompensationSystemGroup(ITimeMachine timeMachine, 
        LagCompensationSystem[] lagCompensationSystems)
     {
         _timeMachine = timeMachine;
         _systems = lagCompensationSystems;
     }

     public override void Execute(GameState gs)
     {
         //На вход кластеризатор принимает текущее игровое состояние,
         //а на выход выдает набор «корзин». В каждой корзине лежат энтити,
         //которым для лагкомпенсации нужно одно и то же время из истории.
         var buckets = _travelMap.RefillBuckets(gs);

         for (int bucketIndex = 0; bucketIndex < buckets.Count; bucketIndex++)
         {
             ProcessBucket(gs, buckets[bucketIndex]);
         }

         //В конце лагкомпенсации мы восстанавливаем физический мир 
         //в исходное состояние
         _timeMachine.TravelToTime(gs.Time);
     }

     private void ProcessBucket(GameState presentState, TimeTravelMap.Bucket bucket)
     {
         //Откатываем время один раз для каждой корзины
         var pastState = _timeMachine.TravelToTime(bucket.Time);

         foreach (var system in _systems)
         {
               system.PastState = pastState;
               system.PresentState = presentState;

               foreach (var entity in bucket)
               {
                   system.Execute(entity);
               }
          }
     }
}

ਜੋ ਬਚਿਆ ਉਹ ਵੇਰਵਿਆਂ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨਾ ਸੀ:

1. ਸਮਝੋ ਕਿ ਸਮੇਂ ਵਿੱਚ ਅੰਦੋਲਨ ਦੀ ਵੱਧ ਤੋਂ ਵੱਧ ਦੂਰੀ ਨੂੰ ਕਿੰਨਾ ਸੀਮਤ ਕਰਨਾ ਹੈ।

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

2. ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਕਿਹੜੀਆਂ ਵਸਤੂਆਂ ਨੂੰ ਸਮੇਂ ਦੇ ਨਾਲ ਹਿਲਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਕਿਹੜੀਆਂ ਨਹੀਂ।

ਅਸੀਂ, ਬੇਸ਼ੱਕ, ਆਪਣੇ ਵਿਰੋਧੀਆਂ ਨੂੰ ਹਿਲਾ ਰਹੇ ਹਾਂ. ਪਰ ਇੰਸਟਾਲ ਕਰਨ ਯੋਗ ਊਰਜਾ ਸ਼ੀਲਡ, ਉਦਾਹਰਨ ਲਈ, ਨਹੀਂ ਹਨ। ਅਸੀਂ ਫੈਸਲਾ ਕੀਤਾ ਕਿ ਰੱਖਿਆਤਮਕ ਸਮਰੱਥਾ ਨੂੰ ਪਹਿਲ ਦੇਣਾ ਬਿਹਤਰ ਹੈ, ਜਿਵੇਂ ਕਿ ਅਕਸਰ ਔਨਲਾਈਨ ਨਿਸ਼ਾਨੇਬਾਜ਼ਾਂ ਵਿੱਚ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਜੇਕਰ ਖਿਡਾਰੀ ਨੇ ਪਹਿਲਾਂ ਹੀ ਵਰਤਮਾਨ ਵਿੱਚ ਇੱਕ ਢਾਲ ਰੱਖੀ ਹੋਈ ਹੈ, ਤਾਂ ਅਤੀਤ ਦੀਆਂ ਪਛੜਨ ਵਾਲੀਆਂ ਗੋਲੀਆਂ ਇਸ ਵਿੱਚੋਂ ਨਹੀਂ ਉੱਡਣੀਆਂ ਚਾਹੀਦੀਆਂ।

3. ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੀ ਡਾਇਨੋਸੌਰਸ ਦੀਆਂ ਕਾਬਲੀਅਤਾਂ ਲਈ ਮੁਆਵਜ਼ਾ ਦੇਣਾ ਜ਼ਰੂਰੀ ਹੈ: ਦੰਦੀ, ਪੂਛ ਦੀ ਹੜਤਾਲ, ਆਦਿ। ਅਸੀਂ ਫੈਸਲਾ ਕੀਤਾ ਕਿ ਕੀ ਲੋੜ ਸੀ ਅਤੇ ਗੋਲੀਆਂ ਦੇ ਸਮਾਨ ਨਿਯਮਾਂ ਅਨੁਸਾਰ ਉਹਨਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦੇ ਹਾਂ।

4. ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਖਿਡਾਰੀ ਦੇ ਟਕਰਾਉਣ ਵਾਲਿਆਂ ਨਾਲ ਕੀ ਕਰਨਾ ਹੈ ਜਿਸ ਲਈ ਪਛੜਨ ਦਾ ਮੁਆਵਜ਼ਾ ਦਿੱਤਾ ਜਾ ਰਿਹਾ ਹੈ। ਚੰਗੇ ਤਰੀਕੇ ਨਾਲ, ਉਨ੍ਹਾਂ ਦੀ ਸਥਿਤੀ ਨੂੰ ਅਤੀਤ ਵਿੱਚ ਨਹੀਂ ਬਦਲਣਾ ਚਾਹੀਦਾ ਹੈ: ਖਿਡਾਰੀ ਨੂੰ ਆਪਣੇ ਆਪ ਨੂੰ ਉਸੇ ਸਮੇਂ ਵਿੱਚ ਦੇਖਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਉਹ ਹੁਣ ਸਰਵਰ 'ਤੇ ਹੈ. ਹਾਲਾਂਕਿ, ਅਸੀਂ ਸ਼ੂਟਿੰਗ ਪਲੇਅਰ ਦੇ ਕੋਲਾਈਡਰਜ਼ ਨੂੰ ਵੀ ਰੋਲ ਬੈਕ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਇਸਦੇ ਕਈ ਕਾਰਨ ਹਨ.

ਪਹਿਲਾਂ, ਇਹ ਕਲੱਸਟਰਿੰਗ ਵਿੱਚ ਸੁਧਾਰ ਕਰਦਾ ਹੈ: ਅਸੀਂ ਨਜ਼ਦੀਕੀ ਪਿੰਗਾਂ ਵਾਲੇ ਸਾਰੇ ਖਿਡਾਰੀਆਂ ਲਈ ਇੱਕੋ ਭੌਤਿਕ ਸਥਿਤੀ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹਾਂ।

ਦੂਜਾ, ਸਾਰੇ ਰੇਕਾਸਟਾਂ ਅਤੇ ਓਵਰਲੈਪਾਂ ਵਿੱਚ ਅਸੀਂ ਹਮੇਸ਼ਾਂ ਉਸ ਖਿਡਾਰੀ ਦੇ ਟਕਰਾਉਣ ਵਾਲਿਆਂ ਨੂੰ ਬਾਹਰ ਰੱਖਦੇ ਹਾਂ ਜੋ ਯੋਗਤਾਵਾਂ ਜਾਂ ਪ੍ਰੋਜੈਕਟਾਈਲਾਂ ਦਾ ਮਾਲਕ ਹੁੰਦਾ ਹੈ। ਡੀਨੋ ਸਕੁਐਡ ਵਿੱਚ, ਖਿਡਾਰੀ ਡਾਇਨੋਸੌਰਸ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦੇ ਹਨ, ਜੋ ਨਿਸ਼ਾਨੇਬਾਜ਼ਾਂ ਦੇ ਮਿਆਰਾਂ ਦੁਆਰਾ ਗੈਰ-ਮਿਆਰੀ ਜਿਓਮੈਟਰੀ ਰੱਖਦੇ ਹਨ। ਭਾਵੇਂ ਖਿਡਾਰੀ ਇੱਕ ਅਸਾਧਾਰਨ ਕੋਣ 'ਤੇ ਗੋਲੀ ਮਾਰਦਾ ਹੈ ਅਤੇ ਗੋਲੀ ਦਾ ਟ੍ਰੈਜੈਕਟਰੀ ਖਿਡਾਰੀ ਦੇ ਡਾਇਨਾਸੌਰ ਕੋਲਾਈਡਰ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ, ਗੋਲੀ ਇਸਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਦੇਵੇਗੀ।

ਤੀਸਰਾ, ਅਸੀਂ ਡਾਇਨਾਸੌਰ ਦੇ ਹਥਿਆਰਾਂ ਦੀ ਸਥਿਤੀ ਜਾਂ ECS ਤੋਂ ਡੇਟਾ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਯੋਗਤਾ ਦੇ ਬਿੰਦੂ ਦੀ ਗਣਨਾ ਕਰਦੇ ਹਾਂ ਭਾਵੇਂ ਪਛੜਨ ਦੇ ਮੁਆਵਜ਼ੇ ਦੀ ਸ਼ੁਰੂਆਤ ਤੋਂ ਪਹਿਲਾਂ.

ਨਤੀਜੇ ਵਜੋਂ, ਪਛੜਨ ਵਾਲੇ ਖਿਡਾਰੀ ਦੇ ਟਕਰਾਅ ਦੀ ਅਸਲ ਸਥਿਤੀ ਸਾਡੇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਅਸੀਂ ਇੱਕ ਵਧੇਰੇ ਲਾਭਕਾਰੀ ਅਤੇ ਉਸੇ ਸਮੇਂ ਸਰਲ ਰਸਤਾ ਅਪਣਾਇਆ।

ਨੈੱਟਵਰਕ ਲੇਟੈਂਸੀ ਨੂੰ ਸਿਰਫ਼ ਹਟਾਇਆ ਨਹੀਂ ਜਾ ਸਕਦਾ, ਇਸ ਨੂੰ ਸਿਰਫ਼ ਮਾਸਕ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਭੇਸ ਦੇ ਕਿਸੇ ਹੋਰ ਢੰਗ ਦੀ ਤਰ੍ਹਾਂ, ਸਰਵਰ ਲੈਗ ਮੁਆਵਜ਼ੇ ਦੇ ਇਸ ਦੇ ਵਪਾਰ ਹਨ. ਇਹ ਉਸ ਖਿਡਾਰੀ ਦੇ ਗੇਮਿੰਗ ਅਨੁਭਵ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਗੋਲੀ ਮਾਰਨ ਵਾਲੇ ਖਿਡਾਰੀ ਦੇ ਖਰਚੇ 'ਤੇ ਗੋਲੀ ਚਲਾ ਰਿਹਾ ਹੈ। ਡੀਨੋ ਸਕੁਐਡ ਲਈ, ਹਾਲਾਂਕਿ, ਇੱਥੇ ਚੋਣ ਸਪੱਸ਼ਟ ਸੀ.

ਬੇਸ਼ੱਕ, ਇਸ ਸਭ ਲਈ ਸਮੁੱਚੇ ਤੌਰ 'ਤੇ ਸਰਵਰ ਕੋਡ ਦੀ ਵਧੀ ਹੋਈ ਗੁੰਝਲਤਾ ਦੁਆਰਾ ਭੁਗਤਾਨ ਕਰਨਾ ਪਿਆ - ਪ੍ਰੋਗਰਾਮਰਾਂ ਅਤੇ ਗੇਮ ਡਿਜ਼ਾਈਨਰਾਂ ਦੋਵਾਂ ਲਈ। ਜੇ ਪਹਿਲਾਂ ਸਿਮੂਲੇਸ਼ਨ ਸਿਸਟਮਾਂ ਦੀ ਇੱਕ ਸਧਾਰਨ ਕ੍ਰਮਵਾਰ ਕਾਲ ਸੀ, ਤਾਂ ਲੇਗ ਮੁਆਵਜ਼ੇ ਦੇ ਨਾਲ, ਨੇਸਟਡ ਲੂਪਸ ਅਤੇ ਸ਼ਾਖਾਵਾਂ ਇਸ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਸਨ। ਅਸੀਂ ਇਸ ਦੇ ਨਾਲ ਕੰਮ ਕਰਨਾ ਸੁਵਿਧਾਜਨਕ ਬਣਾਉਣ ਲਈ ਬਹੁਤ ਕੋਸ਼ਿਸ਼ ਵੀ ਕੀਤੀ।

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

ਅਸੀਂ ਹਰੇਕ ਗੇਮ ਰੂਮ ਨੂੰ ਇਸਦਾ ਆਪਣਾ ਭੌਤਿਕ ਦ੍ਰਿਸ਼ ਦਿੱਤਾ ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਸਿਮੂਲੇਸ਼ਨ ਦੀ ਗਣਨਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਗੁਆਂਢੀ ਕਮਰੇ ਦੇ ਡੇਟਾ ਤੋਂ ਦ੍ਰਿਸ਼ ਨੂੰ "ਸਾਫ" ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਨੂੰ ਖਤਮ ਕਰ ਦਿੱਤਾ। ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਇਸ ਨੇ ਉਤਪਾਦਕਤਾ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਵਾਧਾ ਕੀਤਾ. ਦੂਜਾ, ਇਸਨੇ ਬੱਗਾਂ ਦੀ ਇੱਕ ਪੂਰੀ ਸ਼੍ਰੇਣੀ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾਉਣਾ ਸੰਭਵ ਬਣਾਇਆ ਜੋ ਪੈਦਾ ਹੋਏ ਜੇ ਪ੍ਰੋਗਰਾਮਰ ਨੇ ਨਵੇਂ ਗੇਮ ਐਲੀਮੈਂਟਸ ਨੂੰ ਜੋੜਦੇ ਸਮੇਂ ਸੀਨ ਕਲੀਨਅਪ ਕੋਡ ਵਿੱਚ ਗਲਤੀ ਕੀਤੀ। ਅਜਿਹੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਡੀਬੱਗ ਕਰਨਾ ਔਖਾ ਸੀ, ਅਤੇ ਉਹਨਾਂ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਅਕਸਰ ਇੱਕ ਕਮਰੇ ਦੇ ਦ੍ਰਿਸ਼ ਵਿੱਚ ਭੌਤਿਕ ਵਸਤੂਆਂ ਦੀ ਸਥਿਤੀ ਦੂਜੇ ਕਮਰੇ ਵਿੱਚ "ਵਹਿ ਜਾਂਦੀ ਹੈ"।

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਅਸੀਂ ਇਸ ਬਾਰੇ ਕੁਝ ਖੋਜ ਕੀਤੀ ਕਿ ਕੀ ਭੌਤਿਕ ਦ੍ਰਿਸ਼ਾਂ ਦੀ ਵਰਤੋਂ ਭੌਤਿਕ ਸੰਸਾਰ ਦੇ ਇਤਿਹਾਸ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਭਾਵ, ਸ਼ਰਤ ਅਨੁਸਾਰ, ਹਰੇਕ ਕਮਰੇ ਵਿੱਚ ਇੱਕ ਸੀਨ ਨਹੀਂ, ਸਗੋਂ 30 ਸੀਨ ਨਿਰਧਾਰਤ ਕਰੋ, ਅਤੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਸਾਈਕਲਿਕ ਬਫਰ ਬਣਾਓ, ਜਿਸ ਵਿੱਚ ਕਹਾਣੀ ਨੂੰ ਸਟੋਰ ਕਰਨਾ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ, ਵਿਕਲਪ ਕੰਮ ਕਰਨ ਲਈ ਨਿਕਲਿਆ, ਪਰ ਅਸੀਂ ਇਸਨੂੰ ਲਾਗੂ ਨਹੀਂ ਕੀਤਾ: ਇਸ ਨੇ ਉਤਪਾਦਕਤਾ ਵਿੱਚ ਕੋਈ ਪਾਗਲ ਵਾਧਾ ਨਹੀਂ ਦਿਖਾਇਆ, ਸਗੋਂ ਜੋਖਮ ਭਰੇ ਬਦਲਾਅ ਦੀ ਲੋੜ ਹੈ। ਇੰਨੇ ਸਾਰੇ ਦ੍ਰਿਸ਼ਾਂ ਦੇ ਨਾਲ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਕੰਮ ਕਰਨ 'ਤੇ ਸਰਵਰ ਕਿਵੇਂ ਵਿਵਹਾਰ ਕਰੇਗਾ ਇਹ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ ਮੁਸ਼ਕਲ ਸੀ. ਇਸ ਲਈ, ਅਸੀਂ ਨਿਯਮ ਦੀ ਪਾਲਣਾ ਕੀਤੀ: "ਜੇ ਇਹ ਤੋੜਿਆ ਨਹੀਂ ਜਾਂਦਾ, ਇਸ ਨੂੰ ਠੀਕ ਨਾ ਕਰੋ".

ਸਰੋਤ: www.habr.com