যুদ্ধের রোবটদের 10 বছর উদযাপন করা এবং একটি প্রযুক্তিগত দৃষ্টিকোণ থেকে প্রতিফলিত করা

ওয়ার রোবট এই এপ্রিলে তার 10 বছর পূর্তি উদযাপন করছে! এবং আজ অবধি, আমরা এটিকে বিকাশ এবং সমর্থন করে যাচ্ছি, শুধুমাত্র আমাদের খেলোয়াড়দের জন্য নতুন বৈশিষ্ট্য প্রকাশ করছি না বরং প্রযুক্তিগতভাবে এটিকে উন্নত করছি।

এই নিবন্ধে, আমরা এই বৃহৎ প্রকল্পের প্রযুক্তিগত উন্নয়নে আমাদের বহু বছরের অভিজ্ঞতা নিয়ে আলোচনা করব। কিন্তু প্রথমে, এখানে প্রকল্পটির একটি স্ন্যাপশট যেমন দাঁড়িয়ে আছে:

• কয়েক হাজার DAU (দৈনিক সক্রিয় ব্যবহারকারী)
• লাখ লাখ স্থাপনা
• একযোগে 12-ব্যক্তির দশ হাজার ম্যাচ
• চারটি প্রধান প্ল্যাটফর্মে উপলব্ধ (iOS, Android, Steam, Amazon)
• Android এবং PC সহ হাজার হাজার সমর্থিত ডিভাইস
• শত শত সার্ভার
• প্রায় 20 জন ক্লায়েন্ট ডেভেলপার, 9 সার্ভার ডেভেলপার, 8 জনের একটি ক্রস-প্রজেক্ট ডেভেলপমেন্ট টিম এবং 3টি DevOps
• ক্লায়েন্ট-সাইড কোডের প্রায় 1.5 মিলিয়ন লাইন
• 2014 সালে সংস্করণ 4 থেকে ইউনিটি ব্যবহার করা এবং বর্তমানে 2024 সালে 2022 LTS সংস্করণ ব্যবহার করা হচ্ছে।

এই ধরণের প্রকল্পের কার্যকারিতা বজায় রাখতে এবং আরও উচ্চ-মানের উন্নয়ন নিশ্চিত করতে, শুধুমাত্র তাত্ক্ষণিক পণ্যের কাজগুলিতে কাজ করা যথেষ্ট নয়; এটির প্রযুক্তিগত অবস্থার উন্নতি, উন্নয়ন সহজ করা, এবং স্বয়ংক্রিয় প্রক্রিয়াগুলি - নতুন বিষয়বস্তু তৈরির সাথে সম্পর্কিত সহ। আরও, আমাদের অবশ্যই উপলব্ধ ব্যবহারকারী ডিভাইসগুলির পরিবর্তনশীল বাজারের সাথে ক্রমাগত মানিয়ে নিতে হবে।

পাঠ্যটি Pixonic (MY.GAMES) এর উন্নয়ন বিভাগের প্রধান পাভেল জিনভ এবং ওয়ার রোবটের প্রধান বিকাশকারী দিমিত্রি চেটভারিকভের সাক্ষাৎকারের উপর ভিত্তি করে তৈরি করা হয়েছে।

শুরুতে

2014-এ ফিরে যাওয়া যাক: ওয়ার রোবট প্রকল্পটি প্রাথমিকভাবে একটি ছোট দল দ্বারা তৈরি করা হয়েছিল, এবং সমস্ত প্রযুক্তিগত সমাধান দ্রুত বিকাশ এবং বাজারে নতুন বৈশিষ্ট্য সরবরাহের দৃষ্টান্তের সাথে খাপ খায়। এই সময়ে, কোম্পানির কাছে ডেডিকেটেড সার্ভারগুলি হোস্ট করার জন্য বড় সংস্থান ছিল না, এবং এইভাবে, ওয়ার রোবটগুলি P2P যুক্তির উপর ভিত্তি করে একটি নেটওয়ার্ক মাল্টিপ্লেয়ার সহ বাজারে প্রবেশ করেছে।

ক্লায়েন্টদের মধ্যে ডেটা স্থানান্তর করার জন্য ফোটন ক্লাউড ব্যবহার করা হয়েছিল: প্রতিটি প্লেয়ার কমান্ড, এটি চলন্ত, শুটিং বা অন্য কোনও কমান্ড, পৃথক RPC ব্যবহার করে ফোটন ক্লাউড সার্ভারে পাঠানো হয়েছিল। যেহেতু কোনও ডেডিকেটেড সার্ভার ছিল না, গেমটির একটি মাস্টার ক্লায়েন্ট ছিল, যা সমস্ত খেলোয়াড়ের জন্য ম্যাচ স্টেটের নির্ভরযোগ্যতার জন্য দায়ী ছিল। একই সময়ে, অবশিষ্ট খেলোয়াড়রা তাদের স্থানীয় ক্লায়েন্টদের উপর সম্পূর্ণ গেমের অবস্থা সম্পূর্ণরূপে প্রক্রিয়াজাত করে।

একটি উদাহরণ হিসাবে, আন্দোলনের জন্য কোন যাচাইকরণ ছিল না — স্থানীয় ক্লায়েন্ট তার রোবটটিকে যেমন উপযুক্ত মনে করেছিল তা সরিয়ে নিয়েছিল, এই রাজ্যটি মাস্টার ক্লায়েন্টের কাছে পাঠানো হয়েছিল, এবং মাস্টার ক্লায়েন্ট নিঃশর্তভাবে এই অবস্থাটিকে বিশ্বাস করেছিল এবং কেবলমাত্র ম্যাচের অন্যান্য ক্লায়েন্টদের কাছে এটি ফরওয়ার্ড করেছিল৷ প্রতিটি ক্লায়েন্ট স্বাধীনভাবে যুদ্ধের একটি লগ রাখে এবং ম্যাচের শেষে সার্ভারে পাঠায়, তারপর সার্ভার সমস্ত খেলোয়াড়ের লগগুলি প্রক্রিয়া করে, একটি পুরস্কার প্রদান করে এবং সমস্ত খেলোয়াড়কে ম্যাচের ফলাফল পাঠায়।

প্লেয়ার প্রোফাইল সম্পর্কে তথ্য সংরক্ষণ করতে আমরা একটি বিশেষ প্রোফাইল সার্ভার ব্যবহার করেছি। এটি একটি Cassandra ডাটাবেস সহ অনেক সার্ভার নিয়ে গঠিত। প্রতিটি সার্ভার টমক্যাটে একটি সাধারণ অ্যাপ সার্ভার ছিল এবং ক্লায়েন্টরা HTTP এর মাধ্যমে এটির সাথে যোগাযোগ করেছিল।

আমাদের প্রাথমিক পদ্ধতির অপূর্ণতা

গেমপ্লেতে ব্যবহৃত পদ্ধতির বেশ কয়েকটি অসুবিধা ছিল। দলটি অবশ্যই এগুলি সম্পর্কে জানত, তবে বিকাশের গতি এবং বাজারে চূড়ান্ত পণ্য সরবরাহের কারণে বেশ কয়েকটি আপস করতে হয়েছিল।

এই অসুবিধাগুলির মধ্যে, প্রথমত, মাস্টার ক্লায়েন্ট সংযোগের গুণমান ছিল। যদি ক্লায়েন্টের নেটওয়ার্ক খারাপ থাকে, তাহলে ম্যাচের সব খেলোয়াড়ই পিছিয়ে পড়েন। এবং, যদি মাস্টার ক্লায়েন্ট একটি খুব শক্তিশালী স্মার্টফোনে চলমান না হয়, তাহলে, এটিতে রাখা উচ্চ লোডের কারণে, গেমটি ডেটা স্থানান্তরে বিলম্বের সম্মুখীন হয়েছিল। সুতরাং, এই ক্ষেত্রে, মাস্টার ক্লায়েন্ট ছাড়াও, অন্যান্য খেলোয়াড়দেরও ক্ষতি হয়েছিল।

দ্বিতীয় ত্রুটি ছিল যে এই স্থাপত্যটি প্রতারকদের সাথে সমস্যা প্রবণ ছিল। যেহেতু চূড়ান্ত অবস্থা মাস্টার ক্লায়েন্ট থেকে স্থানান্তর করা হয়েছিল, এই ক্লায়েন্ট তার বিবেচনার ভিত্তিতে অনেক ম্যাচ প্যারামিটার পরিবর্তন করতে পারে, উদাহরণস্বরূপ, ম্যাচে ক্যাপচার করা জোনের সংখ্যা গণনা করা।

তৃতীয়ত, ফটোন ক্লাউডে ম্যাচমেকিং কার্যকারিতার সাথে একটি সমস্যা বিদ্যমান: ফটোন ক্লাউড ম্যাচমেকিং রুমের সবচেয়ে পুরানো খেলোয়াড় মাস্টার ক্লায়েন্ট হয়ে ওঠে এবং ম্যাচমেকিংয়ের সময় তাদের সাথে কিছু ঘটে (উদাহরণস্বরূপ, সংযোগ বিচ্ছিন্ন), তাহলে গ্রুপ তৈরিতে নেতিবাচক প্রভাব পড়ে। সম্পর্কিত মজার ঘটনা: ফোটন ক্লাউডের ম্যাচমেকিংকে একটি গ্রুপে পাঠানোর পরে বন্ধ হওয়া প্রতিরোধ করতে, কিছু সময়ের জন্য, আমরা এমনকি আমাদের অফিসে একটি সাধারণ পিসি সেট আপ করেছি এবং এটি সর্বদা ম্যাচমেকিংকে সমর্থন করে, যার অর্থ ফোটন ক্লাউডের সাথে ম্যাচমেকিং ব্যর্থ হতে পারে না। .

কিছু সময়ে, সমস্যা এবং সমর্থন অনুরোধের সংখ্যা একটি সমালোচনামূলক ভরে পৌঁছেছে, এবং আমরা গেমের প্রযুক্তিগত স্থাপত্যকে বিকশিত করার বিষয়ে গুরুত্ব সহকারে ভাবতে শুরু করেছি – এই নতুন স্থাপত্যটিকে বলা হয় অবকাঠামো 2.0।

পরিকাঠামো 2.0-এ রূপান্তর

এই আর্কিটেকচারের পিছনে মূল ধারণাটি ছিল ডেডিকেটেড গেম সার্ভার তৈরি করা। সেই সময়ে, ক্লায়েন্টের দলে সার্ভার ডেভেলপমেন্টের ব্যাপক অভিজ্ঞতা সহ প্রোগ্রামারদের অভাব ছিল। যাইহোক, সংস্থাটি একই সাথে একটি সার্ভার-ভিত্তিক, উচ্চ-লোড বিশ্লেষণ প্রকল্পে কাজ করছিল, যাকে আমরা AppMetr বলতাম। দলটি এমন একটি পণ্য তৈরি করেছে যা প্রতিদিন কোটি কোটি বার্তা প্রক্রিয়াকরণ করে এবং সার্ভার সমাধানগুলির বিকাশ, কনফিগারেশন এবং সঠিক আর্কিটেকচারে তাদের ব্যাপক দক্ষতা ছিল। এবং তাই, সেই দলের কিছু সদস্য ইনফ্রাস্ট্রাকচার 2.0-এর কাজে যোগ দিয়েছেন।

