নেটকোড হ্যান্ডেল করবেন কীভাবে?

Question

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

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

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

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

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

Answer 1

প্রতিক্রিয়াশীলতা উপেক্ষা করুন। একটি ল্যানে, পিং তুচ্ছ নয়। ইন্টারনেটে, 60-100 মিমি রাউন্ড ট্রিপ একটি আশীর্বাদ। ল্যাগ দেবদেবীদের কাছে প্রার্থনা করুন যে আপনি> 3 কে এর স্পাইক পাবেন না। আপনার সফ্টওয়্যারটি সমস্যা হওয়ার জন্য খুব কম সংখ্যক আপডেট / সেকেন্ডে চলতে হবে। আপনি যদি 25 টি আপডেট / সেকেন্ডের জন্য শ্যুট করেন তবে আপনি যখন প্যাকেট পাবেন এবং এতে কাজ করবেন তখন আপনি 40 মিমি সর্বোচ্চ সময় পেয়েছেন। এবং এটি একক থ্রেডেড কেস ...

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

নেটওয়ার্ক সাবসিস্টেম এবং গেম ইঞ্জিনের মধ্যে যে কোনও যোগাযোগের জন্য এবং যে কোনও দুটি সাবসিস্টেমের মধ্যে সেই বিষয়ে মেসেজিং ব্যবহার করুন। ইন্টার-সাবসিস্টেম মেসেজিং স্ট্যান্ড :: তালিকা ব্যবহার করে পয়েন্টার দ্বারা পাস করা ডেটা ব্লবের মতো সহজ হতে পারে।

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

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

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

আপনি যদি আপনার নেটওয়ার্ক সাবসিস্টেমটিকে ইভেন্টগুলি প্রেরণ / গ্রহণের মাধ্যম হিসাবে বিবেচনা করেন তবে সকেটে কেবল recv () কল করার মাধ্যমে আপনি বেশ কয়েকটি সুবিধা পান।

আপনি ব্যান্ডউইথকে অনুকূলিত করতে পারেন, উদাহরণস্বরূপ, 50 টি ছোট বার্তা (দৈর্ঘ্যে 1-32 বাইট) নিয়ে এবং নেটওয়ার্ক সাবসিস্টেমগুলি সেগুলিকে একটি বড় প্যাকেটে প্যাকেজ করতে এবং প্রেরণ করতে পারেন। এটি যদি খুব বড় ব্যাপার হয় তবে প্রেরণের আগে এটি তাদের সংকোচিত করতে পারে। অন্য প্রান্তে, গেম ইঞ্জিনটি পড়ার জন্য কোডটি বৃহত প্যাকেটটিকে আবার 50 টি বিচ্ছিন্ন ইভেন্টগুলিতে সঙ্কুচিত / আনপ্যাক করতে পারে। এই সব স্বচ্ছভাবে ঘটতে পারে।

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

Comments

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

— স্টিভেন লু

হ্যাঁ, এটা সঠিক। স্টেট :: তালিকার সমস্ত কলকে সুরক্ষিত একটি মিউটেক্স।

— প্যাট্রিকবি

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

— স্টিভেন লু

এই অনুভূতিটি কেটে যাবে। আপনি যে বড় পিতলগুলি অর্জন করেছেন তা আপনার সাথে থাকুন।

— ক্রিসই

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

— তহবিল মনিকার লসুইট

Answer 2

নেটওয়ার্ক সকেটগুলি পরিচালনা করার জন্য আমার (খুব কমপক্ষে) একটি আলাদা থ্রেড থাকা দরকার

না আপনি না।

পুরোপুরি একক থ্রেডযুক্ত নেটওয়র্ক গেম তৈরি করার আমার কাছে একটি সম্ভাব্য উপায় ছিল যা হ'ল নন-ব্লকিং সকেটগুলি ব্যবহার করে প্রতিটি ফ্রেম সরবরাহ করার পরে নেটওয়ার্কটি পরীক্ষা করা check তবে এটি পরিষ্কারভাবে অনুকূল নয় কারণ একটি ফ্রেম রেন্ডার করতে সময়টি নেটওয়ার্ক ল্যাগে যুক্ত হয়:

অগত্যা ব্যাপার না। আপনার যুক্তি আপডেট হয় কখন? আপনি যদি এটি দিয়ে এখনও কিছু না করতে পারেন তবে নেটওয়ার্কটি থেকে ডেটা পাওয়ার খুব একটা পয়েন্ট নেই। একইভাবে আপনার কাছে এখনও কিছু বলার নেই তবে প্রতিক্রিয়া করার সামান্য বিষয় রয়েছে।

উদাহরণস্বরূপ, এটি সার্ভার থেকে একটি রাষ্ট্র আপডেটের সাথে সাথে তাত্ক্ষণিকভাবে একটি এসকে প্যাকেটটি ফেরত পাঠাতে পারে।

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

বেশিরভাগ নেটওয়াক গেমসের জন্য, গেম লুপটি এ জাতীয়ভাবে রাখা সম্ভব:

while 1:
    read_network_messages()
    read_local_input()
    update_world()
    send_network_updates()
    render_world()

আপনি রেন্ডারিং থেকে আপডেটগুলি ডিকুয়াল করতে পারেন, যা অত্যন্ত প্রস্তাবিত, তবে আপনার নির্দিষ্ট প্রয়োজনীয়তা না থাকলে অন্য সমস্ত কিছু সেই সরল থাকতে পারে। ঠিক আপনি কী ধরনের খেলা তৈরি করছেন?

Comments

রেন্ডারিং থেকে আপডেট করার সিদ্ধান্ত নেওয়া কেবল উচ্চ প্রস্তাবিত নয়, আপনি যদি কোনও শিটবিহীন ইঞ্জিন চান তবে এটি প্রয়োজন।

— আক্রমণ হাবো

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

— কাইলোটন

Answer 3

তবে এটি স্পষ্টতই অনুকূল নয় কারণ একটি ফ্রেম রেন্ডার করতে সময়টি নেটওয়ার্কের পিছনে যুক্ত হয়: বর্তমান ফ্রেমের রেন্ডার (এবং গেম যুক্তি) শেষ না হওয়া পর্যন্ত নেটওয়ার্কের মাধ্যমে আসা বার্তাগুলি অপেক্ষা করতে হবে।

এটি মোটেও সত্য নয়। বার্তাটি নেটওয়ার্কের উপরে চলে যায় যখন রিসিভারটি বর্তমান ফ্রেমটিকে উপস্থাপন করে। নেটওয়ার্ক ল্যাগটি ক্লায়েন্টের পক্ষের পুরো সংখ্যক ফ্রেমে আটকে রয়েছে; হ্যাঁ- তবে যদি ক্লায়েন্টের এত কম এফপিএস থাকে যে এটি একটি বড় বিষয়, তবে তাদের বড় সমস্যা রয়েছে।

Answer 4

নেটওয়ার্ক যোগাযোগ ব্যাচ করা উচিত। প্রতিটি গেমের টিক পাঠানো একক প্যাকেটের জন্য আপনার প্রচেষ্টা করা উচিত (যা প্রায়শই যখন ফ্রেম রেন্ডার করা হয় তবে সত্যই স্বাধীন হওয়া উচিত)।

আপনার গেম সত্তা নেটওয়ার্ক সাবসিস্টেম (এনএসএস) এর সাথে কথা বলে। এনএসএস বার্তা, এসি, ইত্যাদি ব্যাচ করে এবং কয়েকটি (আশাকরি একটি) অনুকূল আকারের ইউডিপি প্যাকেটগুলি (সাধারণত 1500 ডলার বাইট) প্রেরণ করে। এনএসএস কেবল একক ইউডিপি প্যাকেট প্রেরণ করার সময় প্যাকেট, চ্যানেল, অগ্রাধিকার, পুনরায় বিক্রয় ইত্যাদি ইমুলেট করে।

মাধ্যমে পড়ুন গেম 'টিউটোরিয়াল উপর শ্রমিক-সর্দার বা শুধু ব্যবহার ENet যা কার্যকরী গ্লেন ফিডলারের এর ধারণা অনেক।

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

Answer 5

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

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