ক্লায়েন্ট / সার্ভারের রিয়েল-টাইম ভিডিওগেমে কীভাবে দ্রুত কম্পিউটারগুলি ব্যবহার করা যায়


15

আমি সকেট.ইও ব্যবহার করে আমার প্রথম অনলাইন গেমটি তৈরি করছি এবং আমি এটিটি আগার.আইও বা ডাইপ.আইওয়ের মতো একটি রিয়েল-টাইম মাল্টিপ্লেয়ার গেম হতে চাই I'd

তবে আমি কীভাবে সমস্ত কম্পিউটারকে একই গতিতে কাজ করতে পারি তা নির্ধারণের চেষ্টা করার বিষয়টি নিয়ে আমি এড়িয়ে গেছি।

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

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

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

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

আমি কিছু গবেষণা করেছি , তবে আমি যে নিবন্ধগুলি পড়েছি সেগুলিতে বিশেষভাবে কোনও ক্লায়েন্ট অন্যান্য ক্লায়েন্টের তুলনায় দ্রুত আপডেটগুলি প্রেরণ করে তবে কী করবেন তা নির্দিষ্টভাবে মনে হচ্ছে না।

আমার বিশেষ ক্ষেত্রে, আমি দ্রুত কীবোর্ডের গতি আছে এমন লোকদের সাথে व्यवहार করছি (তাদের কম্পিউটার অন্যান্য কম্পিউটারগুলির তুলনায় আরও কীবোর্ড আপডেট পাঠাবে)।

প্রোগ্রামাররা সাধারণত কীভাবে এটি মোকাবেলা করে?


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

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

3
আমি প্রশ্নটি ভুল বুঝে চলেছি, তবে টিক ভিত্তিক ক্লায়েন্ট এবং সার্ভার মডেল ব্যবহার করা সম্ভবত আপনি যা করছেন তা সম্ভবত। গেমদেব.স্ট্যাকেক্সেঞ্জার / প্রশ্নগুলি / ৮১60০৮/২ মূলত আপনি কেবলমাত্র প্রতিটি এক্স পরিমাণ সময় ইনপুট এবং লজিক প্রসেস করেন (সাধারণত 1 / এন সেকেন্ড যেমন 60Hz লজিকের জন্য 1/60)
ক্রিস্টোফার ওয়ার্ট

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

1
আহ, রিয়েল টাইম নেটকোড। গেম বিকাশের সবচেয়ে গভীরতমতমতম স্থান জাহাজে স্বাগতম, সাথী!
টি। সর - মনিকা

উত্তর:


8

আপনার তৃতীয় ধারণাটি এই ধরণের সমস্যার শিল্প সমাধান হিসাবে আমি যা মনে করি তার নিকটতম বলে মনে হচ্ছে।

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

একটি টিক সম্ভবত 1 / এন সেকেন্ড আকারে হতে চলেছে, এন প্রতি সেকেন্ডে টিকের সংখ্যা বা টিক্রেট। আপনার ব্যবহারের ক্ষেত্রে এটি নির্ভর করে এই টিক্রেট খুব ঘন ঘন বা খুব কমই হতে পারে। আমার ব্যক্তিগত পরামর্শটি হ'ল 60 টি টিক্স / সেকেন্ডের উপরে টিক্রেট এড়ানো উচিত যদি না আপনি নিশ্চিত হন যে আপনার আরও প্রয়োজন। আপনি সম্ভবত না :)

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

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

রেফারেন্সের জন্য, গেম সার্ভার এবং মাল্টিপ্লেয়ার নেটওয়ার্কিংয়ের নিজের বোঝার পরিপূরক করার জন্য এখানে একটি ভাল লিঙ্ক

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


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

0

নিম্নলিখিত সিস্টেমটি নিশ্চিত করে যে কোনও ক্লায়েন্ট এবং সার্ভার যে কোনও সময়ে প্রায় একই গেমের অবস্থা ভাগ করে।

উভয় ক্লায়েন্ট এবং সার্ভারে গেমের অবস্থা পান।

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

যদি তা হয় তবে প্রেরক ক্লায়েন্টকে চালিত না করে সার্ভারে কমান্ডটি প্রেরণ করুন।

