أردت أن أتدخل هنا فيما يخص ببيئة التطوير المستعملة

اذا كنا لن نستعمل الفريمورك 3.5 أو أي من التقنيات الجديدة على vs2008 فأرى أن نكتفي بالاصدار 2005 حتى يتسنى للكل (تقريبا ) المتابعة
كنت قد قرأت في موضوع متعلق بالمشروع عن وجود جزء يتم كتابته بالc++ والعمل يكون على السي شارب

اظن أن نسخة الاكسبرس لا توفر ضم مشروعين مختلفين في solution واحد إلا اذا كان القصد هو انشاء مكتبة على الc++ وعمل تغليف لها فيما بعد على السي شارب

من جهة أخرى فان عملية التحويل للمشروع تكون من نسخة أقدم وليس العكس يعني سيجد الكثير مشكلة عند قراءة المشروع المكتوب بالاصدار 2008
على اصدارات أقدم

لذلك أرى مما سبق (رأي شخصي) ان يكون الاعتماد على vs2005 حتى يتسنى لنا المتابعة

بالتوفيق للجميع

وانا اشجع هذا الرأي كمان وذلك الى حيث انتشار .net2008 وحصول الجميع عليه, ويمكن بعد ذلك تحويل المشروع الى net2008 في اي وقت
اريد ان اسأل هل ملفات اللعبة التي معكم تقبل التطوير على .net?
------------------------------------------------------------------------------------------------------------------------------------------------------

أجد اننا نتحدث عن المشروع من جهة لغة البرمجة ومن جهة التصاميم, ولم تتوضح الصورة بعد بما تريدون ان تفعلون بالمشروع
هل هو تطوير الشكل والصوت والحفاظ على المراحل كما هي؟
هل تطوير اللعبة ككل؟
هل تطويرها وتغيير المراحل؟
ما هي مدة المشروع؟
متى سنبدأ؟

يرجى توضيح ما يفكر به القائمين على الموقع

صحيح. لكن هذا الوضع نفسه موجود مع VS.NET 2005 أيضاً. إن كان الأعضاء سيستخدمون نسخ Express فأنا لا أرى سبباً واضحاً يمنعنا من استخدام 2008. هل هو حجم الداونلود؟ أعتقد أن أسواقنا تزخر بأقوى وأحدث النسخ، وهي تنتظر من يلتقطها وبسعر بخس.
 
سبب حديثي هذا لأن مبرمجي #C سيستخدمون مكتبة NET. الإصدار 3.5 (نود استخدام LINQ). إن كنتم تصرون على استخدام 2005، فلا مانع لدينا أيضاً، لكن في النهاية سنخسر خبرة جميلة بالتعرف على أحدث الإمكانيات البرمجية في مجالنا. ما رأيكم؟




أنا آسف، وأعتقد أنه من حقكم معرفة الأهداف الحالية حتى وإن كانت قد تتغير. قمنا بالفعل بتجهيز مخططاً لمهام المشروع لجميع الأقسام. إلا أننا فضلنا الانتظار كي نعطي الفرصة لمزيد من الأعضاء للانضمام، وهذا سيؤثر طبعاً على مهام المشروع، فبازدياد العدد ستتاح لنا مهام أكثر، وسيتوسع المخطط. لذا لم نرد طرحه إلى أن يكتمل. 
بالعدد الحالي فإن ما ننوي عمله بشكل عام هو الآتي:
* بناء مزايا لعب جديدة في اللعبة، وتعديل المزايا الحالية لتصبح أفضل.
* إعادة تصميم رسوميات اللعبة لتصبح أكثر جاذبية. والحديث عن هذه الناحية الآن جاري في قسم الرسوميات.
* إعادة تصميم مراحل اللعبة بشكل كامل، وتطوير نهايات أخرى للعبة (لهؤلاء الذين أنهوا اللعبة الحالية ورؤوا النهايات).
 
كما نرى فإننا سنغير نواحي كثيرة من اللعبة هنا. وهذا سيتطلب جهداً برمجياً كبيراً أيضاً. والتفاصيل سنطرحها قريباً إن شاء الله عند بداية المشروع.
 
العمل البرمجي سينقسم إلى جانبين: قسم بالـ ++C وقسم بالـ #C.
ميكانيكيات اللعبة والمؤثرات الخاصة الرسومية كلها ستكون بالـ ++C. أما بالـ #C فسيكون هناك جهداً كبيراً لبناء برنامج تصميم المراحل الذي سنستخدمه لتصميم مراحل جديدة للعبة.
 



