প্লেয়ার ডেটা পরিবর্তনের পাশাপাশি ডিজাইনার ডেটা পরিবর্তন করার উপায়


14

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

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

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

উদাহরণ 1: কোনও প্লেয়ার একটি নতুন ধরণের আইটেম তৈরি করে এবং গেমটি এতে 123456 আইডি বরাদ্দ করে। এই আইটেমটির সমস্ত উদাহরণ 123456-এ ফিরে এসেছে Now এখন কল্পনা করুন গেম ডিজাইনারগুলির একটি একই সিস্টেম রয়েছে এবং একটি ডিজাইনার 123456 নম্বরযুক্ত একটি নতুন আইটেম তৈরি করেন this কীভাবে এড়ানো যায়?

উদাহরণ 2: কেউ একটি জনপ্রিয় মোড তৈরি করে যা আপনার সমস্ত ড্রাগনগুলিকে একটি ফরাসি উচ্চারণ দেয়। এটিতে একটি নতুন অবজেক্টযুক্ত একটি স্ক্রিপ্ট অন্তর্ভুক্ত assignFrenchAccentযা তারা প্রতিটি ড্রাগন অবজেক্টকে নতুন ভয়েস সম্পদ বরাদ্দ করতে ব্যবহার করে। তবে আপনি আপনার "নেপোলিয়ন বনাম স্মাগ" ডিএলসি স্থাপন করতে চলেছেন যার একই নামের একটি অবজেক্ট রয়েছে - আপনি গ্রাহকসেবার সমস্যা ছাড়াই কীভাবে এটি করতে পারেন?

আমি নিম্নলিখিত কৌশলগুলি সম্পর্কে চিন্তা করেছি:

  • আপনি 2 পৃথক ফাইল / ডিরেক্টরি / ডাটাবেস ব্যবহার করতে পারেন, তবে তারপরে আপনার পঠিত অপারেশনগুলি উল্লেখযোগ্যভাবে জটিল। "সমস্ত আইটেম দেখান" ডিজাইনার ডিবিতে একটি পঠন এবং প্লেয়ার ডিবিতে একটি পড়ার সম্পাদন করতে হয় (এবং এখনও এটি কোনওভাবে 2 এর মধ্যে পার্থক্য করতে হয়))
  • আপনি একটি স্টোরের মধ্যে 2 টি পৃথক নেমস্পেস ব্যবহার করতে পারেন, যেমন। স্ট্রিংগুলিকে প্রাথমিক কী হিসাবে ব্যবহার করা এবং এগুলিকে "ডিজাইন:" বা "প্লেয়ার:" দিয়ে উপস্থাপন করা, তবে সেই নামগুলির স্থান তৈরি করা অ-তুচ্ছ এবং নির্ভরতা পরিষ্কার নয় n't (উদাহরণস্বরূপ, আরডিবিএমএসে আপনি স্ট্রিংগুলি প্রাথমিক কী হিসাবে দক্ষতার সাথে ব্যবহার করতে সক্ষম নাও হতে পারেন designer আপনি ডিজাইনার ডেটা হতে নির্দিষ্ট সংখ্যার নীচে সমস্ত প্রাথমিক কী বরাদ্দ করতে পারেন, যেমন 1 মিলিয়ন, এবং সেই বিন্দুটির উপরে থাকা সমস্ত কিছু) প্লেয়ারের ডেটা But তবে সেই তথ্যটি আরডিবিএমএসের কাছে অদৃশ্য এবং বিদেশী কী লিঙ্কগুলি 'ডিভাইড' অতিক্রম করবে, যার অর্থ সমস্ত সরঞ্জামাদি এবং স্ক্রিপ্টগুলিকে এর চারপাশে স্পষ্টতই কাজ করা দরকার))
  • আপনি রিয়েল-টাইমে সর্বদা একই ভাগ করা ডাটাবেসে কাজ করতে পারেন তবে কার্য সম্পাদনটি দুর্বল হতে পারে এবং প্লেয়ারের ডেটার ক্ষতি হওয়ার ঝুঁকি বাড়ানো যেতে পারে। এটি বিভিন্ন বিশ্ব ডেটা সহ 1 টিরও বেশি সার্ভারে চালিত গেমগুলিতেও প্রসারিত হয় না।
  • ... অন্য কোন ধারণা?

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