2015 সালে, খুব অল্প সময়ের মধ্যে, একটি .NET সার্ভার তৈরি করা হয়েছিল, যা Windows সার্ভারে চলমান ফোটন সার্ভার SDK ফ্রেমওয়ার্কের মধ্যে মোড়ানো হয়েছিল। আমরা ক্লায়েন্ট প্রোজেক্টে শুধুমাত্র ফোটন সার্ভার SDK নেটওয়ার্ক ফ্রেমওয়ার্ক রেখে, ফোটন ক্লাউড পরিত্যাগ করার সিদ্ধান্ত নিয়েছি এবং ক্লায়েন্টদের সংযোগ করার জন্য এবং ম্যাচমেকিংয়ের জন্য সংশ্লিষ্ট সার্ভারগুলির জন্য একটি মাস্টার সার্ভার তৈরি করেছি। কিছু যুক্তি ক্লায়েন্ট থেকে একটি ডেডিকেটেড গেম সার্ভারে সরানো হয়েছে। বিশেষ করে, প্রাথমিক ক্ষতির বৈধতা চালু করা হয়েছিল, সেইসাথে সার্ভারে ম্যাচের ফলাফল গণনা করা হয়েছিল।

মাইক্রো সার্ভিসের উত্থান

ইনফ্রাস্ট্রাকচার 2.0 সফলভাবে তৈরি করার পর, আমরা উপলব্ধি করেছি যে পরিষেবাগুলির দায়িত্বগুলিকে ডিকপল করার দিকে আমাদের অগ্রসর হওয়া দরকার: এর ফলাফল ছিল মাইক্রোসার্ভিস আর্কিটেকচার তৈরি। এই স্থাপত্যের উপর তৈরি প্রথম মাইক্রোসার্ভিস ছিল গোষ্ঠী।

সেখান থেকে, একটি পৃথক যোগাযোগ পরিষেবা উপস্থিত হয়েছিল এবং এটি মাইক্রোসার্ভিসের মধ্যে ডেটা স্থানান্তরের জন্য দায়ী ছিল। ক্লায়েন্টকে গেম সার্ভারে মেটা মেকানিক্সের জন্য দায়ী "হ্যাঙ্গার" এর সাথে সংযোগ স্থাপন করতে এবং ফোটন ক্লাউডের উপর UDP ব্যবহার করে API অনুরোধ (পরিষেবাগুলির সাথে ইন্টারঅ্যাক্ট করার জন্য একটি একক এন্ট্রি পয়েন্ট) করতে শেখানো হয়েছিল। ধীরে ধীরে, পরিষেবার সংখ্যা বাড়তে থাকে এবং ফলস্বরূপ, আমরা ম্যাচমেকিং মাইক্রোসার্ভিসকে রিফ্যাক্টর করেছি। এটি দিয়ে, নিউজ কার্যকারিতা, ইনবক্স, তৈরি করা হয়েছিল।

যখন আমরা গোষ্ঠী তৈরি করি, তখন এটা পরিষ্কার ছিল যে খেলোয়াড়রা গেমে একে অপরের সাথে যোগাযোগ করতে চায় – তাদের কিছু ধরণের চ্যাট দরকার ছিল। এটি মূলত ফটোন চ্যাটের উপর ভিত্তি করে তৈরি করা হয়েছিল, কিন্তু শেষ ক্লায়েন্ট সংযোগ বিচ্ছিন্ন হওয়ার সাথে সাথে পুরো চ্যাটের ইতিহাস মুছে ফেলা হয়েছিল। অতএব, আমরা এই সমাধানটিকে ক্যাসান্ড্রা ডাটাবেসের উপর ভিত্তি করে একটি পৃথক মাইক্রোসার্ভিসে রূপান্তরিত করেছি।

অবকাঠামো 4.0 এবং সার্ভার অবস্থান

নতুন মাইক্রোসার্ভিস আর্কিটেকচার আমাদের সুবিধাজনকভাবে প্রচুর পরিসেবা পরিচালনা করতে দেয় যা একে অপরের থেকে স্বতন্ত্র ছিল, যার অর্থ সমগ্র সিস্টেমকে অনুভূমিকভাবে স্কেল করা এবং ডাউনটাইম এড়ানো।

আমাদের গেমে, সার্ভারগুলিকে বিরতি দেওয়ার প্রয়োজন ছাড়াই আপডেটগুলি ঘটেছে৷ সার্ভার প্রোফাইলটি ক্লায়েন্টের বিভিন্ন সংস্করণের সাথে সামঞ্জস্যপূর্ণ ছিল এবং গেম সার্ভারগুলির জন্য, আমাদের কাছে সর্বদা ক্লায়েন্টের পুরানো এবং নতুন সংস্করণগুলির জন্য সার্ভারের একটি পুল থাকে, অ্যাপ্লিকেশন স্টোরগুলিতে একটি নতুন সংস্করণ প্রকাশের পরে এই পুলটি ধীরে ধীরে স্থানান্তরিত হয় এবং গেম সার্ভারগুলি পুরানো সংস্করণ থেকে সময়ের সাথে অদৃশ্য হয়ে গেছে। বর্তমান অবকাঠামোর সাধারণ রূপরেখাকে বলা হত অবকাঠামো 4.0 এবং দেখতে এইরকম:

স্থাপত্য পরিবর্তনের পাশাপাশি, আমাদের সার্ভারগুলি কোথায় থাকবে তা নিয়ে আমরা একটি দ্বিধা-দ্বন্দ্বের সম্মুখীন হয়েছিলাম কারণ তারা সারা বিশ্ব থেকে খেলোয়াড়দের কভার করার কথা ছিল। প্রাথমিকভাবে, অনেকগুলি মাইক্রোসার্ভিস অ্যামাজন এডব্লিউএস-এ বেশ কয়েকটি কারণে অবস্থিত ছিল, বিশেষ করে, এই সিস্টেমটি স্কেলিং এর ক্ষেত্রে নমনীয়তার কারণে, কারণ গেমিং ট্র্যাফিক বৃদ্ধির মুহুর্তগুলিতে এটি অত্যন্ত গুরুত্বপূর্ণ ছিল (যেমন যখন এটি স্টোরগুলিতে প্রদর্শিত হয়েছিল এবং UA বাড়াতে)। উপরন্তু, তখন, এশিয়াতে একটি ভাল হোস্টিং প্রদানকারী খুঁজে পাওয়া কঠিন ছিল যেটি ভাল নেটওয়ার্ক গুণমান এবং বাইরের বিশ্বের সাথে সংযোগ প্রদান করবে।

Amazon AWS-এর একমাত্র নেতিবাচক দিক হল এর উচ্চ খরচ। অতএব, সময়ের সাথে সাথে, আমাদের অনেক সার্ভার আমাদের নিজস্ব হার্ডওয়্যার - সার্ভারগুলিতে চলে গেছে যা আমরা সারা বিশ্বের ডেটা সেন্টারগুলিতে ভাড়া করি। তা সত্ত্বেও, অ্যামাজন এডব্লিউএস স্থাপত্যের একটি গুরুত্বপূর্ণ অংশ হিসাবে রয়ে গেছে, কারণ এটি ক্রমাগত পরিবর্তনশীল কোডের বিকাশের অনুমতি দেয় (বিশেষত, লীগ, গোষ্ঠী, চ্যাট এবং সংবাদ পরিষেবাগুলির জন্য কোড) এবং যা স্থিতিশীলতার দ্বারা পর্যাপ্তভাবে আচ্ছাদিত ছিল না। পরীক্ষা কিন্তু, যত তাড়াতাড়ি আমরা বুঝতে পারি যে মাইক্রোসার্ভিসটি স্থিতিশীল ছিল, আমরা এটিকে আমাদের নিজস্ব সুবিধাগুলিতে স্থানান্তরিত করেছি। বর্তমানে, আমাদের সমস্ত মাইক্রোসার্ভিস আমাদের হার্ডওয়্যার সার্ভারে চলে।

ডিভাইসের মান নিয়ন্ত্রণ এবং আরও মেট্রিক্স

2016 সালে, গেমের রেন্ডারিংয়ে গুরুত্বপূর্ণ পরিবর্তন করা হয়েছিল: যুদ্ধে সমস্ত মেচের জন্য একটি একক টেক্সচার অ্যাটলাস সহ Ubershaders ধারণাটি উপস্থিত হয়েছিল, যা ড্র কলের সংখ্যা ব্যাপকভাবে হ্রাস করেছে এবং গেমের কর্মক্ষমতা উন্নত করেছে।

এটা স্পষ্ট হয়ে গেছে যে আমাদের গেমটি হাজার হাজার বিভিন্ন ডিভাইসে খেলা হচ্ছে এবং আমরা প্রতিটি খেলোয়াড়কে সেরা সম্ভাব্য গেমিং শর্ত সরবরাহ করতে চেয়েছিলাম। এইভাবে, আমরা কোয়ালিটি ম্যানেজার তৈরি করেছি, যা মূলত একটি ফাইল যা একজন খেলোয়াড়ের ডিভাইস বিশ্লেষণ করে এবং নির্দিষ্ট গেম বা রেন্ডারিং বৈশিষ্ট্যগুলিকে সক্ষম (বা অক্ষম) করে। অধিকন্তু, এই বৈশিষ্ট্যটি আমাদের এই ফাংশনগুলিকে নির্দিষ্ট ডিভাইস মডেলে পরিচালনা করার অনুমতি দেয় যাতে আমরা আমাদের খেলোয়াড়দের সম্মুখীন হওয়া সমস্যাগুলি দ্রুত সমাধান করতে পারি।

সার্ভার থেকে কোয়ালিটি ম্যানেজার সেটিংস ডাউনলোড করা এবং বর্তমান পারফরম্যান্সের উপর নির্ভর করে গতিশীলভাবে ডিভাইসে গুণমান নির্বাচন করাও সম্ভব। যুক্তিটি বেশ সহজ: কোয়ালিটি ম্যানেজারের পুরো শরীরটি ব্লকে বিভক্ত, যার প্রত্যেকটি কর্মক্ষমতার কিছু দিকের জন্য দায়ী। (উদাহরণস্বরূপ, ছায়ার গুণমান বা অ্যান্টি-এলিয়াসিং।) যদি একজন ব্যবহারকারীর কর্মক্ষমতা ক্ষতিগ্রস্থ হয়, সিস্টেমটি ব্লকের ভিতরের মানগুলি পরিবর্তন করার চেষ্টা করে এবং একটি বিকল্প নির্বাচন করে যা কার্যক্ষমতা বৃদ্ধির দিকে নিয়ে যায়। আমরা একটু পরে কোয়ালিটি ম্যানেজারের বিবর্তনে ফিরে আসব, কিন্তু এই পর্যায়ে, এটির বাস্তবায়ন বেশ দ্রুত ছিল এবং প্রয়োজনীয় নিয়ন্ত্রণের স্তর সরবরাহ করেছিল।

গ্রাফিক্স ডেভেলপমেন্ট অব্যাহত থাকায় কোয়ালিটি ম্যানেজারের কাজও প্রয়োজনীয় ছিল। গেমটিতে এখন ক্যাসকেডিং ডায়নামিক শ্যাডো রয়েছে, যা সম্পূর্ণরূপে আমাদের গ্রাফিক্স প্রোগ্রামারদের দ্বারা প্রয়োগ করা হয়েছে।

ধীরে ধীরে, প্রজেক্টের কোডে অনেক সত্ত্বা উপস্থিত হয়েছে, তাই আমরা সিদ্ধান্ত নিয়েছি যে তাদের জীবনকাল পরিচালনা করা শুরু করা ভাল হবে, পাশাপাশি বিভিন্ন কার্যকারিতার অ্যাক্সেস সীমাবদ্ধ করা হবে। হ্যাঙ্গার এবং কমব্যাট কোড আলাদা করার জন্য এটি বিশেষভাবে গুরুত্বপূর্ণ ছিল কারণ গেমের প্রেক্ষাপট পরিবর্তিত হলে অনেক সংস্থান সাফ করা হয়নি। আমরা বিভিন্ন IoC নির্ভরতা পরিচালন পাত্রে অন্বেষণ শুরু করেছি। বিশেষ করে, আমরা StrangeIoC সমাধান দেখেছি। সেই সময়ে, সমাধানটি আমাদের কাছে বেশ কষ্টকর বলে মনে হয়েছিল, এবং তাই আমরা প্রকল্পে আমাদের নিজস্ব সাধারণ ডিআই প্রয়োগ করেছি। আমরা হ্যাঙ্গার এবং যুদ্ধের প্রসঙ্গও চালু করেছি।

