ما هو الفرق بين محرك ألعاب الأندلس و openGL ؟
وما الفائدة المرجوة من هذا المشروع ؟
شكراً
ما هو الفرق بين محرك ألعاب الأندلس و Opengl ؟
السلام عليكم .
- محرك الألعاب ( أياً كان اسمه ) .
باختصار : عبارة عن وحدة(وحدات) برمجية كل منها مسؤول عن ملية ما :
- وحدة مخصصة للتعامل مع النظام ( انشاء النافذة + استقبال المدخلات من الكيبورد والماوس و عصا الالعاب .. الخ ).
في نظام ويندوز عادةّ نستخدم Win32 APIs أو أي مكتبة تتيح لنا القيام بذلك .
- وحدة للرسوميات .
هنا نقوم بتغليف OpenGL أو D3D .. بحيث نعزل المستخدم النهائي عن هذه المكتبات ولايضطر لتعلمها .. كل ماعليه أن يتعلم المحرك .. وهذا أسهل .. فبدلا من كتابة 40 سطر من أجل رسم مكعب واكسائه .. يمكن عمل ذلك بسطرين .
وممكن تستخدم مكتبة رسومية خاصة بك من الصفر وحينها نصف المكتبة بأنها تعتمد على Software في الرسم ولاتستغل قدرات كرت الرسوميات .
- وحدة الفيزياء :
تغليف مكتبة فيزيائية .. أو انشاء مكتبة فيزيائية من الصفر .
- وحدة صوتيات :
لتشغيل الاصوات .. نقوم بتغليف OpenAL او FMOD أو Direct Sound .. للقيام بهذه المهمة .
في الاخير ينتج لنا محرك ألعاب متكامل يحوي على كلاسات للرسم والادخال والصور والتأثيرات والاصوات والفيزياء والذكاء ويدير كل هذه الامور .
بينما OpenGL تقوم بالرسم فقط من الصفر .
تطبيق طمأنينة ، نسخة بيتا على أندرويد
عبدالله الشمّري - Al-Shammari
twitter @abshammeri
abshammeri AT gmail.com
github : abshammeri
أتمنى أن يتم التفريق بين محرّك الرسوميات ومحرّك الألعاب، محرّك الرسوميات مهمته الرسم وكل ما يتعلّق به، ولكنه غير مصمّم ولا يحتوي على ما يساعدك على عمل الألعاب نفسها، وهنالك الكثير من الأشياء التي تحتاجها الألعاب بجانب الرسم.
الهدف الرئيسي من محرك الألعاب هو صنع الألعاب، المزايا التي يجب أن يمتلكها هكذا محرك: دعم للفيزياء، مكتبات مساعدة للذكاء الصناعي، إطار عمل للألعاب، دعم للنصوص البرمجية، مجموعة أدوات مفيدة، إمكانات رسم الـ GUI، ...إلخ
معظم المحركات الموجودة تكون إما محرّك يستطيع رسم المشاهد الرائعة ولكن لا يستطيع عمل أكثر من Demo، أو محرّك بإمكانات رسم بسيطة نسبياً ولكن يستطيع عمل لعبة كاملة.
من الصعب جداً الموازنة بين الاثنين، حتى بالنسبة للمحركات التجارية، لذلك فتجد عادة إن كود محركات الرسوميات على أعلى مستوى إلا إن عمل لعبة مسألة صعبة كثيراً بل من الأسهل عمل اللعبة من الصفر، بينما كود محركات الألعاب مكتوب بطريقة سيئة ولكن عمل لعبة باستخدامها عملية سهلة وسريعة.
برأيي، ينقسم المطوّرين إلى فريقين، الفريق الأول لنسميه فريق Ogre3D يؤمن بحيل البرمجة وهندستها المتقدمة لتوصله إلى المحرك الذي يتمنى عمله يركز هذا الفريق في مسألتي المزايا والأداء الرسوميين ولكن لا يهتمون كثيراً للأشياء الأخرى، أما الفريق الثاني ولنسميه فريق GameMaker يهتم بسرعة وسهولة تطوير الألعاب ولكن مع إهمال الأداء وتقليل المرونة بشكل كبير ولا يبدو إنهم يتضايقون من استخدام تقنيات أخر لعبة تجارية استخدمتها كانت في التسعينيات.
ولكن ماذا لو صنعنا محرك يمتلك قدرات وسرعة Ogre3D ولكن سهولة وعملية GameMaker؟؟ هكذا محرك سيكون من مستوى تجاري، وليس هنالك محرك من هذا المستوى مجانّي مفتوح المصدر حتى هذه اللحظة.
اقتباسهنا نقوم بتغليف OpenGL أو D3D .. بحيث نعزل المستخدم النهائي عن هذه المكتبات ولايضطر لتعلمها .. كل ماعليه أن يتعلم المحرك .. وهذا أسهل .. فبدلا من كتابة 40 سطر من أجل رسم مكعب واكسائه .. يمكن عمل ذلك بسطرين .
هذه النقطة قد تكون أسهل شيء يمكن عمله، لأن المسألة مجرد تغليف كما ذكرت، ولكن أتمنى أن تضعوا في حسابكم أولويات تمثل تحدياً أكبر، مثل إنشاء نظام ملفات عملي، حل مشكلة إدارة الموارد، إنشاء نظام توزيع أحداث جيد (Signal/Slot مثلاً)، أشياء عامة ليس لها علاقة بالرسوميات، ولا حتى الألعاب مباشرة، ولكن يجب وجودها.
تم تعديل هذه المشاركة بواسطة SandHawk في 23 سبتمبر 2009 في 00:16
كلامك صحيح أخي .. أفهم تماما ما تقصد .
التوجه هو نحو صناعة محرك ألعاب وليس محرك رسومي فقط .
هناك الكثير من الأمور التي سنناقشها بعد انتهاء المرحلة الاولى ( أو عند نهايتها .. لكن لا أعرف كيف سنقوم بذلك حتى الان :) ):
resource management
scene graph
هذا ما أعرفه .. في مجال ادارة المحرك .. وقد توجد أمور أخرى .
لكن التدرج في مثل هذه الامور جيد .. خاصة وأننا لم نقم بعمل لعبة قوية .. حتى الان .. لذلك لانملك الخبرة الكافية بعيوب المحركات .
فقط نريد أن نتدرج .
اضافة :
شخصيا .. أميل الى التركيز على الانتاج ثم النظر بعيوب الطريقة التي استخدمناها .. بدلا من أن نركز على الطريقة ونهمل المنتج النهائي ... يبدو أني سأتفلسف :D .. الى هنا أتوقف .
تم تعديل هذه المشاركة بواسطة الشمري في 23 سبتمبر 2009 في 00:24
تطبيق طمأنينة ، نسخة بيتا على أندرويد
عبدالله الشمّري - Al-Shammari
twitter @abshammeri
abshammeri AT gmail.com
github : abshammeri
الشمري كتب:شخصيا .. أميل الى التركيز على الانتاج ثم النظر بعيوب الطريقة التي استخدمناها .. بدلا من أن نركز على الطريقة ونهمل المنتج النهائي ... يبدو أني سأتفلسف :D .. الى هنا أتوقف .
لا تتوقف، هذا مبدأ جيد جداً.
هندسة البرامجيات (تحديداً الاتجاه الحديث) تميل لإعطاء تطوير البرامج بعداً فلسفياً يعطي عملية التطوير طعماً خاصاً.
بعض المطورين قد وصلوا لمراحل متقدمة في هذه النقطة.
ولكي لا يقول أحد بأني أتفلسف ;) لمن لم يره، أعطيكم حكم بايثون (Zen of Python) التي وضعها أحد مطوّري لغة بايثون (Tim Peters) أمامه والتزم بها:
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
تم تعديل هذه المشاركة بواسطة SandHawk في 23 سبتمبر 2009 في 01:15
شكراً لردودكم
أفهم من كلامكم أنه لا يوجد مكتبة كاملة للتعامل مع الألعاب حتى الآن ؟
ولا حتى DirectX ؟؟؟
اقتباسSpecial cases aren't special enough to break the rules.
ههه ... هذه هي التي ستتصدر خطة العمل في محركنا :-) .
اقتباسولا حتى DirectX ؟؟؟
طبعا .. لايوجد شيء كامل ..
الى هنا أتوقف وأعود الى مشروع محرك الأندلس .
تطبيق طمأنينة ، نسخة بيتا على أندرويد
عبدالله الشمّري - Al-Shammari
twitter @abshammeri
abshammeri AT gmail.com
github : abshammeri