আপডেট (পুনরুদ্ধার)
যেহেতু আমি বরং একটি ভার্জিক উত্তর লিখেছি, এখানে এটি সমস্ত কীভাবে এটিকে ফুটিয়ে তোলে:
- নেমস্পেসগুলি ভাল, যখনই এটি বোধগম্য হয় এগুলি ব্যবহার করুন
- ব্যবহার
inGameIOএবং playerIOক্লাসগুলি সম্ভবত এসআরপি লঙ্ঘন করবে। এর অর্থ সম্ভবত আপনি যুক্তিকে যুক্তি দিয়ে আইও কে পরিচালনা করার পদ্ধতিটি সংযুক্ত করছেন।
- হ্যান্ডলার ক্লাসগুলি দ্বারা ব্যবহৃত (বা কখনও কখনও ভাগ করা হয়) কয়েকটি জেনেরিক আইও ক্লাস থাকে। এই হ্যান্ডলার ক্লাসগুলি তখন কাঁচের ইনপুটটিকে এমন একটি ফর্ম্যাটে অনুবাদ করবে যা আপনার অ্যাপ্লিকেশন যুক্তিটি বুঝতে পারে।
- আউটপুটটির ক্ষেত্রেও একই কাজ করা যায়: এটি মোটামুটি জেনেরিক ক্লাস দ্বারা করা যেতে পারে তবে কোনও হ্যান্ডলার / ম্যাপার অবজেক্টের মাধ্যমে গেমের স্টেটটি পাস করুন যা অভ্যন্তরীণ গেমের স্টেটটিকে এমন কোনও জেনেরিক আইও ক্লাস পরিচালনা করতে পারে এমনটিতে অনুবাদ করে।
আমি মনে করি আপনি এটিকে ভুল উপায়ে দেখছেন। আপনি অ্যাপ্লিকেশনটির উপাদানগুলির কার্যকরীভাবে আইওকে আলাদা করছেন, যদিও - আমার কাছে - উত্সের ভিত্তিতে পৃথক আইও ক্লাস এবং আইওর "টাইপ" করা আরও বোধগম্য ।
শুরু করার জন্য কিছু বেস / জেনেরিক KeyboardIOক্লাস MouseIOথাকা, এবং তারপরে আপনার কখন এবং কোথায় তাদের প্রয়োজনের ভিত্তিতে সাবক্লাস রয়েছে যা হ্যান্ডেল আইওকে অন্যভাবে বলেছে।
উদাহরণস্বরূপ, পাঠ্য ইনপুট এমন একটি জিনিস যা আপনি সম্ভবত ইন-গেম নিয়ন্ত্রণগুলিতে আলাদাভাবে পরিচালনা করতে চান। আপনি প্রতিটি ব্যবহারের ক্ষেত্রে নির্ভর করে নির্দিষ্ট কীগুলি আলাদাভাবে মানচিত্রের সন্ধান করতে দেখবেন, তবে সেই ম্যাপিং আইও-র অংশ নয়, আপনি কীভাবে আইও পরিচালনা করছেন।
এসআরপিকে আঁকড়ে ধরে, আমার কাছে কয়েকটি ক্লাস ছিল যা আমি কীবোর্ড আইওয়ের জন্য ব্যবহার করতে পারি। পরিস্থিতির উপর নির্ভর করে, আমি সম্ভবত এই ক্লাসগুলির সাথে অন্যভাবে ইন্টারঅ্যাক্ট করতে চাই, তবে তাদের একমাত্র কাজটি ব্যবহারকারী আমাকে কী করছে তা আমাকে জানান।
আমি তখন এই বিষয়গুলি হ্যান্ডলার অবজেক্টে ইনজেক্ট করব যা কাঁচা আইওকে আমার অ্যাপ্লিকেশন লজিক দিয়ে কাজ করতে পারে এমন কিছুতে মানচিত্র তৈরি করবে (যেমন: ব্যবহারকারী চাপুন "ডাব্লু" , হ্যান্ডলারের মানচিত্রগুলি যেটিতে MOVE_FORWARD)।
এই হ্যান্ডলারগুলি পরিবর্তে অক্ষরগুলি সরানো এবং সেই অনুযায়ী স্ক্রিন আঁকতে ব্যবহৃত হয়। একটি স্থূল ওভারসিম্প্লিফিকেশন, তবে এর সংক্ষিপ্তসারটি এই ধরণের কাঠামো:
[ IO.Keyboard.InGame ] // generic, if SoC and SRP are strongly adhered to, changing this component should be fairly easy to do
||
==> [ Controls.Keyboard.InGameMapper ]
[ Game.Engine ] <- Controls.Keyboard.InGameMapper
<- IO.Screen
<- ... all sorts of stuff here
InGameMapper.move() //returns MOVE_FORWARD or something
||
==> 1. Game.updateStuff();//do all the things you need to do to move the character in the given direction
2. Game.Screen.SetState(GameState); //translate the game state (inverse handler)
3. IO.Screen.draw();//generate actual output
আমাদের এখন যা রয়েছে তা এমন একটি বর্গ যা কাঁচা আকারে কীবোর্ড আইওর জন্য দায়বদ্ধ। এই বিভাগটি গেম ইঞ্জিনটি প্রকৃত অর্থে এমন কিছুতে অনুবাদ করতে পারে যা এই ডেটাটি অনুবাদ করে, এরপরে এই ডেটাটি জড়িত সমস্ত উপাদানগুলির অবস্থা আপডেট করতে ব্যবহৃত হয় এবং শেষ পর্যন্ত, একটি পৃথক শ্রেণি পর্দায় আউটপুটটির যত্ন নেবে।
প্রতিটি একক শ্রেণীর একক কাজ থাকে: কীবোর্ড ইনপুট হ্যান্ডলিং এমন শ্রেণীর দ্বারা সম্পন্ন হয় যা জানেন না / যত্ন করে না / জানেন যে ইনপুটটির প্রক্রিয়াকরণটির অর্থ কী। এটি কেবল কীভাবে ইনপুট পেতে হবে তা নিশ্চিত (বাফারড, আনফফার্ড, ...)।
হ্যান্ডলার এটিকে এই তথ্যটি বোঝার জন্য বাকী অ্যাপ্লিকেশনটির জন্য অভ্যন্তরীণ উপস্থাপনায় অনুবাদ করে into
গেম ইঞ্জিনটি অনুবাদ করা ডেটা গ্রহণ করে এবং কিছু চলছে এমন সমস্ত প্রাসঙ্গিক উপাদানকে অবহিত করতে এটি ব্যবহার করে। এই উপাদানগুলির প্রত্যেকটি কেবল একটি কাজ করে, এটি সংঘর্ষের চেক বা চরিত্রের অ্যানিমেশন পরিবর্তন হোক, এটি কোনও ব্যাপার নয়, এটি প্রতিটি পৃথক বস্তুর নীচে।
এই বিষয়গুলি তারপরে তাদের অবস্থাটিকে রিলে করে দেয় এবং এই ডেটাটি চলে যায় Game.Screen, যা মূলত একটি বিপরীত আইও হ্যান্ডলার। এটি IO.Screenপ্রকৃত আউটপুট উত্পন্ন করতে উপাদানটি ব্যবহার করতে পারে এমন কিছুতে অভ্যন্তরীণ প্রতিনিধিত্বকে মানচিত্র করে ।