Яке управління проектами повинен використовувати проект соло-розробника?

Я сам працюю над ігровим проектом, розробку якого можна розділити на 3 незалежні частини (генерування карт, двигун «overorld» та бойовий двигун), але в міру розвитку, я не впевнений, з чим мені слід мати справу управління цим проектом, особливо стосовно цих 3 пунктів:

1. Чи варто це використовувати систему контролю версій, оскільки я працюю соло?

2. Чи слід використовувати формальний метод для реєстрації запланованих функцій / помилок (я просто пам’ятаю, що зараз потрібно зробити)

3. Найголовніше питання: як я можу знати, що розвивати спочатку? Тепер, коли самі основи виконані, я знаю список функцій, які потрібно кодувати, але не знаю, в якому порядку я повинен це робити.

Я б використав:

1. Управління кодом

GIT (та дивовижна довідка ), розповсюджений диспетчер вихідного коду для керування моїм кодом та розміщення його на GitHub як приватний проект, якщо я хочу його відключити від меж.

(Тут багато варіантів, просто Google для управління вихідним кодом, вам навіть НЕ ПОТРІБНО використовувати GitHub чи будь-який інший веб-сайт; Git буде працювати чудово на вашому локальному комп’ютері, але використання GitHub додасть біль для управління резервними копіями. набагато простіше.

Якщо у вас є два комп’ютери, ви можете створити сховище на одному, яке ви будете викликати своєю резервною машиною, потім ви клонуєте це сховище через локальну мережу і використовуєте його для розробки, коли ви закінчите функцію, ви можете натиснути її на резервна машина, і у вас буде резервна копія 1: 1!)

2. Управління випуском та функціями

Я б використовував вбудоване управління випусками Trello або GitHub, щоб відслідковувати помилки та речі, які потрібно робити.

3. Майте процес проектування

Я б створив свою гру спочатку;

1. спершу на моєму розумі,
2. потім на папері,
3. то , ймовірно , використовувати Gamemaker або PyGame прототипу мою ідею, і перебирати 1-3 , поки я не те , що мені подобається грати.

4. Використовуйте мій прототип як керівництво та розробляйте мою гру

Тоді я би відклав свій прототип і вибрав платформу, яку я хочу розробити. Потім знайдіть існуючі двигуни і виберіть той, який найкраще підходить для моєї ідеї гри. Тоді я б поставив чіткі цілі для свого проекту, структурував їх у невеликі завдання, а потім почав працювати над виконанням завдань. Коли ви досягли цього стану, ви, швидше за все, виявите, що у вас є власний спосіб роботи, який підходить вам найкраще, тому йдіть з цим!

Існує кілька різних методологій / філософій, які ви можете застосувати до свого стилю розробки, XP, водоспаду тощо. Просто перейдіть до тієї, яку ви відчуваєте, що ви швидше просуваєтеся.

5. Майте багато ігрових тестерів!

Коли у вас щось відтворюється, попросіть своїх найближчих друзів спробувати це! Зробіть їх легким, щоб допомогти вам, встановивши швидкі пакети встановлення, якщо вони працюють під керуванням Windows, або написати якийсь скрипт оболонки, який може автоматизувати процес для них, якщо вони використовують Linux / Mac. Будьте обережні у відгуках ваших тестерів, і не забудьте повідомити їх про свій дизайн гри та про те, яку гру ви намагаєтеся створити.

6. Створіть веб-сайт для моєї гри

Як тільки у мене щось буде добре, я, мабуть, створив веб-сайт для своєї гри - щоб продовжувати свою творчість та контент, коли це неможливо застосувати до прогресу моєї гри, наприклад, якщо я зосереджуюсь на своїх дослідженнях або потрібна перерва у розвитку!

Якщо я використовую GitHub , я створив би проектну сторінку для своєї гри, інакше розміщую блог WordPress / Jekyll або щось подібне і пишу свої публікації з цим.

Це дозволить тримати себе в мотиві, а також мати місце для направлення потенційних геймерів / тестерів!

7. Приєднуйтесь до конкурсів

Існує багато конкурсів ігор для розробників ігор, які відбуваються майже весь час. Я б спробував приєднатися до однієї з них зі своєю грою, якщо правила дозволяють. Це підвищує мотивацію і робить все ще веселішим - кому не подобається перемагати!

(Якщо ви розробляєтесь у строгий термін, ви можете пропустити цю точку хоча б.)

Я настійно пропоную використовувати систему контролю версій, навіть якщо ви працюєте в поодинці. Це може заощадити вам багато часу, коли ви випадково щось видалите або зробите більші зміни, лише щоб згодом усвідомити, що це була погана ідея, і ви повинні скасувати всі зміни.

