النص الأصلي والترجمة مرخصة بموجب CC-BY.
في الوقت الحالي ، تضم Battle for Wesnoth 109 فنانًا مختلفًا ، لذا يعرف Jetrel ما يتحدث عنه.
المصدر .
بالإضافة إلى الأطروحة الرئيسية ، ستتطرق المقالة أيضًا إلى القضايا التالية:
- ما الذي يجذبنا للبرمجة؟
- ما هو خطر محرري الرسوم لتعديل؟
- كم من الوقت ينتظر المبدعون؟
- هل يحتاج الفنان إلى معرفة البرمجة؟
- كم عدد الفنانين الرسميين الذين تحتاجهم؟
- كيف تجد ذلك؟
- ماذا تفعل بالنجوم؟
من غير المحتمل أن يسجل المؤلف في حبري بشكل مستقل. ولكن إذا كانت لديك أسئلة ، يمكنني توجيهها. لقد تلقيت بنفسي الموافقة على الترجمة من خلال قناة Frogatto في الخلاف .
سيتم تقديم ما يلي بصيغة المتكلم.
لقد سُئلت عدة مرات على IRC عن هذه المقالة ، وأخيراً تمكنت من كتابتها. قد يكون هناك بعض الأخطاء المطبعية فيه. لا تتردد في وضع إشارة مرجعية عليها ومناقشة الأشياء التي تعتقد أنه يجب إضافتها إلى هذه المقالة. على الأرجح أنها ليست شاملة بما فيه الكفاية.
في وقت كتابة هذا التقرير (2009) ، كانت مشاريع الألعاب مفتوحة المصدر تحتوي على فائض من المبرمجين ونقص مؤلم في الفنانين. وبالتالي ، أثر ذلك سلباً على المجتمع. تخجل العديد من ألعابنا من عرضها للجمهور. إنها جذابة فقط لعدد قليل من اللاعبين الذين لا يهتمون بالمظهر.
المصدر المفتوح والمجتمع المستقل في وضع العنب الأخضر. بمعنى آخر ، يعتبر المظهر الجيد السمة المميزة للألعاب التجارية السيئة. في بعض الأحيان يعود الأمر إلى عداء بسيط للرسومات الجيدة. لن يدافع هذا المقال عن أهمية الرسومات. لقد ثبت علميًا أن معظم الأشخاص هم بصريات ، مما يعني أنهم يقدرون الصورة الجميلة في الألعاب. إذا لم تكن مستعدًا لقبول هذا ، فأنت تقود نفسك عمدًا إلى غيتو صغير. لا يمكنني مساعدتك في ذلك - تفترض هذه المقالة أنك تريد صنع لعبة يستمتع بها أكبر عدد ممكن من الجمهور.
من الصعب المجادلة بأنه في الكثير من الألعاب التجارية ، تغطي الرسومات الجيدة أسلوب اللعب السيئ ، ولكن السبب في ذلك هو ضيق المواعيد النهائية ، والميزانيات المحدودة ، وعدم وجود "الاختيار الطبيعي" لتصفية الألعاب التي ليست ممتعة للعب. تغرق العديد من الشركات الألعاب بالمال والرسومات ، ثم تجد صعوبة في الاستمتاع بها. يأتي هذا الإدراك بعد إنفاق موارد ضخمة. عادةً ما تُترك غير مكتملة لأن المديرين التنفيذيين لا يستطيعون إعادة التصميم أو يخشون فقدان الأعمال الفنية باهظة الثمن التي لن تُستخدم بعد تغييرات كبيرة.
الخبر السار هو أن المصدر المفتوح محصن ضد هذه الأنواع من المشاكل بشكل افتراضي.
يعني جوهر المصدر المفتوح أن اللعبة مفتوحة المصدر ستصبح شائعة فقط إذا كانت ممتعة للعب. هذا هو السبب في أن الناس سيقضون وقتًا في الفن لألعاب ممتعة. بالإضافة إلى ذلك ، لا يوجد لدى المصدر المفتوح مواعيد نهائية صارمة أو ميزانية صارمة ، لذا يمكنهم تحمل إعادة كل ما يحتاجون إليه لجعل اللعبة ممتعة في أوقات فراغهم. لإرضاء الفنانين والحصول على فن جديد ، يجب أن تعتز بالفن الحالي حتى تكمل إعادة البناء وبناء أساس لميكانيكا اللعبة الشيقة.
المفتاح لجذب المبدعين هو جذب عدد كبير من اللاعبين وإبلاغهم أنك على استعداد لقبول مساهماتهم. إحصائيًا ، ستكون نسبة معينة من اللاعبين مبدعين. إذا كنت تستهدف ثقافة فرعية معينة ، فسيكون هناك عدد غير متناسب من الأشخاص المهتمين بالفنون البصرية (مثل الخيال أو الخيال العلمي). من أجل الاحتفاظ بالمبدعين ، عليك أن تحفزهم. أنت لا تدفع للمبدعين ، لذا فإن الدافع هو الطريقة الوحيدة لإبقائهم في مشروعك. بمجرد توقفهم عن تلقي المتعة أو التقدير ، سيخرجون من الباب.
اصنع لعبة ممتعة
للحصول على الكثير من اللاعبين ، وبالتالي المبدعين ، اصنع لعبة ممتعة حقًا. انه صعب. يمكن كتابة العديد من الكتب حول هذا الموضوع ، ولكن هذا هو السبب الرئيسي.
استخدم تنسيقات الملفات الشائعة
عامل مهم آخر هو استخدام أكثر التنسيقات المفتوحة. من خلال الانفتاح ، لا أعني مصطلحات المصدر المفتوح ، بل أعني بالأحرى "الأشكال التي يعمل بها الناس عادة". غالبًا ما يكونون نفس الشيء ، لكن ليس دائمًا. من المهم جدًا أن يتمكن الأشخاص من إعداد الفن تمامًا للعبة بدون أدوات خاصة وفي نفس الوقت يمكنهم الدخول إلى اللعبة ورؤية النتيجة على الفور أثناء العمل ، دون مساعدة إضافية. عادةً ما يعني ذلك استخدام تنسيقات مثل OGG أو PNG ، بدلاً من التنسيقات ذاتية الصنع ، كما هو الحال في العديد من ألعاب التسعينيات. إذا كتبت تنسيق الموسيقى الخاص بك مثل MOD أو طريقتك الخاصة في تخزين أقنعة البيت ، فلن يمتلك أي شخص الأدوات اللازمة لإنشاء فن في لعبتك. سيتعين عليهم الخوض في صندوق الأدوات الخاص بك. سيؤدي ذلك إلى إبعاد نسبة كبيرة من المشاركين المحتملين ،لأن معظم الناس "يتذوقون الماء" في إبداع الفن بمجرد العبث بنسختهم من اللعبة.
بالإضافة إلى ما سبق ، فإن معظم المبدعين المهتمين بتطوير لعبة ما لديهم بالفعل مهارات تعديل. يجب أن يدعم محركك التعديلات. يجب أن يكونوا قادرين على إنشاء مستوياتهم ومخلوقاتهم وشخصياتهم. ينجذب المبدعون بشدة إلى جزء اللعبة الذي يسمح لهم برواية قصتهم. يمكنك تحقيق ذلك باستخدام محرر رائع أو تنسيق تخزين نصي ميسور التكلفة لكل شيء. معظم المبدعين في تطوير الألعاب جيدون بما يكفي باستخدام جهاز كمبيوتر لتحرير ملفات البيانات النصية. سيكون محرر اللعبة أفضل لأنه يمكن استخدامه من قبل الجميع تقريبًا ، لكن تنفيذه يستغرق وقتًا طويلاً. خاصة للمحتوى الذي نادرًا ما يتغير. خطر الكأس المقدسة في إنشاء واجهة المستخدم الرسومية "لكل شيء" هوأن بعض أجزاء اللعبة لا تزال تتطلب البرمجة ، بغض النظر عن كيفية تمثيلك لها. لذلك ، من الأفضل برمجتها بالطرق التقليدية. إذا حاولت إنشاء واجهة مستخدم رسومية لهم ، فسوف ينتهي بك الأمر مع لغة برمجة رسومية ، ولكن على الأرجح ستحدث كارثة.
إن تقليل عتبة الدخول للمشاركة في مشروع أمر مهم حقًا. أولاً ، يحتاج الشخص لمحاولة صنع فن من أجلك ، وعندها فقط يمكنه أن يفهم أنه يحبه. في الحياة اليومية ، لا أحد يقرر فعل شيء بجدية وعندها فقط يقع في حبه. في معظم الحالات ، لن يستثمر الناس بجدية في شيء ما ثم يقررون ما إذا كانوا يحبونه أم لا. في البداية ، سيتعرف الشخص على الدرس بشكل سطحي وفقط إذا أحب ذلك ، فهل يتعمق فيه ويستمر في القيام به. إذا لم تتح له فرصة التدليل معه ، فلن يبدأ. هذه هي الطريقة التي بدأ بها معظم المعتدلين رحلتهم - في البداية ، تدليل تافه مع المحرر المدمج ، أثار اهتمامهم ، ثم تكبر الأحداث مثل كرة الثلج. لنفس السبب،بدأ معظم القراء رحلتهم في البرمجة - لقد كتبت شيئًا تافهًا في بيئة ودية ، وقد نجح ذلك ، ودفعتك متعة الإبداع إلى المزيد. الإشباع الفوري مهم حقًا - فهو يخلق الزخم والتحفيز.
الإشباع الفوري ضروري للحفاظ على تحفيز المبدعين. إذا بدأ المبدع في إعداد تحفة فنية لك ، فمن المهم جدًا أن تصل نتيجة العمل إلى السيد في أقرب وقت ممكن. إنه لأمر مثير أن ترى عملك يتم التعرف عليه وإدراجه في البناء الرسمي للعبة. وبالمثل ، والعكس صحيح ، من القاتل أن تعرف أن عملك لا يحتاج إليه أحد. نادرًا ما يفهم المبدعون مدى صعوبة البرمجة ، مما يعني أنهم سيعتقدون أنك لا تستخدم عملهم لأنك لست سعيدًا به. إنه نفس الشيء بالنسبة للفن والكود ، لا يستطيع المبدعون قراءة أفكارك. إذا كنت تخطط لمشاهدة هذا في غضون أسابيع قليلة ، فلن يعلم أحد بذلك. إذا لم تبدأ على الفور في العمل مع الكود أو الفن أو الموسيقى المقترحة ، فلن يفعلوا أي شيء لك بعد الآن. هذه ليست مشكلة لإصلاح الأخطاء لمرة واحدة. لكن هذه علامة سيئة بالنسبة لهؤلاءالذي يرسل لك العينة الأولى وهو مستعد لملء لعبتك بالنماذج والرسومات. تحتاج إلى متابعتها ، وتحتاج إلى العمل معهم وإبقائهم مهتمين. سيضيع جميع المشاركين الذين يمكنهم ملء اللعبة تقريبًا إذا لم تعد إليهم في غضون أسبوع أو يومين. هذه إحدى الحجج المؤيدة لسياسة RERO (الإصدار المبكر ، الإصدار كثيرًا).
قد لا يكون الأمر واضحًا ، لكن لا يمكن للفنانين تجميع لعبتك. إذا كانت الإصدارات الرسمية أقل من مرة في الشهر أو شهرين ، فيجب عليك تزويدهم بالإصدارات. لا ينبغي أن يكونوا عالقين في غيتو الإصدارات القديمة ، لأنهم سيخرجون من تيار الابتكار في لعبتك. هم أيضًا جزء من الفريق ومن المهم بالنسبة لهم معرفة كيفية دمج عملهم مع التغييرات الجديدة. من المهم أيضًا إصدار إصدارات لمنصتهم. أعلم أن مبرمجي Linux ليس لديهم دائمًا القدرة على الترجمة لنظام التشغيل Mac (على سبيل المثال). ولكن إذا قدم شخص ما تحفة فنية ، فعليك أن تمنحه إجازة. لأنه إذا لم يتمكنوا من لعب لعبتك ، فلن يكونوا مهتمين بمساعدتك. في الممارسة العملية ، أنت بحاجة إلى بنية مسبقة الإنشاء متاحة للجمهور لنظامي التشغيل Mac و Windows. نقطة. إذا لم يكن لديك واحدة ، فلن يلعب 99٪ من مستخدمي الكمبيوتر لعبتك ،مما يعني أنهم لن يهتموا بإنشاء روائع لها. يعد Mac مهمًا بشكل خاص للفنانين والموسيقيين نظرًا لوجود عدد كبير منهم بشكل غير متناسب.
إثبات نجاح اللعبة
يرفض المبدعون بشكل قاطع الخطط بروح "اللانهاية ليست الحد". هناك الكثير من المشاريع المماثلة. معظم ألعاب الفيديو (مفتوحة المصدر والتجارية على حدٍ سواء) هي ألعاب ضعيفة ، وقد حاول معظم المبدعين المهتمين بإنشاء فن لعبة فيديو بالفعل المشاركة في مشروع واحد على الأقل وواجهوا صعوبة في ذلك. ذهب كل عملهم. تكمن المشكلة في أن المبدعين ليس لديهم القدرة على قياس مهارات المطورين. قد ينظر المطورون الآخرون إلى الكود بشكل جانبي ويقررون ما إذا كان موثوقًا أم سيئًا ، لكن معظم المبدعين لديهم فقط كلام شفهي. ليس لديهم فكرة عما إذا كان لديك ما يلزم. لإظهار أنك جاد ، عليك إكمال طريقة اللعب الأساسية. كما هو الحال في Return of the Jedi ، لا تحتاج نجمة الموت إلى إكمالها ، ولكن يجب أن تكون "تعمل بكامل طاقتها".
بشكل عام ، هذه ممارسة جيدة لتصميم اللعبة. أولاً ، تقوم بعمل نموذج أولي سريع وبناء العناصر الوظيفية الرئيسية للعبة في أسرع وقت ممكن. من الجدير بالذكر أنني رأيت عددًا لا يحصى من مشاريع الألعاب التي تم وضعها كنقطة انطلاق لرواد الفضاء المعماريين. إذا كنت ترغب فقط في التركيز على تطوير الذكاء الاصطناعي ولا تهتم بإكمال اللعبة ، فلا تجذب المشاركين المحتملين بادعاءات "تطوير اللعبة". لا تستطيع الإجابة على كلماتك ، على أمل أن كل شيء سينتهي من تلقاء نفسه؟ احترق في الجحيم. الأشخاص الذين يصنعون روائع هم جادون حقًا ، وإلا فإنهم سيضيعون الوقت في محافظهم في صالات العرض مثل DeviantArt. أعلن فقط أنك تصنع لعبة إذا كان هدفك الأساسي هو إكمال لعبة عالية الجودة وخالية من العيوب.
لا تدع رواد الفضاء المعماريين يخيفونك
[تقريبًا. كان هذا الرابط في الأصل ، اتركه كما هو]
يحتاج الفنانون إلى سلطة الرسومات
ربما تعتقد أنك تعرف أفضل ما يجب أن تبدو عليه لعبتك. إذا لم تفعل كل الفن بنفسك ، فتخلى عن نواياك. عادة ما يستمتع فنانونك ببعض من أسلوبهم البصري. تذكر أنهم لا يعملون من أجل المال ، ولكن من أجل المتعة. إما أن تتفق معهم ، أو تُترك بدون فن على الإطلاق. هذا مختلف تمامًا عن الألعاب التجارية. أنت لست الرئيس ، ولا يمكنك إخبارهم بما يجب عليهم فعله. يحتاج الفنانون إلى تفويض كامل عن الفن. تمامًا مثل المبرمجين ، يتم تمكينهم من اختيار لغة البرمجة ومعيار الترميز. ستكون غاضبًا بحق إذا أخبرك الفنانون بما يجب تغييره. على أي حال ، فإن طلبات إعادة العمل بسبب الأسلوب غير المناسب ستدمر السحر وتفسد متعة العمل. لا متعة ولا فنان.
إن العثور على فنان لمشروع لعبة يشبه العثور على عروس. كما هو الحال في الحياة الأسرية ، فأنت تريد تجنب الزواج (أو الزواج) من فنان يفعل شيئًا تكرهه. إذا كنت تصنع لعبة فيديو وجاء إليك فنان يعرض عملاً بأسلوب لا تحبه على الإطلاق (على سبيل المثال ، الرسوم المتحركة) ، فقد تحتاج إلى رفضه. من الأفضل القيام بذلك مسبقًا. آخر شيء تحتاجه هو قنبلة موقوتة. إنه اختيار صعب. قد لا يكون لديك فن إذا رفضت هذا الشخص ، لكن من الأفضل أن تكون صادقًا مع نفسك وتحل هذه المشكلة. ربما يجب أن تتحمل أسلوبًا يثير استيائك قليلاً.
أنت بحاجة إلى فنان رئيسي
يمكن أن تنشأ إحدى المشكلات الواضحة عندما يسحب العديد من الفنانين في فريق عربة في اتجاهات مختلفة. ماذا تفعل في هذه الحالة؟ بالضبط نفس الشيء كما هو الحال مع الكود. اختر الشخص الذي يقوم بأفضل عمل (وهو جاد في إنجاز المشروع) واجعله هو الديكتاتور. إذا قام بالفعل بنصيب الأسد من العمل ، فأنت لا تخشى إخافة الأشخاص الذين يختلفون معه. وبالتالي ، فإن كل من يريد المشاركة سيقدم لك روائع أنيقة بنفس الأسلوب والجودة. بعبارة أخرى ، عليك التظاهر بأنك لعبة تجارية. إن الثقة بشخص ما يتمتع بالسلطة والسلطة تؤثر أيضًا بشكل إيجابي على دافع ذلك الخالق. سيعملون عادة بجدية أكبر ويرقون إلى مستوى ثقتك فيما يتعلق بالرسومات.
الخيار الأفضل هو ربط نفس المهووس المتحمس مثلك ، ولكن الذي يريد أن يصنع الرسومات ، وليس الكود. سيكون قادرًا على استدعاء لعبتك بنفسه.
من المهم أن يتمتع هذا الشخص بسلطة إزالة الأجزاء المؤسفة الخارجة عن النمط العام. نعم ، يبدو الأمر مضيعة للوقت ، لكن الشركات التجارية تفعل ذلك طوال الوقت. لذلك ، فإن ألعابهم مصنوعة بأسلوب متكامل واحد. للسبب نفسه ، يرمي المبرمجون القشرة أثناء إعادة البناء. ما عليك سوى القلق من أن المبلغ الإجمالي للمحتوى الذي تمت إزالته لا يتجاوز مقدار المحتوى الذي تم إنشاؤه. نفس المبدأ يعمل مع الكود. أنت لا تتبع نصيحة أول شخص يأتي إلى مشروعك ويصرح بإعادة هيكلة كل شيء. دعه يثبت أولاً أنه يعرف ما يفعله.
يمكن أن يكون لديك أكثر من فنان رئيسي. عندما يقع الفن ضمن فئات واضحة تتطلب مجموعة مهارات مختلفة ، فإن الفنانين سوف يقعون بشكل طبيعي في مجموعات المهارات. العديد من الرسامين المهرة غير أكفاء تمامًا في النمذجة ثلاثية الأبعاد (والعكس صحيح).
لست بحاجة إلى فنانين مفاهيم
على الأقل في شكل تخصص منفصل ومستقل. الفنان المفهوم موجود في ثقافة الشركات التجارية ، والتي يمكنها إغراق قضية "الإبداع" بالمال. هذا هو أعلى شكل من أشكال القيادة. إنهم ينشئون المفاهيم ، وعلى الفنانين الآخرين فهمها وإنشاء أجزاء مفيدة من اللعبة نفسها. عادة ما يكون هذا المستوى من التخصص مضيعة للوقت. بالإضافة إلى أنه يحرم "التابعين" من حقهم في إبداعهم ، وهو أمر ممتع وسبب لمشاركتهم الحرة. لقد طرحوا ذلك في مشاريع تجارية لأنهم يتقاضون رواتبهم ، لكنهم عادة لا يحبونها - يضطرون إلى فعل ما فعله فنان المفهوم بالضبط ولا يُمنحون الفرصة لإظهار ذوقهم الخاص في التصميم.
أنت بحاجة إلى فنانين يقومون بإنشاء صور يمكن استخدامها في اللعبة. بدون هذه ، لن يكون لديك لعبة. لن تكون قادرًا على تطبيق عمل فناني المفهوم على اللعبة. الصور في حد ذاتها غير مجدية. ومن المثير للاهتمام أن المبدعين الذين يمكنهم إنشاء صور مفيدة يمكنهم أيضًا إنشاء فن مفاهيمي. سيستغرق الأمر منهم المزيد من الوقت ، لكن هذا هو الجزء الأكثر متعة في أن تصبح فنانًا. سيكون الجميع تقريبًا هكذا يومًا ما. بالإضافة إلى ذلك ، عادة ما يكون الفريق الفني مبدعًا بدرجة كافية بحيث لا تنشأ ببساطة الحاجة إلى فنان مفهوم منفصل. هذا بالتأكيد كافي لك لضمان المظهر اللائق.
يتطور الفنانون في جو من النقد الفني
هناك عدد كبير من المبدعين المشهورين الذين يعتبرون عملهم "فوق" أي نقد. من الحكمة أن تتعرف على هذه الأشياء وتوجهها إلى الباب في أسرع وقت ممكن. حتى لو كانت جيدة ، فإنها سوف تضر أكثر مما تنفع. تذكر أن البحث عن فنان هو الزواج / الزواج ، مما يعني التواصل المتبادل. بما في ذلك من جانب الفنان. على الرغم من حقيقة أنه في الفنون المرئية ، يعتمد الكثير على وجهة النظر الشخصية والرأي ، يمكن تقييم الكثير من الأشياء باستخدام مقاييس الجودة الموضوعية. يتطلب الأمر مهارة لإنشاء فن جيد ، وبعض الناس سيئون.
كيف يمكن للفن أن يكون جيدًا
[تقريبًا. كان هذا الرابط في الأصل ، اتركه كما هو]
حتى أفضل الفنانين يمكنهم ارتكاب أخطاء فنية في عملهم. على سبيل المثال أطراف من أماكن غير متوقعة ؛ مواقف غريبة وغير طبيعية (لأنها في الواقع ستكون مستحيلة أو متعبة) ؛ المنظور الذي من خلاله ايشريدور في نعش. هذه اللحظات لا تعتمد على الأسلوب البصري أو "الأفكار العميقة" للفنان. تحدث الأخطاء لأن المؤدي أخطأ. الصورة التي بها أخطاء مثل هذه تبدو سخيفة ، حتى بالنسبة للمؤلف ، بمجرد أن يدرك خطأه. يجب أن يحتفظ الناس بآرائهم حول الأسلوب لأنفسهم ، لكن النقد الصحي للأخطاء الحقيقية سيفيد الجميع. هذا الجو سيجعل فنك يبدو أفضل. سيسمح هذا لفنانيك بالنمو. سيحصل المبدعون على انطباع بأنهم يعاملون معاملة عادلة. يشجع هذا الحوار الصحي حول إنشاء فن لمشروعك ، وهو أفضل بكثير من تعليقات "الوظيفة الرائعة" ذات السطر الواحد غير الطبيعية عند مناقشة مقترحات جديدة.
باختصار ، عامل المبدعين (الفنانين والملحنين) كشركاء متساوين لك في تطوير اللعبة وفي يوم من الأيام ستجد مجنونًا مثلك تمامًا. للعثور عليه بنجاح ، تحتاج إلى فهم مصدره ، وبذل جهودك لتزويده ببيئة يسهل الوصول إليها. تذكر ، إذا عرض شخص ما لعبتك بضع سنوات من العمل ، فستكون "له" كما هي "لك".
سؤال وجواب
لماذا لا تجعل الرسومات قابلة للتحويل؟ ثم لن يرى أسلوبًا لا يحبه.
النص الأصلي
In general, a major software-development principle we held when working on Wesnoth (and which I think is generally pretty smart) was: «options are bad».
Every option in a software program is another code path you have to support, and the combinatorial complexity of multiple code paths, when it comes to testing and all sorts of similar «hidden costs» of doing development, really adds up.
So you don't want to accept multiple kinds of art, and gate each kind of art behind an option flag which users (or the author) can turn off.
It's bad because not only does it increase the support costs of the software, but it also makes it harder to achieve the goal of having a single, coherent art set for the project you're on, because it severely «confuses» your messaging to new contributors.
Ultimately if you've got a game that only has a portion of the art done, your game's mere existence is the best «help wanted» ad for getting additional art. But a critical part of asking for this additional art is a detailed description of what you need to do to match the game's current style.
The thing is — just existing is usually enough. «A picture is worth a thousand words». You don't need to waste a huge amount of time explaining what you want if you've got a large body of examples.
But — if these examples severely contradict themselves, then you're in for a lot of pain. If you've got two radically different visual styles, it's very difficult to explain to new contributors «which style» you'd like the game to actually be in.
All of a sudden you go from a hands-off, «no work for the project lead» matter of just letting the art speak for itself, to having to be deeply, personally involved in steering people.
— Alternate interpretation: It's possible you're suggesting a scenario in which someone's offering to make art for the game in a single, coherent style, and this is a situation where the entire game would get art, but you, the developer, would hide the art from yourself.
At the risk of being impolite, this is absolutely insane.
Which is to say it's «impossible» — there's an enormous time-cost and ongoing maintenance cost of time you'll have to spend getting the graphics to display correctly, and making sure they continue to display correctly as development continues and features get added and removed.
In almost all cases where this has happened (dwarf fortress being a key example), these external «artists» essentially did an enormous amount of programming to make their work viable.
Dwarf fortress mods operate by literally doing direct memory access and looking at the RAM state of the app as it runs, since there's no mod API or anything, but even if you did have a mod API — somebody has to pay the enormous cost of writing the code to get the entire graphics-drawing layer working correctly, and the complexity of doing this is usually equivalent to writing an entire game of its own.
… I mean — any game where this succeeds has essentially «won the lottery», and is an extremely dangerous target to imitate the habits of, because it succeeded not due to «good developer practices» but because it got insanely lucky.
A dangerous thing when looking at the dev practices of other games, especially «popular, successful» games, is a phenomenon called «survivor bias».
Survivor bias is when someone looks at the behavior of a very successful thing, and instead of thinking «oh, they were really successful, so they were able to survive even though they made a bad choice» — instead, one assumes «oh, they succeeded BECAUSE they made this choice».
For example — dwarf fortress doesn't use source control. :ohno:
Not git, not svn, not cvs. They just have old copies of the code in folders.
Anyways, when it comes to art — I honestly personally believe you're going to be entering a really toxic/awkward relationship if you're working with an artist who's producing a style you really don't like.
You can try to «fake» it by being nice, and accepting the art even though you don't like it, but you're far better off just living without and being honest.
It's a lot like getting married. :neutral_face:
Every option in a software program is another code path you have to support, and the combinatorial complexity of multiple code paths, when it comes to testing and all sorts of similar «hidden costs» of doing development, really adds up.
So you don't want to accept multiple kinds of art, and gate each kind of art behind an option flag which users (or the author) can turn off.
It's bad because not only does it increase the support costs of the software, but it also makes it harder to achieve the goal of having a single, coherent art set for the project you're on, because it severely «confuses» your messaging to new contributors.
Ultimately if you've got a game that only has a portion of the art done, your game's mere existence is the best «help wanted» ad for getting additional art. But a critical part of asking for this additional art is a detailed description of what you need to do to match the game's current style.
The thing is — just existing is usually enough. «A picture is worth a thousand words». You don't need to waste a huge amount of time explaining what you want if you've got a large body of examples.
But — if these examples severely contradict themselves, then you're in for a lot of pain. If you've got two radically different visual styles, it's very difficult to explain to new contributors «which style» you'd like the game to actually be in.
All of a sudden you go from a hands-off, «no work for the project lead» matter of just letting the art speak for itself, to having to be deeply, personally involved in steering people.
— Alternate interpretation: It's possible you're suggesting a scenario in which someone's offering to make art for the game in a single, coherent style, and this is a situation where the entire game would get art, but you, the developer, would hide the art from yourself.
At the risk of being impolite, this is absolutely insane.
Which is to say it's «impossible» — there's an enormous time-cost and ongoing maintenance cost of time you'll have to spend getting the graphics to display correctly, and making sure they continue to display correctly as development continues and features get added and removed.
In almost all cases where this has happened (dwarf fortress being a key example), these external «artists» essentially did an enormous amount of programming to make their work viable.
Dwarf fortress mods operate by literally doing direct memory access and looking at the RAM state of the app as it runs, since there's no mod API or anything, but even if you did have a mod API — somebody has to pay the enormous cost of writing the code to get the entire graphics-drawing layer working correctly, and the complexity of doing this is usually equivalent to writing an entire game of its own.
… I mean — any game where this succeeds has essentially «won the lottery», and is an extremely dangerous target to imitate the habits of, because it succeeded not due to «good developer practices» but because it got insanely lucky.
A dangerous thing when looking at the dev practices of other games, especially «popular, successful» games, is a phenomenon called «survivor bias».
Survivor bias is when someone looks at the behavior of a very successful thing, and instead of thinking «oh, they were really successful, so they were able to survive even though they made a bad choice» — instead, one assumes «oh, they succeeded BECAUSE they made this choice».
For example — dwarf fortress doesn't use source control. :ohno:
Not git, not svn, not cvs. They just have old copies of the code in folders.
Anyways, when it comes to art — I honestly personally believe you're going to be entering a really toxic/awkward relationship if you're working with an artist who's producing a style you really don't like.
You can try to «fake» it by being nice, and accepting the art even though you don't like it, but you're far better off just living without and being honest.
It's a lot like getting married. :neutral_face:
بشكل عام ، عند تطوير Battle for Wesnoth ، التزمنا بمبدأ "الاختيار شر". كل خيار في البرنامج هو فرع إضافي من الكود الذي تحتاج إلى صيانته. ينمو العدد الإجمالي لفروع الكود وفقًا لقوانين التوافقية. ونتيجة لذلك ، يزداد تعقيد الاختبار و "التكلفة غير المرئية" للتنمية.
لذلك لا تريد حقًا أن تأخذ الكثير من الاتجاهات الفنية وأن يكون لديك علامة تعطيل لكل منها في الخيارات.
الاختيار شرير ليس فقط لأنه يزيد من تكلفة صيانة البرامج. سيمنعك الاختيار من تحقيق أسلوب فني متسق ومتسق في مشروعك ، لأن رسالتك إلى المساهمين الجدد ستكون "مزعجة".
في النهاية ، إذا كانت لعبتك تحتوي على جزء فقط من الفن جاهز ، فإن وجودها ذاته سينقل بشكل أفضل فكرة "أنا بحاجة إلى مساعدة" للحصول على فن إضافي. لكن الجزء المهم من طلب المساعدة هو تفصيل ما تحتاجه بالضبط لمطابقة أسلوب لعبك العام.
الشيء هو أن الوجود وحده يكفي. "الصورة أبلغ من ألف كلمة." إذا كان لديك العديد من الأمثلة ، فلن تضطر إلى قضاء الكثير من الوقت في شرح رؤيتك بالنص. لكن إذا تناقضت هذه الأمثلة مع بعضها البعض ، فسوف تعاني. سيمنعك وجود نمطين مختلفين جذريًا من الفن من شرح النمط الذي تود أن تنتهي به بنفسك.
عادة ، لا تحتاج إلى التدخل في تطوير النمط المرئي. الفن سيتحدث عن نفسه. ولكن بالنظر إلى الاختيار ، عليك فجأة أن تدير كل فرد بمفردك وتوجهه.
تفسير آخر. ربما تقترح سيناريو عندما يكون لديك مشارك قادر على تولي كل الأعمال الفنية ، ولكن في نفس الوقت ، بصفتك المؤلف ، ستخفي هذا الفن عنك.
قد أبدو غير مهذب ، لكن هذا جنون.
وفي الواقع ، يكاد يكون هذا مستحيلًا - ستبذل جهودًا هائلة لضمان العرض الصحيح لهذا الفن بالذات في بداية المشروع وطوال حياته.
لقد حدث هذا بالفعل في قلعة القزم وفي العديد من المشاريع الأخرى. في النهاية ، كان على "الفنانين الخارجيين" استثمار الكثير من جهود البرمجة من أجل مشاهدة أعمالهم على الإطلاق.
تعمل تعديلات قلعة القزم مع الوصول المباشر إلى ذاكرة الوصول العشوائي لعملية التشغيل. لا توجد واجهة برمجة تطبيقات مباشرة للتعديل أو أي شيء من هذا القبيل ، ولكن حتى لو كان هناك واحد ، فلا يزال يتعين على شخص ما كتابة التعليمات البرمجية لجعل طبقة عرض الرسومات تعمل. يمكن مقارنة تعقيد هذه المهمة بتطوير لعبتك الخاصة.
... أعني ، ليس عليك البحث عن الألعاب التي يكون فيها نهج "الفوز باليانصيب". هذا مثال خطير للغاية لأنه لا ينجح من خلال "ممارسات التنمية الجيدة" ولكن من خلال الحظ المذهل.
يعتبر النظر إلى ممارسات تطوير الألعاب الشعبية والناجحة فكرة سيئة بشكل عام. بل إن هناك مصطلح - "خطأ الناجي". بدلاً من قول "واو ، لقد تمكنوا من البقاء على قيد الحياة على الرغم من القرارات السيئة" - يقول الناس "لقد نجحوا لأنهم اتخذوا تلك القرارات".
حسنًا ، على سبيل المثال ، لا تستخدم قلعة القزم التحكم في الإصدار. لا git ولا svn ولا حتى السير الذاتية. يقومون فقط بنسخ مجلد إلى دليل.
مهما كان الأمر ، فأنا شخصياً أشعر أن العمل مع فنان لا يعجبك أسلوبه هو عدم احترام غير طبيعي لنفسك. يمكنك أن تتظاهر وأن تكون مهذبًا وتقبل الفن حتى لو لم يعجبك ، ولكن سيكون من الأسهل عليك أن ترفض وأن تكون صادقًا مع نفسك.
هذا مشابه جدًا للزواج / الزواج.
ملاحظة: إذا وجدت أخطاء مطبعية أو أخطاء في النص ، فيرجى إبلاغي بذلك. يمكن القيام بذلك عن طريق تحديد جزء من النص والضغط على "Ctrl / ⌘ + Enter" ، إذا كان لديك Ctrl / ⌘ ، أو من خلال الرسائل الخاصة . إذا لم يتوفر كلا الخيارين ، فاكتب عن الأخطاء في التعليقات. شكر!