আমি একই সাথে ক্লায়েন্ট এবং সার্ভার উভয়কে কীভাবে দক্ষতার সাথে কোড করব?


15

আমি একটি ক্লায়েন্ট-সার্ভার মডেল ব্যবহার করে আমার গেম কোডিং করছি। সিঙ্গলপ্লেয়ারে খেললে গেমটি একটি স্থানীয় সার্ভার শুরু করে এবং এটির সাথে দূরবর্তী সার্ভারের (মাল্টিপ্লেয়ার) মত ইন্টারেক্ট করে। পৃথক একক প্লেয়ার এবং মাল্টিপ্লেয়ার কোড কোডিং এড়ানোর জন্য আমি এটি করেছি।

আমি সবে কোডিং শুরু করেছি এবং একটি বড় সমস্যার মুখোমুখি হয়েছি। বর্তমানে আমি গেমটি Eclipse এ বিকাশ করছি, সমস্ত গেম ক্লাস প্যাকেজগুলিতে व्यवस्थित করে। তারপরে, আমার সার্ভার কোডে, আমি কেবল ক্লায়েন্ট প্যাকেজগুলির মধ্যে সমস্ত ক্লাস ব্যবহার করি।

সমস্যাটি হ'ল, এই ক্লায়েন্ট ক্লাসগুলির রেন্ডারিংয়ের জন্য নির্দিষ্ট এমন ভেরিয়েবল রয়েছে, যা সম্ভবত কোনও সার্ভারে সঞ্চালিত হবে না।

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


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

আমি মাইন্ড ওয়ারাক্সের সাথে একমত শর্তসাপেক্ষ সংকলন জাভাতে ব্যথা হলেও, এর সমাধান রয়েছে যা বিবেচনা করা উচিত।
সাম होচেভার

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

উত্তর:


23

আপনার রেন্ডারিং কোডটি আপনার গেম যুক্তি থেকে আলাদা রাখতে পছন্দ করা উচিত , কারণ এগুলি পৃথক উদ্বেগ

যদি আপনি আপনার ক্লায়েন্ট / সার্ভার কোড থেকে আপনার রেন্ডারিং কোডটি আলাদা করেন তবে আপনি কয়েকটি সুবিধা পাবেন:

  • ডেডিকেটেড সার্ভার তৈরি করা সহজ হবে, যে কোনও কোড যা রেন্ডার করে তা এক জায়গায় থাকবে।
  • আপনি আপনার updateপর্যায়টি আপনার পর্ব থেকে আলাদা করতে পারেন renderএবং এগুলি বিভিন্ন সময় অনুসারে চালাতে পারেন।
  • আপনি নিশ্চিত করতে পারেন যে আপনার রেন্ডারিং কোডটি constবাগের পরিমাণ হ্রাস করে গেমের স্থিতি পরিবর্তন করে না ।

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

5

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


+1 আমি এটির সাথে একমত হতে চাই। যদি সার্ভারটি কোনও ক্লায়েন্ট চলমান থাকে তবে পৃথক প্রক্রিয়া হিসাবে এটি করা উচিত।
ইঞ্জিনিয়ার

5

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

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.