উপরন্তু, আমরা প্রকল্পের মান নিয়ন্ত্রণের কাজ শুরু করেছি; FirebaseCrashlytics কে ক্র্যাশ, ANR, এবং উৎপাদন পরিবেশে ব্যতিক্রম সনাক্ত করতে গেমে একীভূত করা হয়েছে।

AppMetr নামক আমাদের অভ্যন্তরীণ বিশ্লেষণাত্মক সমাধান ব্যবহার করে, আমরা গ্রাহকের অবস্থা নিয়মিত পর্যবেক্ষণের জন্য প্রয়োজনীয় ড্যাশবোর্ড তৈরি করেছি এবং প্রকাশের সময় করা পরিবর্তনগুলির তুলনা করেছি৷ আরও, প্রকল্পের গুণমান উন্নত করতে এবং কোডে করা পরিবর্তনগুলিতে আত্মবিশ্বাস বাড়ানোর জন্য, আমরা অটোটেস্ট নিয়ে গবেষণা শুরু করেছি।

বিষয়বস্তুতে সম্পদের সংখ্যা এবং অনন্য বাগ বৃদ্ধি আমাদের সম্পদকে সংগঠিত এবং একত্রিত করার বিষয়ে ভাবতে বাধ্য করেছে। এটি বিশেষত মেকগুলির জন্য সত্য কারণ তাদের নির্মাণ তাদের প্রত্যেকের জন্য অনন্য ছিল; এর জন্য, আমরা ইউনিটিতে সরঞ্জাম তৈরি করেছি এবং এইগুলির সাহায্যে আমরা প্রধান প্রয়োজনীয় উপাদানগুলির সাথে মেক ডামি তৈরি করেছি। এর মানে হল যে গেম ডিজাইন ডিপার্টমেন্ট সহজেই সেগুলিকে সম্পাদনা করতে পারে - এবং এইভাবে আমরা প্রথম মেচের সাথে আমাদের কাজকে একীভূত করতে শুরু করি।

আরও প্ল্যাটফর্ম

প্রকল্পটি বাড়তে থাকে এবং দলটি এটিকে অন্যান্য প্ল্যাটফর্মে প্রকাশ করার বিষয়ে চিন্তা করতে শুরু করে। এছাড়াও, অন্য একটি বিষয় হিসাবে, সেই সময়ে কিছু মোবাইল প্ল্যাটফর্মের জন্য, এটি গুরুত্বপূর্ণ ছিল যে গেমটি প্ল্যাটফর্মের যতটা সম্ভব নেটিভ ফাংশন সমর্থন করে, কারণ এটি গেমটিকে বৈশিষ্ট্যযুক্ত করার অনুমতি দেয়। সুতরাং, আমরা অ্যাপল টিভির জন্য ওয়ার রোবটের একটি পরীক্ষামূলক সংস্করণ এবং অ্যাপল ওয়াচের জন্য একটি সহচর অ্যাপ নিয়ে কাজ শুরু করেছি।

উপরন্তু, 2016 সালে, আমরা একটি প্ল্যাটফর্মে গেমটি চালু করেছি যা আমাদের জন্য নতুন ছিল — Amazon AppStore। প্রযুক্তিগত বৈশিষ্ট্যের পরিপ্রেক্ষিতে, এই প্ল্যাটফর্মটি অনন্য কারণ এটিতে অ্যাপলের মতো ডিভাইসগুলির একটি একীভূত লাইন রয়েছে, তবে এই লাইনের শক্তি নিম্ন-এন্ড অ্যান্ড্রয়েডের স্তরে রয়েছে। এটি মাথায় রেখে, এই প্ল্যাটফর্মে চালু করার সময়, মেমরি ব্যবহার এবং কর্মক্ষমতা অপ্টিমাইজ করার জন্য উল্লেখযোগ্য কাজ করা হয়েছিল, উদাহরণস্বরূপ, আমরা অ্যাটলেস, টেক্সচার কম্প্রেশন নিয়ে কাজ করেছি। অ্যামাজন পেমেন্ট সিস্টেম, লগইন এবং কৃতিত্বের জন্য গেম সেন্টারের একটি অ্যানালগ, ক্লায়েন্টের সাথে একীভূত করা হয়েছিল, এবং সেইজন্য প্লেয়ারের লগইনের সাথে কাজ করার প্রবাহ পুনরায় করা হয়েছিল, এবং প্রথম সাফল্যগুলি চালু করা হয়েছিল।

এটিও লক্ষণীয় যে, একই সাথে, ক্লায়েন্ট টিম প্রথমবারের মতো ইউনিটি এডিটরের জন্য সরঞ্জামগুলির একটি সেট তৈরি করেছে এবং এটি ইঞ্জিনে ইন-গেম ভিডিওগুলি শুট করা সম্ভব করেছে৷ এটি আমাদের বিপণন বিভাগের পক্ষে সম্পদের সাথে কাজ করা, যুদ্ধ নিয়ন্ত্রণ করা এবং আমাদের দর্শকদের খুব পছন্দের ভিডিওগুলি তৈরি করতে ক্যামেরা ব্যবহার করা সহজ করেছে৷

প্রতারকদের বিরুদ্ধে লড়াই

ইউনিটির অনুপস্থিতির কারণে, এবং বিশেষ করে সার্ভারে পদার্থবিদ্যা ইঞ্জিন, বেশিরভাগ ম্যাচ প্লেয়ার ডিভাইসে অনুকরণ করা অব্যাহত ছিল। এই কারণে, প্রতারকদের সাথে সমস্যা অব্যাহত ছিল। পর্যায়ক্রমে, আমাদের সহায়তা দল প্রতারকদের ভিডিও সহ আমাদের ব্যবহারকারীদের কাছ থেকে প্রতিক্রিয়া পেয়েছে: তারা একটি সুবিধাজনক সময়ে গতি বাড়িয়েছে, মানচিত্রের চারপাশে উড়েছে, একটি কোণ থেকে অন্য খেলোয়াড়দের হত্যা করেছে, অমর হয়ে গেছে এবং আরও অনেক কিছু।

আদর্শভাবে, আমরা সার্ভারে সমস্ত মেকানিক্স স্থানান্তর করব; যাইহোক, গেমটি ধ্রুবক বিকাশে ছিল এবং ইতিমধ্যেই যথেষ্ট পরিমাণে লিগ্যাসি কোড জমা করেছে তা ছাড়াও, একটি প্রামাণিক সার্ভারের সাথে একটি পদ্ধতির অন্যান্য অসুবিধাও থাকতে পারে। উদাহরণস্বরূপ, অবকাঠামোর উপর লোড বৃদ্ধি এবং একটি ভাল ইন্টারনেট সংযোগের চাহিদা। প্রদত্ত যে আমাদের বেশিরভাগ ব্যবহারকারী 3G/4G নেটওয়ার্কে খেলেন, এই পদ্ধতিটি, যদিও স্পষ্টতই, সমস্যাটির কার্যকর সমাধান ছিল না। দলের মধ্যে প্রতারকদের বিরুদ্ধে লড়াই করার বিকল্প পদ্ধতি হিসাবে, আমরা একটি নতুন ধারণা নিয়ে এসেছি - একটি "কোরাম" তৈরি করা।

কোরাম হল এমন একটি প্রক্রিয়া যা আপনাকে বিভিন্ন খেলোয়াড়ের একাধিক সিমুলেশন তুলনা করার অনুমতি দেয় যখন ক্ষতি হয়েছে নিশ্চিত করা হয়; ক্ষতি গ্রহণ করা গেমের প্রধান বৈশিষ্ট্যগুলির মধ্যে একটি, যার উপর কার্যত এর বাকি রাজ্য নির্ভর করে। উদাহরণস্বরূপ, আপনি যদি আপনার বিরোধীদের ধ্বংস করেন, তারা বীকন ক্যাপচার করতে সক্ষম হবে না।

এই সিদ্ধান্তের ধারণাটি নিম্নরূপ ছিল: প্রতিটি খেলোয়াড় এখনও সমগ্র বিশ্বকে অনুকরণ করছিল (অন্যান্য খেলোয়াড়দের শুটিং সহ) এবং ফলাফলগুলি সার্ভারে পাঠাচ্ছিল। সার্ভারটি সমস্ত খেলোয়াড়ের ফলাফল বিশ্লেষণ করে এবং প্লেয়ারটি শেষ পর্যন্ত ক্ষতিগ্রস্ত হয়েছে কিনা এবং কতটা তা নিয়ে সিদ্ধান্ত নেয়। আমাদের ম্যাচগুলিতে 12 জন লোক জড়িত, তাই সার্ভারের জন্য যে ক্ষতি হয়েছে তা বিবেচনা করার জন্য, 7 জন খেলোয়াড়ের স্থানীয় সিমুলেশনের মধ্যে নিবন্ধিত হওয়া যথেষ্ট। এই ফলাফলগুলি তারপর আরও বৈধতার জন্য সার্ভারে পাঠানো হবে। পরিকল্পিতভাবে, এই অ্যালগরিদমটি নিম্নরূপ উপস্থাপন করা যেতে পারে:

এই স্কিমটি আমাদেরকে প্রতারকদের সংখ্যা উল্লেখযোগ্যভাবে হ্রাস করার অনুমতি দেয় যারা যুদ্ধে নিজেদের অযোগ্য করে তুলেছিল। নিম্নলিখিত গ্রাফটি এই ব্যবহারকারীদের বিরুদ্ধে অভিযোগের সংখ্যার পাশাপাশি সার্ভারে ক্ষতি গণনা বৈশিষ্ট্যগুলি সক্ষম করার এবং ক্ষতির কোরাম সক্ষম করার পর্যায়গুলি দেখায়:

এই ক্ষতি-কারবার প্রক্রিয়াটি দীর্ঘ সময়ের জন্য প্রতারণার সাথে সমস্যার সমাধান করেছে কারণ সার্ভারে পদার্থবিজ্ঞানের অভাব থাকা সত্ত্বেও (এবং তাই পৃষ্ঠের টপোগ্রাফি এবং মহাকাশে রোবটের বাস্তব অবস্থানের মতো বিষয়গুলিকে বিবেচনায় নিতে অক্ষমতা) এর ফলাফলগুলি সমস্ত ক্লায়েন্টের সিমুলেশন এবং তাদের সম্মতি একটি দ্ব্যর্থহীন বোধগম্যতা দিয়েছে যে কে কাকে এবং কোন পরিস্থিতিতে ক্ষতি করেছে।

প্রকল্পের আরও উন্নয়ন

সময়ের সাথে সাথে, গতিশীল ছায়াগুলির পাশাপাশি, আমরা ইউনিটি পোস্ট প্রসেসিং স্ট্যাক এবং ব্যাচ রেন্ডারিং ব্যবহার করে গেমটিতে পোস্ট-ইফেক্ট যোগ করেছি। পোস্ট-প্রসেসিং প্রভাব প্রয়োগের ফলে উন্নত গ্রাফিক্সের উদাহরণ নিচের ছবিতে দেখা যেতে পারে:

ডিবাগ বিল্ডগুলিতে কী ঘটছে তা আরও ভালভাবে বোঝার জন্য, আমরা একটি লগিং সিস্টেম তৈরি করেছি এবং অভ্যন্তরীণ পরিকাঠামোতে একটি স্থানীয় পরিষেবা স্থাপন করেছি যা অভ্যন্তরীণ পরীক্ষকদের কাছ থেকে লগ সংগ্রহ করতে পারে এবং বাগগুলির কারণগুলি খুঁজে পাওয়া সহজ করতে পারে৷ এই টুলটি এখনও QA দ্বারা প্লেটেস্টের জন্য ব্যবহৃত হয় এবং এর কাজের ফলাফল জিরার টিকিটের সাথে সংযুক্ত করা হয়।

আমরা প্রকল্পে একটি স্ব-লিখিত প্যাকেজ ম্যানেজারও যোগ করেছি। প্রাথমিকভাবে, আমরা বিভিন্ন প্যাকেজ এবং বাহ্যিক প্লাগইনগুলির সাথে কাজটি উন্নত করতে চেয়েছিলাম (যার মধ্যে প্রকল্পটি ইতিমধ্যেই যথেষ্ট পরিমাণে জমা করেছে)। যাইহোক, সেই সময়ে ইউনিটির কার্যকারিতা যথেষ্ট ছিল না, তাই আমাদের অভ্যন্তরীণ প্ল্যাটফর্ম টিম প্যাকেজ সংস্করণ, এনপিএম ব্যবহার করে স্টোরেজ এবং কেবল গিটহাবের একটি লিঙ্ক যোগ করার মাধ্যমে প্যাকেজগুলিকে প্রকল্পে সংযুক্ত করার ক্ষমতা সহ নিজস্ব সমাধান তৈরি করেছিল। যেহেতু আমরা এখনও একটি নেটিভ ইঞ্জিন সলিউশন ব্যবহার করতে চেয়েছিলাম, তাই আমরা ইউনিটির সহকর্মীদের সাথে পরামর্শ করেছি এবং 2018 সালে যখন তারা তাদের প্যাকেজ ম্যানেজার রিলিজ করেছিল তখন আমাদের বেশ কিছু ধারণা ইউনিটির চূড়ান্ত সমাধানে অন্তর্ভুক্ত করা হয়েছিল।

আমরা প্ল্যাটফর্মের সংখ্যা প্রসারিত করতে থাকি যেখানে আমাদের গেম উপলব্ধ ছিল। অবশেষে, ফেসবুক গেমরুম, একটি প্ল্যাটফর্ম যা কীবোর্ড এবং মাউস সমর্থন করে, হাজির। এটি ফেসবুক (মেটা) থেকে একটি সমাধান, যা ব্যবহারকারীদের একটি পিসিতে অ্যাপ্লিকেশন চালানোর অনুমতি দেয়; মূলত, এটি একটি স্টিম স্টোর এনালগ। অবশ্যই, Facebook শ্রোতারা বেশ বৈচিত্র্যময়, এবং Facebook গেমরুমটি প্রচুর সংখ্যক ডিভাইসে চালু করা হয়েছিল, প্রধানত নন-গেমিংগুলি। সুতরাং, আমরা গেমটিতে মোবাইল গ্রাফিক্স রাখার সিদ্ধান্ত নিয়েছি যাতে প্রধান দর্শকদের পিসিগুলিকে বোঝা না হয়। একটি প্রযুক্তিগত দৃষ্টিকোণ থেকে, গেমটির জন্য প্রয়োজনীয় শুধুমাত্র উল্লেখযোগ্য পরিবর্তনগুলি হল SDK, পেমেন্ট সিস্টেমের একীকরণ এবং নেটিভ ইউনিটি ইনপুট সিস্টেম ব্যবহার করে কীবোর্ড এবং মাউসের জন্য সমর্থন।

টেকনিক্যালি, এটি স্টিমের জন্য গেম তৈরির থেকে সামান্যই আলাদা ছিল, কিন্তু ডিভাইসগুলির গুণমান উল্লেখযোগ্যভাবে কম ছিল কারণ প্ল্যাটফর্মটি নৈমিত্তিক প্লেয়ারদের জন্য মোটামুটি সাধারণ ডিভাইসগুলির জন্য একটি জায়গা হিসাবে অবস্থান করা হয়েছিল যা একটি ব্রাউজার ছাড়া আর কিছুই চালাতে পারে না, এর সাথে মনে মনে ফেসবুক একটি মোটামুটি বড় বাজারে প্রবেশের আশা. এই ডিভাইসগুলির সংস্থানগুলি সীমিত ছিল এবং প্ল্যাটফর্মে, বিশেষত, স্থায়ী মেমরি এবং কর্মক্ষমতা সমস্যা ছিল।

পরে, প্ল্যাটফর্ম বন্ধ হয়ে যায়, এবং আমরা আমাদের খেলোয়াড়দের স্টিমে স্থানান্তরিত করেছি, যেখানে এটি সম্ভব ছিল। এর জন্য, আমরা প্ল্যাটফর্মগুলির মধ্যে অ্যাকাউন্টগুলি স্থানান্তর করার জন্য কোড সহ একটি বিশেষ সিস্টেম তৈরি করেছি।

VR-এ যুদ্ধের রোবট ব্যবহার করে দেখুন

2017 সালের আরেকটি উল্লেখযোগ্য ইভেন্ট: iPhone X এর রিলিজ, একটি খাঁজ সহ প্রথম স্মার্টফোন। সেই সময়ে, ইউনিটি নচ সহ ডিভাইসগুলিকে সমর্থন করে না, তাই আমাদের UnityEngine.Screen.safeArea প্যারামিটারের উপর ভিত্তি করে একটি কাস্টম সমাধান তৈরি করতে হয়েছিল, যা UI কে ফোনের স্ক্রিনে বিভিন্ন নিরাপদ অঞ্চল স্কেল করতে এবং এড়াতে বাধ্য করে৷

উপরন্তু, 2017 সালে, আমরা অন্য কিছু চেষ্টা করার সিদ্ধান্ত নিয়েছি - আমাদের গেমের একটি VR সংস্করণ স্টিমে প্রকাশ করছি। বিকাশ প্রায় ছয় মাস স্থায়ী হয়েছিল এবং সেই সময়ে উপলব্ধ সমস্ত হেলমেটগুলির পরীক্ষা অন্তর্ভুক্ত করেছিল: ওকুলাস, এইচটিসি ভিভ এবং উইন্ডোজ মিক্সড রিয়েলিটি। এই কাজটি Oculus API এবং Steam API ব্যবহার করে করা হয়েছিল। এছাড়াও, PS VR হেডসেটের জন্য একটি ডেমো সংস্করণ প্রস্তুত করা হয়েছিল, সেইসাথে MacOS-এর জন্য সমর্থন।

প্রযুক্তিগত দৃষ্টিকোণ থেকে, একটি স্থিতিশীল FPS বজায় রাখা প্রয়োজন ছিল: PS VR-এর জন্য 60 FPS এবং HTC Vive-এর জন্য 90 FPS৷ এটি অর্জনের জন্য, স্ব-স্ক্রিপ্টেড জোন কুলিং ব্যবহার করা হয়েছিল, স্ট্যান্ডার্ড ফ্রাস্টাম এবং অক্লুশন ছাড়াও, সেইসাথে পুনঃপ্রজেকশন (যখন কিছু ফ্রেম পূর্ববর্তীগুলির উপর ভিত্তি করে তৈরি করা হয়)।

গতির অসুস্থতার সমস্যা সমাধানের জন্য, একটি আকর্ষণীয় সৃজনশীল এবং প্রযুক্তিগত সমাধান গৃহীত হয়েছিল: আমাদের খেলোয়াড় রোবট পাইলট হয়েছিলেন এবং ককপিটে বসেছিলেন। কেবিনটি একটি স্থির উপাদান ছিল, তাই মস্তিষ্ক এটিকে বিশ্বের একধরনের ধ্রুবক হিসাবে উপলব্ধি করেছিল এবং সেইজন্য, মহাকাশে চলাচল খুব ভালভাবে কাজ করেছিল।

গেমটির একটি দৃশ্যকল্পও ছিল যার জন্য বেশ কয়েকটি পৃথক ট্রিগার, স্ক্রিপ্ট এবং হোমমেড টাইমলাইন বিকাশের প্রয়োজন ছিল কারণ ইউনিটির সেই সংস্করণে সিনেমা মেশিন এখনও উপলব্ধ ছিল না।

প্রতিটি অস্ত্রের জন্য, লক্ষ্যবস্তু, লকিং, ট্র্যাকিং এবং স্বয়ং-নিশানার জন্য যুক্তি স্ক্র্যাচ থেকে লেখা হয়েছিল।

সংস্করণটি স্টিমে প্রকাশিত হয়েছিল এবং আমাদের খেলোয়াড়দের দ্বারা ভালভাবে গ্রহণ করা হয়েছিল। যাইহোক, কিকস্টার্টার প্রচারের পরে, আমরা প্রকল্পের উন্নয়ন চালিয়ে যাওয়ার সিদ্ধান্ত নিয়েছি যেহেতু VR-এর জন্য একটি পূর্ণাঙ্গ PvP শুটারের বিকাশ প্রযুক্তিগত ঝুঁকি এবং এই ধরনের একটি প্রকল্পের জন্য বাজারের অপ্রস্তুত ছিল।

আমাদের প্রথম গুরুতর বাগ মোকাবেলা

যখন আমরা গেমের প্রযুক্তিগত উপাদানের উন্নতির জন্য কাজ করছিলাম, সেইসাথে নতুন এবং বিদ্যমান মেকানিক্স এবং প্ল্যাটফর্মগুলি তৈরি করার জন্য, আমরা গেমের প্রথম গুরুতর বাগটি দেখতে পেয়েছি, যা একটি নতুন প্রচার চালু করার সময় রাজস্বকে নেতিবাচকভাবে প্রভাবিত করে। সমস্যাটি ছিল যে "মূল্য" বোতামটি ভুলভাবে "পুরস্কার" হিসাবে স্থানীয়করণ করা হয়েছিল। বেশিরভাগ খেলোয়াড় এতে বিভ্রান্ত হয়েছিলেন, আসল মুদ্রা দিয়ে কেনাকাটা করেছিলেন এবং তারপরে অর্থ ফেরত চেয়েছিলেন।

প্রযুক্তিগত সমস্যাটি ছিল যে, আমাদের সমস্ত স্থানীয়করণ গেম ক্লায়েন্টে তৈরি করা হয়েছিল। যখন এই সমস্যাটি আবির্ভূত হয়েছিল, তখন আমরা বুঝতে পেরেছিলাম যে আমরা এমন একটি সমাধানে কাজ স্থগিত করতে পারি না যা আমাদের স্থানীয়করণ আপডেট করার অনুমতি দেয়। এভাবেই CDN এবং এর সাথে থাকা সরঞ্জামগুলির উপর ভিত্তি করে একটি সমাধান তৈরি করা হয়েছিল, যেমন TeamCity-এর প্রকল্পগুলি, যা CDN-এ স্থানীয়করণ ফাইলগুলি স্বয়ংক্রিয়ভাবে আপলোড করে।

এটি আমাদের ব্যবহার করা পরিষেবা (POEditor) থেকে স্থানীয়করণ ডাউনলোড করতে এবং CDN-এ কাঁচা ডেটা আপলোড করার অনুমতি দেয়।

এর পরে, সার্ভার প্রোফাইল স্থানীয়করণ ডেটার সাথে সম্পর্কিত ক্লায়েন্টের প্রতিটি সংস্করণের জন্য লিঙ্ক সেট করতে শুরু করে। অ্যাপ্লিকেশনটি চালু হলে, প্রোফাইল সার্ভার ক্লায়েন্টকে এই লিঙ্কটি পাঠাতে শুরু করে এবং এই ডেটা ডাউনলোড এবং ক্যাশে করা হয়েছিল।