আমি এটিকে "সংস্করণ নিয়ন্ত্রণ" হিসাবেও ট্যাগ করেছি কারণ এক স্তরে এটি যা হ'ল - ডেটা বিকাশের 2 টি শাখা যা মার্জ করা দরকার। সম্ভবত কিছু অন্তর্দৃষ্টি সেই দিক থেকে আসতে পারে।

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


1
আমি কল্পনা করি এর ডিজাইনাররা কোন ধরণের ডেটা যুক্ত করছে এবং খেলোয়াড়রা কী যুক্ত করছে তার উপর অন্তত কিছুটা নির্ভর করতে পারে imagine
lathomas64

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

1
প্রচুর লোক এই প্রশ্নের বিন্দু অনুপস্থিত - এটি খেলোয়াড়ের পরিবর্তন নয় যা বিরোধমূলক: বরং সামগ্রী আপডেট ইত্যাদি বিদ্যমান লেআউটগুলি ভেঙে দেয়। @ কাইলোটান আমি ঠিক আছি?
জোনাথন ডিকিনসন

এটি যেখানে বিকাশকারী সামগ্রী আপডেটগুলি প্লেয়ার সামগ্রীর আপডেটগুলির সাথে সংঘটিত হয়। আমি গেম ডিজাইনের কাজের ক্ষেত্রে (যেমন, কেবলমাত্র খেলোয়াড়দের নির্দিষ্ট জায়গায় তৈরি করতে দেয়) তে আগ্রহী নই (উদাহরণস্বরূপ, খেলোয়াড়রা আইডি দিয়ে 1 মিলিয়নের বেশি জিনিস তৈরি করতে দিন)।
কাইলোটন

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

উত্তর:


2

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

আপনি এখানে যে কথা বলছেন তা সমস্যার বণ্টিত বিকাশের মডেলটিতে পড়ে। আমি বিশ্বাস করি প্রথম পদক্ষেপটি খেলোয়াড় এবং ডিজাইনারকে আলাদা ধরণের সামগ্রী স্রষ্টা হিসাবে ভাবা না। এটি আপনার সমস্যার একটি কৃত্রিম মাত্রা সরিয়ে দেয় যা সমাধানটিকে প্রভাবিত করে না।

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

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

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

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

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

আহ আমি দেখি. ভাল যেহেতু আপনি তাদের বিল্ডিং সরঞ্জামগুলি নিয়ন্ত্রণ করেন, কমপক্ষে সেই মার্জ-বান্ধব পদ্ধতির (নেমস্পেসগুলি ইত্যাদি) কার্যকর করা এমন কোনও বিষয় যা আপনি খেলোয়াড়দের সম্মত না করেই করতে পারেন।
মিঃ ক্র্যাঙ্কি

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

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

হ্যাঁ হ্যাঁ, আমি এখন দেখছি, এটি নামের পছন্দ হিসাবে এতটা নিজের নিজের জায়গাগুলি নয়। সেক্ষেত্রে জিইউইডিগুলি সম্ভবত আবার উত্তর - সামগ্রীটি তার নিজস্ব সামান্য ক্ষেত্রে কার্যকরভাবে রাখা হয়েছে kept একটি আলংকারিক নাম দেওয়া যেতে পারে, তবে গেমটি জিইউইডি ব্যবহার করবে।
মিঃ ক্র্যাঙ্কি

1

মাউন্ট পয়েন্ট সহ - অ্যাট্রিবিউট (বা সজ্জাকারী) হিসাবে সবকিছু সংরক্ষণ করুন। খেলোয়াড় একটি উদাহরণ হিসাবে ডিজাইন করেছেন এমন একটি বাড়ি আসুন:

o House: { Type = 105 } // Simple square cottage.
 o Mount point: South Wall:
  o Doodad: Chair { Displacement = 10cm }
   o Mount point: Seat:
    o Doodad: Pot Plant { Displacement = 0cm, Flower = Posies } // Work with me here :)
 o Mount point: North Wall:
  o Doodad: Table { Displacement = 1m }
    o Mount point: Left Edge:
     o Doodad: Food Bowl { Displacement = 20cm, Food = Meatballs}

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

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

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

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


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

1

আমি এটি বুঝতে পারি এমন কিছুটির সাথে এটি সংযুক্ত করার চেষ্টা করছি, তাই আমি এখনই মাইনক্রাফ্টের দিক দিয়ে ভাবছি। খেলোয়াড়গণ রিয়েল-টাইমে পরিবর্তন আনার সাথে আমি একটি লাইভ সার্ভার চিত্রিত করছি যখন বিকাশকারীরা পরীক্ষার সার্ভারে চলছে এবং নতুন সামগ্রী তৈরি করছে।

