وسام البهنسي
مشاركة 1
في 22 يناير 2012 01:57 ص
السلام عليكم،
هذا الموضوع استكمال لنقاش بدأه الزميل أنس مصطفاوي في مدونته:
http:/
وترتب عليه بعض الجدال في مجموعة الشبكة في الفيسبوك، تضمن تدوينة أخرى من قبل الزميل أمين التاجر:
http:/
وقمتُ أنا بحشر نفسي فيه أيضاً (كالعادة) مبدياً رأياً شاذاً (أيضاً كالعادة) في المسألة:
http:/
واستمر النقاش على الموضوع، فقررت نقله إلى هنا لأن تبادل الأفكار في تعلقيات الفيسبوك مزعج جداً ومحدود... سأبدأ أولاً بالرد على تعليق أنس مصطفاوي، إذ قال:
-----------------------------------------------------------------------------------------------------------------------
بصراحة، حل "الربط الديناميكي" لم اسمع به بتاتا كبديل للنظام البريمجات. سأحاول البحث عن هذه النقطة، لكن لنرى ان فهمت الفكرة :
- كتابة اجراءات معينة ، و يتم ادراجها في ملف ترويسة مثلا : كود تحريك الشخصيات. أو كود مسير الحالات(States System).
- الان المشروع لا يحتوي على ملفات كود تعالج الاجراءات السابقة(و كاننا نقلنا المحرك الى عدة ملفات ترويسة).
- نكتب الان كود اللعبة، باستدعاء اجراءات ملفات الترويسة.
- مرحلة بناء الكود لن تعالج سوى ملفات الكود المكتوبة في المرحلة السابقة، و لن تتطرق الى ما هو موجود في ملف الترويسة، بهذا نستطيع ربح الوقت.
اذا كان هذا هو مضمون الفكرة، فاراها حل مناسبا.
بعض اللغات تسمح باستخدام نفسها كلغة بريميجية، و على سبيل المثال لغة السي شارب. اين يمكن كتابة كود سي شارب و استدعاءه اثناء تشغيل برنامج ما. ما رأيك بهذه النقطة ؟ ام ان الامر مجرد خاصية لا تختلف بتاتا عما هو مذكور في المقالة ؟
-----------------------------------------------------------------------------------------------------------------------
بالضبط كما ذكرت أنس. مثال:
كود اللعبة الأساسي يريد تحريك الشخصيات في المرحلة، لكنه يودّ ترك هذه المهمة للمصمم. فنضع إجراء في ملف ترويسة البريمجات اسمه TickCharacter ويستلم بارامتر الشخصية المطلوب تحريكها. مكتبة الربط الديناميكي تقوم بتضمين ملف الترويسة إياه فقط، وليس أي شيء غيره، ثم يكتب الإجراء TickCharacter ويملؤه بالمنطق المطلوب. الآن بعد بناء مكتبة الربط الديناميكي، يتم تحميلها في اللعبة واستدعاء الإجراء كما تم تعريفه في المكتبة.
بالنسبة لسؤالك الثاني عن سي شارب، نعم. سي شارب تقدم هذه الإمكانية وهي تعتبر حل آخر لكنه خاص بسي شارب فقط. كافة الإيجابيات مصانة من أداء وإمكانيات ...الخ.
هذا الموضوع استكمال لنقاش بدأه الزميل أنس مصطفاوي في مدونته:
http:/
وترتب عليه بعض الجدال في مجموعة الشبكة في الفيسبوك، تضمن تدوينة أخرى من قبل الزميل أمين التاجر:
http:/
وقمتُ أنا بحشر نفسي فيه أيضاً (كالعادة) مبدياً رأياً شاذاً (أيضاً كالعادة) في المسألة:
http:/
واستمر النقاش على الموضوع، فقررت نقله إلى هنا لأن تبادل الأفكار في تعلقيات الفيسبوك مزعج جداً ومحدود... سأبدأ أولاً بالرد على تعليق أنس مصطفاوي، إذ قال:
-----------------------------------------------------------------------------------------------------------------------
بصراحة، حل "الربط الديناميكي" لم اسمع به بتاتا كبديل للنظام البريمجات. سأحاول البحث عن هذه النقطة، لكن لنرى ان فهمت الفكرة :
- كتابة اجراءات معينة ، و يتم ادراجها في ملف ترويسة مثلا : كود تحريك الشخصيات. أو كود مسير الحالات(States System).
- الان المشروع لا يحتوي على ملفات كود تعالج الاجراءات السابقة(و كاننا نقلنا المحرك الى عدة ملفات ترويسة).
- نكتب الان كود اللعبة، باستدعاء اجراءات ملفات الترويسة.
- مرحلة بناء الكود لن تعالج سوى ملفات الكود المكتوبة في المرحلة السابقة، و لن تتطرق الى ما هو موجود في ملف الترويسة، بهذا نستطيع ربح الوقت.
اذا كان هذا هو مضمون الفكرة، فاراها حل مناسبا.
بعض اللغات تسمح باستخدام نفسها كلغة بريميجية، و على سبيل المثال لغة السي شارب. اين يمكن كتابة كود سي شارب و استدعاءه اثناء تشغيل برنامج ما. ما رأيك بهذه النقطة ؟ ام ان الامر مجرد خاصية لا تختلف بتاتا عما هو مذكور في المقالة ؟
-----------------------------------------------------------------------------------------------------------------------
بالضبط كما ذكرت أنس. مثال:
كود اللعبة الأساسي يريد تحريك الشخصيات في المرحلة، لكنه يودّ ترك هذه المهمة للمصمم. فنضع إجراء في ملف ترويسة البريمجات اسمه TickCharacter ويستلم بارامتر الشخصية المطلوب تحريكها. مكتبة الربط الديناميكي تقوم بتضمين ملف الترويسة إياه فقط، وليس أي شيء غيره، ثم يكتب الإجراء TickCharacter ويملؤه بالمنطق المطلوب. الآن بعد بناء مكتبة الربط الديناميكي، يتم تحميلها في اللعبة واستدعاء الإجراء كما تم تعريفه في المكتبة.
بالنسبة لسؤالك الثاني عن سي شارب، نعم. سي شارب تقدم هذه الإمكانية وهي تعتبر حل آخر لكنه خاص بسي شارب فقط. كافة الإيجابيات مصانة من أداء وإمكانيات ...الخ.
وسام البهنسي
مبرمج في إنفيديا وإنفريمز
مبرمج في إنفيديا وإنفريمز
وسام البهنسي
مشاركة 2
في 22 يناير 2012 02:58 ص
ذكر الأخ أمين التاجر بعض الملاحظات أيضاً (مقتبسة هنا باللغة الإنجليزية). سأجيب عليها واحدة بواحدة بين السطور بالعربية:
- Level designers don't have the same kind of programming experience like game programmers, so giving them the ability to write game logic in a language like C++ is an overki...ll - at least from my point of view, even if you would let them use a language it's still difficult for them, they'll have to deal with memory management and nitty gritty details.
أعتقد أنني قد عالجتُ هذه النقطة بوضوح عندما قلت:
"لكن لنكن واقعيين هنا، لغات البريمجات القائمة الآن كلها تشبه سي بلس بلس بشكل أو بآخر، فهي تحوي متغيرات وإجراءات وأصناف ووراثة إن لم يكن أكثر وأعقد من ذلك. أنظر إلى لغة لوا LUA مثلاً، هل نزعم أن شخصاً لا يعرف البرمجة قادر على التعامل معها؟"
لا أعلم لمَ نخدع أنفسنا هنا. لغة لوا لغة غرضية التوجه بامتياز، وأنت تدعي أنه يمكن لمن يجهل البرمجة أن يتعلمها في 3 أيام فقط. على هذا المقياس يمكننا إذن أن نقول أن تعلم لغة سي بلس بلس لن يستغرق أكثر من 5 أيام. ألا تشاركني الرأي أن هذا الكلام مبالغ به؟
- I don't know why UnrealScript performs so bad in this, especially that the Unreal Engine is a very respected engine, I mean did Epic Games have to make it so slow in order to make it work?
بصراحة، وبعد أن عملت على هذا المحرك لمدة 3 سنوات، فإنني أقول رأيي بصراحة وتواضع: أنريل محرك تعيس، ويحوز على صيت كبير لكنه (برأيي) لا يستحقه. دعنا نقصر الحديث الآن على أنريل سكربت فقط. لماذا هي فاشلة؟ دعنا نراجع سوية الأهداف المرجوة من نظام البريمجات، ولنرى إن كانت أنريل سكريبت تحققها أم لا:
* زمن التكرار: عند كل تغيير في ملف أنريل سكربت ستحتاج لإغلاق كامل المحرك (المحرر واللعبة) كلياً، ثم إعادة تشغيل المحرر كي تتم إعادة ترجمة البريمجات. هذه العملية تستغرق (بناء على مكان التعديل) ما بين دقيقة و 45 دقيقة في حال أن التعديل اضطرك لإعادة ترجمة كود السي بلس بلس أيضاً. أضف إلى ذلك حوالي 3 دقائق لإعادة تشغيل المحرر... هذه الأزمان على جهاز محطة عمل بمعالج بثمان أنوية وثمانية جيجابايت ذاكرة وقرص صلب رايد سريع ومعالج رسوميات جيفورس 8800 جي تي إكس (هو الأسرع أداءً في ذلك الوقت). يمكننا الحكم هنا إذن أن أنريل سكربت لا تحقق هذا المطلب.
* الإتاحة: عملياً أنريل سكربت هي مسخ مصغر من سي بلس بلس. غرضية التوجه وتدعم الوراثة وتشبه سي بلس بلس في هجائها. إذن هي ليست سهلة التعلم. ثم إن اللغة تفتقد الأدوات اللازمة لتتبع الأخطاء والتنقيح. ناهيك عن أن المترجم الخاص بها ليس كامل النضج ويرتكب بعض الأخطاء عندما يبدأ الكود بالتعقد.
* الهندسة البرمجية: قلنا أن استخدام البريمجات يساعد في فصل كود اللعب عن الكود الأساسي. في حالة أنريل بالذات فإنهم لا يلتزمون بذلك، بل يقومون بتعريف العديد من المكونات الرئيسية في المحرك داخل أنريل سكربت، مما يؤدي إلى أن يصبح الكود متداخلاً دون وضوح في الفصل. إذن أيضاً هي لا تحقق هذا الهدف...
كما ترى، الأهداف الثلاثة غير محققة، وبصراحة لا أعلم أبداً ما الفكرة من هذه اللغة. هي تحقق فقط هدفاً واحداً، وهو إضفاء ما يدعى بمعلومات الأنواع في زمن التشغيل (run-time type information) أو ما يعرف أيضاً بالانعكاس (reflection). وهي ميزة لا تستحق أبداً أن تفرد لها لغة برمجة كاملة برأيي... لهذا أنا أراها فاشلة...
- If a scripting language was build to memory pools in mind I think we would overcome the memory fragmentation issue, but none of these languages come to my mind.
بالفعل، لا توجد لغة بريمجات تحترم هذا القيد حتى الآن. لكنه ليس مستحيل التحقيق كذلك.
Your Dynamic Link Libraries solution provides a wonderful approach like being fast, having better compile time and the rest of benifits, but I think there are major issues with that:
- We go back to using programming languages like C++ in order to add logic code which is something not many level editors are capable of.
يمكننا أيضاً التفصيل في هذه النقطة. لدي صديق هنا يقول أن مبرمج السي بلس بلس الحقيقي لا يحتاج لاستعمال كلمة new و delete البتة. بصراحة، تستطيع تحويل سي بلس بلس إلى أي شيء آخر باستخدام الماكرويات (macros)، فيمكنك استخدام هذا الأسلوب لتبسيط اللغة وتخليص المصمم من الحاجة للتعامل مع الذاكرة كلياً إن كانت هذه هي المشكلة في سي بلس بلس برأيك.
- Providing game logic in a separate module like a DLL file is risky, meaning you have your whole gameplay details in one small place and that can be reverse engineered and even changed to allow cheating. Compiled scripts are better in this side because the way they're represented is obscure - especially if it's a proprietary scripting language.
ماذا تقول يا رجل 😲 ليس هناك أسهل من تحويل مكتبة الربط الديناميكي لتربط ستاتيكياً بالكود النهائي للعبة. تستطيع فعل ذلك في فيجوال ستوديو بسهولة تامة. ما يصل اللاعب النهائي هو ملف تنفيذي وحيد يحوي كل الكود دون أن يظهر منه إجراء واحد للخارج. أنا لا أتفق معك في هذه النقطة.
أشكرك على ملاحظاتك أخي أمين...
السلام عليكم ورحمة الله وبركاته
- Level designers don't have the same kind of programming experience like game programmers, so giving them the ability to write game logic in a language like C++ is an overki...ll - at least from my point of view, even if you would let them use a language it's still difficult for them, they'll have to deal with memory management and nitty gritty details.
أعتقد أنني قد عالجتُ هذه النقطة بوضوح عندما قلت:
"لكن لنكن واقعيين هنا، لغات البريمجات القائمة الآن كلها تشبه سي بلس بلس بشكل أو بآخر، فهي تحوي متغيرات وإجراءات وأصناف ووراثة إن لم يكن أكثر وأعقد من ذلك. أنظر إلى لغة لوا LUA مثلاً، هل نزعم أن شخصاً لا يعرف البرمجة قادر على التعامل معها؟"
لا أعلم لمَ نخدع أنفسنا هنا. لغة لوا لغة غرضية التوجه بامتياز، وأنت تدعي أنه يمكن لمن يجهل البرمجة أن يتعلمها في 3 أيام فقط. على هذا المقياس يمكننا إذن أن نقول أن تعلم لغة سي بلس بلس لن يستغرق أكثر من 5 أيام. ألا تشاركني الرأي أن هذا الكلام مبالغ به؟
- I don't know why UnrealScript performs so bad in this, especially that the Unreal Engine is a very respected engine, I mean did Epic Games have to make it so slow in order to make it work?
بصراحة، وبعد أن عملت على هذا المحرك لمدة 3 سنوات، فإنني أقول رأيي بصراحة وتواضع: أنريل محرك تعيس، ويحوز على صيت كبير لكنه (برأيي) لا يستحقه. دعنا نقصر الحديث الآن على أنريل سكربت فقط. لماذا هي فاشلة؟ دعنا نراجع سوية الأهداف المرجوة من نظام البريمجات، ولنرى إن كانت أنريل سكريبت تحققها أم لا:
* زمن التكرار: عند كل تغيير في ملف أنريل سكربت ستحتاج لإغلاق كامل المحرك (المحرر واللعبة) كلياً، ثم إعادة تشغيل المحرر كي تتم إعادة ترجمة البريمجات. هذه العملية تستغرق (بناء على مكان التعديل) ما بين دقيقة و 45 دقيقة في حال أن التعديل اضطرك لإعادة ترجمة كود السي بلس بلس أيضاً. أضف إلى ذلك حوالي 3 دقائق لإعادة تشغيل المحرر... هذه الأزمان على جهاز محطة عمل بمعالج بثمان أنوية وثمانية جيجابايت ذاكرة وقرص صلب رايد سريع ومعالج رسوميات جيفورس 8800 جي تي إكس (هو الأسرع أداءً في ذلك الوقت). يمكننا الحكم هنا إذن أن أنريل سكربت لا تحقق هذا المطلب.
* الإتاحة: عملياً أنريل سكربت هي مسخ مصغر من سي بلس بلس. غرضية التوجه وتدعم الوراثة وتشبه سي بلس بلس في هجائها. إذن هي ليست سهلة التعلم. ثم إن اللغة تفتقد الأدوات اللازمة لتتبع الأخطاء والتنقيح. ناهيك عن أن المترجم الخاص بها ليس كامل النضج ويرتكب بعض الأخطاء عندما يبدأ الكود بالتعقد.
* الهندسة البرمجية: قلنا أن استخدام البريمجات يساعد في فصل كود اللعب عن الكود الأساسي. في حالة أنريل بالذات فإنهم لا يلتزمون بذلك، بل يقومون بتعريف العديد من المكونات الرئيسية في المحرك داخل أنريل سكربت، مما يؤدي إلى أن يصبح الكود متداخلاً دون وضوح في الفصل. إذن أيضاً هي لا تحقق هذا الهدف...
كما ترى، الأهداف الثلاثة غير محققة، وبصراحة لا أعلم أبداً ما الفكرة من هذه اللغة. هي تحقق فقط هدفاً واحداً، وهو إضفاء ما يدعى بمعلومات الأنواع في زمن التشغيل (run-time type information) أو ما يعرف أيضاً بالانعكاس (reflection). وهي ميزة لا تستحق أبداً أن تفرد لها لغة برمجة كاملة برأيي... لهذا أنا أراها فاشلة...
- If a scripting language was build to memory pools in mind I think we would overcome the memory fragmentation issue, but none of these languages come to my mind.
بالفعل، لا توجد لغة بريمجات تحترم هذا القيد حتى الآن. لكنه ليس مستحيل التحقيق كذلك.
Your Dynamic Link Libraries solution provides a wonderful approach like being fast, having better compile time and the rest of benifits, but I think there are major issues with that:
- We go back to using programming languages like C++ in order to add logic code which is something not many level editors are capable of.
يمكننا أيضاً التفصيل في هذه النقطة. لدي صديق هنا يقول أن مبرمج السي بلس بلس الحقيقي لا يحتاج لاستعمال كلمة new و delete البتة. بصراحة، تستطيع تحويل سي بلس بلس إلى أي شيء آخر باستخدام الماكرويات (macros)، فيمكنك استخدام هذا الأسلوب لتبسيط اللغة وتخليص المصمم من الحاجة للتعامل مع الذاكرة كلياً إن كانت هذه هي المشكلة في سي بلس بلس برأيك.
- Providing game logic in a separate module like a DLL file is risky, meaning you have your whole gameplay details in one small place and that can be reverse engineered and even changed to allow cheating. Compiled scripts are better in this side because the way they're represented is obscure - especially if it's a proprietary scripting language.
ماذا تقول يا رجل 😲 ليس هناك أسهل من تحويل مكتبة الربط الديناميكي لتربط ستاتيكياً بالكود النهائي للعبة. تستطيع فعل ذلك في فيجوال ستوديو بسهولة تامة. ما يصل اللاعب النهائي هو ملف تنفيذي وحيد يحوي كل الكود دون أن يظهر منه إجراء واحد للخارج. أنا لا أتفق معك في هذه النقطة.
أشكرك على ملاحظاتك أخي أمين...
السلام عليكم ورحمة الله وبركاته
وسام البهنسي
مبرمج في إنفيديا وإنفريمز
مبرمج في إنفيديا وإنفريمز
فراس أسعد
مشاركة 3
في 22 يناير 2012 09:15 ص
لقد استمتعت بقراءة آراء الأعضاء ووجدت الموضوع مفيدا جدا. لا أدري أي وجهة نظر انحاز لها لأن كل طرف قدم حججا مقنعة.
يبدو أن جون كارماك يوافق وسام في الرأي:
http:/
و هذا أمر مثير للاهتمام لأن لديه خبرة طويلة في كتابة المحركات التي تستعمل البريمجات. و لكن جون كارماك معروف بحبه لدفع محركات الألعاب الى حدودها و هذا قد يختلف من لعبة لأخرى. لا أظن أنه يجب التقليل من فائدة البريمجات للمصممين. بالتأكيد من يتعلم لوا يستطيع تعلم لغة السي لو أراد، و لكن مصمم الألعاب مهتم أكثر بخوارزميات القتال و المقاطع السينمائية و ليس بالمؤشرات و أي هيكل بيانات يجب استخدامه لتمثيل قائمة ما.
بالتحديد يبدو أن أنريل سكريبت مثال سيء لاستخدام البريمجات. و أنا أوافق أن ليس كل محرك ألعاب يحتاج لغة كهذه. و لكن تخيل لعبة مثل skyrim أو civilization بدون استخدام بريمجات. في هذه الألعاب الفصل بين مبرمجي المحرك و مصممي المراحل واضح جدا، و يمكن للاعبين تصميم مراحلهم الخاصة. الفرق بين البرمجة في لغة مثل لوا أو بايثون و لغات مثل السي و مشتقاتها كبير، و لتقلل المسافة بينهم عليك تصميم مكتبة شاملة و فرض معايير برمجة مثل استعمال المؤشرات الذكية أو عدم استخدام القوالب. مبرمج السي++ الجيد يستطيع كتابة برامج بدون استعمال new أو delete و لكن يبدو أنك محظوظ بالعمل مع مبرمجين مميزين لأنه من خبرتي فإن نسبة كبيرة من المبرمجين لا يصلون إلى ذلك المستوى من المهارة (خاصة اذا كان اهتمامهم منصب على التصميم و ليس البرمجة).
وجهة نظري أن الموضوع يعتمد على نوع اللعبة و خبرة المبرمجين و المصممين و الموازنة بين الايجابيات و السلبيات التي ذكرتها. أما بشأن بطء هذه اللغات، فأعتقد أن الفكرة هي أن 80% من بطء اللعبة مصدره 20% من الكود و يجب أن لا تكون البريمجات جزء من ال20%. من الأفضل استعمال لغات موجودة و مثبتة مثل لوا أو بايثون أو جافاسكربت.
لا أرى أن هناك جواب واحد يناسب كل الألعاب، و لكن ربما الألعاب التي تعتمد على المضمون بشدة مثل ألعاب الRPG و الاستراتيجية تستفيد أكثر من البريمجات من الألعاب التي تعتمد على المحرك مثل ألعاب السباق.
يبدو أن جون كارماك يوافق وسام في الرأي:
http:/
و هذا أمر مثير للاهتمام لأن لديه خبرة طويلة في كتابة المحركات التي تستعمل البريمجات. و لكن جون كارماك معروف بحبه لدفع محركات الألعاب الى حدودها و هذا قد يختلف من لعبة لأخرى. لا أظن أنه يجب التقليل من فائدة البريمجات للمصممين. بالتأكيد من يتعلم لوا يستطيع تعلم لغة السي لو أراد، و لكن مصمم الألعاب مهتم أكثر بخوارزميات القتال و المقاطع السينمائية و ليس بالمؤشرات و أي هيكل بيانات يجب استخدامه لتمثيل قائمة ما.
بالتحديد يبدو أن أنريل سكريبت مثال سيء لاستخدام البريمجات. و أنا أوافق أن ليس كل محرك ألعاب يحتاج لغة كهذه. و لكن تخيل لعبة مثل skyrim أو civilization بدون استخدام بريمجات. في هذه الألعاب الفصل بين مبرمجي المحرك و مصممي المراحل واضح جدا، و يمكن للاعبين تصميم مراحلهم الخاصة. الفرق بين البرمجة في لغة مثل لوا أو بايثون و لغات مثل السي و مشتقاتها كبير، و لتقلل المسافة بينهم عليك تصميم مكتبة شاملة و فرض معايير برمجة مثل استعمال المؤشرات الذكية أو عدم استخدام القوالب. مبرمج السي++ الجيد يستطيع كتابة برامج بدون استعمال new أو delete و لكن يبدو أنك محظوظ بالعمل مع مبرمجين مميزين لأنه من خبرتي فإن نسبة كبيرة من المبرمجين لا يصلون إلى ذلك المستوى من المهارة (خاصة اذا كان اهتمامهم منصب على التصميم و ليس البرمجة).
وجهة نظري أن الموضوع يعتمد على نوع اللعبة و خبرة المبرمجين و المصممين و الموازنة بين الايجابيات و السلبيات التي ذكرتها. أما بشأن بطء هذه اللغات، فأعتقد أن الفكرة هي أن 80% من بطء اللعبة مصدره 20% من الكود و يجب أن لا تكون البريمجات جزء من ال20%. من الأفضل استعمال لغات موجودة و مثبتة مثل لوا أو بايثون أو جافاسكربت.
لا أرى أن هناك جواب واحد يناسب كل الألعاب، و لكن ربما الألعاب التي تعتمد على المضمون بشدة مثل ألعاب الRPG و الاستراتيجية تستفيد أكثر من البريمجات من الألعاب التي تعتمد على المحرك مثل ألعاب السباق.
Ahmed Hashem
مشاركة 4
في 04 سبتمبر 2012 10:35 م
السلام عليكم
ممكن يكون الموضوع قديم بعض الشىء ولاكنى اود المشاركة خسن لنرى مذا سأقول (ارجو ان لا ابالغ)
انا صراحة اعمل على نظام اسمية بال GameBase وهو عبارة عن استخدامى لمحرك اليونتى وعمل قاعدة او بالاحرى محرك فرعى داخل المحرك لمعظم انواع الالعاب (MMORPG - RPG - Action - FPT - TPS - Strategy) وهو يعتبر قائم على الحل الذى ذكرتة وهو ال DLL كمل بة اساسيات اللعبة
وانا او بالاحرى نحن بكونى لست لوحدى انا معى فريق صغير شوية مكون من اخى التؤم واخى الصغير نعمل عمل فردى ومتقطع ولكننا والحمد لله وصلنا الى مستو جيد فى تصميم الالعاب والتحليل الذى فية قدر من التعمق لهذا المجال لنجاحنا فى عمل لعبتنا ال MMORPG التى تعتبر - الحلم الكبير - كما اسميهاوالتى نعمل بها بواسطة محرك اليونتى الرائع - من وحهة نظرى -
ممكن يكون الموضوع قديم بعض الشىء ولاكنى اود المشاركة خسن لنرى مذا سأقول (ارجو ان لا ابالغ)
انا صراحة اعمل على نظام اسمية بال GameBase وهو عبارة عن استخدامى لمحرك اليونتى وعمل قاعدة او بالاحرى محرك فرعى داخل المحرك لمعظم انواع الالعاب (MMORPG - RPG - Action - FPT - TPS - Strategy) وهو يعتبر قائم على الحل الذى ذكرتة وهو ال DLL كمل بة اساسيات اللعبة
وانا او بالاحرى نحن بكونى لست لوحدى انا معى فريق صغير شوية مكون من اخى التؤم واخى الصغير نعمل عمل فردى ومتقطع ولكننا والحمد لله وصلنا الى مستو جيد فى تصميم الالعاب والتحليل الذى فية قدر من التعمق لهذا المجال لنجاحنا فى عمل لعبتنا ال MMORPG التى تعتبر - الحلم الكبير - كما اسميهاوالتى نعمل بها بواسطة محرك اليونتى الرائع - من وحهة نظرى -
NTSoft Inc