কীভাবে প্লেয়ার এবং ওয়ার্ল্ডের মধ্যে বিজ্ঞপ্তি নির্ভরতা এড়ানো যায়?

60

আমি একটি 2 ডি গেম নিয়ে কাজ করছি যেখানে আপনি উপরে, নীচে, বাম এবং ডানদিকে যেতে পারেন। আমার কাছে মূলত দুটি গেম লজিক অবজেক্ট রয়েছে:

খেলোয়াড়: বিশ্বের সাথে সম্পর্কিত একটি অবস্থান আছে
বিশ্ব: মানচিত্র এবং প্লেয়ার আঁকুন

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

খেলোয়াড়ের দেয়াল দিয়ে চলাচল করা অসম্ভব হয়ে উঠতে আমি এখন সংঘর্ষ সনাক্তকরণ যুক্ত করতে চাই।

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

আমার সবচেয়ে ভাল বিকল্প কি? বা একটি বৃত্তাকার নির্ভরতা এড়ানো কি মূল্যহীন?

collision-detection architecture objects

— futlib
সূত্র

4

আপনি কেন মনে করেন যে একটি বিজ্ঞপ্তি নির্ভরতা একটি খারাপ জিনিস? stackoverflow.com/questions/1897537/...

— Fuhrmanator

@ ফুহরম্যানেটর আমি মনে করি না যে তারা সাধারণত একটি খারাপ জিনিস, তবে আমার পরিচয় দেওয়ার জন্য আমার কোডগুলিতে কিছুটা জটিল করতে হবে।

— futlib

আমি আমাদের সামান্য আলোচনা সম্পর্কে একটি পোস্ট পাগল করছি, যদিও নতুন কিছু নয়: yannbane.com/2012/11/… ...

— jcora

61

বিশ্বকে নিজেরাই আঁকতে হবে না; রেন্ডারারের উচিত বিশ্বকে আঁকতে। প্লেয়ার নিজেই আঁকা উচিত নয়; রেন্ডারারের প্লেয়ারকে বিশ্বের সাথে সম্পর্কিত হওয়া উচিত।

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

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

— Liosan
সূত্র

25

@ স্নাপ 5 - "ক্যান" এবং "করা উচিত" এর মধ্যে পার্থক্য রয়েছে। যে কোনও কিছু আঁকতে পারে - তবে আপনার যখন অঙ্কনের সাথে সম্পর্কিত কোডটি পরিবর্তন করতে হবে তখন "রেন্ডারার" শ্রেণিতে যাওয়া "আঁকানো" কোনও কিছু অনুসন্ধান করার চেয়ে আরও সহজ। "সংমিশ্রণ" এর আরও একটি শব্দ "সংমিশ্রণে অবসন্ন হওয়া"

— Nate

16

@ মিঃ বিস্ট, না, তিনি নন। তিনি ভাল ডিজাইনের পক্ষে পরামর্শ দিচ্ছেন। একটি শ্রেণীর এক ত্রুটিযুক্ত সবকিছুতে ক্র্যামিং করা কোনও অর্থবোধ করে না।

— jcora

23

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

— লিওসান

12

@ স্নাপ 5 প্রোগ্রামারটির জন্য আরও ক্লাস যুক্ত করার বিষয়টি ওভারহেড যুক্ত করে আমার অভিজ্ঞতা প্রায়শই সম্পূর্ণ ভুল wrong আমার মতে তথ্যমূলক নাম এবং ভাল সংজ্ঞায়িত দায়িত্ব সহ 10x100 লাইন ক্লাসগুলি একক 1000 লাইন গড ক্লাসের চেয়ে প্রোগ্রামারটির পক্ষে পড়া সহজ এবং কম ওভারহেড ।

— মার্টিন

7

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

— zzzzBov

35

এখানে একটি সাধারণ রেন্ডারিং ইঞ্জিন কীভাবে এই জিনিসগুলি পরিচালনা করে:

কোনও বস্তু মহাকাশে কোথায় রয়েছে এবং কীভাবে বস্তুটি আঁকবে তার মধ্যে একটি মৌলিক পার্থক্য রয়েছে।

একটি বস্তু অঙ্কন

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

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

দৃশ্য নোডগুলি কীভাবে পরিচালিত হয়? একটি সিন ম্যানেজারের মাধ্যমে । এই শ্রেণিটি আপনার দৃশ্যের প্রতিটি দৃশ্যনোড তৈরি করে এবং ট্র্যাক করে। আপনি এটিকে একটি নির্দিষ্ট সিন নোড (সাধারণত "প্লেয়ার" বা "টেবিল" এর মতো স্ট্রিং নাম দ্বারা চিহ্নিত) বা সমস্ত নোডের একটি তালিকা চাইতে পারেন।
বিশ্বকে আঁকছে

