Какой вид управления проектом должен использовать проект соло-разработчика?

Я работаю над игровым проектом, разработка которого может быть разделена на 3 независимые части (создание карт, движок «над миром» и боевой движок), но по мере развития я не уверен, как мне следует иметь дело с управление этим проектом, особенно в отношении этих 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, Waterfall и т. Д. Просто выберите ту, которая, по вашему мнению, сделает вас быстрее всего.

5. Иметь много игровых тестеров!

Если у вас есть что-то играбельное, попросите своих ближайших друзей попробовать! Облегчите им задачу, настроив пакеты быстрой установки, если они работают под Windows, или напишите какой-нибудь сценарий оболочки, который может автоматизировать процесс для них, если они используют Linux / Mac. Внимательно следите за отзывами ваших тестеров и не забывайте сообщать им о своем игровом дизайне и о том, какую игру вы пытаетесь создать.

6. Сделайте сайт для моей игры

Как только у меня все будет хорошо, я, вероятно, создам веб-сайт для своей игры - чтобы мои творческие способности и контент развивались, когда его нельзя применить к прогрессу моей игры, например, если я сосредоточен на учебе или нужно отдохнуть от развития!

Если бы я использовал GitHub , я бы создал страницу проекта для своей игры, в противном случае разместил бы блог WordPress / Jekyll или что-то подобное и написал бы мои посты с этим.

Это сохранит мотивацию, а также место, куда можно направить потенциальных геймеров / тестеров!

7. Присоединяйтесь к конкурсам

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

(Если вы разрабатываете в сжатые сроки, вы можете по крайней мере пропустить этот пункт.)

Я настоятельно рекомендую использовать систему контроля версий, даже если вы работаете в одиночку. Это может сэкономить вам много времени, если вы случайно удалите что-то или внесете более значительные изменения, но потом поймете, что это плохая идея, и вам нужно отменить изменения.

Изменить : Есть много бесплатных решений по управлению исходным кодом.

• Я использовал сервер VisualSVN , который легко настроить и использовать под Windows.

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

Что касается отслеживания ошибок и функций: если у вас уже есть большая аудитория, которая может быть заинтересована в бета-тестировании вашей игры, сообщая об ошибках и запрашивая функции, продолжайте.
Однако, если таких людей всего несколько (или их вообще нет), это не нужно.

А что касается приоритетов развития - решать вам . Кто должен знать лучше, что делать в проекте, чем его единственный разработчик?

Стоит ли использовать систему контроля версий, так как я работаю соло?

Я так думаю. Его довольно просто настроить, и я неоднократно сходил с ума от рефакторинга или делал что-то еще глупое, и возможность откатить мои изменения сэкономила немало времени. Кроме того, если он размещен на сервере, у вас есть резервная копия нашего кода на случай, если что-то пойдет не так .

Должен ли я использовать формальный метод для регистрации запланированных функций / ошибок (я просто помню, что нужно сделать сейчас)

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

Самый важный вопрос: как я могу знать, что развивать в первую очередь? Теперь, когда основа уже готова, я знаю список возможностей кода, но не знаю, в каком порядке я должен это делать.

Возьмите этот список выше, закройте глаза и случайно ткните его. Поработайте над тем, на чем вы держите палец. Если элементы не зависят друг от друга, важнее просто поддерживать поток, чем следить за тем, чтобы все происходило в любом конкретном порядке.

Обязательно используйте контроль версий

Контроль версий подобен страховочной сети для канатоходца: он освобождает вас от попыток совершить сумасшедшие поступки. Большой рефактор, удаляющий огромные куски кода, не проблема, если вы можете легко вернуться. Тем более, если вы находитесь на экспериментальной ветке в своем репо и можете решить не объединять ее обратно.

Если у вас нет такой свободы, вы можете оставить закомментированный код повсюду, опасаясь, что он вам может понадобиться.

Я бы проголосовал за Git. Синтаксис немного странный, но есть две замечательные вещи:

• Низкие накладные расходы . Перейдите в папку и введите текст, git initи вы готовы начать регистрировать материал. Если вы решите, что все-таки не хотите управлять версиями, rm -rf .gitв этой папке, и это больше не Git-репо.

• Распространяется через SSH . Git распространяется, что означает, что вы можете иметь несколько полных копий своего репо (всю историю и т. Д.) В разных местах и ​​синхронизировать их. Вы можете настроить другое Git-репо на любой машине, к которой у вас есть доступ по SSH, а затем добавить это другое репо в качестве удаленного. После этого, в любое время вы хотите сделать резервную копию только git pushв этом репо.

  Это большое преимущество по сравнению, скажем, с Subversion, где все хранилище находится на одном компьютере, и на этом компьютере должен работать сервер Subversion.

У Mercurial могут быть те же самые точки в его пользу, но я не использовал это.

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 ) и т. Д. Основные принципы в дальнейшем помогут избежать головной боли.