Редагувати : Є багато рішень для управління безкоштовними джерелами.

• Я використовував сервер VisualSVN , який легко налаштувати і використовувати під Windows.

• Також є онлайн-альтернативи, такі як Codeplex (з SVNабо Mercurial), SourceForge або Google Code . Перевернути це те, що вам не доведеться створювати та підтримувати сховище, а ваші дані знаходяться у хмарі; суть у тому, що ви не можете вільно розміщувати проекти з закритим кодом.

Що стосується відстеження помилок та функцій: Якщо у вас вже є більша аудиторія, яка може бути зацікавлена ​​у бета-тестуванні вашої гри, повідомленні про помилки та запиті функцій, продовжуйте.
Якщо, однак, є лише жменька таких людей (або їх взагалі немає), це непотрібно.

А щодо пріоритетів розвитку - це вам вирішити. Хто повинен краще знати, що робити в проекті, ніж його єдиний розробник?

Чи варто це використовувати систему контролю версій, оскільки я працюю соло?

Я думаю так. Це досить тривіально, щоб налаштувати, і я вже неодноразово божеволіла від рефакторингу або робила щось інше дурне, а можливість відката моїх змін заощадила багато тонн часу. Плюс якщо його розміщено на сервері, то у вас є резервна копія нашого коду, якщо щось піде не так .

Чи слід використовувати формальний метод для реєстрації запланованих функцій / помилок (я просто пам’ятаю, що зараз потрібно зробити)

Я не вважаю за потрібне. Я б зберігав письмовий список того, що ви маєте намір зробити, хоча просто для того, щоб не забути незначну помилку, плюс я вважаю, що це допомагає вам почати знову після перерви в кодуванні.

Найголовніше питання: як я можу знати, що розвивати спочатку? Тепер, коли самі основи виконані, я знаю список функцій, які потрібно кодувати, але не знаю, в якому порядку я повинен це робити.

Візьміть цей список вище, заплющіть очі і випадковим чином засуньте його. Працюйте над будь-якою функцією, на якій ви пальцем. Якщо тільки елементи не залежать один від одного, то важливіше лише продовжувати рух, ніж гарантувати, що все відбувається в будь-якому конкретному порядку.

Однозначно використовувати контроль версій

Контроль версій - це як мережа безпеки для пішохідного переходу: він звільняє вас від спроб шалених речей. Великий рефактор видалення величезних фрагментів коду - це не проблема, якщо ви можете легко повернути його назад. Навіть менше, якщо ви перебуваєте на експериментальній гілці свого репо і можете вирішити не об’єднувати його назад.

Якщо у вас немає такої свободи, ви, ймовірно, залишите коментований код, що сидить навколо себе, боячись, що він вам може знадобитися.

Я би голосував за Гіта. Синтаксис трохи дивний, але про нього є дві важливі речі:

• Низькі накладні витрати . Перейдіть у папку та введіть, git initі ви готові почати перевірку матеріалів. Якщо ви вирішите, що не хочете, щоб версія контролювала її все-таки rm -rf .gitу цій папці, і це вже не Git repo.

• Поширюється через SSH . Git поширюється, тобто ви можете мати кілька повних копій репо (всієї історії тощо) у різних місцях та тримати їх синхронізовано. Ви можете налаштувати інше репортаж Git на будь-якій машині, де ви маєте доступ до SSH, а потім додайте це репо як дистанційне. Після цього в будь-який час ви хочете створити резервну копію саме git pushдо цього репо.

  Це велика перевага перед, скажімо, Subversion, де вся репо живе на одній машині, і ця машина повинна працювати на сервері Subversion.

У Меркуріала можуть бути ті самі точки на свою користь, але я не використовував це.

1. Так! Оскільки ви запитуєте, я здогадуюсь, що ви добре прийняті з системою контролю ревізії. Це обов'язково!

2. Що стосується вашого другого питання, то існує формальний метод реєстрації помилок, і ви повинні ним скористатися. Щодо особливостей планування, я думаю, що будь-який менш формальний маршрут не буде боляче (коли ви працюєте в самоті)

3. Спершу зробіть ті функції, які зроблять вашу живу життя. Дайте уявлення про те, якою буде фінальна гра.

1) Так, звичайно. Я рекомендую Mercurial через BitBucket та TortoiseHg. BitBucket безкоштовний для 5 користувачів, і оскільки він розміщений у хмарі, він додає вам певного настрою (не потрібно робити резервні копії).