لم نحدد مدة المشروع كاملة لأننا لا نملك وقت الأعضاء بعد. وكما رأينا هناك فترة امتحانات قريبة، ولن يستطيع الجميع الالتزام ببرنامج زمني صارم لكامل المشروع. بدلاً من هذا فإننا سنقوم بإعطاء مدة زمنية على الأجزاء المرحلية من المشروع، نستطيع من خلالها تدارك أي تغيرات تحدث في وقت الفريق بشكل مرن. المرحلة الأولى مقدرة لدينا الآن بمدة عشرة أيام من البداية، والتي ستكون إن شاء الله خلال الأيام الأربعة القادمة. وسنقوم بتأكيد الأسماء خلال هذه الفترة بشكل نهائي إن شاء الله، فترقبوا... 
(سأضع نسخة من هذا الرد في موضوع المشروع الأساسي كي تقرؤه جميع الاختصاصات الأخرى)
 
تحياتي

السلام عليكم




هل تعنى أستاذ وسام أن ال Depends لا يعطينا معلومات عن المكتبات المرتبطة مع البرنامج ديناميكيا dynamic linking
وهو بذلك لا يفيد الا فى حالة البرامج التى تعتمد بصفة كبيرة على ال static linking
أرجو التوضيح

أيضا أتمنى الاتفاق على نسخة ال visual studio التى سنعمل عليها جميعا
وأنا مع رأى الاستاذ وسام بأنه يفضل استخدام نسخة 2008 وذلك لاتاحة استخدام التقنيات الجديدة للتسهيل وأيضا
لمتابعة اخر التقنيات الجديدة

وجزاكم الله خيرا ونحن فى انتظار بداية المشروع ان شاء الله
والسلام عليكم

ليس هذا ما قصده. Depends يستطيع إعطاء معلومات عن المكتبات المرتبطة ديناميكياً فقط!! أما المكتبات المرتيطة غير ديناميكياً (static linking libraries) فلا يقوم Depends بكشفها وذلك لأن هذه البرنامج لا "يعتمد" على وجود هذه المكتبات لأنها متضمنة في ملف البرنامج التنفيذي.
 
لكن مالا يستطيع Depends كشفه هو تلك المكتبات التي يقوم البرنامج بـ "تحمليها" ديناميكياً. لاحظ أني قلت تحميلها وليس "ربطها". كمثال على ذلك المكتبات التي تحمل عن طريق الإجراء LoadLibrary الموجود في الـ Win32 API. أو في حالة D3D عند نداء إجراء COM المسمى CoCreateInstance والذي يقوم بتحميل المكتبة (حسب الـ version المطلوب) وربطها مع البرنامج.
هذا بالطبع شيء منطقي لأن Depends لا يقوم بتشغيل البرنامج وإنما ينظر إلى ملف البرنامج التنفيذي نفسه. وبالتالي لن يستطيع كشف وجود نداءات لإجراءات تحميل المكتبات في البرنامج.

السلام عليكم
 
جزاكم الله خيرا على التوضيح
 
اذن ما فهمته ايضا ان ال visual studio يتفوق عليه فى انه عند عمل attach process كما سبق وشرح
الاستاذ وسام فكأن البرنامج تم فتحه بعد مروره على ال visual studio وبالتالى فيمكنه معرفة المكتبات
التى يقوم البرنامج او العبة بتحميلها على عكس ال Depends كما أشرت
 
أيضا هذا مشابه جدا حينما نقوم بعمل مراقبة لحالة الموارد المستهلكة وكذلك امور اخرى باستخدام ال PIX tool
حيث اننا نقوم بفتح اللعبة مثلا عن طريق ال PIX وبالتالى فانها تراقب كيف يقوم برنامجنا باستدعاء اوامر الرسم مثلا
وبالتالى فان ال PIX أيضا يمكنه معرفة المكتبات التى يحملها برنامجنا ان اراد
 
والسلام عليكم

بالضبط.
 
ملاحظة: إذا كان هناك تتمة للنقاش فيستحسن فتح موضوع جديد له قبل يرانا وسام و يخبرنا عن "أهمية المحافظة على التنظيم الموضوعي المنطقي في المنتدى"☺ أمزح فقط...