Маючи достатньо часу в наших руках, щоб завершити ігри, які ми розробляємо, як ви можете досягти хорошого балансу між надійною архітектурою програмного забезпечення та успішним прогресом, щоб все це було зроблено?
Мій особистий виклик: як щодо ефективності сьогодні та довгострокового мислення одночасно? Плюс, якщо ви це робите, ви можете так само хотіти навчитися новому в дорозі, а не вдаватися до тих же повторюваних моделей, якими ви користувалися за останні 5 років?
Відповіді:
Чим менше досвіду у вас, тим більше часу ви витрачаєте на передній дизайн. Робити хороший дизайн - це те, чого ви навчитесь, роблячи це, а потім побачивши / оцінюючи, як це виходить. Деякі рішення мають далекосяжний, але незрозумілий вплив. Після деяких ігор ви, ймовірно, зможете зробити початковий дизайн досить солідним, і це окупиться вкласти ще трохи часу на цей етап.
Мій девіз: в першу чергу робіть справи, але використовуйте здоровий глузд, щоб виявити, які компоненти є більш критичними, ніж інші, і спроектуйте їх досить добре, у межах вашого терміну. Наприклад, якщо AI має вирішальне значення для вашої гри, переконайтеся, що згодом ви можете її легко розширити / змінити. Або, якщо ви збираєтеся написати компонент, який будете використовувати в кожній грі, спроектуйте його для повторного використання. Слідкуйте за своїм часом і не дивіться на розробку. Встановіть термін розробки, а після цього починайте зламати все, щоб отримати термін випуску. Але не забудьте зауважити, які моменти потребують рефакторингу / перепланування після цього, і порахуйте за деякий час, перш ніж розпочати наступну гру, щоб покращити ці речі, щоб вони не змусили вас відкусити назад!
Гарна порада: якщо вам доведеться вибирати між двома варіантами, не затримуйтесь надто довго над деталями. Найчастіше немає "хорошого" чи "поганого". У деяких ситуаціях А буде кращим, у деяких - Б, і загалом різниця між обома не завжди може коштувати часу.
Набути багато досвіду в розробці програмного забезпечення або ігор, тому переконайтеся, що ви витрачаєте частину свого часу на дослідження (наприклад, читайте книгу на дизайн, читайте про досвід інших людей, спілкуючись з колегами-програмістами про свої проекти тощо). ).
Люди жахливо прогнозують майбутнє. Особливо це стосується ігор, де вимоги можуть змінюватися щодня.
Існує принцип під назвою YAGNI , він же "Вам не знадобиться", який, в основному, говорить, що ви не повинні щось реалізовувати, поки не знаєте, що вам це знадобиться.
Я бачив, як багато систем завалилися архітектурною жорсткістю, що насправді не використовувала жодну з них, оскільки функції, які люди думали, що їм знадобиться, ніколи не обійдуться, щоб їх використовувати.
Моя особиста філософія - це зробити найпростішу річ, яка могла б працювати . За словами, є різниця між "Зробити це зроблено" та "Зламати лайно разом". Написання коду з ціллю не повинно означати робити речі, які генерують "запах коду", як оприлюднення всього, проведення класів, які роблять все, або будь-яку з тих десятків інших речей, що означають "поганий" код.
Сьогодні це в моїй думці відповідає дійсності:
Я друг програмного забезпечення швидкого прототипування. Особливо під час розробки ігор. Це добре для швидкого навчання, тестування та використання речей. Для мене близький апаратний програмування або складні алгоритми - найкращий метод для мене.
Theory();
RapidPrototype();
bool bOk = false;
while(!bOk)
{
Testing();
LotOfFixing();
PlayingWith();
bOk= AnalysingResults();
}
FinalFastAndNiceDataStructuresAndCode();Моя версія швидкого прототипу повинна мати належну кору прототипу:
Переваги:
Якщо ви це зробите добре, ви можете мати реальну версію свого продукту / налагодження.
Ми використовуємо це в нашому проекті і ми задоволені цим.
Погляньте на гнучку розробку програмного забезпечення . Хоча це не срібна куля, вона має на меті зробити і те, і інше (зробити це і мати надійний дизайн програмного забезпечення).