ডেটা দিয়ে কাজ অপ্টিমাইজ করা

2018-এর দিকে ফ্ল্যাশ ফরোয়ার্ড। প্রজেক্ট বাড়ার সাথে সাথে সার্ভার থেকে ক্লায়েন্টে ডেটা স্থানান্তরের পরিমাণও বেড়েছে। সার্ভারের সাথে সংযোগ করার সময়, ব্যালেন্স, বর্তমান সেটিংস ইত্যাদি সম্পর্কে প্রচুর ডেটা ডাউনলোড করার প্রয়োজন ছিল।

বর্তমান ডেটা XML বিন্যাসে উপস্থাপিত হয়েছিল এবং স্ট্যান্ডার্ড ইউনিটি সিরিয়ালাইজার দ্বারা সিরিয়ালাইজ করা হয়েছিল।

ক্লায়েন্ট চালু করার সময়, সেইসাথে প্রোফাইল সার্ভার এবং গেম সার্ভারের সাথে যোগাযোগ করার সময় মোটামুটি বিপুল পরিমাণ ডেটা স্থানান্তর করার পাশাপাশি, প্লেয়ার ডিভাইসগুলি বর্তমান ব্যালেন্স সংরক্ষণ করতে এবং এটিকে সিরিয়ালাইজ/ডিসারিয়ালাইজ করতে প্রচুর মেমরি ব্যয় করে।

এটি স্পষ্ট হয়ে গেছে যে অ্যাপ্লিকেশনের কর্মক্ষমতা এবং শুরুর সময় উন্নত করার জন্য, বিকল্প প্রোটোকলগুলি খুঁজে বের করার জন্য R&D পরিচালনা করা প্রয়োজন।

আমাদের পরীক্ষার তথ্যের উপর অধ্যয়নের ফলাফল এই টেবিলে প্রদর্শিত হয়:

ফলস্বরূপ, আমরা মেসেজপ্যাক ফরম্যাট বেছে নিয়েছি যেহেতু একই ধরনের আউটপুট ফলাফলের সাথে ফ্ল্যাটবাফারে স্যুইচ করার চেয়ে মাইগ্রেশন সস্তা ছিল, বিশেষ করে পূর্ণসংখ্যা কীগুলির সাথে মেসেজপ্যাক ব্যবহার করার সময়।

ফ্ল্যাটবাফারের জন্য (এবং প্রোটোকল বাফারগুলির সাথে) এটি একটি পৃথক ভাষায় বার্তা বিন্যাস বর্ণনা করা, C# এবং জাভা কোড তৈরি করা এবং অ্যাপ্লিকেশনটিতে জেনারেট করা কোড ব্যবহার করা প্রয়োজন। যেহেতু আমরা ক্লায়েন্ট এবং সার্ভার রিফ্যাক্টর করার এই অতিরিক্ত খরচ বহন করতে চাইনি, তাই আমরা মেসেজপ্যাকে স্যুইচ করেছি।

রূপান্তরটি প্রায় নিরবচ্ছিন্ন ছিল, এবং প্রথম প্রকাশগুলিতে, আমরা XML-এ ফিরে যাওয়ার ক্ষমতাকে সমর্থন করেছি যতক্ষণ না আমরা নিশ্চিত হয়েছি যে নতুন সিস্টেমে কোনও সমস্যা নেই। নতুন সমাধানটি আমাদের সমস্ত কাজকে কভার করেছে - এটি ক্লায়েন্ট লোডিং সময়কে উল্লেখযোগ্যভাবে হ্রাস করেছে এবং সার্ভারগুলিতে অনুরোধ করার সময় কর্মক্ষমতা উন্নত করেছে।

আমাদের প্রকল্পের প্রতিটি বৈশিষ্ট্য বা নতুন প্রযুক্তিগত সমাধান একটি "পতাকা" অধীনে প্রকাশিত হয়। এই পতাকাটি খেলোয়াড়ের প্রোফাইলে সংরক্ষিত থাকে এবং ব্যালেন্স সহ গেমটি শুরু হলে ক্লায়েন্টের কাছে আসে। একটি নিয়ম হিসাবে, যখন একটি নতুন কার্যকারিতা প্রকাশ করা হয়, বিশেষত একটি প্রযুক্তিগত, বেশ কয়েকটি ক্লায়েন্ট রিলিজে পুরানো এবং নতুন উভয় কার্যকারিতা থাকে। নতুন কার্যকারিতা অ্যাক্টিভেশন উপরে বর্ণিত পতাকার অবস্থা অনুযায়ী কঠোরভাবে ঘটে, যা আমাদের রিয়েল-টাইমে একটি নির্দিষ্ট সমাধানের প্রযুক্তিগত সাফল্য নিরীক্ষণ এবং সামঞ্জস্য করতে দেয়।

ধীরে ধীরে, এটি প্রকল্পে নির্ভরশীল ইনজেকশন কার্যকারিতা আপডেট করার সময় ছিল। বর্তমানটি আর বিপুল সংখ্যক নির্ভরতার সাথে মোকাবিলা করতে পারেনি এবং কিছু ক্ষেত্রে, অ-স্পষ্ট সংযোগ চালু করেছে যেগুলি ভাঙা এবং রিফ্যাক্টর করা খুব কঠিন ছিল। (এটি বিশেষ করে এক বা অন্য উপায়ে UI এর সাথে সম্পর্কিত উদ্ভাবনের জন্য সত্য ছিল।)

একটি নতুন সমাধান নির্বাচন করার সময়, পছন্দটি সহজ ছিল: সুপরিচিত জেনজেক্ট, যা আমাদের অন্যান্য প্রকল্পগুলিতে প্রমাণিত হয়েছে। এই প্রকল্পটি দীর্ঘকাল ধরে উন্নয়নের মধ্যে রয়েছে, সক্রিয়ভাবে সমর্থিত, নতুন বৈশিষ্ট্য যুক্ত করা হচ্ছে এবং দলের অনেক বিকাশকারী এটির সাথে কিছু উপায়ে পরিচিত ছিলেন।

অল্প অল্প করে, আমরা জেনজেক্ট ব্যবহার করে যুদ্ধের রোবটগুলি পুনরায় লিখতে শুরু করি। সমস্ত নতুন মডিউল এটির সাথে তৈরি করা হয়েছিল এবং পুরানোগুলিকে ধীরে ধীরে রিফ্যাক্টর করা হয়েছিল। জেনজেক্ট ব্যবহার করার পর থেকে, আমরা আগে আলোচনা করা প্রসঙ্গে (যুদ্ধ এবং হ্যাঙ্গার) লোডিং পরিষেবাগুলির একটি পরিষ্কার ক্রম পেয়েছি, এবং এটি ডেভেলপারদের প্রকল্পের উন্নয়নে আরও সহজে ডুব দিতে এবং সেইসাথে আরও আত্মবিশ্বাসের সাথে নতুন বৈশিষ্ট্যগুলি বিকাশ করার অনুমতি দেয়। এই প্রেক্ষাপটের মধ্যে।

ইউনিটির অপেক্ষাকৃত নতুন সংস্করণে, অ্যাসিঙ্ক্রোনাস কোডের সাথে অ্যাসিঙ্ক/অপেক্ষার মাধ্যমে কাজ করা সম্ভব হয়েছে। আমাদের কোড ইতিমধ্যেই অ্যাসিঙ্ক্রোনাস কোড ব্যবহার করেছে, কিন্তু কোডবেস জুড়ে কোনও একক স্ট্যান্ডার্ড ছিল না, এবং যেহেতু ইউনিটি স্ক্রিপ্টিং ব্যাকএন্ড অ্যাসিঙ্ক/অপেক্ষা সমর্থন করতে শুরু করেছে, আমরা R&D পরিচালনা করার এবং অ্যাসিঙ্ক্রোনাস কোডে আমাদের পদ্ধতির মানসম্মত করার সিদ্ধান্ত নিয়েছি।

আরেকটি অনুপ্রেরণা ছিল কোড থেকে কলব্যাক হেল অপসারণ করা - এটি যখন অ্যাসিঙ্ক্রোনাস কলগুলির একটি ক্রমিক চেইন থাকে এবং প্রতিটি কল পরবর্তীটির ফলাফলের জন্য অপেক্ষা করে।

সেই সময়ে, বেশ কিছু জনপ্রিয় সমাধান ছিল, যেমন RSG বা UniRx; আমরা সেগুলিকে তুলনা করেছি এবং একটি একক টেবিলে কম্পাইল করেছি:

শেষ পর্যন্ত, আমরা অ্যাসিঙ্ক্রোনাস C# কোডের সাথে কাজ করার জন্য স্ট্যান্ডার্ড হিসাবে নেটিভ অ্যাসিঙ্ক/ওয়েট ব্যবহার করার বিষয়ে স্থির হয়েছি যা বেশিরভাগ বিকাশকারীরা পরিচিত। আমরা UniRx.Async ব্যবহার না করার সিদ্ধান্ত নিয়েছি, যেহেতু প্লাগইনের সুবিধাগুলি তৃতীয় পক্ষের সমাধানের উপর নির্ভর করার প্রয়োজনকে কভার করেনি৷

আমরা ন্যূনতম প্রয়োজনীয় কার্যকারিতার পথ অনুসরণ করতে বেছে নিয়েছি। আমরা RSG. প্রতিশ্রুতি বা ধারকদের ব্যবহার পরিত্যাগ করেছি, কারণ, প্রথমত, নতুন বিকাশকারীদের এইগুলি, সাধারণত অপরিচিত সরঞ্জামগুলির সাথে কাজ করার জন্য প্রশিক্ষণ দেওয়া প্রয়োজন ছিল এবং দ্বিতীয়ত, তৃতীয় পক্ষের কোডের জন্য একটি মোড়ক তৈরি করা প্রয়োজন ছিল যা RSG. প্রতিশ্রুতি বা হোল্ডারগুলিতে অ্যাসিঙ্ক টাস্ক ব্যবহার করে। অ্যাসিঙ্ক/অপেক্ষার পছন্দটি কোম্পানির প্রকল্পগুলির মধ্যে উন্নয়ন পদ্ধতির মানসম্মত করতেও সাহায্য করেছে। এই রূপান্তরটি আমাদের সমস্যার সমাধান করেছে - আমরা অ্যাসিঙ্ক্রোনাস কোডের সাথে কাজ করার জন্য একটি পরিষ্কার প্রক্রিয়ার সাথে শেষ করেছি এবং প্রকল্প থেকে কলব্যাক-টু-সাপোর্ট করা কঠিন সরিয়ে দিয়েছি।

UI ধীরে ধীরে উন্নত হয়েছে। যেহেতু আমাদের দলে, নতুন বৈশিষ্ট্যগুলির কার্যকারিতা ক্লায়েন্ট প্রোগ্রামারদের দ্বারা তৈরি করা হয় এবং লেআউট এবং ইন্টারফেস ডেভেলপমেন্ট UI/UX বিভাগ দ্বারা সঞ্চালিত হয়, তাই আমাদের একটি সমাধানের প্রয়োজন ছিল যা আমাদের একই বৈশিষ্ট্যের কাজকে সমান্তরাল করার অনুমতি দেবে - যাতে প্রোগ্রামার যুক্তি লেখার সময় লেআউট ডিজাইনার ইন্টারফেস তৈরি এবং পরীক্ষা করতে পারে।