এটি এখনই বেশ সুস্পষ্ট হওয়া উচিত। দৃশ্যের প্রতিটি দৃশ্য নোড দিয়ে কেবল হাঁটুন এবং রেন্ডারারকে এটি সঠিক জায়গায় আঁকুন। আপনি এটিকে রেন্ডারিংয়ের আগে কোনও বস্তুর রুপান্তরকরণ সংরক্ষণ করে সঠিক জায়গায় এটি আঁকতে পারেন।
সংঘর্ষ সনাক্তকরণ

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

তাহলে, খেলোয়াড় কী এবং বিশ্ব কী?

প্লেয়ারটি একটি দৃশ্য নোড সমেত একটি শ্রেণি হতে পারে, যার পরিবর্তে রেন্ডার করার মডেল থাকে। আপনি দৃশ্যের নোডের অবস্থান পরিবর্তন করে প্লেয়ারটি সরিয়ে নিয়েছেন। বিশ্বটি কেবল দৃশ্য পরিচালকের একটি উদাহরণ an এটিতে সমস্ত বস্তু রয়েছে (সিন নোডের মাধ্যমে)। আপনি দৃশ্যের বর্তমান অবস্থাতে প্রশ্ন তৈরি করে সংঘর্ষ সনাক্তকরণ পরিচালনা করেছেন।

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

— rootlocus
সূত্র

+1 - আমি নিজেকে আমার গেম সিস্টেমগুলি এমন কিছু তৈরি করতে দেখেছি এবং এটি বেশ নমনীয় বলে মনে করি।

— সাইফার

+1, দুর্দান্ত উত্তর। আমার নিজের থেকে আরও কংক্রিট এবং বিন্দুতে।

— jcora

+1, আমি এই উত্তরটি থেকে অনেক কিছু শিখেছি এবং এটির একটি অনুপ্রেরণীয় সমাপ্তিও ছিল। ধন্যবাদ @ রূতলোকস

— জোস্লিনম

16

কেন আপনি এড়াতে চান? আপনি যদি পুনঃব্যবহারযোগ্য বর্গ করতে চান তবে বিজ্ঞপ্তি নির্ভরতা এড়ানো উচিত। তবে প্লেয়ার এমন কোনও শ্রেণি নেই যা পুনরায় পুনরায় ব্যবহারযোগ্য হওয়া দরকার। আপনি কি কখনও বিশ্ব ছাড়াই প্লেয়ারটি ব্যবহার করতে চান? সম্ভবত না.

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

ঠিক আছে সম্পাদনা করুন , প্রশ্নের উত্তর দেওয়ার জন্য: আপনি এড়াতে পারবেন যে কলব্যাকগুলি ব্যবহার করে প্লেয়ারকে সংঘর্ষের চেকগুলির জন্য বিশ্ব জানা দরকার:

World::checkForCollisions()
{
  [...]
  foreach(entityA in entityList)
    foreach(entityB in entityList)
      if([... entityA and entityB have collided ...])
         entityA.onCollision(entityB);
}

Player::onCollision(other)
{
  [... react on the collision ...]
}

প্রশ্নে আপনি যে ধরণের পদার্থবিজ্ঞানের বিবরণ দিয়েছেন তা বিশ্ব দ্বারা পরিচালিত হতে পারে যদি আপনি সত্তাগুলির বেগ প্রকাশ করেন:

World::calculatePhysics()
{ 
  foreach(entityA in entityList)
    foreach(entityB in entityList)
    {
      [... move entityA according to its velocity as far as possible ...]
      if([... entityA has collided with the world ...])
         entityA.onWorldCollision();
      [... calculate the movement of entityB in order to know if A has collided with B ...]
      if([... entityA and entityB have collided ...])
         entityA.onCollision(entityB);
    }
}

তবে মনে রাখবেন যে সম্ভবত আপনার সম্ভবত খুব শীঘ্রই বা পরে বিশ্বের নির্ভরতা প্রয়োজন, এটি যখনই আপনার বিশ্বের কার্যকারিতা প্রয়োজন: আপনি জানতে চান নিকটতম শত্রু কোথায়? আপনি জানতে চান পরবর্তী লজটি কতটা দূরে? নির্ভরতা এটি।

— এপিআই-বিস্ট
সূত্র

4

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