2) Помилки слід виправити перед впровадженням нових функцій. Я б використовував простий доступний список TODO для відстеження речей, які очікують на розгляд. Ви можете просто використовувати звичайний текстовий файл, тільки не забудьте додати його у своє сховище керування джерелом.

3) Робіть те, що ви хочете робити в будь-який день, пам’ятаючи, що доставка чогось відтворюваного кінцевим користувачем є основною метою. Наприклад, якщо вам набридло право на фізику, працюйте над рендерінгом або, можливо, додайте якісь пропущені одиничні тести для цього ШІ.

Шматки роботи повинні бути досить маленькими, щоб їх можна було виконати приблизно за пару днів. Важливо залишатися мотивованими та уникати вигорання.

Якщо архітектура виконана належним чином, ви зможете легко додати модифіковані частини двигуна / гри, не впливаючи на кілька інших (інакше почніть з рефакторингу :).

1) Як всі кажуть: ТАК (я б навіть сказав, зняти дешевий онлайн)

2) Дотримуйтесь простого списку, або якщо ваш проект зростає, і ви отримуєте бета-тестери, встановіть Mantis Bug Tracker

3) Я не знаю, але я розповім, як я це роблю: Спершу розробіть найменше цікаве та / або найважче. Повторюйте, поки все не буде зроблено. Таким чином розвиток стає просто веселішим і простішим (і ви не досягнете цієї проблеми, просто не зможете вирішити занадто пізно, якщо колись це станеться).

Дякуємо, що задали це запитання. Це саме те, що я зараз роблю.

1) Контроль версій: Це обов'язково. Зараз я підтримую резервну копію вручну. Це корисно принаймні, коли щось, що працювало чудово, раптом кидає помилки (або не функціонує, як очікувалося). Я порівнюю версії і часто зустрічаю дурні помилки (в основному щось коментуючи)

2) Я створив текстовий документ і перерахував усі функції, які матиме моя гра, у категоричному порядку та з багаторівневими відступами, що перелічують підфункції (та пов'язані з клієнтом / сервером, або все, що коли-небудь застосовно).

3) Після списку, який я отримав (який звичайно не буде повним, і надалі до нього щось додається), я думаю про свою ігрову течію та висвітлюю всі моменти, які мені потрібні, щоб зробити гру запущеною та почати робити їх. Я позначаю жовтий сенс роботи, що триває. зелений після завершення. помаранчевий, щоб вказати на покращений тембр або має деякі відомі вади

сподіваюся, що це допомагає

1.) Варто використовувати контроль версій для будь-якого проекту. Навіть дуже маленькі, якщо ви вже знаєте, як ним користуватися. Я використовував Subversion протягом багатьох років у Linux та Windows з TortoiseSVN . Навіть створюючи невеликий проект (<500 рядків), я створити для нього сховище, щоб я міг скасувати зміни, відстежувати, що я робив, якщо я на деякий час відмовлюся від проекту тощо.

2.) Залежить від того, наскільки великим буде проект. Якщо ви плануєте грати-тестувати з командою та розповсюджувати, ймовірно, варто мати систему відстеження помилок. В даний час я працюю соло (хоча у мене є виконавець) над проектом, який налічує понад 20 тис. Рядків, і я просто зберігаю свій список справ у текстовому файлі, який також знаходиться у моєму сховищі SVN. Хоча я ще не маю необхідності ділитися ним з іншими, тому зараз відстеження помилок не відповідає моїм потребам. Я б не хвилювався з цього приводу, поки не виникне необхідність. Найгірше, що може статися, - вам доведеться вводити будь-які помилки, які ви вже записали, і видалити / переглянути ті, що виправили. Коли ви почнете втрачати ментальні сліди своїх нотаток, знайдіть помилку про помилки.

3.) Накресліть його на папері. Почніть з того, що ви хочете, щоб ваша закінчена гра була, запишіть суть її. Потім розбийте її на те, що знадобиться: виявлення зіткнення? мережевий код? типи гравців та монстри? ієрархії класів? Працюйте назад від свого бачення, щоб ви отримали чітке уявлення про те, як будувати його з нуля. Я припускаю, що ви використовуєте об'єктно-орієнтовану мову. Найважливішим кроком для початку було б домогтися того, щоб ці ієрархії класів були налаштовані розумним чином. Постарайтеся, щоб ви не мали абсолютно ніякого багаторазового успадкування (хоча іноді це неминуче), намічайте відносини класів у редакторі діаграм (я використовую Dia ) тощо. Основні директори проходять довгий шлях уникнути головних болів пізніше.