অভিনেতা হিসাবে Sprites


12

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

সুতরাং আমি ভেবেছিলাম, সম্ভবত আপনি এগুলিকে 2 ডি-স্প্রিটসের বেস ক্লাস হিসাবে ব্যবহার করতে পারেন, গেম-লুপের জিনিসটি ভেঙে ফেলার জন্য যা সমস্ত স্প্রিটের মধ্য দিয়ে যেতে এবং সেগুলি সরাতে হবে। তারা মূলত ইভেন্ট-চালিত নিজেদের স্থানান্তরিত করত।

এটি কি কোনও খেলার জন্য অর্থবোধ করে? এটির মতো মাল্টিটাস্ক করা হচ্ছে? সর্বোপরি, এটি JVM এ চলবে, যদিও এটি আজকাল খুব বেশি সমস্যা হওয়া উচিত নয়।

সম্পাদনা করুন:

কিছুক্ষণ ছোঁড়াছুড়ি করার পরে, আমি লক্ষ্য করেছি যে এই ধারণার একমাত্র আসল সুবিধা রয়েছে: মাল্টিকোর সমর্থন। একটি সাধারণ গেম লুপ কেবল একটি কোরে চলবে এবং ক্রমানুসারে সমস্ত কিছুতে কাজ করবে।

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

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

আমি যত তাড়াতাড়ি সম্ভব আমার স্কালা 2 ডি ইঞ্জিনে এটি তৈরি করার পরিকল্পনা নিয়েছি।


আমি এটি জানতে পেরে খুব আগ্রহী হব very আমি স্কালাকে কয়েকবার দেখেছি কিন্তু এর আগে কখনই কবুতর হয়নি।
ডেভি 8

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

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

উত্তর:


7

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

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

আমার কাছে মনে হচ্ছে আপনার এখানে যা দরকার তা হ'ল একরকম খুব হালকা ওজনের মাল্টিটাস্কিং এবং কোনও বার্তা একেবারেই যায় না। আপনার নিজের অভিনেতার মতো বাস্তবায়নে রোলিং যা ন্যায়বিচার নিশ্চিত করে আপনি সম্ভবত এটি নিশ্চিত করতে চান তবে সবচেয়ে ভাল উপায়, তবে এটি খুব অল্প লাভের জন্য খুব বেশি কাজ। দেখার মতো আরেকটি বিষয় হ'ল কার্যক্ষম প্রতিক্রিয়াশীল প্রোগ্রামিং এবং scala.react, আমি বিশ্বাস করি যে এই ব্যবহারের ক্ষেত্রে আরও ভাল মিল।

আমি স্কালায় একটি 2 ডি আইসোমেট্রিক গেম ইঞ্জিন প্রয়োগ করেছি। অ্যানিমেটেড দৃশ্যমান স্প্রিটগুলি আপডেট করতে আমি কেবলমাত্র 1 জন গ্লোবাল অভিনেতা ব্যবহার করেছি।

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

তবুও, আমি যদি আপনি থাকতাম তবে আমি কী চেষ্টা করে তা দেখতে চেষ্টা করতাম।


1

সুতরাং আমি ভেবেছিলাম, সম্ভবত আপনি এগুলিকে 2 ডি-স্প্রিটসের বেস ক্লাস হিসাবে ব্যবহার করতে পারেন, গেম-লুপের জিনিসটি ভেঙে ফেলার জন্য যা সমস্ত স্প্রিটের মধ্য দিয়ে যেতে এবং সেগুলি সরাতে হবে। তারা মূলত ইভেন্ট-চালিত নিজেদের স্থানান্তরিত করত।

এমন ঘটনা কী ঘটবে যা তাদের চালিত করে?

আপনি কি ফ্রেমে প্রতি একবার নির্গত ঘটনাটি হবেন?

এবং যদি তা হয় তবে কীভাবে এটি কোনও ব্যবহারিক উপায়ে সিস্টেমকে পরিবর্তন করেছে?

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


অভিনেতা একটি বহু-থ্রেডযুক্ত সমাধান। যোগাযোগগুলি সমকালীন নয়। স্কালা অভিনেতা (এরলং থেকে ধারণা) সহজ মাল্টি কোর প্রোগ্রামের অনুমতি দেয়।
এলিস

আপনার এখানে একটি বক্তব্য রয়েছে তবে এখানে পার্থক্যটি xyz.doThis(x)হ'ল অভিনেতা-ভিত্তিক স্প্রিটটি ক্রিয়াটি সম্পাদন করার সময় গেম লুপটিকে অবরুদ্ধ করে না, যেখানে পদ্ধতি-পদ্ধতির সম্পন্ন হওয়া পর্যন্ত অপেক্ষা করে। আমি মনে করি এটি গেম যুক্তি দ্রুততর করতে বিশেষত মাল্টি-কোর সিস্টেমে সহায়তা করতে পারে।
ল্যানবো