আপনার প্রশ্নটি প্রায় 2 টি অনন্য প্রশ্নের মতো মনে হচ্ছে:

  1. কীভাবে বীমা করতে হবে যে অবজেক্ট আইডিগুলি অনন্য
  2. কিভাবে স্ক্রিপ্ট নেমস্পেসের সংঘর্ষ না ঘটে তা নিশ্চিত করতে হবে

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

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

# 2 এর জন্য, মনে হচ্ছে আপনার কাছে সত্যিকারের মধ্যবর্তী স্ক্রিপ্টের ট্রান্সমুটেশন এর কিছু স্তর থাকা দরকার যা ফাংশনটির নামটিকে একটি অনন্য নেমস্পেসে হ্যাশ করতে পারে। অর্থাত

assignFrenchAccent

হয়ে

_Z11assignFrenchAccent

0

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


0

আমি মনে করি একটি 'চেক-আউট' প্রক্রিয়া সহ পরিবেশের জুড়ে প্রতিলিপি করা একটি ডাটাবেস / ফাইল সিস্টেমটি সবচেয়ে ভাল।

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

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

সম্পত্তির লকিং সেই সম্পত্তিগুলিতে সীমাবদ্ধ থাকতে পারে যেখানে আপনি কোনও বিরোধের গ্যারান্টি দিতে চান: উদাহরণ 1-এ, ID 123456প্লেয়ারটি এটি তৈরি করা শুরু করার সাথে সাথেই আপনি লক করে ফেলবেন, সুতরাং বিকাশকারীদের সেই আইডি বরাদ্দ দেওয়া হবে না। উদাহরণ 2-এ আপনার বিকাশকারীরা assignFrenchAccentবিকাশের সময় স্ক্রিপ্টের নামটি লক করে দিতেন, সুতরাং খেলোয়াড়কে তার পরিবর্তনটি বিকাশের সময় আলাদা আলাদা নাম চয়ন করতে হবে (নাম উপস্থাপনের মাধ্যমে ছোট উপদ্রব হ্রাস করা যেতে পারে তবে আপনি প্রতিটি না দিয়ে দ্বন্দ্ব এড়াতে পারবেন না) ব্যবহারকারী / বিকাশকারী একটি নির্দিষ্ট নেমস্পেস এবং তারপরে নেমস্পেসগুলি পরিচালনা করার ক্ষেত্রে আপনার একই সমস্যা থাকবে)। এর অর্থ এই নয় যে সমস্ত বিকাশকে একটি একক অন-লাইন ডাটাবেস থেকে পড়তে হবে, তবে এই উদাহরণগুলিতে সেই ডাটাবেস থেকে আপনার প্রয়োজনীয় সমস্ত কিছুই অবজেক্টের নাম, সুতরাং কার্য সম্পাদন কোনও সমস্যা হওয়া উচিত নয়।

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


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

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

0

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

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

এটি একটি বিশাল জটিল সমস্যা, সৌভাগ্য! সম্ভবত একটি উত্তর নেই।


0

আমি মনে করি না যে এটি তৈরি করার সাথে সাথে এটির একটি বড় সমস্যা রয়েছে।

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

ব্যবহারকারীর তৈরি সামগ্রীর জন্য একই, কেবল একটি ব্যাকআপ তৈরি করুন এবং ওভাররাইট করুন।

এই বিষয়ে আমার কোনও আসল অভিজ্ঞতা নেই, কেবল পরামর্শ দেওয়া।


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

তারপরে আপনি যে সামগ্রীটি পরে যুক্ত করতে পারেন তার জন্য কেবল সিস্টেমে ঘর ছেড়ে দিন। আপনি যদি আইডি নম্বর ব্যবহার করেন তবে 1-1000 টি রিজার্ভ করুন। অথবা যদি ব্যবহারকারীরা তাদের সম্পদের নাম রাখতে পারে তবে ব্যবহারকারীদের নামটি "FINAL-" বা কোনও কিছু দিয়ে শুরু করতে দিন না (এটি নিজের সম্পদের জন্য সংরক্ষণ করুন)। সম্পাদনা: বা আরও ভাল, বিপরীতে এটি করুন, ব্যবহারকারীর সামগ্রীকে একটি ব্যাপ্তি বা উপসর্গের জন্য জোর করে
উডি জ্যান্টজিংগার
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.