— লরেন্ট কুইভিডু

4

-1, এটি অবশ্যই বৃত্তাকার নির্ভরতা না প্রবর্তনের একমাত্র কারণ নয়। এগুলি প্রবর্তন না করে আপনি আপনার সিস্টেমকে প্রসারিত করা এবং পরিবর্তন করা সহজতর করেছেন।

— jcora

4

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

— এপিআই-বিস্ট

3

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

— jcora

1

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

— এপিআই-বিস্ট

13

আপনার বর্তমান ডিজাইনটি সলড ডিজাইনের প্রথম নীতিটির বিপরীতে চলেছে বলে মনে হচ্ছে ।

"একক দায়িত্বের নীতি" নামে পরিচিত এই প্রথম নীতিটি সাধারণত একচেটিয়া, করণীয় সমস্ত জিনিস তৈরি না করে যাতে আপনার নকশাকে সর্বদা আঘাত দেয়।

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

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

এখন, আপনার আসল প্রশ্নের উত্তর দিতে ...

এটি করার অনেকগুলি উপায় রয়েছে এবং এটি হ'ল একমাত্র উপায়:

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

— jcora
সূত্র

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

— মার্কাস ফন ব্রডি

উত্তরাধিকার হিসাবে, বিশ্বকে অবশ্যই কিছু ধরণের জিনিস সম্পর্কে সচেতন হতে হবে, যা সাধারণ উপায়ে বর্ণনা করা যায়। সমস্যাটি এই নয় যে বিশ্বের কেবল প্লেয়ারের একটি রেফারেন্স রয়েছে, তবে এটি সম্ভবত এটি একটি শ্রেণি হিসাবে নির্ভর করে (যেমন ক্ষেত্রগুলি ব্যবহার করুন healthযা কেবলমাত্র এই উদাহরণটি Playerরয়েছে)।

— jcora

আহ, আপনার মানে বিশ্বের প্লেয়ারের কোনও রেফারেন্স নেই, এটির প্রয়োজনে আইটোলিডেবল ইন্টারফেস বাস্তবায়নকারী প্লেয়ারের সাথে একত্রে কিছু জিনিস রয়েছে of

— মার্কাস ভন ব্রডি

2

+1 ভাল উত্তর। তবে: "দয়া করে সমস্ত লোককে অগ্রাহ্য করুন যারা বলেন যে ভাল সফ্টওয়্যার ডিজাইন গুরুত্বপূর্ণ নয়"। সাধারণ. কেউ তা বলেনি।

— লরেন্ট কুইভিডু

2

সম্পাদিত! এটি যাইহোক এক ধরণের অপ্রয়োজনীয় বলে মনে হয়েছিল ...

— jcora

1

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

বিজ্ঞপ্তি সংক্রান্ত রেফারেন্সের ক্ষেত্রে আপনি যা এড়াতে চান তা একে অপরের প্রতি এতটুকু রেফারেন্স নয়, বরং একে অপরকে কোডে স্পষ্টভাবে উল্লেখ করা।

— টম জনসন
সূত্র

1

যখনই দুটি ভিন্ন ধরণের বস্তু একে অপরকে জিজ্ঞাসা করতে পারে। তারা একে অপরের উপর নির্ভর করবে কারণ এর পদ্ধতিগুলি কল করার জন্য তাদের অন্যের রেফারেন্স রাখা প্রয়োজন।

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

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

— Calmarius
সূত্র

0

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

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

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

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

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

— FlintZA
সূত্র

0

অন্যদের বলেছি, আমি মনে করি আপনার Worldএক জিনিস অনেকগুলি করছে: এটা করার চেষ্টা করছে উভয় খেলা ধারণ Map(যা একটি স্বতন্ত্র সত্তা হওয়া উচিত) এবং একটি হতে Rendererএকই সময়ে।

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

তারপর আপনি আরো একটি প্রয়োজন Rendererঅবজেক্ট। আপনি এই বস্তুকে এমন জিনিস তৈরি করতে পারেন Rendererযা উভয়ই রয়েছে GameMap এবং Player(পাশাপাশি Enemies)ও আঁকতে পারে।

— bobobobo
সূত্র

-6

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

বিজ্ঞপ্তি রেফারেন্স দ্বারা সৃষ্ট সমস্যাগুলি কার্যকরভাবে বন্ধ করতে প্লেয়ার অবজেক্টটিকে ধ্বংস করার আগে / এর আগে রেফারেন্সটি ধ্বংস করাও সম্ভব।

— snake5
সূত্র

1

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

— কলমারিয়াস