এই সমস্যার সমাধান ইন্টারফেসের সাথে কাজ করার MVVM মডেলে রূপান্তরের মধ্যে পাওয়া গেছে। এই মডেলটি ইন্টারফেস ডিজাইনারকে শুধুমাত্র একটি প্রোগ্রামারকে জড়িত না করেই একটি ইন্টারফেস ডিজাইন করতে দেয় না বরং কোন প্রকৃত ডেটা এখনও সংযুক্ত না থাকলে ইন্টারফেসটি নির্দিষ্ট ডেটাতে কীভাবে প্রতিক্রিয়া দেখাবে তাও দেখতে দেয়। অফ-দ্য-শেল্ফ সমাধানগুলিতে কিছু গবেষণার পরে, সেইসাথে আমাদের নিজস্ব সমাধানের দ্রুত প্রোটোটাইপিং যার নাম Pixonic ReactiveBindings, আমরা নিম্নলিখিত ফলাফলগুলির সাথে একটি তুলনা সারণী সংকলন করেছি:

যত তাড়াতাড়ি নতুন সিস্টেম নিজেকে প্রমাণ করেছে, প্রাথমিকভাবে নতুন ইন্টারফেসের উত্পাদন সহজ করার শর্তে, আমরা সমস্ত নতুন প্রকল্পের পাশাপাশি প্রকল্পে উপস্থিত সমস্ত নতুন বৈশিষ্ট্যগুলির জন্য এটি ব্যবহার করা শুরু করেছি।

নতুন প্রজন্মের মোবাইল ডিভাইসের জন্য গেমটির রিমাস্টার

2019 সাল নাগাদ, Apple এবং Samsung থেকে বেশ কয়েকটি ডিভাইস প্রকাশ করা হয়েছিল যেগুলি গ্রাফিক্সের দিক থেকে বেশ শক্তিশালী ছিল, তাই আমাদের কোম্পানি ওয়ার রোবটগুলির একটি উল্লেখযোগ্য আপগ্রেডের ধারণা নিয়ে এসেছিল। আমরা এই সমস্ত নতুন ডিভাইসের শক্তি ব্যবহার করতে এবং গেমটির ভিজ্যুয়াল ইমেজ আপডেট করতে চেয়েছিলাম।

আপডেট হওয়া চিত্র ছাড়াও, আমাদের আপডেট হওয়া পণ্যের জন্য আমাদের বেশ কিছু প্রয়োজনীয়তাও ছিল: আমরা একটি 60 FPS গেম মোড সমর্থন করতে চেয়েছিলাম, সেইসাথে বিভিন্ন ডিভাইসের জন্য সম্পদের বিভিন্ন গুণাবলী।

বর্তমান কোয়ালিটি ম্যানেজারকেও একটি পুনঃকাজের প্রয়োজন ছিল, কারণ ব্লকের মধ্যে গুণাবলীর সংখ্যা বাড়ছিল, যেগুলি ফ্লাই চালু ছিল, উত্পাদনশীলতা হ্রাস করে, সেইসাথে বিপুল সংখ্যক পারমুটেশন তৈরি করে, যার প্রতিটিকে পরীক্ষা করতে হয়েছিল, যা অতিরিক্ত চাপিয়েছিল প্রতিটি রিলিজের সাথে QA টিমের খরচ।

ক্লায়েন্ট পুনরায় কাজ করার সময় আমরা প্রথম যে জিনিসটি শুরু করেছি তা হল রিফ্যাক্টরিং শুটিং। মূল বাস্তবায়ন ফ্রেম রেন্ডারিং গতির উপর নির্ভর করে কারণ ক্লায়েন্টে গেম সত্তা এবং এর ভিজ্যুয়াল উপস্থাপনা এক এবং একই বস্তু ছিল। আমরা এই সত্তাগুলিকে আলাদা করার সিদ্ধান্ত নিয়েছি যাতে শটটির গেম সত্তা আর তার ভিজ্যুয়ালের উপর নির্ভরশীল না হয় এবং এটি বিভিন্ন ফ্রেম রেট সহ ডিভাইসগুলির মধ্যে আরও ভাল খেলা অর্জন করে।

গেমটি প্রচুর সংখ্যক শট নিয়ে কাজ করে, তবে এগুলির ডেটা প্রক্রিয়াকরণের জন্য অ্যালগরিদমগুলি বেশ সহজ – চলন্ত, শত্রুকে আঘাত করা হয়েছে কিনা তা নির্ধারণ করা ইত্যাদি। প্রজেক্টাইল আন্দোলনের যুক্তি সংগঠিত করার জন্য সত্তা উপাদান সিস্টেম ধারণাটি উপযুক্ত ছিল খেলায়, তাই আমরা এটির সাথে লেগে থাকার সিদ্ধান্ত নিয়েছি।

উপরন্তু, আমাদের সমস্ত নতুন প্রকল্পে, আমরা ইতিমধ্যেই যুক্তির সাথে কাজ করার জন্য ECS ব্যবহার করছিলাম, এবং আমাদের মূল প্রকল্পে একীকরণের জন্য এই দৃষ্টান্তটি প্রয়োগ করার সময় এসেছে। কাজ করার ফলস্বরূপ, আমরা একটি মূল প্রয়োজনীয়তা উপলব্ধি করেছি – 60 FPS এ ছবি চালানোর ক্ষমতা নিশ্চিত করা। যাইহোক, সমস্ত যুদ্ধ কোড ইসিএস-এ স্থানান্তরিত হয়নি, তাই এই পদ্ধতির সম্ভাব্যতা সম্পূর্ণরূপে উপলব্ধি করা যায়নি। পরিশেষে, আমরা যতটা পছন্দ করতাম ততটা পারফরম্যান্স উন্নত করিনি, তবে আমরা এটিকেও অবনমিত করিনি, যা এখনও এমন একটি শক্তিশালী দৃষ্টান্ত এবং স্থাপত্য পরিবর্তনের সাথে একটি গুরুত্বপূর্ণ সূচক।

একই সময়ে, আমরা আমাদের নতুন গ্রাফিক্স স্ট্যাকের সাথে গ্রাফিক্সের কোন স্তর অর্জন করতে পারি তা দেখতে আমাদের পিসি সংস্করণে কাজ শুরু করেছি। এটি ইউনিটি এসআরপির সুবিধা নিতে শুরু করেছিল, যা সেই সময়ে প্রিভিউ সংস্করণে ছিল এবং ক্রমাগত পরিবর্তন হচ্ছিল। স্টিম সংস্করণের জন্য যে ছবিটি এসেছে তা বেশ চিত্তাকর্ষক ছিল:

আরও, উপরের ছবিতে দেখানো কিছু গ্রাফিকাল বৈশিষ্ট্য শক্তিশালী মোবাইল ডিভাইসে স্থানান্তর করা যেতে পারে। এটি বিশেষত অ্যাপল ডিভাইসগুলির জন্য, যেগুলির ঐতিহাসিকভাবে ভাল পারফরম্যান্স বৈশিষ্ট্য, চমৎকার ড্রাইভার এবং হার্ডওয়্যার এবং সফ্টওয়্যারগুলির একটি আঁটসাঁট সমন্বয় রয়েছে; এটি তাদের আমাদের পক্ষে কোনও অস্থায়ী সমাধান ছাড়াই খুব উচ্চ মানের ছবি তৈরি করতে দেয়।

আমরা দ্রুত বুঝতে পেরেছিলাম যে একা গ্রাফিক্স স্ট্যাক পরিবর্তন করলে ইমেজ পরিবর্তন হবে না। এটাও স্পষ্ট হয়ে ওঠে যে, শক্তিশালী ডিভাইস ছাড়াও, দুর্বল ডিভাইসের জন্য আমাদের সামগ্রীর প্রয়োজন হবে। সুতরাং, আমরা বিভিন্ন মানের স্তরের জন্য সামগ্রী তৈরি করার পরিকল্পনা শুরু করেছি।

এর মানে হল যে মেচ, বন্দুক, মানচিত্র, প্রভাব এবং তাদের টেক্সচারগুলিকে গুণমানে আলাদা করতে হবে, যা বিভিন্ন গুণের জন্য বিভিন্ন সত্তায় অনুবাদ করে। অর্থাৎ, HD কোয়ালিটিতে কাজ করবে এমন ফিজিক্যাল মডেল, টেক্সচার এবং মেচ টেক্সচারের সেট অন্যান্য গুণাবলীতে কাজ করবে এমন মেচ থেকে আলাদা।

এছাড়াও, গেমটি মানচিত্রে প্রচুর পরিমাণে সংস্থান উত্সর্গ করে এবং এগুলিকে নতুন গুণাবলী মেনে চলতে পুনরায় তৈরি করা দরকার। এটাও স্পষ্ট হয়ে ওঠে যে বর্তমান কোয়ালিটি ম্যানেজার আমাদের চাহিদা পূরণ করে না কারণ এটি সম্পদের গুণমান নিয়ন্ত্রণ করে না।

সুতরাং, প্রথমে, আমাদের সিদ্ধান্ত নিতে হয়েছিল যে আমাদের গেমটিতে কী কী গুণাবলী পাওয়া যাবে। আমাদের বর্তমান কোয়ালিটি ম্যানেজারের অভিজ্ঞতা বিবেচনায় নিয়ে, আমরা বুঝতে পেরেছি যে নতুন সংস্করণে, আমরা বেশ কিছু নির্দিষ্ট গুণাবলী চেয়েছিলাম যা ব্যবহারকারী স্বতন্ত্রভাবে একটি প্রদত্ত ডিভাইসের জন্য সর্বাধিক উপলব্ধ মানের উপর নির্ভর করে সেটিংসে পরিবর্তন করতে পারে৷

নতুন মানের সিস্টেম ব্যবহারকারীর মালিকানাধীন ডিভাইসটি নির্ধারণ করে এবং ডিভাইস মডেল (iOS-এর ক্ষেত্রে) এবং GPU মডেলের (Android-এর ক্ষেত্রে) উপর ভিত্তি করে, একটি নির্দিষ্ট প্লেয়ারের জন্য সর্বাধিক উপলব্ধ গুণমান সেট করার অনুমতি দেয়। এই ক্ষেত্রে, এই গুণ, সেইসাথে সমস্ত পূর্ববর্তী গুণাবলী পাওয়া যায়।

এছাড়াও, প্রতিটি মানের জন্য, 30 এবং 60-এর মধ্যে সর্বাধিক FPS পরিবর্তন করার একটি সেটিং রয়েছে। প্রাথমিকভাবে, আমরা প্রায় পাঁচটি গুণ (ULD, LD, MD, HD, UHD) রাখার পরিকল্পনা করেছি। যাইহোক, উন্নয়ন প্রক্রিয়া চলাকালীন, এটি স্পষ্ট হয়ে গেছে যে এই পরিমাণ গুণাবলীর বিকাশ হতে অনেক সময় লাগবে এবং এটি আমাদের QA-এর উপর লোড কমাতে দেবে না। এটি মাথায় রেখে, শেষ পর্যন্ত, আমরা গেমটিতে নিম্নলিখিত গুণাবলী নিয়ে শেষ করেছি: HD, LD, এবং ULD। (একটি রেফারেন্স হিসাবে, এই গুণাবলীর সাথে খেলা দর্শকদের বর্তমান বিতরণ নিম্নরূপ: HD - 7%, LD - 72%, ULD - 21%৷)

যত তাড়াতাড়ি আমরা বুঝতে পারি যে আমাদের আরও গুণাবলী প্রয়োগ করতে হবে, আমরা সেই গুণাবলী অনুসারে সম্পদগুলি কীভাবে সাজানো যায় তা নিয়ে কাজ শুরু করেছি। এই কাজটিকে সহজ করার জন্য, আমরা নিম্নলিখিত অ্যালগরিদমে সম্মত হয়েছি: শিল্পীরা সর্বোচ্চ মানের (HD) সম্পদ তৈরি করবে এবং তারপরে, স্ক্রিপ্ট এবং অন্যান্য অটোমেশন টুল ব্যবহার করে, এই সম্পদগুলির অংশগুলিকে সরলীকৃত করা হয় এবং অন্যান্য গুণাবলীর জন্য সম্পদ হিসাবে ব্যবহার করা হয়।