সত্য, একাধিক কোর জুড়ে সত্তাকে হ্যান্ডলিং বিতরণ করা সহজ করে তোলে। তবে এর ব্যয়টি হ'ল বার্তাগুলিতে অতিরিক্ত বার্তা বা অতিরিক্ত ডেটা প্রেরণ করা ছাড়া আপনি সহজেই একজন অভিনেতা থেকে অন্য অভিনেতার কাছে উল্লেখ করতে পারবেন না। সুতরাং আপনি দ্রুত বুঝতে পারবেন যে এখানে নিষ্পাপ দৃষ্টিভঙ্গি আপনাকে সহায়তা করে না - আপনি কীভাবে অভিনেতার ভিত্তিক আপডেটগুলি সম্পাদন করার উপায় তৈরি করতে পারেন?
কাইলোটান

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

হ্যাঁ, তবে সমস্যাটি আপডেটটিকে ট্রিগার হিসাবে চালিত করে না, বার্তাটি প্রাপককে নিশ্চিত করার জন্য এটির প্রয়োজনীয় সমস্ত তথ্য রয়েছে।
কাইলোটন

0

এটি আপনার গেমের বিষয়গুলি আপডেট করার বিষয়ে চিন্তাভাবনা করার একটি দুর্দান্ত কৌশল approach আমি স্কালাকে চিনি না, তবে আমি বলি এটির একটি শট দিন এবং দেখুন কীভাবে এটি বেরিয়ে আসে এবং আরও ভাল ফলাফল আপনার ফলাফল পোস্ট করুন!

আমার মনে যে প্রধান প্রশ্নগুলি বসেছে সেগুলি হ'ল: কিছু গেম অবজেক্ট অন্যের তুলনায় কত ঘন ঘন আপডেট হয় তা আপনি কীভাবে পরিচালনা করবেন? আপনার কি স্প্রিট অভিনেতাদের অনেক বেশি চক্র গ্রহণের বিষয়ে চিন্তা করতে হবে যে রেন্ডারিং সিস্টেমে প্রতি সেকেন্ডের 1 / 60th | 30th | 24 তম প্রতি ফ্রেম আঁকার সময় নেই?

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


স্কালা অভিনেতা সম্পর্কে দুর্দান্ত বিষয় হ'ল তারা বার্তা চালিত। তাদের প্রত্যেকের একটি নিজস্ব বার্তা / ইভেন্ট-সারি রয়েছে। 'অঙ্কন' কোনও বার্তা বা কল করার কোনও পদ্ধতি হওয়া উচিত কিনা তা আমি নিশ্চিত নই। আমি মনে করি এটি পরবর্তীকালে হবে, যাতে কোনও স্প্রাইট যে কোনও সময় আঁকতে পারে, তাদের ইভেন্টের সারির অবস্থা নির্বিশেষে। একটি নির্দিষ্ট ক্রমে জিনিসগুলি সম্পন্ন হওয়ার বিষয়টি নিশ্চিত করতে তারা একে অপরকে বার্তা পাঠাতে পারে।
ল্যান্বো

সেখানে সাবধানতা অবলম্বন করুন, আমি মনে করি না যে প্রতিটি স্প্রিটের একটি ড্র পদ্ধতি বা ইভেন্ট থাকায় দরকারী হবে, দৃশ্যমানতা টগল করার জন্য পতাকা হিসাবে সম্ভবত। গেম লুপের রেন্ডার পর্যায়ে, স্প্রিটগুলি স্ক্রিনে যে ক্রম হিসাবে রেন্ডার করা হয় তা ফলাফলের উপরে বড় প্রভাব ফেলে। যদি আপনার কাছে একটি স্প্রিট থাকে যা অন্যটির সামনে অবস্থিত (মনিটরের দিকে মাত্রা থাকে), আপনি চান যে এটি দ্বিতীয়টি আঁকতে। আমি দেখছি স্কালার অভিনেতারা গেম লুপের আপডেট / লজিক অংশের জন্য দরকারী।
michael.bartnett

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

আহ ঠিক আছে, আপনি যা বর্ণনা করছেন তা আমি ভুল বুঝেছি। আমি কোনওভাবেই স্প্রাইটগুলি যখনই এবং যাইহোক তারা খুশি তাই তাদের রেন্ডারিংয়ের কল্পনা করছিলাম। আমাদের এটি কীভাবে সক্রিয় তা জানা যাক!
michael.bartnett

0

ঠিক আছে, আমিও তেমন কোনও প্রোগ্রামার নই, তবে আপনার প্রস্তাবটিতে আমি কোনও সমস্যা দেখছি না। অভিনেতাদের বিকাশের এমন পদ্ধতি নিয়ে আমি ভাবিনিও।

এটি বেশ চ্যালেঞ্জ হতে পারে, যেহেতু আইএর অনিশ্চিত আচরণ এড়াতে খুব নির্ভুল হতে হবে, তবে এর বাইরেও আমি দেখছি এটি বেশ ভাল প্রস্তাব


0

স্প্রিট দ্বারা যদি আপনি গেম সত্তা বোঝাচ্ছেন তবে নিশ্চিত।

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

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

আমি স্কালার বিকাশকারী নই, তবে এরলংয়ের সাথে আমি বেশ কিছুটা করেছি। সুতরাং যদি আমার কিছু স্কেলার পরিভাষা ভুল হয় তবে দয়া করে আমাকে ক্ষমা করুন।

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