হ্যালো! আমি আন্দ্রে মাখোরিন, Pixonic (MY.GAMES) এর সার্ভার ডেভেলপার। এই নিবন্ধে, আমি কীভাবে আমার দল এবং আমি ব্যাকএন্ড বিকাশের জন্য একটি সর্বজনীন সমাধান তৈরি করেছি তা শেয়ার করব। আপনি ধারণাটি, এর ফলাফল এবং আমাদের সিস্টেম, সিঙ্গুলারিটি, বাস্তব-বিশ্বের প্রকল্পগুলিতে কীভাবে পারফর্ম করেছে সে সম্পর্কে শিখবেন। আমরা যে চ্যালেঞ্জগুলো মোকাবেলা করেছি তার গভীরে আমিও যাব। পটভূমি যখন একটি গেম স্টুডিও শুরু হয়, এটি একটি বাধ্যতামূলক ধারণা দ্রুত প্রণয়ন এবং বাস্তবায়ন করা গুরুত্বপূর্ণ: কয়েক ডজন অনুমান পরীক্ষা করা হয়, এবং গেমটি ক্রমাগত পরিবর্তনের মধ্য দিয়ে যায়; নতুন বৈশিষ্ট্য যোগ করা হয় এবং অসফল সমাধান সংশোধন বা বাতিল করা হয়। যাইহোক, দ্রুত পুনরাবৃত্তির এই প্রক্রিয়া, কঠোর সময়সীমা এবং একটি সংক্ষিপ্ত পরিকল্পনা দিগন্তের সাথে মিলিত, প্রযুক্তিগত ঋণ সঞ্চয় করতে পারে। বিদ্যমান প্রযুক্তিগত ঋণের সাথে, পুরানো সমাধানগুলি পুনরায় ব্যবহার করা জটিল হতে পারে কারণ তাদের সাথে বিভিন্ন সমস্যা সমাধান করা প্রয়োজন। এটি স্পষ্টতই সর্বোত্তম নয়। কিন্তু আরেকটি উপায় আছে: একটি "সর্বজনীন কাঠামো"। জেনেরিক, পুনঃব্যবহারযোগ্য উপাদান (যেমন লেআউট উপাদান, উইন্ডোজ এবং লাইব্রেরি যা নেটওয়ার্ক মিথস্ক্রিয়া বাস্তবায়ন করে) ডিজাইন করে, স্টুডিওগুলি নতুন বৈশিষ্ট্যগুলি বিকাশের জন্য প্রয়োজনীয় সময় এবং প্রচেষ্টাকে উল্লেখযোগ্যভাবে হ্রাস করতে পারে। এই পদ্ধতিটি শুধুমাত্র কোড ডেভেলপারদের লেখার পরিমাণ কমায় না, এটি নিশ্চিত করে যে কোডটি ইতিমধ্যেই পরীক্ষা করা হয়েছে, যার ফলে রক্ষণাবেক্ষণে কম সময় ব্যয় হয়। আমরা একটি গেমের প্রেক্ষাপটে বৈশিষ্ট্য বিকাশ নিয়ে আলোচনা করেছি, তবে এখন অন্য কোণ থেকে পরিস্থিতিটি দেখুন: যে কোনও গেম স্টুডিওর জন্য, একটি প্রকল্পের মধ্যে কোডের ছোট টুকরো পুনরায় ব্যবহার করা উত্পাদনকে স্ট্রিমলাইন করার জন্য একটি কার্যকর কৌশল হতে পারে, তবে শেষ পর্যন্ত, তারা একটি নতুন হিট গেম তৈরি করতে হবে। একটি বিদ্যমান প্রকল্প থেকে সমাধানগুলি পুনঃব্যবহার করা, তাত্ত্বিকভাবে, এই প্রক্রিয়াটিকে ত্বরান্বিত করতে পারে, তবে দুটি উল্লেখযোগ্য প্রতিবন্ধকতা দেখা দেয়। প্রথমত, একই প্রযুক্তিগত ঋণের সমস্যাগুলি এখানে প্রযোজ্য, এবং দ্বিতীয়ত, কোনও পুরানো সমাধানগুলি সম্ভবত পূর্ববর্তী গেমের নির্দিষ্ট প্রয়োজনীয়তা অনুসারে তৈরি করা হয়েছিল, যা তাদের নতুন প্রকল্পের জন্য উপযুক্ত নয়। এই সমস্যাগুলি আরও সমস্যাগুলির দ্বারা জটিল: ডাটাবেস ডিজাইন নতুন প্রকল্পের প্রয়োজনীয়তাগুলি পূরণ করতে পারে না, প্রযুক্তিগুলি পুরানো হতে পারে এবং নতুন দলের প্রয়োজনীয় দক্ষতার অভাব থাকতে পারে। তদুপরি, মূল সিস্টেমটি প্রায়শই একটি নির্দিষ্ট জেনার বা গেমকে মাথায় রেখে ডিজাইন করা হয়, এটি একটি নতুন প্রকল্পের সাথে মানিয়ে নেওয়া কঠিন করে তোলে। আবার, এখানেই একটি সার্বজনীন কাঠামো কার্যকর হয়, এবং গেমগুলি তৈরি করার সময় যেগুলি একে অপরের থেকে সম্পূর্ণ আলাদা একটি দুর্লভ চ্যালেঞ্জ বলে মনে হতে পারে, এমন প্ল্যাটফর্মের উদাহরণ রয়েছে যা সফলভাবে এই সমস্যাটি মোকাবেলা করেছে: প্লেফ্যাব, ফোটন ইঞ্জিন এবং অনুরূপ প্ল্যাটফর্ম ডেভেলপারদের অবকাঠামোর পরিবর্তে গেম তৈরিতে ফোকাস করার অনুমতি দিয়ে ডেভেলপমেন্টের সময় উল্লেখযোগ্যভাবে হ্রাস করার ক্ষমতা প্রদর্শন করেছে। এখন, আমাদের গল্পে ঝাঁপ দেওয়া যাক। সিঙ্গুলারিটির প্রয়োজন মাল্টিপ্লেয়ার গেমগুলির জন্য, একটি শক্তিশালী ব্যাকএন্ড অপরিহার্য। কেস ইন পয়েন্ট: আমাদের ফ্ল্যাগশিপ গেম, ওয়ার রোবট। এটি একটি মোবাইল পিভিপি শ্যুটার, এটি প্রায় 10 বছরেরও বেশি সময় ধরে রয়েছে এবং এটি ব্যাকএন্ড সমর্থনের প্রয়োজন এমন অসংখ্য বৈশিষ্ট্য সংগ্রহ করেছে। এবং যখন আমাদের সার্ভার কোডটি প্রজেক্টের স্পেসিফিকেশন অনুসারে তৈরি করা হয়েছিল, তখন এটি সেকেলে হয়ে যাওয়া প্রযুক্তি ব্যবহার করছিল। যখন একটি নতুন গেম বিকাশের সময় এসেছিল, আমরা বুঝতে পেরেছিলাম যে ওয়ার রোবটগুলির সার্ভার উপাদানগুলি পুনরায় ব্যবহার করার চেষ্টা করা সমস্যাযুক্ত হবে। কোডটি খুব প্রজেক্ট-নির্দিষ্ট এবং প্রযুক্তিতে প্রয়োজনীয় দক্ষতা ছিল যা নতুন দলটির অভাব ছিল। আমরা এটিও স্বীকার করেছি যে নতুন প্রকল্পের সাফল্যের নিশ্চয়তা দেওয়া হয়নি, এবং এটি সফল হলেও, আমাদের শেষ পর্যন্ত আরেকটি নতুন গেম তৈরি করতে হবে এবং আমরা একই "খালি স্লেট" সমস্যার মুখোমুখি হব। এটি এড়াতে এবং কিছু ভবিষ্যত-প্রুফিং করতে, আমরা গেম ডেভেলপমেন্টের জন্য প্রয়োজনীয় প্রয়োজনীয় উপাদানগুলি চিহ্নিত করার এবং তারপর একটি সর্বজনীন কাঠামো তৈরি করার সিদ্ধান্ত নিয়েছি যা ভবিষ্যতের সমস্ত প্রকল্পে ব্যবহার করা যেতে পারে। আমাদের লক্ষ্য ছিল ডেভেলপারদের এমন একটি টুল প্রদান করা যা তাদের বারবার ব্যাকএন্ড , ডাটাবেস স্কিমা, ইন্টারঅ্যাকশন প্রোটোকল এবং নির্দিষ্ট প্রযুক্তি ডিজাইন করার প্রয়োজন থেকে রেহাই দেবে। আমরা লোকেদের অনুমোদন, অর্থপ্রদান প্রক্রিয়াকরণ এবং ব্যবহারকারীর তথ্য সঞ্চয়স্থান বাস্তবায়নের বোঝা থেকে মুক্ত করতে চেয়েছিলাম, যাতে তারা গেমের মূল দিকগুলিতে ফোকাস করতে পারে: গেমপ্লে, ডিজাইন, ব্যবসায়িক যুক্তি এবং আরও অনেক কিছু। আর্কিটেকচার উপরন্তু, আমরা শুধু আমাদের নতুন কাঠামোর সাথে উন্নয়ন ত্বরান্বিত করতে চাইনি, ক্লায়েন্ট প্রোগ্রামারদের নেটওয়ার্কিং, ডিবিএমএস বা অবকাঠামো সম্পর্কে গভীর জ্ঞান ছাড়াই সার্ভার-সাইড লজিক লিখতে সক্ষম করতে চাই। এর বাইরে, পরিষেবাগুলির একটি সেটকে মানককরণ করে, আমাদের DevOps টিম সমস্ত গেম প্রকল্পের সাথে একইভাবে আচরণ করতে সক্ষম হবে, শুধুমাত্র আইপি ঠিকানাগুলি পরিবর্তন করে৷ এটি আমাদের পুনরায় ব্যবহারযোগ্য স্থাপনার স্ক্রিপ্ট টেমপ্লেট এবং পর্যবেক্ষণ ড্যাশবোর্ড তৈরি করতে সক্ষম করবে। পুরো প্রক্রিয়া জুড়ে, আমরা স্থাপত্যগত সিদ্ধান্ত নিয়েছি যা ভবিষ্যতের গেমগুলিতে ব্যাকএন্ড পুনরায় ব্যবহার করার সম্ভাবনা বিবেচনা করে। এই পদ্ধতিটি নিশ্চিত করেছে যে আমাদের কাঠামো নমনীয়, মাপযোগ্য এবং বিভিন্ন প্রকল্পের প্রয়োজনীয়তার সাথে খাপ খাইয়ে নেওয়া যায়। (এটাও লক্ষণীয় যে কাঠামোর বিকাশ একটি দ্বীপ ছিল না - এটি অন্য প্রকল্পের সাথে সমান্তরালভাবে তৈরি করা হয়েছিল।) প্লাটফর্ম তৈরি করা আমরা সিঙ্গুলারিটিকে একটি গেমের জেনার, সেটিং বা মূল গেমপ্লেতে অজ্ঞেয়বাদী ফাংশনগুলির একটি সেট দেওয়ার সিদ্ধান্ত নিয়েছি, যার মধ্যে রয়েছে: প্রমাণীকরণ ব্যবহারকারীর ডেটা স্টোরেজ গেম সেটিংস এবং ব্যালেন্স পার্সিং পেমেন্ট প্রসেসিং এবি টেস্টিং ডিস্ট্রিবিউশন বিশ্লেষণ সেবা ইন্টিগ্রেশন সার্ভার অ্যাডমিন প্যানেল এই ফাংশনগুলি যেকোন মাল্টি-ইউজার মোবাইল প্রোজেক্টের জন্য মৌলিক (অন্তত, এগুলি পিক্সোনিক-এ বিকশিত প্রকল্পগুলির সাথে প্রাসঙ্গিক)। এই মূল ফাংশনগুলি ছাড়াও, সিঙ্গুলারিটি ব্যবসায়িক যুক্তির কাছাকাছি আরও প্রকল্প-নির্দিষ্ট বৈশিষ্ট্যগুলিকে মিটমাট করার জন্য ডিজাইন করা হয়েছিল। এই ক্ষমতাগুলি বিমূর্ততা ব্যবহার করে তৈরি করা হয়েছে, এগুলিকে বিভিন্ন প্রকল্পে পুনরায় ব্যবহারযোগ্য এবং এক্সটেনসিবল করে তোলে। কিছু উদাহরণ অন্তর্ভুক্ত: অনুসন্ধান অফার বন্ধুর তালিকা ম্যাচমেকিং রেটিং টেবিল খেলোয়াড়দের অনলাইন অবস্থা ইন-গেম বিজ্ঞপ্তি প্রযুক্তিগতভাবে, সিঙ্গুলারিটি প্ল্যাটফর্ম চারটি উপাদান নিয়ে গঠিত: এটি লাইব্রেরির একটি সেট যার উপর ভিত্তি করে গেম প্রোগ্রামাররা তাদের সার্ভারগুলি বিকাশ করতে পারে। সার্ভার SDK: এছাড়াও লাইব্রেরির একটি সেট, কিন্তু একটি মোবাইল অ্যাপ্লিকেশন বিকাশের জন্য৷ ক্লায়েন্ট SDK: এগুলি রেডিমেড সার্ভার যেগুলির পরিবর্তনের প্রয়োজন হয় না৷ এর মধ্যে রয়েছে প্রমাণীকরণ সার্ভার, ব্যালেন্স সার্ভার এবং অন্যান্য। রেডিমেড মাইক্রোসার্ভিসের একটি সেট: এই লাইব্রেরিগুলি ইতিমধ্যেই বিভিন্ন বৈশিষ্ট্য প্রয়োগ করে, যেমন অফার, অনুসন্ধান ইত্যাদি৷ গেম প্রোগ্রামাররা তাদের গেমের প্রয়োজন হলে এই এক্সটেনশনগুলি সক্ষম করতে পারে৷ এক্সটেনশন লাইব্রেরি: পরবর্তী, আসুন এই উপাদানগুলির প্রতিটি পরীক্ষা করা যাক। সার্ভার SDK প্রোফাইল পরিষেবা এবং ম্যাচমেকিংয়ের মতো কিছু পরিষেবার জন্য গেম-নির্দিষ্ট ব্যবসায়িক যুক্তি প্রয়োজন। এটি মিটমাট করার জন্য, আমরা এই পরিষেবাগুলিকে লাইব্রেরি হিসাবে বিতরণ করার জন্য ডিজাইন করেছি৷ তারপরে এই লাইব্রেরিগুলির উপরে তৈরি করে, বিকাশকারীরা এমন অ্যাপ্লিকেশন তৈরি করতে পারে যা কমান্ড হ্যান্ডলার, ম্যাচমেকিং লজিক এবং অন্যান্য প্রকল্প-নির্দিষ্ট উপাদানগুলিকে অন্তর্ভুক্ত করে। এই পদ্ধতিটি একটি ASP.NET অ্যাপ্লিকেশন তৈরির সাথে সাদৃশ্যপূর্ণ, যেখানে ফ্রেমওয়ার্ক নিম্ন-স্তরের HTTP প্রোটোকল কার্যকারিতা প্রদান করে, এদিকে, বিকাশকারী ব্যবসায়িক যুক্তি ধারণ করে এমন কন্ট্রোলার এবং মডেল তৈরিতে ফোকাস করতে পারে। উদাহরণস্বরূপ, ধরা যাক আমরা গেমের মধ্যে ব্যবহারকারীর নাম পরিবর্তন করার ক্ষমতা যোগ করতে চাই। এটি করার জন্য, প্রোগ্রামারদের একটি কমান্ড ক্লাস লিখতে হবে যাতে এই কমান্ডের জন্য নতুন ব্যবহারকারীর নাম এবং একটি হ্যান্ডলার অন্তর্ভুক্ত থাকে। এখানে একটি ChangeNameCommand এর একটি উদাহরণ: public class ChangeNameCommand : ICommand { public string Name { get; set; } } এই কমান্ড হ্যান্ডলারের একটি উদাহরণ: class ChangeNameCommandHandler : ICommandHandler<ChangeNameCommand> { private IProfile Profile { get; } public ChangeNameCommandHandler(IProfile profile) { Profile = profile; } public void Handle(ICommandContext context, ChangeNameCommand command) { Profile.Name = command.Name; } } এই উদাহরণে, হ্যান্ডলারকে অবশ্যই একটি আইপ্রোফাইল বাস্তবায়নের সাথে শুরু করতে হবে, যা নির্ভরতা ইনজেকশনের মাধ্যমে স্বয়ংক্রিয়ভাবে পরিচালনা করা হয়। কিছু মডেল, যেমন Iprofile, IWallet, এবং IInventory, অতিরিক্ত পদক্ষেপ ছাড়াই বাস্তবায়নের জন্য উপলব্ধ। যাইহোক, এই মডেলগুলি তাদের বিমূর্ত প্রকৃতির কারণে কাজ করার জন্য খুব সুবিধাজনক নাও হতে পারে, ডেটা সরবরাহ করে এবং যুক্তিগুলি গ্রহণ করে যা নির্দিষ্ট প্রকল্পের প্রয়োজন অনুসারে তৈরি নয়। জিনিসগুলিকে সহজ করার জন্য, প্রকল্পগুলি তাদের নিজস্ব ডোমেন মডেলগুলিকে সংজ্ঞায়িত করতে পারে, হ্যান্ডলারদের অনুরূপভাবে তাদের নিবন্ধন করতে পারে এবং প্রয়োজন অনুসারে কনস্ট্রাক্টরগুলিতে তাদের ইনজেক্ট করতে পারে। ডেটা নিয়ে কাজ করার সময় এই পদ্ধতিটি আরও উপযোগী এবং সুবিধাজনক অভিজ্ঞতার জন্য অনুমতি দেয়। এখানে একটি ডোমেন মডেলের একটি উদাহরণ: public class WRProfile { public readonly IProfile Raw; public WRProfile(IProfile profile) { Raw = profile; } public int Level { get => Raw.Attributes["level"].AsInt(); set => Raw.Attributes["level"] = value; } } ডিফল্টরূপে, প্লেয়ার প্রোফাইলে লেভেল প্রপার্টি থাকে না। যাইহোক, একটি প্রকল্প-নির্দিষ্ট মডেল তৈরি করে, এই ধরনের সম্পত্তি যোগ করা যেতে পারে এবং কেউ সহজেই কমান্ড হ্যান্ডলারগুলিতে প্লেয়ার-স্তরের তথ্য পড়তে বা পরিবর্তন করতে পারে। ডোমেন মডেল ব্যবহার করে একটি কমান্ড হ্যান্ডলারের একটি উদাহরণ: class LevelUpCommandHandler : ICommandHandler<LevelUpCommand> { private WRProfile Profile { get; } public LevelUpCommandHandler(WRProfile profile) { Profile = profile; } public void Handle(ICommandContext context, LevelUpCommand command) { Profile.Level += 1; } } এই কোডটি স্পষ্টভাবে দেখায় যে একটি নির্দিষ্ট গেমের ব্যবসায়িক যুক্তি অন্তর্নিহিত পরিবহন বা ডেটা স্টোরেজ স্তরগুলি থেকে উত্তাপিত। এই বিমূর্ততা প্রোগ্রামারদের লেনদেন, রেসের অবস্থা, বা অন্যান্য সাধারণ ব্যাকএন্ড সমস্যা সম্পর্কে চিন্তা না করেই মূল গেম মেকানিক্সের উপর ফোকাস করতে দেয়। আরও এখনও, সিঙ্গুলারিটি গেমের যুক্তি বাড়ানোর জন্য ব্যাপক নমনীয়তা সরবরাহ করে। প্লেয়ারের প্রোফাইল হল "কী-টাইপড ভ্যালু" জোড়ার একটি সংগ্রহ, যা গেম ডিজাইনারদের সহজেই যেকোন বৈশিষ্ট্য যোগ করতে সক্ষম করে, ঠিক যেমনটি তারা কল্পনা করে। প্রোফাইলের বাইরে, সিঙ্গুলারিটিতে প্লেয়ার সত্তা নমনীয়তা বজায় রাখার জন্য ডিজাইন করা বেশ কিছু প্রয়োজনীয় উপাদান নিয়ে গঠিত। উল্লেখযোগ্যভাবে, এর মধ্যে একটি মানিব্যাগ রয়েছে যা এর মধ্যে থাকা প্রতিটি মুদ্রার পরিমাণ ট্র্যাক করে এবং সেইসাথে প্লেয়ারের আইটেম তালিকাভুক্ত একটি তালিকা। মজার বিষয় হল, সিঙ্গুলারিটির আইটেমগুলি প্রোফাইলের মতোই বিমূর্ত সত্তা; প্রতিটি আইটেমের একটি অনন্য শনাক্তকারী এবং কী-টাইপ করা মান জোড়ার একটি সেট রয়েছে। সুতরাং, একটি আইটেম অগত্যা একটি বাস্তব বস্তু যেমন একটি অস্ত্র, পোশাক, বা গেম বিশ্বের সম্পদ হতে হবে না. পরিবর্তে, এটি খেলোয়াড়দের জন্য অনন্যভাবে জারি করা যেকোনো সাধারণ বিবরণকে উপস্থাপন করতে পারে, যেমন একটি অনুসন্ধান বা অফার। নিম্নলিখিত বিভাগে, আমি একটি নির্দিষ্ট গেম প্রকল্পের মধ্যে এই ধারণাগুলি কীভাবে প্রয়োগ করা হয় তা বিস্তারিত জানাব। সিঙ্গুলারিটির একটি মূল পার্থক্য হল যে আইটেমগুলি ব্যালেন্স শীটে একটি সাধারণ বিবরণের একটি রেফারেন্স সংরক্ষণ করে। যদিও এই বিবরণটি স্থির থাকে, জারি করা পৃথক আইটেমের বৈশিষ্ট্যগুলি পরিবর্তিত হতে পারে। উদাহরণস্বরূপ, খেলোয়াড়দের অস্ত্রের স্কিন পরিবর্তন করার ক্ষমতা দেওয়া যেতে পারে। উপরন্তু, প্লেয়ার ডেটা স্থানান্তর করার জন্য আমাদের কাছে শক্তিশালী বিকল্প রয়েছে। প্রথাগত ব্যাকএন্ড ডেভেলপমেন্টে, ডাটাবেস স্কিমা প্রায়ই ব্যবসায়িক যুক্তির সাথে শক্তভাবে মিলিত হয় এবং একটি সত্তার বৈশিষ্ট্যের পরিবর্তনের জন্য সাধারণত সরাসরি স্কিমা পরিবর্তনের প্রয়োজন হয়। যাইহোক, ঐতিহ্যগত পদ্ধতিটি সিঙ্গুলারিটির জন্য অনুপযুক্ত কারণ ফ্রেমওয়ার্কটিতে খেলোয়াড় সত্তার সাথে যুক্ত ব্যবসায়িক বৈশিষ্ট্য সম্পর্কে সচেতনতার অভাব রয়েছে এবং গেম ডেভেলপমেন্ট টিমের ডাটাবেসে সরাসরি অ্যাক্সেসের অভাব রয়েছে। পরিবর্তে, মাইগ্রেশনগুলিকে কমান্ড হ্যান্ডলার হিসাবে ডিজাইন এবং নিবন্ধিত করা হয় যা সরাসরি সংগ্রহস্থলের মিথস্ক্রিয়া ছাড়াই কাজ করে। যখন একটি প্লেয়ার সার্ভারের সাথে সংযোগ করে, তখন তাদের ডেটা ডাটাবেস থেকে আনা হয়। যদি সার্ভারে নিবন্ধিত কোনো মাইগ্রেশন এখনও এই প্লেয়ারে প্রয়োগ করা না হয়, তবে সেগুলি কার্যকর করা হয় এবং আপডেট করা অবস্থা ডাটাবেসে আবার সংরক্ষিত হয়। প্রয়োগকৃত স্থানান্তরের তালিকাটি প্লেয়ারের সম্পত্তি হিসাবেও সংরক্ষণ করা হয়, এবং এই পদ্ধতির আরেকটি উল্লেখযোগ্য সুবিধা রয়েছে: এটি সময়ের সাথে সাথে মাইগ্রেশনগুলিকে স্তব্ধ হতে দেয়। এটি আমাদের ডাউনটাইম এবং পারফরম্যান্স সংক্রান্ত সমস্যাগুলি এড়াতে দেয় যা অন্যথায় ব্যাপক ডেটা পরিবর্তনের কারণ হতে পারে, যেমন সমস্ত প্লেয়ার রেকর্ডে একটি নতুন সম্পত্তি যোগ করার সময় এবং এটিকে একটি ডিফল্ট মান সেট করার সময়। ক্লায়েন্ট SDK সিঙ্গুলারিটি ব্যাকএন্ড ইন্টারঅ্যাকশনের জন্য একটি সহজবোধ্য ইন্টারফেস অফার করে, প্রকল্প দলগুলিকে প্রোটোকল বা নেটওয়ার্ক যোগাযোগ প্রযুক্তির সমস্যাগুলি নিয়ে চিন্তা না করেই গেমের বিকাশে ফোকাস করার অনুমতি দেয়। (এটি বলেছে, SDK প্রয়োজনে প্রকল্প-নির্দিষ্ট কমান্ডের জন্য ডিফল্ট সিরিয়ালাইজেশন পদ্ধতিগুলিকে ওভাররাইড করার নমনীয়তা প্রদান করে।) SDK API এর সাথে সরাসরি ইন্টারঅ্যাকশন সক্ষম করে, তবে এটিতে একটি মোড়কও রয়েছে যা রুটিন কাজগুলিকে স্বয়ংক্রিয় করে। উদাহরণস্বরূপ, প্রোফাইল পরিষেবাতে একটি কমান্ড কার্যকর করা ইভেন্টের একটি সেট তৈরি করে যা প্লেয়ারের প্রোফাইলে পরিবর্তনগুলি নির্দেশ করে। ক্লায়েন্ট প্রোফাইলের বর্তমান সংস্করণ বজায় রাখে তা নিশ্চিত করে র্যাপার স্থানীয় রাজ্যে এই ঘটনাগুলি প্রয়োগ করে। এখানে একটি কমান্ড কলের একটি উদাহরণ: var result = _sandbox.ExecSync(new LevelUpCommand()) রেডিমেড মাইক্রোসার্ভিস সিঙ্গুলারিটির মধ্যে বেশিরভাগ পরিষেবা বহুমুখী হওয়ার জন্য ডিজাইন করা হয়েছে এবং নির্দিষ্ট প্রকল্পগুলির জন্য কাস্টমাইজেশনের প্রয়োজন নেই। এই পরিষেবাগুলি পূর্ব-নির্মিত অ্যাপ্লিকেশন হিসাবে বিতরণ করা হয় এবং বিভিন্ন গেম জুড়ে ব্যবহার করা যেতে পারে। প্রস্তুত-তৈরি পরিষেবাগুলির স্যুটে রয়েছে: ক্লায়েন্ট অনুরোধের জন্য একটি গেটওয়ে একটি প্রমাণীকরণ পরিষেবা সেটিংস এবং ব্যালেন্স টেবিল পার্সিং এবং স্টোর করার জন্য একটি পরিষেবা একটি অনলাইন স্থিতি পরিষেবা একটি বন্ধু সেবা একটি লিডারবোর্ড পরিষেবা কিছু পরিষেবা প্ল্যাটফর্মের জন্য মৌলিক এবং অবশ্যই স্থাপন করা উচিত, যেমন প্রমাণীকরণ পরিষেবা এবং গেটওয়ে৷ অন্যগুলি ঐচ্ছিক, যেমন বন্ধুদের পরিষেবা এবং লিডারবোর্ড, এবং গেমগুলির পরিবেশ থেকে বাদ দেওয়া যেতে পারে যেগুলির প্রয়োজন নেই৷ আমি পরে প্রচুর পরিসেবা পরিচালনার সাথে সম্পর্কিত সমস্যাগুলি স্পর্শ করব, কিন্তু আপাতত, ঐচ্ছিক পরিষেবাগুলি ঐচ্ছিক থাকা উচিত তা জোর দেওয়া অপরিহার্য। পরিষেবার সংখ্যা বাড়ার সাথে সাথে নতুন প্রকল্পগুলির জন্য জটিলতা এবং অনবোর্ডিং থ্রেশহোল্ডও বৃদ্ধি পায়। এক্সটেনশন লাইব্রেরি যদিও সিঙ্গুলারিটির মূল কাঠামোটি বেশ সক্ষম, উল্লেখযোগ্য বৈশিষ্ট্যগুলি মূল পরিবর্তন না করেই প্রকল্প দলগুলি দ্বারা স্বাধীনভাবে প্রয়োগ করা যেতে পারে। যখন কার্যকারিতা একাধিক প্রকল্পের জন্য সম্ভাব্য উপকারী হিসাবে চিহ্নিত করা হয়, তখন এটি ফ্রেমওয়ার্ক দল দ্বারা বিকাশ করা যেতে পারে এবং পৃথক এক্সটেনশন লাইব্রেরি হিসাবে প্রকাশ করা যেতে পারে। এই লাইব্রেরিগুলিকে তখন একত্রিত করা যায় এবং ইন-গেম কমান্ড হ্যান্ডলার ব্যবহার করা যায়। কিছু উদাহরণ বৈশিষ্ট্য যা এখানে প্রযোজ্য হতে পারে তা হল অনুসন্ধান এবং অফার। মূল কাঠামোর দৃষ্টিকোণ থেকে, এই সত্তাগুলি কেবল খেলোয়াড়দের জন্য নির্ধারিত আইটেম। যাইহোক, এক্সটেনশন লাইব্রেরিগুলি এই আইটেমগুলিকে নির্দিষ্ট বৈশিষ্ট্য এবং আচরণের সাথে আবদ্ধ করতে পারে, সেগুলিকে অনুসন্ধান বা অফারে রূপান্তরিত করতে পারে। এই ক্ষমতাটি আইটেমের বৈশিষ্ট্যগুলির গতিশীল পরিবর্তনের অনুমতি দেয়, অনুসন্ধানের অগ্রগতির ট্র্যাকিং সক্ষম করে বা প্লেয়ারের কাছে একটি অফার উপস্থাপনের শেষ তারিখ রেকর্ড করে। এখন পর্যন্ত ফলাফল আমাদের সাম্প্রতিক বিশ্বব্যাপী উপলব্ধ গেমগুলির একটি, লিটল বিগ রোবট-এ সিঙ্গুলারিটি সফলভাবে প্রয়োগ করা হয়েছে এবং এটি ক্লায়েন্ট ডেভেলপারদের সার্ভারের লজিক নিজেরাই পরিচালনা করার ক্ষমতা দিয়েছে। উপরন্তু, আমরা এমন প্রোটোটাইপ তৈরি করতে সক্ষম হয়েছি যা প্ল্যাটফর্ম টিমের সরাসরি সহায়তার প্রয়োজন ছাড়াই বিদ্যমান কার্যকারিতা ব্যবহার করে। যাইহোক, এই সর্বজনীন সমাধান তার চ্যালেঞ্জ ছাড়া নয়। বৈশিষ্ট্যের সংখ্যা যেমন প্রসারিত হয়েছে, তেমনি প্ল্যাটফর্মের সাথে ইন্টারঅ্যাক্ট করার জটিলতাও রয়েছে। এককতা একটি সাধারণ টুল থেকে একটি পরিশীলিত, জটিল সিস্টেমে বিকশিত হয়েছে—কিছু উপায়ে একটি মৌলিক পুশ-বোতাম ফোন থেকে সম্পূর্ণ বৈশিষ্ট্যযুক্ত স্মার্টফোনে রূপান্তরের অনুরূপ। যদিও সিঙ্গুলারিটি ডেভেলপারদের ডাটাবেস এবং নেটওয়ার্ক যোগাযোগের জটিলতায় ডুব দেওয়ার প্রয়োজনীয়তা হ্রাস করেছে, এটি তার নিজস্ব শেখার বক্ররেখাও চালু করেছে। বিকাশকারীদের এখন সিঙ্গুলারিটির সূক্ষ্মতা বুঝতে হবে, যা একটি উল্লেখযোগ্য পরিবর্তন হতে পারে। ডেভেলপার থেকে শুরু করে অবকাঠামো প্রশাসক পর্যন্ত লোকেরা চ্যালেঞ্জের সম্মুখীন হয়। এই পেশাদারদের প্রায়ই পোস্টগ্রেস এবং কাফকার মতো সুপরিচিত সমাধান স্থাপন এবং রক্ষণাবেক্ষণে গভীর দক্ষতা থাকে। যাইহোক, সিঙ্গুলারিটি একটি অভ্যন্তরীণ পণ্য, যার প্রয়োজনে তারা নতুন দক্ষতা অর্জন করে: তাদের সিঙ্গুলারিটির ক্লাস্টারগুলির জটিলতাগুলি শিখতে হবে, প্রয়োজনীয় এবং ঐচ্ছিক পরিষেবাগুলির মধ্যে পার্থক্য করতে হবে এবং কোন মেট্রিকগুলি পর্যবেক্ষণের জন্য গুরুত্বপূর্ণ তা বুঝতে হবে। যদিও এটি সত্য যে একটি কোম্পানির মধ্যে, বিকাশকারীরা সর্বদা কিছু পরামর্শের জন্য প্ল্যাটফর্মের নির্মাতাদের কাছে পৌঁছাতে পারে, তবে এই প্রক্রিয়াটি অনিবার্যভাবে সময় দাবি করে। আমাদের লক্ষ্য যতটা সম্ভব প্রবেশের বাধা কমিয়ে আনা। এটি অর্জনের জন্য প্রতিটি নতুন বৈশিষ্ট্যের জন্য ব্যাপক ডকুমেন্টেশনের প্রয়োজন হয়, যা উন্নয়নকে ধীর করে দিতে পারে, কিন্তু তবুও প্ল্যাটফর্মের দীর্ঘমেয়াদী সাফল্যে একটি বিনিয়োগ হিসাবে বিবেচিত হয়। অধিকন্তু, সিস্টেমের নির্ভরযোগ্যতা নিশ্চিত করার জন্য শক্তিশালী ইউনিট এবং ইন্টিগ্রেশন পরীক্ষার কভারেজ অপরিহার্য। সিঙ্গুলারিটি স্বয়ংক্রিয় পরীক্ষার উপর অনেক বেশি নির্ভর করে কারণ ম্যানুয়াল পরীক্ষার জন্য আলাদা গেমের দৃষ্টান্ত বিকাশের প্রয়োজন হবে, যা অবাস্তব। স্বয়ংক্রিয় পরীক্ষাগুলি বিশাল সংখ্যাগরিষ্ঠ-অর্থাৎ, 99% ত্রুটি ধরতে পারে। যাইহোক, সর্বদা একটি ছোট শতাংশ সমস্যা রয়েছে যা শুধুমাত্র নির্দিষ্ট গেম পরীক্ষার সময় স্পষ্ট হয়ে ওঠে। এটি প্রকাশের সময়রেখাকে প্রভাবিত করতে পারে কারণ সিঙ্গুলারিটি দল এবং প্রকল্প দলগুলি প্রায়শই অ্যাসিঙ্ক্রোনাসভাবে কাজ করে। অনেক আগে লেখা কোডে একটি ব্লকিং এরর পাওয়া যেতে পারে এবং প্ল্যাটফর্ম ডেভেলপমেন্ট টিম অন্য একটি গুরুত্বপূর্ণ কাজের সাথে জড়িত হতে পারে। (এই চ্যালেঞ্জটি এককতার জন্য অনন্য নয় এবং কাস্টম ব্যাকএন্ড বিকাশেও ঘটতে পারে।) আরেকটি উল্লেখযোগ্য চ্যালেঞ্জ হল সিঙ্গুলারিটি ব্যবহার করে এমন সমস্ত প্রকল্প জুড়ে আপডেট পরিচালনা করা। সাধারণত, একটি ফ্ল্যাগশিপ প্রকল্প রয়েছে যা বৈশিষ্ট্য অনুরোধ এবং বর্ধিতকরণের একটি ধ্রুবক প্রবাহের সাথে কাঠামোর বিকাশকে চালিত করে। এই প্রকল্পের দলের সাথে মিথস্ক্রিয়া ঘনিষ্ঠ হয়; আমরা তাদের চাহিদা বুঝতে পারি এবং কীভাবে তারা তাদের সমস্যা সমাধানের জন্য আমাদের প্ল্যাটফর্ম ব্যবহার করতে পারে। যদিও কিছু ফ্ল্যাগশিপ প্রজেক্ট ফ্রেমওয়ার্ক টিমের সাথে ঘনিষ্ঠভাবে জড়িত, প্রাথমিক বিকাশের পর্যায়ে অন্যান্য গেমগুলি প্রায়শই স্বাধীনভাবে কাজ করে, শুধুমাত্র বিদ্যমান কার্যকারিতা এবং ডকুমেন্টেশনের উপর নির্ভর করে। এটি কখনও কখনও অপ্রয়োজনীয় বা সাবঅপ্টিমাল সমাধানের দিকে নিয়ে যেতে পারে, কারণ ডেভেলপাররা ডকুমেন্টেশন ভুল বুঝতে পারে বা উপলব্ধ বৈশিষ্ট্যগুলি অপব্যবহার করতে পারে। এটি প্রশমিত করার জন্য, উপস্থাপনা, মিটআপ এবং দলের আদান-প্রদানের মাধ্যমে জ্ঞান ভাগাভাগি সহজতর করা অত্যন্ত গুরুত্বপূর্ণ, যদিও এই ধরনের উদ্যোগগুলির জন্য যথেষ্ট সময় বিনিয়োগের প্রয়োজন হয়। ভবিষ্যৎ এককতা ইতিমধ্যেই আমাদের গেম জুড়ে এর মূল্য প্রদর্শন করেছে এবং আরও বিকশিত হওয়ার জন্য প্রস্তুত। যদিও আমরা নতুন বৈশিষ্ট্যগুলি প্রবর্তন করার পরিকল্পনা করছি, আমাদের প্রাথমিক ফোকাস এই মুহূর্তে নিশ্চিত করা যে এই বর্ধনগুলি প্রকল্প দলগুলির জন্য প্ল্যাটফর্মের ব্যবহারযোগ্যতাকে জটিল করে না। এটি ছাড়াও, প্রবেশের বাধা কমানো, স্থাপনা সহজ করা, বিশ্লেষণের ক্ষেত্রে নমনীয়তা যোগ করা, প্রকল্পগুলিকে তাদের সমাধানগুলিকে সংযুক্ত করার অনুমতি দেওয়া প্রয়োজন। এটি দলের জন্য একটি চ্যালেঞ্জ, কিন্তু আমরা বিশ্বাস করি এবং অনুশীলনে দেখতে পাই যে আমাদের সমাধানে বিনিয়োগ করা প্রচেষ্টা অবশ্যই সম্পূর্ণরূপে পরিশোধ করবে!