এই অটোমেশন সিস্টেমে কাজ করার প্রক্রিয়াতে, আমরা নিম্নলিখিত সমাধানগুলি তৈরি করেছি:

• সম্পদ আমদানিকারক - আমাদের টেক্সচারের জন্য প্রয়োজনীয় সেটিংস সেট করতে দেয়
• মেক ক্রিয়েটর – একটি টুল যা ইউনিটি প্রিফ্যাব ভেরিয়েন্টের উপর ভিত্তি করে বেশ কয়েকটি মেক সংস্করণ তৈরি করতে দেয়, সেইসাথে গুণমান এবং টেক্সচার সেটিংস, সংশ্লিষ্ট প্রকল্প ফোল্ডারে বিতরণ করা হয়।
• টেক্সচার অ্যারে প্যাকার – একটি টুল যা আপনাকে টেক্সচার অ্যারেতে টেক্সচার প্যাক করতে দেয়
• গুণমান মানচিত্র নির্মাতা – একটি উৎস UHD গুণমান মানচিত্র থেকে একাধিক মানচিত্রের গুণাবলী তৈরি করার একটি টুল

বিদ্যমান মেক এবং ম্যাপ সংস্থান রিফ্যাক্টর করার জন্য অনেক কাজ করা হয়েছে। মূল মেকগুলি বিভিন্ন গুণাবলী মাথায় রেখে ডিজাইন করা হয়নি এবং তাই, একক প্রিফ্যাবগুলিতে সংরক্ষণ করা হয়েছিল। রিফ্যাক্টরিংয়ের পরে, প্রাথমিক অংশগুলি তাদের থেকে বের করা হয়েছিল, প্রধানত তাদের যুক্তি সহ, এবং প্রিফ্যাব ভেরিয়েন্টগুলি ব্যবহার করে, একটি নির্দিষ্ট মানের জন্য টেক্সচার সহ ভেরিয়েন্ট তৈরি করা হয়েছিল। এছাড়াও, আমরা এমন সরঞ্জামগুলি যুক্ত করেছি যা গুণাবলীর উপর নির্ভর করে টেক্সচার স্টোরেজ ফোল্ডারগুলির শ্রেণিবিন্যাসকে বিবেচনায় নিয়ে একটি মেককে স্বয়ংক্রিয়ভাবে বিভিন্ন গুণাবলীতে ভাগ করতে পারে।

নির্দিষ্ট ডিভাইসে নির্দিষ্ট সম্পদ সরবরাহ করার জন্য, গেমের সমস্ত সামগ্রীকে বান্ডিল এবং প্যাকগুলিতে ভাগ করা প্রয়োজন ছিল। প্রধান প্যাকটিতে গেমটি চালানোর জন্য প্রয়োজনীয় সম্পদ, সমস্ত ক্ষমতায় ব্যবহৃত সম্পদ, সেইসাথে প্রতিটি প্ল্যাটফর্মের জন্য গুণমানের প্যাক রয়েছে: Android_LD, Android_HD, Android_ULD, iOS_LD, iOS_HD, iOS_ULD, এবং আরও অনেক কিছু।

আমাদের প্ল্যাটফর্ম টিম দ্বারা তৈরি করা রিসোর্সসিস্টেম টুলের জন্য প্যাকগুলিতে সম্পদের বিভাজন সম্ভব হয়েছে। এই সিস্টেমটি আমাদেরকে আলাদা প্যাকেজে সম্পদ সংগ্রহ করার অনুমতি দেয় এবং তারপরে সেগুলিকে ক্লায়েন্টে এম্বেড করতে পারে বা CDN-এর মতো বাহ্যিক সংস্থানগুলিতে আপলোড করার জন্য আলাদাভাবে নিতে পারে৷

সামগ্রী সরবরাহ করার জন্য, আমরা একটি নতুন সিস্টেম ব্যবহার করেছি, যা প্ল্যাটফর্ম টিম দ্বারা তৈরি করা হয়েছে, তথাকথিত ডেলিভারি সিস্টেম। এই সিস্টেমটি আপনাকে রিসোর্সসিস্টেম দ্বারা তৈরি একটি ম্যানিফেস্ট গ্রহণ করতে এবং নির্দিষ্ট উত্স থেকে সংস্থানগুলি ডাউনলোড করতে দেয়৷ এই উত্সটি হয় একটি মনোলিথিক বিল্ড, পৃথক APK ফাইল বা একটি দূরবর্তী CDN হতে পারে৷

প্রাথমিকভাবে, আমরা রিসোর্স প্যাকগুলি সঞ্চয় করার জন্য Google Play (Play Asset Delivery) এবং AppStore (অন-ডিমান্ড রিসোর্সেস) এর ক্ষমতাগুলি ব্যবহার করার পরিকল্পনা করেছি, কিন্তু অ্যান্ড্রয়েড প্ল্যাটফর্মে, স্বয়ংক্রিয় ক্লায়েন্ট আপডেটের সাথে সম্পর্কিত অনেক সমস্যা ছিল, সেইসাথে সীমাবদ্ধতা সঞ্চিত সম্পদের সংখ্যা।

আরও, আমাদের অভ্যন্তরীণ পরীক্ষাগুলি দেখিয়েছে যে একটি CDN সহ একটি বিষয়বস্তু বিতরণ ব্যবস্থা সবচেয়ে ভাল কাজ করে এবং সবচেয়ে স্থিতিশীল, তাই আমরা স্টোরগুলিতে সংস্থানগুলি সংরক্ষণ করা ছেড়ে দিয়েছি এবং সেগুলিকে আমাদের ক্লাউডে সংরক্ষণ করতে শুরু করেছি৷

রিমাস্টার রিলিজ করা হচ্ছে

যখন রিমাস্টারের মূল কাজ শেষ হয়েছিল, তখন মুক্তির সময় ছিল। যাইহোক, আমরা দ্রুত বুঝতে পেরেছি যে 3 GB এর মূল পরিকল্পিত আকারটি একটি খারাপ ডাউনলোড অভিজ্ঞতা ছিল যদিও বাজারে বেশ কয়েকটি জনপ্রিয় গেমের জন্য ব্যবহারকারীদের 5-10 GB ডেটা ডাউনলোড করতে হয়। আমাদের তত্ত্বটি ছিল যে ব্যবহারকারীরা এই নতুন বাস্তবতায় অভ্যস্ত হবে যখন আমরা আমাদের রিমাস্টার করা গেমটি বাজারে প্রকাশ করব, কিন্তু হায়।

অন্য কথায়, প্লেয়াররা মোবাইল গেমের জন্য এই ধরণের বড় ফাইলগুলিতে অভ্যস্ত ছিল না। আমাদের এই সমস্যার দ্রুত সমাধান খুঁজে বের করতে হবে। আমরা এর পরে বেশ কয়েকটি পুনরাবৃত্তির এইচডি গুণমান ছাড়াই একটি সংস্করণ প্রকাশ করার সিদ্ধান্ত নিয়েছি, কিন্তু তারপরও আমরা আমাদের ব্যবহারকারীদের কাছে এটি সরবরাহ করেছি।

রিমাস্টারের উন্নয়নের সাথে সমান্তরালভাবে, আমরা সক্রিয়ভাবে প্রকল্প পরীক্ষা স্বয়ংক্রিয়ভাবে কাজ করেছি। প্রকল্পের স্থিতি স্বয়ংক্রিয়ভাবে ট্র্যাক করা যায় তা নিশ্চিত করার জন্য QA টিম একটি দুর্দান্ত কাজ করেছে৷ এই মুহুর্তে, আমাদের কাছে ভার্চুয়াল মেশিন সহ সার্ভার রয়েছে যেখানে গেমটি চলে। একটি স্ব-লিখিত পরীক্ষার কাঠামো ব্যবহার করে, আমরা স্ক্রিপ্ট সহ প্রকল্পের যেকোনো বোতাম টিপতে পারি - এবং একই স্ক্রিপ্টগুলি সরাসরি ডিভাইসে পরীক্ষা করার সময় বিভিন্ন পরিস্থিতিতে চালানোর জন্য ব্যবহার করা হয়।

আমরা এই সিস্টেমটি বিকাশ চালিয়ে যাচ্ছি: স্থিতিশীলতা, কার্যকারিতা এবং সঠিক লজিক এক্সিকিউশন পরীক্ষা করার জন্য শত শত ক্রমাগত-চলমান পরীক্ষা ইতিমধ্যেই লেখা হয়েছে। ফলাফলগুলি একটি বিশেষ ড্যাশবোর্ডে প্রদর্শিত হয় যেখানে আমাদের QA বিশেষজ্ঞরা, ডেভেলপারদের সাথে, সবচেয়ে সমস্যাযুক্ত এলাকাগুলি (পরীক্ষা চালানোর আসল স্ক্রিনশট সহ) বিশদভাবে পরীক্ষা করতে পারেন৷

বর্তমান সিস্টেমটি কার্যকর করার আগে, রিগ্রেশন টেস্টিং অনেক সময় নেয় (প্রকল্পের পুরানো সংস্করণে প্রায় এক সপ্তাহ), যা ভলিউম এবং বিষয়বস্তুর পরিমাণের দিক থেকে বর্তমানের তুলনায় অনেক ছোট ছিল। কিন্তু স্বয়ংক্রিয় পরীক্ষার জন্য ধন্যবাদ, গেমটির বর্তমান সংস্করণটি মাত্র দুই রাতের জন্য পরীক্ষা করা হয়; এটি আরও উন্নত করা যেতে পারে, কিন্তু বর্তমানে, আমরা সিস্টেমের সাথে সংযুক্ত ডিভাইসের সংখ্যা দ্বারা সীমাবদ্ধ।

রিমাস্টারের সমাপ্তির দিকে, অ্যাপল টিম আমাদের সাথে যোগাযোগ করে এবং আমাদের ব্যবহার করে নতুন Apple A14 বায়োনিক চিপ (2020 সালের শরত্কালে নতুন আইপ্যাডগুলির সাথে প্রকাশিত) এর ক্ষমতা প্রদর্শনের জন্য একটি নতুন পণ্য উপস্থাপনায় অংশ নেওয়ার সুযোগ দেয়। নতুন গ্রাফিক্স। এই মিনি প্রকল্পে কাজ করার সময়, একটি সম্পূর্ণরূপে কাজ করা HD সংস্করণ তৈরি করা হয়েছিল, যা 120 FPS এ অ্যাপল চিপগুলিতে চলতে সক্ষম। এছাড়াও, নতুন চিপের শক্তি প্রদর্শনের জন্য বেশ কিছু গ্রাফিকাল উন্নতি যোগ করা হয়েছে।

একটি প্রতিযোগিতামূলক এবং বরং কঠিন নির্বাচনের ফলস্বরূপ, আমাদের গেমটি অ্যাপল ইভেন্টের শরৎ উপস্থাপনায় অন্তর্ভুক্ত ছিল! পুরো দলটি এই ইভেন্টটি দেখতে এবং উদযাপন করতে জড়ো হয়েছিল, এবং এটি সত্যিই দুর্দান্ত ছিল!

ফোটন ত্যাগ করা এবং ওয়ার্ল্ডস্টেট আর্কিটেকচারে স্থানান্তর করা।

2021 সালে গেমটির রিমাস্টারড সংস্করণ চালু হওয়ার আগেও একটি নতুন টাস্ক আবির্ভূত হয়েছিল। অনেক ব্যবহারকারী নেটওয়ার্ক সমস্যা সম্পর্কে অভিযোগ করেছিলেন, যার মূল ছিল সেই সময়ে আমাদের বর্তমান সমাধান, ফোটন ট্রান্সপোর্ট লেয়ার, যা ফোটন সার্ভার SDK এর সাথে কাজ করতে ব্যবহৃত হত। আরেকটি সমস্যা ছিল একটি র্যান্ডম ক্রমে সার্ভারে পাঠানো RPC-এর একটি বড় এবং অপ্রমাণিত সংখ্যক উপস্থিতি।

