के बारे में सुझाव की आवश्यकता है मैं एक टर्न-आधारित आरामदायक एमएमओआरपीजी गेम सर्वर विकसित करने में व्यस्त हूं।एमएमओआरपीजी डेटा मॉडल डिज़ाइन, डेटाबेस एक्सेस और स्टैकलेस पायथन
निम्न स्तर इंजन (नहीं हमारे द्वारा लिखित) जो नेटवर्किंग, बहु सूत्रण, टाइमर, इंटर-सर्वर संचार, मुख्य खेल पाश आदि, सी द्वारा लिखित था ++ संभाल। उच्च स्तर का खेल तर्क पायथन द्वारा लिखा गया था।
मेरा प्रश्न हमारे गेम में डेटा मॉडल डिज़ाइन के बारे में है।
सबसे पहले हम केवल रैम में एक खिलाड़ी के सभी डेटा और एक साझा डेटा कैश सर्वर जब क्लाइंट प्रवेश लोड और एक टाइमर डेटा कैश सर्वर और डेटा कैश सर्वर में समय-समय पर फ्लश डेटा अनुसूची डेटाबेस में डेटा बना रहेगा करने के लिए प्रयास करें।
लेकिन हम इस दृष्टिकोण पाया कुछ समस्याओं
1) कुछ डेटा ऐसी खोज प्रगति, स्तर ऊपर, आइटम & पैसा हासिल आदि
2) के अनुसार रूप में सहेजा जा करने के लिए या जाँच की तुरंत जरूरत है खेल तर्क के लिए, कभी-कभी हमें कुछ ऑफलाइन प्लेयर के डेटा से पूछताछ करने की आवश्यकता होती है।
3) कुछ वैश्विक गेम विश्व डेटा को अलग-अलग गेम उदाहरणों के बीच साझा करने की आवश्यकता है जो एक अलग मेजबान पर चल रहे हैं या उसी होस्ट पर एक अलग प्रक्रिया हो सकती है। यह डेटा कारण है कि हमें डेटा कैश सर्वर गेम तर्क सर्वर और डेटाबेस के बीच बैठता है।
4) प्लेयर को गेम के उदाहरणों के बीच स्वतंत्र रूप से स्विच की आवश्यकता है।
1) सभी डेटा का उपयोग आपरेशन नेटवर्क आई/ओ मुख्य खेल तर्क धागा अवरुद्ध से बचने के लिए asynchronized किया जाना चाहिए:
नीचे कठिनाई हमने अतीत में सामना करना पड़ा है। हमें डेटाबेस या कैश सर्वर पर संदेश भेजना है और फिर कॉलबैक फ़ंक्शन में डेटा उत्तर संदेश संभालना है और आगे बढ़ें गेम तर्क जारी रखें। यह कुछ मामूली जटिल गेम तर्क लिखने के लिए दर्दनाक हो जाता है जिसे डीबी के साथ कई बार बात करने की आवश्यकता होती है और गेम लॉजिक कई कॉलबैक फ़ंक्शंस में बिखरा हुआ है, इसे समझना मुश्किल हो जाता है और बनाए रखता है।
2) विज्ञापन-प्रसार डेटा कैश सर्वर चीजों को और अधिक जटिल बनाता है, हमें डेटा स्थिरता को प्रभावी ढंग से अद्यतन/लोड/रीफ्रेश डेटा बनाए रखना मुश्किल है।
3) इन-गेम डेटा क्वेरी अक्षम और बोझिल है, खेल तर्क ऐसी सूची, आइटम की जानकारी, अवतार राज्य आदि के रूप में कई जानकारी क्वेरी करने के लिए कुछ लेनदेन machanism भी जरूरत है उदाहरण के लिए, यदि एक कदम में विफल रहा है की जरूरत है पूरे ऑपरेशन रोलबैक होना चाहिए। हम रैम, में एक अच्छी डेटा मॉडल प्रणाली बनाने की कोशिश करते हैं, जिसमें कई सूचनाएं कम करने के लिए कई जटिल इंडेक्स तैयार किए जाते हैं, लेनदेन समर्थन इत्यादि जोड़ते हैं। जल्दी ही मुझे एहसास हुआ कि हम क्या बना रहे हैं एक मेमोरी डेटाबेस सिस्टम है, हम पुनर्विचार कर रहे हैं पहिया ...
अंततः मैं स्टैकलेस पायथन पर जाता हूं, हमने कैश सर्वर को हटा दिया। सभी डेटा डेटाबेस में सहेजे गए हैं। खेल तर्क सर्वर सीधे डेटाबेस क्वेरी।स्टैकलेस पायथन के माइक्रो टास्कलेट और चैनल के साथ, हम गेम तर्क को एक सिंक्रनाइज़ तरीके से लिख सकते हैं। यह लिखना और समझना और उत्पादकता बहुत अधिक आसान है में सुधार हुआ।
वास्तव में, अंतर्निहित डीबी पहुँच भी asynchronized है: एक और करने के लिए एक ग्राहक tasklet मुद्दा अनुरोध डीबी आई/ओ कार्यकर्ता धागा समर्पित और tasklet एक चैनल पर अवरुद्ध है, लेकिन पूरे मुख्य खेल तर्क अवरुद्ध नहीं कर रहा है, अन्य ग्राहक का कार्यपत्र निर्धारित और स्वतंत्र रूप से चलाया जाएगा। जब डीबी डेटा अवरुद्ध टास्कलेट को जागृत कर दिया जाएगा और 'ब्रेक बिंदु' (निरंतरता?) पर चलना जारी रखेगा। पिछले कैश्ड समाधान की तुलना में अक्सर
1) डीबी पहुँच हो जाएगा करता डीबी उच्च लगातार जानकारी/अद्यतन आपरेशन का समर्थन कर सकते हैं:
ऊपर डिजाइन के साथ, मैं कुछ प्रश्न हैं? क्या कुछ परिपक्व कैश समाधान जैसे रेडिस, निकट भविष्य में memcached की आवश्यकता है?
2) क्या मेरे डिजाइन में कोई गंभीर समस्या है? क्या आप लोग मुझे कुछ बेहतर सुझाव दे सकते हैं, खासकर इन-गेम डेटा प्रबंधन पैटर्न पर।
किसी भी सुझाव की सराहना की जाएगी, धन्यवाद।