Войти
ПроектыФорумСобираю команду

Игра для тех кто-хотел бы побсуждать и потворить в свое удовольствие. (2 стр)

Страницы: 1 2
#15
4:57, 31 окт. 2019

xorix
> основном озарение приходило в двух вариантах:
>
> 1) Разрабатываешь что-то, помимо этого ресерчить и тут бах - а если сделать вот
> так-то - это вообще будет бомба. Т.е. в процессе работы над чем-то приходят
> новые идеи.
>
> 2) При обсуждении проблемы/задачи с командой.

Это примерно то же самое, что сесть писать книгу или начать снимать кино, не имея проработанного плана с проработанной основой. Да, в процессе работы появляются новые идеи и их иногда следует внедрять, но без четкого понимания того, что вы делаете, то есть в контексте игростроя речь идет о центральных core mechanics - не стоит даже начинать. В данном обсуждении есть два актуальных вопроса:

1) Чем вы лучше и интересней L2D и Resident Evil?
2) Что в вашей игре сможет делать интересного игрок такого, чего он не может делать в других играх?

Первое - вопрос актуальности на фоне конкурентов.
Второе - вопрос уникальных механик выделяющих данный проект.

Список ответов на эти вопросы должен быть достаточно длинный, что бы сесть за проект. А дальше идет пайплайн разработки игры - сначала продумывается до мельчайших деталей вся концепция верхнего уровня, проект уходит в разработку, а пока персонажи учатся ходить, стрелять, умирать, получать и наносить урон - прописываются детали второго уровня - экономика, баланс, концепции удержания и возврата игрока. Когда этот аспект работы готов, он уходит в разработку - программисты пишут фичи во всей их полноте, а геймдизайнер прорабатывает третий уровень - глобальные фичеры, челленджи, просчитывает нагрузку на игрока, проводит оценку эмоционального импакта тех или иных игровых ситуаций. Когда эта работа готова - проект передается в руки level designerу, который должен уже в тесном сотрудничестве с геймдизайнером проработать уровни с точки зрения концепции, с точки зрения игровой активности. На этом этапе программисты в проекте работают над сетью, клиентской частью, UI и прочим, а основная нагрузка по работе идет на арт-отдел, который должен все это превратить в сочное месиво. На всех этапах возможно восходящее проектирование, т.е опираясь на проделанную детализацию - уточнение концепций верхнего уровня. И вся эта работа начинается с четкого представления о геймплейных фичерах проекта, без которых все теряет смысл.

То же самое и с разработкой ПО - вы должны сначала представлять зачем оно нужно, что оно будет делать и для чего предназначаться, и уже потом садиться проектировать.


#16
21:44, 31 окт. 2019

xorix
> и кстати в начале честно написал что нет дизайн документа
Он и не нужен.

ММО шутер это очень сложная тема, это не просто так что в период расцвет ММОРПС, ММОшутер было раз-два и обчелся. Не просто так развалились все профессиональные лиги по КС и ТФ (хотя дефмачи все еще живут).

Была у меня одна задумка еще в те времена когда Бондер всерьез делал ММО всем форумом, если еще интерес есть (если ПиКа его не отбил),  стукни в личку

#17
23:18, 31 окт. 2019

PeeKay

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

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

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

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

- Проработка требований аналитиками и драйвером начинается параллельно с реализацией прототипа. Тут важный момент - на прототип лучше брать ответственного сеньера (который понимает во что это выльется), а не джуниора, потому как большинство прототипов (со всеми их костылями) становятся фундаментом будущего проекта. Ни кто ни времени ни денег платить не будет чтоб потом вместо прототипа сделать проект "по правильному".

В процессе проработки требований и архитектуры заводятся дочерние запросы на необходимые доработки. В случае не стыковок переделываются требования или в крайнем случае прототип. В итоге прототип перевращается "в элегантные шорты" в альфу (но чаще сразу в бету). А там в виде багфикса доделывают функционал который не успели доделать до беты.

Иногда требования дописываются после того как уже реализован функционал, как бы это странно не звучало.

#18
23:21, 31 окт. 2019

Ren

Скидывай, будем посмотреть.

Страницы: 1 2
ПроектыФорумСобираю команду

Тема в архиве.