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

Я работаю сам по игровому проекту, чье развитие можно разделить на 3 независимые части (создание карты, «двигатель во всем мире» и механизм битвы), но по мере развития развития я не уверен, как Я должен иметь дело с управлением этим проектом, особенно в отношении этих 3 пунктов:

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

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

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

48 голосов | спросил lezebulon 15 ThuEurope/Moscow2011-12-15T15:48:48+04:00Europe/Moscow12bEurope/MoscowThu, 15 Dec 2011 15:48:48 +0400 2011, 15:48:48

9 ответов


59

Я бы использовал:

1. Управление кодом

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

(Здесь есть много вариантов, просто Google для управления исходным кодом, вам даже НЕ НУЖНО использовать GitHub или любой другой веб-сайт, Git будет отлично работать на вашем локальном компьютере, но с помощью GitHub будет облегчить управление резервными копиями.

Если у вас есть два компьютера, вы можете создать репозиторий на том, который вы назовете на своей резервной машине, тогда вы клонируете этот репозиторий через локальную сеть и используете его для разработки, когда вы закончите с функцией вы можете нажать его на резервную машину, и у вас будет резервная копия 1: 1!)

2. Issue & Управление функциями

Я бы использовал Trello или встроенное управление выпуском GitHub , чтобы отслеживать ошибки и все, что нужно делать.

3. Имейте процесс проектирования

Я бы сначала разработал свою игру;

  1. сначала в моем уме,
  2. затем на бумаге
  3. , то, вероятно, используйте GameMaker или PyGame , чтобы прототип моей идеи и повторить более 1-3, пока у меня не будет того, что мне нравится играть.

4. Используйте мой прототип в качестве руководства и разработайте мою игру

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

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

5. У вас много игровых тестеров!

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

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

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

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

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

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

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

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

ответил Zolomon 15 ThuEurope/Moscow2011-12-15T18:15:23+04:00Europe/Moscow12bEurope/MoscowThu, 15 Dec 2011 18:15:23 +0400 2011, 18:15:23
14

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

Изменить . Существует множество бесплатных решений для управления версиями.

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

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

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

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

ответил ver 15 ThuEurope/Moscow2011-12-15T16:07:29+04:00Europe/Moscow12bEurope/MoscowThu, 15 Dec 2011 16:07:29 +0400 2011, 16:07:29
7
  

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

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

  

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

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

  

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

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

ответил ClassicThunder 15 ThuEurope/Moscow2011-12-15T16:07:43+04:00Europe/Moscow12bEurope/MoscowThu, 15 Dec 2011 16:07:43 +0400 2011, 16:07:43
5

Определенно использовать управление версиями

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

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

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

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

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

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

ответил Nathan Long 15 ThuEurope/Moscow2011-12-15T22:59:50+04:00Europe/Moscow12bEurope/MoscowThu, 15 Dec 2011 22:59:50 +0400 2011, 22:59:50
3
  1. Да! Поскольку вы спрашиваете, я предполагаю, что вы хорошо приняты с системой контроля версий. Его необходимо!

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

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

ответил Quazi Irfan 15 ThuEurope/Moscow2011-12-15T16:32:13+04:00Europe/Moscow12bEurope/MoscowThu, 15 Dec 2011 16:32:13 +0400 2011, 16:32:13
3

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

2) Ошибки должны быть исправлены до внедрения новых функций. Я бы использовал простой доступный список TODO для отслеживания вещей - отложенных /выполненных. Вы можете просто использовать простой текстовый файл, просто не забудьте добавить его в свой репозиторий управления версиями.

3) Делайте то, что вы хотите делать в любой день, имея в виду, что доставка чего-то, играемого конечным пользователем, является основной задачей. Например. если вы устали от получения права на физику, работаете над рендерингом или, возможно, добавляете некоторые недостающие модульные тесты для этого AI.

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

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

ответил Den 15 ThuEurope/Moscow2011-12-15T17:14:54+04:00Europe/Moscow12bEurope/MoscowThu, 15 Dec 2011 17:14:54 +0400 2011, 17:14:54
2

1) Как все говорят: ДА (я бы даже сказал, арендую дешевую онлайн-версию)

2) Сохраните простой список или ваш проект станет большим, и вы получите бета-тестеры, установите Mantis Bug Tracker

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

ответил Valmond 15 ThuEurope/Moscow2011-12-15T16:26:03+04:00Europe/Moscow12bEurope/MoscowThu, 15 Dec 2011 16:26:03 +0400 2011, 16:26:03
1

Спасибо, что задали этот вопрос. Это именно то, что я делаю в настоящее время.

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

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

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

надеюсь, что это поможет

ответил Noob Game Developer 16 FriEurope/Moscow2011-12-16T09:57:51+04:00Europe/Moscow12bEurope/MoscowFri, 16 Dec 2011 09:57:51 +0400 2011, 09:57:51
0

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

2.) В зависимости от того, насколько большой будет проект. Если вы планируете играть в тест с командой и распространять, вероятно, стоит иметь систему отслеживания ошибок. В настоящее время я работаю соло (хотя у меня есть художник) по проекту с более чем 20 тыс. Строк, и я просто сохраняю список дел в текстовом файле, который также находится в моем репозитории SVN. Хотя мне пока еще не нужно делиться ею с другими, поэтому пока что отслеживание ошибок не соответствует моим потребностям. Я бы не стал беспокоиться об этом, пока не возникнет необходимость. Самое худшее, что может случиться, - вам придется вводить все ошибки, которые вы уже записали, и удалить /переустановить исправления. Когда вы начинаете терять умственные следы своих заметок, получите трекер ошибок.

3.) Разместите его на бумаге. Начните с того, что вы хотите, чтобы ваша законченная игра была, напишите ее суть. Затем разбейте его на то, что потребуется, чтобы сделать это: обнаружение столкновения? сетевой код? типы игроков и монстров? иерархии классов? Работайте назад от своего видения, чтобы получить четкое представление о том, как построить его с нуля. Я предполагаю, что вы используете объектно-ориентированный язык. Самым важным шагом в начале было бы создание этих иерархий классов, созданных разумным способом. Попробуйте, чтобы ваш damnedest не имел абсолютно никакого множественного наследования (хотя иногда это неизбежно), постройте отношения классов в редакторе диаграмм (я использую

ответил zeroth 8 MarpmFri, 08 Mar 2013 23:56:51 +04002013-03-08T23:56:51+04:0011 2013, 23:56:51

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132