Ты играешь в мире, где твои действия влияют на других игроков, а их — на тебя. Если все «срезают углы», то в песочнице части геймплея сами собой окажутся отрезанными для «честных» игроков. Несмоненно, можно найти свою нишу, но зачем?
Ну это и раньше было. И t1 хулы и капы — все строили. (Хотя если про простые капы говорить, то покупали их в имперских лоусеках в основном :) )
Но это всё т1 — просто, мало прибыльно. Фактически т1 это просто упаковка минералов, а не производство.
Я, просто, не очень вижу что изменят эти астероидные бусты для нулевого производства…
Что-то я вообще не поняла ваши восторги по-поводу множества функций на корабле… Где мотивация этим всем заниматься? Только неозможность купить/заработать свой корабль или как? Другой мотивации как-то не видно… Сразу же вспоминаем Аллоды-онлайн, где реализованы профессии стрелка, наводчика, оператора энергоустановок и т.д. и т.п. (я в нее мало играла-всего лишь знакомилась на фришке) однако там весь этот функционал у кораблей есть. И что много людей жаждут этим всем заниматься? Я бы не сказала. Мне немного понравилось стрелять демонов (наводчик на пушке), и все равно хотелось управлять кораблем (но это дорого — его купить, и управляет кораблем его владелец — капитан). Так где интерес игроков занаматься этим? Непонятно пока.
Всё зависит от заказчика. Тесное сотрудничество с заказчиком — краеугольный камень всех Agile методов разработки. В теории.
Кент Беку, было круто теории разрабатывать когда он для собственной корпорации систему зарплаты писал.
В реальности, за 20 лет активной практики, за исключением внутренних проектов, я ни разу не встречал полностью «разумного» заказчика :)
Зато я имел и инею множество проектов с очень «тяжёлыми» клиентами которые ничего не хотят понимать и никак не хотят помогать. Не сотрудничество, а какой-то бой непрерывный.
Причём, что характерно — чем крупней клиент, тем тяжелее с ним работать «гибкими» методами.
Либо ты живёшь с этим, либо не имеешь работы. Как-то так.
Так что когда речь идет о профи, сдающих проект в срок, то я скорее верю в людей, которые находят в себе силы отказать неадекватным\проблемным заказчикам.
И это тоже. Ну или, если уверены в своих силах, застроить заказчика, научить его выдавать внятную информацию и т.п. Это всегда часть работы — интеракция с заказчиками/инвесторами и ее тоже можно делать хорошо или плохо.
Сроки сдачи проекта в немалой степени зависят от заказчика. Предоставление всех необходимых материалов. Конечность требований. Разумное отношение к тестированию продукта и качеству.
Т.е. если заказчик имеет обыкновение задерживать данные и внезапно приходить с очень важными идеями, для учета которых нужно переделывать много и долго, то понятно, что ничего хорошего такому проекту не светит. Особенно с авансовой оплатой.
Так что когда речь идет о профи, сдающих проект в срок, то я скорее верю в людей, которые находят в себе силы отказать неадекватным\проблемным заказчикам.
Что заказчик «думает туман» — это штатная ситуация. Чтобы из тумана проступило что-то конкретное — придумали разбивать проект на итерации
Вот тебе (по итогам комментов) я почему-то верю, что у тебя есть опыт работы с средними/крупными проектами. И, вероятно, не только в качестве помощника младшего черпальщика :) Хотя, честно говоря, хватило бы и обычной логики.
Организация работы в жесткие сроки при условии меняющихся и дополняющихся вводных — это штатная ситуация. Другой она просто не бывает.
В этом контексте было бы очень интересно узнать и сравнить между собою бюджет на собственно разработку (кодеры, QA, дизайнеры и другие), и на опциональные вещи вроде рекламной компании, расходов на ролики, на озвучку и т.п.
Даже там, где речь идет о жизненно необходимых вещах, есть варианты. Можно на роль прототипа и голоса главного героя нанять актера или модель с узнаваемым лицом (Republic Commando, Force Unleashed, Mass Effect), а можно обойтись внутренними ресурсами (Max Paine), и не факт, что конечный результат будет существенно отличаться по качеству и силе воздействия на потребителя. Вспоминая последний, комикс-вставки там смотрелись ничуть не хуже скриптовых или CGI роликов, особенно в сравнении с тогдашней графикой.
На самом деле в нулях есть достаточно много нишь для производства — во первых капиталы, во вторых т1 хулы (их логистика стоит столько же сколько производство), плюс покупка мунматов у «своих» и богатая планетарка позволяют достаточно легко делать весь необходимый ассортимент т2. Лично я, когда завожу товар из житы, внимательно просматриваю рынок на предмет демпингующих производственников, и нередко (особенно если это али формат) отказываюсь от позиции.
1. Команда на каждый спринт может подбираться заново. Если окажется, что на каком-то этапе нужен сапожник — значит надо искать сапожника.
На практике никто так не делает из-за заморочек HR.
2. Зависит от того, входит product owner в команду или нет.
В теории должен, на практике я этого не видел никогда. Почему — отдельная история.
3. Я говорил не «небольшое», а «хотя бы небольшое» :) Считай это риторической конструкцией :)
Что заказчик «думает туман» — это штатная ситуация. Чтобы из тумана проступило что-то конкретное — придумали разбивать проект на итерации. А итерация — это уже нечто совершенно конкретное и конечное.
Насколько до мена дошло, издатели уже додумались, что деньги можно получать не за весь продукт а по частям. Теперь бы еще научились сами так платить разработчикам :)
По моему мнению он не добьются никаких существенных изменений в этом вопросе. До тех пор пока альянсы не будут иметь проблем с крупной логистикой из империи в нули — они будут закупаться в Жите. Плевать что будут переплачивать — возможность купить что угодно, в любом количестве и сразу будет перевешивать любые другие резоны.
С isboxer всё просто — как я примерно выше описал. Да, есть какое-то фиксированное время которое понадобится на освоение и подстройку под себя. Но оно конечно. Ну три дня потратить, ну неделю. Потом — ноль особых усилий.
Теоретически :) А на практике заказчик на начальном этапе не представляет на 100% чего он хочет получить. Т.е. не представляет все use cases. Понимание многих вещей заказчиком и его желания меняются в процессе разработки, и игры не исключение :) И не важно, выступает в роли заказчика издатель или сами игроделы :)
угу. Только сразу проявить ограничения.
1. Результат должен быть известен перед сбором команды. Чтобы не собирать команду из гениального булочника. идеального сапожника и великолепного трубочиста. А потом предложить им что нибудь сделать. Зачастую в большинстве инди проектов команда собирается именно такая.
2. опять же оставить команде только те " решения, которые кроме них все равно никто адекватно принять не способен."
Решения о сроках, изменениях в задаче или тем более о способе распространения это решения которые разработчик зачастую как раз адекватно не сможет принять. Т.е. решение «а давайте забабахаем еще и перламутровые пуговицы это не решение команды разработчиков».Кстати байку как программисты строили дом т тут все помнят? Или мне еще поднять рейтинг левым тестом?
3. замечательно только вместо слова «небольшое», которое очень не точно и может интерпретироваться по разному стоит поставить словосочетание «заранее оговоренное». Это по крайней мере позволит какое никакое планирование и не сделает разработчиков основным источником бардака в команде.
Плохой код — а что это такое вообще?
Это совсем в сторону. но в качестве примера — когда разработчики ВоВ говорят «мы не можем расширить сумку свыше 16 ячеек потому что код был написан давно и сейчас его невозможно менять» Это говорит о том что код в настоящий момент плохой. с другой стороны почти любая програма которую дописывают 10 лет будет обладать этим свойством. особенно если проектировалась она на 2-3 года (как предрекали тому же ВоВ в начала разработки).
Да, я работал и работаю в крупных технических проектах.
Заметно — возражения по теме и без лишних риторических конструкций. вроде «смеются с..» или «городишь ересь».
Кстати в качестве доп замечаний --в этом случае кикстартер в общем то очень условный способ выхода. поскольку эти три пункта никак особо не поддерживает.
При том что разработчику такой выпуск не принесет вообще ничего хорошего, у него фиксированная оплата.
Если платить дополнительно за патчи и фиксы — будет еще хуже :) Если процент с продаж — то на какие шиши вести разработку? Если и то и другое — как считать риск?
Чисто теоретически — можно и спроектировать, и оттестировать и даже верифицировать. Ибо количество use cases и состояний конечно :) Только времени на это нужно несколько больше, чем принято отводить. Причем если бы софт, и игры в частности, не изобретали каждый раз заново — оно бы нашлось.
Но это всё т1 — просто, мало прибыльно. Фактически т1 это просто упаковка минералов, а не производство.
Я, просто, не очень вижу что изменят эти астероидные бусты для нулевого производства…
Кент Беку, было круто теории разрабатывать когда он для собственной корпорации систему зарплаты писал.
В реальности, за 20 лет активной практики, за исключением внутренних проектов, я ни разу не встречал полностью «разумного» заказчика :)
Зато я имел и инею множество проектов с очень «тяжёлыми» клиентами которые ничего не хотят понимать и никак не хотят помогать. Не сотрудничество, а какой-то бой непрерывный.
Причём, что характерно — чем крупней клиент, тем тяжелее с ним работать «гибкими» методами.
Либо ты живёшь с этим, либо не имеешь работы. Как-то так.
Т.е. если заказчик имеет обыкновение задерживать данные и внезапно приходить с очень важными идеями, для учета которых нужно переделывать много и долго, то понятно, что ничего хорошего такому проекту не светит. Особенно с авансовой оплатой.
Так что когда речь идет о профи, сдающих проект в срок, то я скорее верю в людей, которые находят в себе силы отказать неадекватным\проблемным заказчикам.
Организация работы в жесткие сроки при условии меняющихся и дополняющихся вводных — это штатная ситуация. Другой она просто не бывает.
Даже там, где речь идет о жизненно необходимых вещах, есть варианты. Можно на роль прототипа и голоса главного героя нанять актера или модель с узнаваемым лицом (Republic Commando, Force Unleashed, Mass Effect), а можно обойтись внутренними ресурсами (Max Paine), и не факт, что конечный результат будет существенно отличаться по качеству и силе воздействия на потребителя. Вспоминая последний, комикс-вставки там смотрелись ничуть не хуже скриптовых или CGI роликов, особенно в сравнении с тогдашней графикой.
На практике никто так не делает из-за заморочек HR.
2. Зависит от того, входит product owner в команду или нет.
В теории должен, на практике я этого не видел никогда. Почему — отдельная история.
3. Я говорил не «небольшое», а «хотя бы небольшое» :) Считай это риторической конструкцией :)
Насколько до мена дошло, издатели уже додумались, что деньги можно получать не за весь продукт а по частям. Теперь бы еще научились сами так платить разработчикам :)
1. Результат должен быть известен перед сбором команды. Чтобы не собирать команду из гениального булочника. идеального сапожника и великолепного трубочиста. А потом предложить им что нибудь сделать. Зачастую в большинстве инди проектов команда собирается именно такая.
2. опять же оставить команде только те " решения, которые кроме них все равно никто адекватно принять не способен."
Решения о сроках, изменениях в задаче или тем более о способе распространения это решения которые разработчик зачастую как раз адекватно не сможет принять. Т.е. решение «а давайте забабахаем еще и перламутровые пуговицы это не решение команды разработчиков».Кстати байку как программисты строили дом т тут все помнят?
Или мне еще поднять рейтинг левым тестом?3. замечательно только вместо слова «небольшое», которое очень не точно и может интерпретироваться по разному стоит поставить словосочетание «заранее оговоренное». Это по крайней мере позволит какое никакое планирование и не сделает разработчиков основным источником бардака в команде.
Это совсем в сторону. но в качестве примера — когда разработчики ВоВ говорят «мы не можем расширить сумку свыше 16 ячеек потому что код был написан давно и сейчас его невозможно менять» Это говорит о том что код в настоящий момент плохой. с другой стороны почти любая програма которую дописывают 10 лет будет обладать этим свойством. особенно если проектировалась она на 2-3 года (как предрекали тому же ВоВ в начала разработки).
Заметно — возражения по теме и без лишних риторических конструкций. вроде «смеются с..» или «городишь ересь».
Кстати в качестве доп замечаний --в этом случае кикстартер в общем то очень условный способ выхода. поскольку эти три пункта никак особо не поддерживает.
Если платить дополнительно за патчи и фиксы — будет еще хуже :) Если процент с продаж — то на какие шиши вести разработку? Если и то и другое — как считать риск?