যখন সার্ভার কমান্ডটি গ্রহণ করবে, গেমটির বৈধতা আছে কিনা তার অবস্থার দিকে তাকান।

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

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

তারিখটি যদি আগের হয়, আপনি আগের ধাপে সমস্যা পেয়েছেন, এটি ঠিক করুন। তারিখটি কিছু না করার পরে কিছু না করা থাকলে, তারিখটি যদি দীর্ঘ হয় তবে ক্লায়েন্টটি সিঙ্কের বাইরে চলে যায়, অর্থাৎ ক্লায়েন্টটি খুব বেশি পিছনে থাকে।

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

ক্লায়েন্টগুলিতে, কেবলমাত্র যখন কিছুই করার বাকি নেই তখন কেবলমাত্র স্ক্রিনে জিনিস সরবরাহ করুন। সাধারণ পরিস্থিতিতে রেন্ডার ফাংশনটি কেবল বর্তমান গেমের স্টেটকে ইনপুট হিসাবে গ্রহণ করে।

এর উপরে আপনি ভবিষ্যদ্বাণীমূলক সিস্টেমগুলি ব্যবহার করে, কমান্ডগুলি গোষ্ঠীকরণ করে, কেবলমাত্র ডিফএস ইত্যাদি রেন্ডার করে অনেকগুলি অনুকূল করতে পারেন ...

বৈধকরণ পৃথক হওয়া উচিত, উদাহরণস্বরূপ, কমান্ড অনুরোধ / সময় ইউনিট সীমাবদ্ধ করা সার্ভারের উপর নির্ভর করে।


0

আপনি যে লাইব্রেরি বা পরিবেশ ব্যবহার করছেন সেটি সমস্যা কিনা তা আমি জানি না তবে আমি মনে করি আপনি এটি সম্পূর্ণরূপে ভুল করছেন।

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

দ্রুত কীবোর্ড গতি

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

অন্যথায়, প্রশ্নটি বেশ বিস্তৃত বলে মনে হচ্ছে এবং আপনার "সাধারণ" সমস্যাটি তৈরি করার চেষ্টা না করে আপনার একক প্রকৃত সমস্যার দিকে মনোনিবেশ করা উচিত that


দ্রুত কীবোর্ডের গতি টাইপিংয়ের বিষয়ে নয়, এটি যদি আপনি "এগিয়ে চলুন" কী বা "শ্যুট" কী ধরে রাখেন তবে কতটি আদেশ পাঠানো যায়।
gbjbaanb

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

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

@gbjbaanb নং এটি ভুল। সার্ভার জানে "প্লেয়ার এগিয়ে চলেছে" এবং তারপরে দ্বিতীয় প্রতি 1/60 তম এটি সমস্ত খেলোয়াড়ের অবস্থানগুলি আপডেট করে যদি তারা এগিয়ে চলেছে তার উপর ভিত্তি করে updates সমস্ত গেমস এভাবেই কাজ করে। আপডেট লুপটি গেমের সমস্ত সত্তার জন্য একই এবং আপডেটগুলি ইউআই থেকে প্রাপ্ত ইভেন্টের ভিত্তিতে নয়।
ইউফোরিক

1
না, ওপি-র বোঝাপড়াটি এটাই ছিল না, সে কারণেই তিনি এটি জিজ্ঞাসা করেছিলেন এবং যে কারণে আপনি বলেছিলেন "আমি এমনকি তার অর্থ কী তাও জানি না"। আপনি যদি ওপিএসের অবস্থানটি বুঝতে পারেন তবে তার প্রশ্নটি বোধগম্য হয়। ওপি যদি ক্লায়েন্টের কাছ থেকে কীভাবে দ্রুত ইভেন্টগুলি সরবরাহ করা হয় তার উপর ভিত্তি করে গেম লুপের সাথে কাজ করার জন্য যদি তার গেমটি কোড করে থাকে তবে সে তার সম্পর্কে যা জিজ্ঞাসা করছে - আপনি ওপি আসলে যা জিজ্ঞাসা করছেন তাতে কিছু অনুমানের গেম ডিজাইন প্রয়োগ করা ভুল, তার নকশা বেশিরভাগ মানের দ্বারা ভুল কিনা তা নির্বিশেষে।
gbjbaanb
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.