Мир Ролевых Игр
Создание Миров и Игровых Систем => Теория НРИ и игростроения => Тема начата: Karel.Wintersky от Сентября 01, 2018, 17:09
-
Вот не надо опять поднимать срач о том, сколько изменений должно быть внесено в уже существующий объект чтобы результирующий считался отдельной сущностью.
Жаль, что мы не применяем к созданию ролевых систем методологии и инструменты разработки ПО.
Система контроля версий (GIT, к примеру) была бы очень полезна. А там можно сделать fork репозитория - и проследить историю изменений.
А там и пулл-реквесты не за горами, ишью (issues aka bug-reports), etc etc
<удалено не относящееся к теме>
-
Жаль, что мы не применяем к созданию ролевых систем методологии и инструменты разработки ПО.
Система контроля версий (GIT, к примеру) была бы очень полезна. А там можно сделать fork репозитория - и проследить историю изменений.
А там и пулл-реквесты не за горами, ишью (issues aka bug-reports), etc etc
Что-то слышал про написанную в GIT систему, но не помню, как она называлась, и не путаю ли я ролевую систему с текстовой ролевой игрой (коих в гите мириады, по ощущениям).
-
Вот не надо опять поднимать срач о том, сколько изменений должно быть внесено в уже существующий объект чтобы результирующий считался отдельной сущностью.
Коллеги в чате подсказали:
В некоторых научных кругах считается, что статья Б сделанная на основе статьи А должна иметь более 30% разницы по содержанию.
UPD. Проверил это встречается и как официальное требование "XXX требует, чтобы статья содержала более 30% новых материалов."
-
Что-то слышал про написанную в GIT систему, но не помню, как она называлась, и не путаю ли я ролевую систему с текстовой ролевой игрой (коих в гите мириады, по ощущениям).
Dungeon world это
-
Жаль, что мы не применяем к созданию ролевых систем методологии и инструменты разработки ПО.
Система контроля версий (GIT, к примеру) была бы очень полезна. А там можно сделать fork репозитория - и проследить историю изменений.
.....
А это существенно сложнее. В первую очередь по таким признакам как:
а) разделению областей ответственности.
б) завершённость пул-реквеста.
В ПО это достаточно давно прорабатываемая и на сегодня достаточно хорошо проработанная тема.
В разработке НРИ... по-моему там даже близко конь не валялся (кроме самых примитивных случаев: тут у нас "механика" а тут "сеттинг").
-
ПС
В моём понимании лучше назвать "принципы разработки ПО в создании НРИ".
Всё-таки речь идёт не (и по отношению к ПО и по отношению к НРИ) не о конечном продукте, а о процессе создания).
-
А какие еще принципы разработки есть? Безотносительно применимости в НРИ — сначала хорошо бы получить пул идей, а потом уже какие-то решения пробовать в области геймдизайна.
-
Нужны не принципы разработки ПО, а принципы разработки компьютерных игр.
Разница существенная: например, в ПО дизайн рисует сторонняя контора, которая режет на куски, и пишет как эти куски вставить. К разработке НРИ такой паттерн неприменим.
-
А принципы и методы непосредственно геймдизайна чем неустраивают-то?
-
А принципы и методы непосредственно геймдизайна чем неустраивают-то?
To a man with a hammer, everything looks like a nail, же
-
А какие еще принципы разработки есть? Безотносительно применимости в НРИ — сначала хорошо бы получить пул идей, а потом уже какие-то решения пробовать в области геймдизайна.
Ну, я имел в виду в первую очередь инструменты - такие же, какие применяются при разработке ПО.
Парадигмами организации разработки (такими как Agile (Scrum/Kanban)) я не владею (хотя и читал он них), тем более что для их применения нужна команда.
Принципы геймдизайна - это как делать игры.
Принципы разработки - это как организовывать процесс делания игр.
-
А принципы и методы непосредственно геймдизайна чем неустраивают-то?
В ПО собственно геймдизайна только UX/UB.
Сравнивать последнее с разработкой настольной игры — всё равно что сравнивать возведение домика из сендвич-панелей на приусадебном участке, с возведением Башни Конфедерации (или Федерации).
-
По поводу интсрументов. www.trello.com подходит на все случаи.
-
По поводу интсрументов. www.trello.com подходит на все случаи.
А зачем, если в типовой команде НРИ:
Концептер — одна штука
Разработчик — одна штука
Писатели, и у друг друга редакторы — штуки три
Артисты — на аутсорсе
Арт-директор — одна штука
Менеджер типографии — одна штука
Вот если переводы на весь мир делать, тогда система учета времени и тасков нужна. Но trello — не единственный выбор, есть basecamp, Fogbugz и ещё куча других. Причём указанные, в отличии от трелло, существуют в оффлайн варианте.
-
Трелло не предназначена для учета времени. Это система для учета задач, формализации идей и синхронизации работы нескольких людей. Есть клиент на мобильный, который работает оффлайн.
-
А зачем, если в типовой команде НРИ:
Концептер — одна штука
Разработчик — одна штука
Писатели, и у друг друга редакторы — штуки три
Артисты — на аутсорсе
Арт-директор — одна штука
Менеджер типографии — одна штука
Даже если все эти люди - один человек, Trello все еще очень полезная штука. Говорю как человек, который Trello активно пользуется в разработке: без него и с ним - две большие разницы, как говорят в Одессе.
-
Концептер — одна штука
Разработчик — одна штука
Писатели, и у друг друга редакторы — штуки три
Артисты — на аутсорсе
Арт-директор — одна штука
Менеджер типографии — одна штука
То есть 7-9 человек? Самое то (как пишут в интернете) - для аджайла/скрама.
... правда получается как обычно - х..к/х..к и в продакшен.
-
Трелло не предназначена для учета времени. Это система для учета задач, формализации идей и синхронизации работы нескольких людей. Есть клиент на мобильный, который работает оффлайн.
Если бы ты сказал мне это про GURPS, и я не знал бы о других системах, то я может и поверил бы. Иначе надо объяснить в чём преимущество этой перед другими.
То есть 7-9 человек? Самое то (как пишут в интернете) - для аджайла/скрама.
... правда получается как обычно - х..к/х..к и в продакшен.
Для Agile не хватает ещё придурков из команды заказчиков, меняющих требования и дебилов среди этих 7-ми.