এছাড়াও, ম্যাচের শুরুতে বিশ্বগুলিকে সিঙ্ক্রোনাইজ করা এবং বার্তা সারিতে উপচে পড়া সমস্যা ছিল, যা উল্লেখযোগ্য ব্যবধানের কারণ হতে পারে।

পরিস্থিতির প্রতিকারের জন্য, আমরা নেটওয়ার্ক ম্যাচ স্ট্যাকটিকে আরও প্রচলিত মডেলের দিকে নিয়ে যাওয়ার সিদ্ধান্ত নিয়েছি, যেখানে সার্ভারের সাথে যোগাযোগ প্যাকেট এবং রিসিভিং গেম স্টেটের মাধ্যমে হয়, RPC কলের মাধ্যমে নয়।

নতুন অনলাইন ম্যাচ আর্কিটেকচারটিকে ওয়ার্ল্ডস্টেট বলা হয় এবং গেমপ্লে থেকে ফোটনকে সরিয়ে দেওয়ার উদ্দেশ্যে করা হয়েছিল।

LightNetLib লাইব্রেরির উপর ভিত্তি করে ফোটন থেকে UDP-তে ট্রান্সপোর্ট প্রোটোকল প্রতিস্থাপন করার পাশাপাশি, এই নতুন আর্কিটেকচারটি ক্লায়েন্ট-সার্ভার কমিউনিকেশন সিস্টেমকে স্ট্রিমলাইন করার সাথে জড়িত।

এই বৈশিষ্ট্যটিতে কাজ করার ফলস্বরূপ, আমরা সার্ভারের দিকে খরচ কমিয়েছি (উইন্ডোজ থেকে লিনাক্সে স্যুইচ করা এবং ফোটন সার্ভার SDK লাইসেন্স ত্যাগ করা), এমন একটি প্রোটোকলের সাথে শেষ করেছি যা ব্যবহারকারীর শেষ ডিভাইসগুলির জন্য অনেক কম দাবি করে, সমস্যার সংখ্যা হ্রাস করে। সার্ভার এবং ক্লায়েন্টের মধ্যে স্টেট ডিসিঙ্ক্রোনাইজেশন সহ, এবং নতুন PvE বিষয়বস্তু বিকাশের একটি সুযোগ তৈরি করেছে।

রাতারাতি পুরো গেমের কোড পরিবর্তন করা অসম্ভব হবে, তাই ওয়ার্ল্ডস্টেটের কাজটি কয়েকটি পর্যায়ে বিভক্ত ছিল।

প্রথম পর্যায়ে ক্লায়েন্ট এবং সার্ভারের মধ্যে যোগাযোগ প্রোটোকলের একটি সম্পূর্ণ পুনঃডিজাইন ছিল, এবং মেকগুলির চলাচল নতুন রেলগুলিতে স্থানান্তরিত হয়েছিল। এটি আমাদের গেমের জন্য একটি নতুন মোড তৈরি করার অনুমতি দিয়েছে: PvE। ধীরে ধীরে, মেকানিক্স সার্ভারে যেতে শুরু করে, বিশেষ করে সাম্প্রতিক (মেকগুলির ক্ষতি এবং গুরুতর ক্ষতি)। ওয়ার্ল্ডস্টেট মেকানিজমগুলিতে পুরানো কোডের ধীরে ধীরে স্থানান্তরের কাজ অব্যাহত রয়েছে এবং আমাদের এই বছর বেশ কয়েকটি আপডেটও থাকবে।

2022 সালে, আমরা একটি নতুন প্ল্যাটফর্ম চালু করেছি: Facebook ক্লাউড। প্ল্যাটফর্মের পিছনের ধারণাটি আকর্ষণীয় ছিল: ক্লাউডে এমুলেটরগুলিতে গেমগুলি চালানো এবং স্মার্টফোন এবং পিসিতে ব্রাউজারে সেগুলি স্ট্রিম করা, গেমটি চালানোর জন্য শেষ প্লেয়ারের একটি শক্তিশালী পিসি বা স্মার্টফোনের প্রয়োজন ছাড়াই; শুধুমাত্র একটি স্থিতিশীল ইন্টারনেট সংযোগ প্রয়োজন।

বিকাশকারীর দিক থেকে, প্ল্যাটফর্মটি ব্যবহার করবে এমন প্রধানটি হিসাবে দুটি ধরণের বিল্ড বিতরণ করা যেতে পারে: অ্যান্ড্রয়েড বিল্ড এবং উইন্ডোজ বিল্ড৷ এই প্ল্যাটফর্মের সাথে আমাদের বৃহত্তর অভিজ্ঞতার কারণে আমরা প্রথম পথটি নিয়েছি।

Facebook ক্লাউডে আমাদের গেমটি চালু করার জন্য, আমাদের বেশ কিছু পরিবর্তন করতে হবে, যেমন গেমটিতে অনুমোদন পুনরায় করা এবং কার্সার নিয়ন্ত্রণ যোগ করা। আমাদের সমস্ত অন্তর্নির্মিত সংস্থানগুলির সাথে একটি বিল্ড প্রস্তুত করতে হবে কারণ প্ল্যাটফর্মটি CDN সমর্থন করে না, এবং আমাদের আমাদের ইন্টিগ্রেশনগুলি কনফিগার করতে হবে, যা সবসময় এমুলেটরগুলিতে সঠিকভাবে চলতে পারে না।

গ্রাফিক্স স্ট্যাকের কার্যকারিতা নিশ্চিত করার জন্য গ্রাফিক্সের দিকেও অনেক কাজ করা হয়েছিল কারণ Facebook এমুলেটরগুলি আসল অ্যান্ড্রয়েড ডিভাইস ছিল না এবং ড্রাইভার বাস্তবায়ন এবং সংস্থান পরিচালনার ক্ষেত্রে তাদের নিজস্ব বৈশিষ্ট্য ছিল।

যাইহোক, আমরা দেখেছি যে এই প্ল্যাটফর্মের ব্যবহারকারীরা অনেক সমস্যার সম্মুখীন হয়েছে - উভয়ই অস্থির সংযোগ এবং এমুলেটরগুলির অস্থির অপারেশন, এবং Facebook 2024 সালের শুরুতে তাদের প্ল্যাটফর্ম বন্ধ করার সিদ্ধান্ত নিয়েছে।

প্রোগ্রামারদের পক্ষে ক্রমাগত যা ঘটে এবং যা এত ছোট নিবন্ধে বিশদভাবে আলোচনা করা যায় না তা হ'ল প্রকল্পের প্রযুক্তিগত ঝুঁকি নিয়ে নিয়মিত কাজ, প্রযুক্তিগত মেট্রিক্সের নিয়মিত পর্যবেক্ষণ, মেমরির সাথে অবিচ্ছিন্ন কাজ এবং সংস্থানগুলির অপ্টিমাইজেশন, সমস্যাগুলির সন্ধান করা। অংশীদার SDK-এর তৃতীয়-পক্ষ সমাধান, বিজ্ঞাপন সংহতকরণ এবং আরও অনেক কিছু।

উপরন্তু, আমরা গুরুতর ক্র্যাশ এবং ANR ঠিক করার জন্য গবেষণা এবং ব্যবহারিক কাজ চালিয়ে যাচ্ছি। যখন একটি প্রকল্প এত সংখ্যক সম্পূর্ণ ভিন্ন ডিভাইসে চলে, তখন এটি অনিবার্য।

আলাদাভাবে, আমরা যারা সমস্যার কারণ খুঁজে বের করতে কাজ করে তাদের পেশাদারিত্বের দিকে লক্ষ্য রাখতে চাই। এই প্রযুক্তিগত সমস্যাগুলি প্রায়শই জটিল প্রকৃতির হয় এবং একে অপরের উপরে বেশ কয়েকটি বিশ্লেষণাত্মক সিস্টেম থেকে ডেটা উচ্চতর করা প্রয়োজন, সেইসাথে কারণ খুঁজে পাওয়ার আগে কিছু অ-তুচ্ছ পরীক্ষা-নিরীক্ষা করা প্রয়োজন। প্রায়শই, বেশিরভাগ জটিল সমস্যাগুলির একটি ধারাবাহিকভাবে পুনরুত্পাদনযোগ্য কেস থাকে না যা পরীক্ষা করা যায়, তাই পরীক্ষামূলক ডেটা এবং আমাদের পেশাদার অভিজ্ঞতা প্রায়শই সেগুলি ঠিক করতে ব্যবহৃত হয়।

একটি প্রকল্পে সমস্যাগুলি খুঁজে পেতে আমরা যে সরঞ্জাম এবং সংস্থানগুলি ব্যবহার করি সে সম্পর্কে কয়েকটি শব্দ বলা উচিত।

• AppMetr – একটি অভ্যন্তরীণ বিশ্লেষণ সমাধান যা আপনাকে প্লেয়ারের সমস্যাগুলি অধ্যয়ন করতে ডিভাইসগুলি থেকে বেনামী ডেটা সংগ্রহ করতে দেয়। কিছু অনুরূপ সরঞ্জাম যা পাঠকের কাছে আরও বেশি পরিচিত হতে পারে: Firebase Analytics, Google Analytics, Flurry, GameAnalytics, devtodev, AppsFlyer ইত্যাদি।
• Google Firebase Crashlytics
• গুগল প্লে কনসোল - অ্যান্ড্রয়েড ভাইটালস
• লগ - ডিবাগ বিল্ডে লগের একটি সিস্টেম, যা আপনাকে স্টুডিওর মধ্যে প্লেটেস্টে সমস্যাগুলির জন্য অনুসন্ধানকে কমিয়ে দিতে দেয়
• পাবলিক টেস্ট রিয়েলম - আমাদের গেমটিতে পাবলিক টেস্ট সার্ভার রয়েছে যা আপনাকে নতুন পরিবর্তনগুলি পরীক্ষা করতে এবং বিভিন্ন প্রযুক্তিগত পরীক্ষা চালানোর অনুমতি দেয়
• ইউনিটি প্রোফাইলার
• এক্সকোড যন্ত্র

এটি প্রযুক্তিগত উন্নতির একটি ছোট তালিকা যা প্রকল্পটি তার অস্তিত্বের সময় হয়েছে। প্রোজেক্টটি ক্রমাগত উন্নয়নশীল হওয়ার পর থেকে যে সমস্ত কিছু সম্পন্ন হয়েছে তার তালিকা করা কঠিন, এবং প্রযুক্তিগত পরিচালকরা ক্রমাগতভাবে শেষ ব্যবহারকারীদের জন্য এবং যারা স্টুডিওর ভিতরে এটির সাথে কাজ করে তাদের জন্য পণ্যের কর্মক্ষমতা উন্নত করার জন্য পরিকল্পনা তৈরি এবং বাস্তবায়নের জন্য ক্রমাগত কাজ করছেন। বিকাশকারীরা নিজেরা এবং অন্যান্য বিভাগ।

আমাদের কাছে এখনও অনেক উন্নতি আছে যা পরবর্তী দশকে পণ্যটির হবে, এবং আমরা আশা করি যে আমরা আমাদের পরবর্তী নিবন্ধগুলিতে সেগুলি ভাগ করতে সক্ষম হব।

শুভ জন্মদিন, যুদ্ধের রোবট, এবং প্রযুক্তিগত বিশেষজ্ঞদের বিশাল দলকে ধন্যবাদ যারা এই সব সম্ভব করে তোলে!