Теоретически :) А на практике заказчик на начальном этапе не представляет на 100% чего он хочет получить. Т.е. не представляет все use cases. Понимание многих вещей заказчиком и его желания меняются в процессе разработки, и игры не исключение :) И не важно, выступает в роли заказчика издатель или сами игроделы :)
угу. Только сразу проявить ограничения.
1. Результат должен быть известен перед сбором команды. Чтобы не собирать команду из гениального булочника. идеального сапожника и великолепного трубочиста. А потом предложить им что нибудь сделать. Зачастую в большинстве инди проектов команда собирается именно такая.
2. опять же оставить команде только те " решения, которые кроме них все равно никто адекватно принять не способен."
Решения о сроках, изменениях в задаче или тем более о способе распространения это решения которые разработчик зачастую как раз адекватно не сможет принять. Т.е. решение «а давайте забабахаем еще и перламутровые пуговицы это не решение команды разработчиков».Кстати байку как программисты строили дом т тут все помнят? Или мне еще поднять рейтинг левым тестом?
3. замечательно только вместо слова «небольшое», которое очень не точно и может интерпретироваться по разному стоит поставить словосочетание «заранее оговоренное». Это по крайней мере позволит какое никакое планирование и не сделает разработчиков основным источником бардака в команде.
Плохой код — а что это такое вообще?
Это совсем в сторону. но в качестве примера — когда разработчики ВоВ говорят «мы не можем расширить сумку свыше 16 ячеек потому что код был написан давно и сейчас его невозможно менять» Это говорит о том что код в настоящий момент плохой. с другой стороны почти любая програма которую дописывают 10 лет будет обладать этим свойством. особенно если проектировалась она на 2-3 года (как предрекали тому же ВоВ в начала разработки).
Да, я работал и работаю в крупных технических проектах.
Заметно — возражения по теме и без лишних риторических конструкций. вроде «смеются с..» или «городишь ересь».
Кстати в качестве доп замечаний --в этом случае кикстартер в общем то очень условный способ выхода. поскольку эти три пункта никак особо не поддерживает.
При том что разработчику такой выпуск не принесет вообще ничего хорошего, у него фиксированная оплата.
Если платить дополнительно за патчи и фиксы — будет еще хуже :) Если процент с продаж — то на какие шиши вести разработку? Если и то и другое — как считать риск?
Чисто теоретически — можно и спроектировать, и оттестировать и даже верифицировать. Ибо количество use cases и состояний конечно :) Только времени на это нужно несколько больше, чем принято отводить. Причем если бы софт, и игры в частности, не изобретали каждый раз заново — оно бы нашлось.
1. Собрать команду компетентных людей, заинтересованных в хорошем результате
2. Дать им право принмать решения, которые кроме них все равно никто адекватно принять не способен.
3. Оставить их хотя бы небольшое время в покое от своего внимания, чтобы они могли сконцентрироваться на работе.
Это рецепт идеального «спринта» от Капитана Очевидность. На практике лажают во всех трех пунктах. Плохой код — а что это такое вообще?
Да, я работал и работаю в крупных технических проектах.
Вовремя. Когда достигнут этот компромис. Для твоего проекта.
А ты выше писал о дедлайнах, выставляемых по принципу — «выпускать надо в сентябре, а то летом люди в отпусках, а в октябре уже конкурент релизится». При том что разработчику такой выпуск не принесет вообще ничего хорошего, у него фиксированная оплата.
Я не знаю механику EVE, но я как-то раз пробовал мультибоксить на одном фришарде ВоВ. Одна только подготовка 4 персонажей заняла у меня 3 дня, начиная с раскачки-одевания (это при том, что это был фан сервер, где сразу давался макслвл), заканчивая настройкой билдов и макросов (на изучение макросов заранее было потрачено много часов). Ещё один день пришлось тренироваться управлять и банально передвигаться целым сквадом. И только на пятые сутки я смог поиграть, и, скажу вам, это было чертовски сложно!
Во-первых, это в любом случае сложнее, чем копать одним кораблем. И риска больше. Возражения есть?
Да чем сложнее-то? Как управлял одним кораблём — так и управляешь. А финансового риска даже меньше — поймать пять барж сразу сложнее чем одну, при том что добывают то они в разы больше, т.е. возросшие доходы с лихвой перекрывают потенциально возросшие потери.
Я немного в недоумении: в предыдущих роликах нам показывали, как 2 персонажа строят что-то во время полёта. Зачем прыгать тогда? Или это 2 независимых режима?
А ты?
Потому что то что описал Алгори имеет один недостаток.
Это совершеннейшие банальности нормальной разработки крупного проекта.
А приводимые ниже возражения я многократно слышал в своей работе, как отмазки плохих кодеров --" если бы нам создали идеальные условия мы бы выдали идеальный код"
Причем чаще всего говорящие после этого ничего хорошего не выдают даже в хороших условиях.
Сразу чтобы убрать обвинения в дилетанстве --2 проекта несколько внедерений. В том числе 1 неудачный проект именно потому что «творцы ждали идеальных условий и делали идеальную программу» (20 лет делали если что и наверно до сих пор делают).
Кстати из возражавших --кто нибудь вообще работал в крупных технических проектах, не обязательно кодерских?
Можешь назвать хорошую, интересную инди-игру, сравнимую с тем же Скайримом, Deus Ex…
А затем ты мне будешь доказывать, что она не хорошая и не интересная? Ну ок, а сравнимую в чем, собственно? В интересности геймплея? В сюжете? В атмосфере? В музыке? В открытом мире? Ну не в бюджете же, надеюсь?)))
А просто хороших инди вагон, мне даже перечислять как-то не хочется. Достаточно в стиме запустить поиск по жанру «инди». Первые пришедшие на ум — Don't Starve, Bastion, Dust.
Кроме того мультиоконщики выдавливают хардкорных шахтеров — которые готовы часами копать астероиды, тратить на это массу своего времени и часто рисковать при этом.
Мультиоконщики и есть хардкорные игроки. Выпиливают казуалов, часами копающих астероиды. Они больше рискуют, планируют и вкладывают в игру. Как раз казуалы просят от игры уровнять их подход по эффективности с остальными игроками. А они, как известно, должны страдать :)
Ну и Скайрим, который в некотором роде исключение, но без модов играть как-то пресно…
Серия elder scroll's всегда славилась своей забагованностью. Если посмотреть на игру Morrowind, во время которой и сформировался концепт современных elder scrolls, то на релизе это так еще поделка была.
Подтвердил энтером — гарантированный вылет из игры. Через пол года фикс, в диалоговых окнах заблокировали возможность работать с клавиатуры.
При прыжке есть 1% шанс провалиться под текстуры. За день игры это могло случиться под сотню раз. Не увере, что вообще пофиксили.
Перед квестом на сопровождение необходимо было сохраниться, так как в среднем пройти можно было с третей попытки. Перезапускать квест в течении двух часов в морроувинде — привычное занятие.
И т.д. и т.п., дальше уже пошла просто эксплуатация серии. В обливионе уже было не так страшно, скайрим просто дополнение к нему.
Насколько я понял, в понимании Algori настройка такого софта и есть сложность этого процесса) Но в этом случае сложен метагейминг, а совсем не игра.
Во-первых, это в любом случае сложнее, чем копать одним кораблем. И риска больше. Возражения есть?
Во-вторых, метагейминг в EVE — часть игры, как нигде.
А в-третьих, если вот эта «копка в 10 окон» делается с помощью стороннего софта (я вообще не в курсе, я и одним не копаю: ) — то это вроде бы нарушение EULA, не? А это уже совсем другая история…
Нету тут близко уникального геймплея с необычными решениями или концепцией, все последнее идет исключительно из мира инди.
Можешь назвать хорошую, интересную инди-игру, сравнимую с тем же Скайримом, Deus Ex… ну, собственно, лениво перечислять, ты понял идею? Майнкрафт не предлагать, там специфично все, включая историю раскрутки проекта.
Не концепт, не «хорошие идеи», не «еще немного допилить и был бы шедевр». Просто хорошую игру. Вообще-то я парочку знаю, например, M&B в принципе — полуинди. Но, как ни странно, никаких революционных идей там нет. Есть хороший, добротно сделанный боевой движок. И все. Остальное давным-давно известно.
Инди дают белый шум. Информационный трэш. Чем-то похоже на брэйн-сторм по классической методике. Ведь в нем самое главное не накидать каких попало идей. Главное в нем — выбрать потом те, с которыми стоит возиться и доводить их до состояния готового продукта. На этапе накидки идей можно брать почти кого угодно. На этапе отбора и доработки — нужны хорошие профессионалы. Иначе все без толку.
Да чего там сложного? Пошаговые инструкции по каждой игре на ихнем сайте + их Форум, чат и фики. К тому же это коммерческий продукт с развитым интерфейсом.
1. Результат должен быть известен перед сбором команды. Чтобы не собирать команду из гениального булочника. идеального сапожника и великолепного трубочиста. А потом предложить им что нибудь сделать. Зачастую в большинстве инди проектов команда собирается именно такая.
2. опять же оставить команде только те " решения, которые кроме них все равно никто адекватно принять не способен."
Решения о сроках, изменениях в задаче или тем более о способе распространения это решения которые разработчик зачастую как раз адекватно не сможет принять. Т.е. решение «а давайте забабахаем еще и перламутровые пуговицы это не решение команды разработчиков».Кстати байку как программисты строили дом т тут все помнят?
Или мне еще поднять рейтинг левым тестом?3. замечательно только вместо слова «небольшое», которое очень не точно и может интерпретироваться по разному стоит поставить словосочетание «заранее оговоренное». Это по крайней мере позволит какое никакое планирование и не сделает разработчиков основным источником бардака в команде.
Это совсем в сторону. но в качестве примера — когда разработчики ВоВ говорят «мы не можем расширить сумку свыше 16 ячеек потому что код был написан давно и сейчас его невозможно менять» Это говорит о том что код в настоящий момент плохой. с другой стороны почти любая програма которую дописывают 10 лет будет обладать этим свойством. особенно если проектировалась она на 2-3 года (как предрекали тому же ВоВ в начала разработки).
Заметно — возражения по теме и без лишних риторических конструкций. вроде «смеются с..» или «городишь ересь».
Кстати в качестве доп замечаний --в этом случае кикстартер в общем то очень условный способ выхода. поскольку эти три пункта никак особо не поддерживает.
Если платить дополнительно за патчи и фиксы — будет еще хуже :) Если процент с продаж — то на какие шиши вести разработку? Если и то и другое — как считать риск?
2. Дать им право принмать решения, которые кроме них все равно никто адекватно принять не способен.
3. Оставить их хотя бы небольшое время в покое от своего внимания, чтобы они могли сконцентрироваться на работе.
Это рецепт идеального «спринта» от Капитана Очевидность. На практике лажают во всех трех пунктах. Плохой код — а что это такое вообще?
Да, я работал и работаю в крупных технических проектах.
А ты выше писал о дедлайнах, выставляемых по принципу — «выпускать надо в сентябре, а то летом люди в отпусках, а в октябре уже конкурент релизится». При том что разработчику такой выпуск не принесет вообще ничего хорошего, у него фиксированная оплата.
К тому же баржа, вообще корабль не особо дорогой.
Потому что то что описал Алгори имеет один недостаток.
Это совершеннейшие банальности нормальной разработки крупного проекта.
А приводимые ниже возражения я многократно слышал в своей работе, как отмазки плохих кодеров --" если бы нам создали идеальные условия мы бы выдали идеальный код"
Причем чаще всего говорящие после этого ничего хорошего не выдают даже в хороших условиях.
Сразу чтобы убрать обвинения в дилетанстве --2 проекта несколько внедерений. В том числе 1 неудачный проект именно потому что «творцы ждали идеальных условий и делали идеальную программу» (20 лет делали если что и наверно до сих пор делают).
Кстати из возражавших --кто нибудь вообще работал в крупных технических проектах, не обязательно кодерских?
А просто хороших инди вагон, мне даже перечислять как-то не хочется. Достаточно в стиме запустить поиск по жанру «инди». Первые пришедшие на ум — Don't Starve, Bastion, Dust.
Подтвердил энтером — гарантированный вылет из игры. Через пол года фикс, в диалоговых окнах заблокировали возможность работать с клавиатуры.
При прыжке есть 1% шанс провалиться под текстуры. За день игры это могло случиться под сотню раз. Не увере, что вообще пофиксили.
Перед квестом на сопровождение необходимо было сохраниться, так как в среднем пройти можно было с третей попытки. Перезапускать квест в течении двух часов в морроувинде — привычное занятие.
И т.д. и т.п., дальше уже пошла просто эксплуатация серии. В обливионе уже было не так страшно, скайрим просто дополнение к нему.
Во-вторых, метагейминг в EVE — часть игры, как нигде.
А в-третьих, если вот эта «копка в 10 окон» делается с помощью стороннего софта (я вообще не в курсе, я и одним не копаю: ) — то это вроде бы нарушение EULA, не? А это уже совсем другая история…
Не концепт, не «хорошие идеи», не «еще немного допилить и был бы шедевр». Просто хорошую игру. Вообще-то я парочку знаю, например, M&B в принципе — полуинди. Но, как ни странно, никаких революционных идей там нет. Есть хороший, добротно сделанный боевой движок. И все. Остальное давным-давно известно.
Инди дают белый шум. Информационный трэш. Чем-то похоже на брэйн-сторм по классической методике. Ведь в нем самое главное не накидать каких попало идей. Главное в нем — выбрать потом те, с которыми стоит возиться и доводить их до состояния готового продукта. На этапе накидки идей можно брать почти кого угодно. На этапе отбора и доработки — нужны хорошие профессионалы. Иначе все без толку.