Pull to refresh

Comments 71

Спасибо за опыт.
У меня есть мечта — сделать игру.
Хороший художник начинает писать картину крупными мазками без деталей.
Верно, в этом суть, от простого к сложному.
Художникам очень хорошо это дается, сам такой, нужно видеть картину в целом. Не каждый художник этого придерживается, начинают дробить.
Для последовательности действий нужен еще и аналитический склад ума, либо кодер, который будет подпинывать в случае отклонения от курса.
Часто видел как игры создаются от обратного.
Художник рисует эскизы игры. Затем выбирают те рисунки, что ему/всем/самому буйному понравились, начинают коллективно придумывать механику игры.
Затем художник допиливает рисунки уже к обговоренной механике (как он ее понял), а программисты делают все как у вас описано, но уже с частичной графикой.
После этого этапа начинают прикидывать как монетизировать будущий шЫдевр, и дальше дорабатывают с учетом будущей монетизации.
Никто не мешает сделать наброски и концепты, но начинается игра с геймдизанй документа на основе жанровой механики.

Прототип не включает в себя творчество, совсем. Творчество идет параллельно, пока работают кодеры, художники рисуют.

Монетизация продумывается на этапе ГД.
Разработка начинается с геймдизайн документа, остальное — гаражные посиделки.

Статья по созданию ГД востребована, в скором времени напишу, там будут ответы на многое.
Наверно я не так выразился.
У нас часто было так приходит наш художник и показывает концепты и/или героев будущей игры которая ему приснилась/привиделась/подсмотрел где-то.
Затем все кто рядом начинают фантазировать как в это играть и т.д. см выше.
Поэтому 1й документ уже идет с графикой.

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

Большинство так не умеют. То что вы вместе можете это создать, вообще замечательно. Молодцы!
Вы будете смеяться, но этим грешат не только начинающие. Я конечно не был разработчиком игр, а разработчиком в команде разработки СДК для геймдева. Но иногда приходили запросы на локализации игр — и от авторов игры (а иногда это были довольно известные ребята) сводной таблички для монстров в удобном виде не видел ни разу (разве что в виде файла ресурсов для игры).
Для внутреннего тестирования функционала и баланса игры — прототип необходим, но адекватного прогноза успешности игры он не даст (кроме может инди-игр с уникальным новаторским геймплеем, но не для обозначенных вами шутеров и РПГ.). Почему?
А вы попробуйте сократить несколько популярных и провальных игр данного формата до такого схематичного протипа, а затем попробуйте найти между ними различия!
Выкиньте из Скайрима все квесты, фракции, диалоги и красивый мир, оставив такой схематический прототип, и чем он после этого будет отличаться от десятков других РПГ которые мало кому известны? Где вы тут увидите то, что сделало игру популярной? На уровне механик ничего выдающегося в нем, по сравнению с кучей других РПГ нет!
С шутерами, тем более сведенными до такого прототипа сотрутся вообще все отличия между хилым инди проектом с сотней игроков и топ-ААА с миллионами продаж, потому что на уровне протитипа и там и там одно и тоже по-сути, но итоговая проработанность мира и сценариев, а в итоге и ощущения от игр в итоге принципиально разные!
Верно, потому нужна фокус группа. Игра всегда делается для конкретной ЦА.
Очень удачный пример скайрима, можно выкинуть из него все, но он останется с геймплеем, в него все же будут играть, если механики не пострадают.
По шутерам, не согласен. Есть сейчас материал по комбинированию монстров в разработке. Если кратко, то плотность геймплея +дизайн уровней = успех шутера.
Главное идти последовательно, не начиная с конца, тогда игра обрастает всем тем необходимым.
А для прогноза продаж нужен маркетолог, но даже он не даст гарантии успеха.
Самое важно — хорошая и интересная игра, она должна давать игроку эмоции и ощущение потока.
Именно с этим поможет игровой прототип, ведь при добавлении деталей на хороший скелет, общее ощущение только усиливается и создаются хорошие игры.

Очень удачный пример скайрима, можно выкинуть из него все, но он останется с геймплеем, в него все же будут играть, если механики не пострадают.
Геймплей скайрима достаточно стандартен для РПГ, как и используемые механики. Но сам мир, сама атмосфера при этом создана так, что в этом мире интересно находится, интересно его исследовать, быть его частью. И вот эту целостность и насыщенность мира не получится воссоздать на схематическом прототипе, схематический прототип будет похож на десятки других игр этого же жанра, которые даже близко не достигли такого же успеха…
Согласен, но с оговоркой. Прокачка навыка при использовании предмета — редкость. Стамина при действиях — тоже не очень популярно.
В остальном — бесспорно.
Можем пойти от обратного, сделали красиво, но не продумали геймплей, скелеты имбалансы либо игрок слишком сильный, да сюжет крутой, но играть в это не интересно.
Есть еще момент — геймплей ради сюжета, либо сюжет ради геймплея.
Т.е либо сюжет «для галочки» и упор на геймплей, либо упор в сюжет.
От этого зависит что делать в игровом прототипе, если игра — история, то нужно тестировать ее подачу и юзабилити, размеры шрифтов, создать диалоги и тд. Но если игра про убийство тысячи монстров то примеры в статье отлично подходят для старта.

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

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

Верно, а потом уже игрок смотрит на качество реализации с течением времени.
Но изначально механика отличается и цепляет.
Можем пойти от обратного, сделали красиво, но не продумали геймплей, ск
В уже упомянутом скайриме имбалансных монстров, предметов, умений — тьма. Но в него все равно играют. Потому что, во-первых, как уже упомянули — мир. Не так много игр куда можно зайти, загрузиться в свой дом, дойти до шкафа с книгами и сесть читать на несколько часов. А во-вторых скайрим — это рай для моддеров. Как и предыдущие части. Его модифицировать настолько легко что это можно сделать самому за несколько минут (только примитивные вещи конечно). Если бы в скайриме не было модов он бы и десятую часть своей популярности не поимел. А прокачка действиями на самом деле весьма распространена, начиная с ультимы и дварф фортресс и заканчивая азиатскими играми, тот же last revenant или final fantasy (некоторые и до определенной степени). В скайриме нет уникальных основных механик. Мелочи — есть, общий набор — да более-менее уникален. Но в МВП скайрима этого всего не будет. А если строить минимальный прототип на том что делает скайрим таким популярным, то мне очень сложно представить как это должно выглядеть. Как книга с возможностью редактирования? Ну то есть текстовый файл?
Нет, то что вы описали — МВП, это же фишки игры, они должны быть в прототипе. Исследование мира — одна из основных составляющих скайрима.
Но, вы серьезно готовы делать исследование мира, до того как у вас готов бой на мечах? Прокачка? Противники? Ловушки?
Последовательность и еще раз последовательность.
От простого к сложному, только так, все о чем пишут в комментариях — следующий этап. Но начальный, который описан в статье, пропускать нельзя, а его пропускают и сначала делают интересный мир, а не ядро.
Я видимо вас понял: суть не в том, чтобы в прототипе показать чем ваша игра уникальна, а в том, чтобы понять что основные механики — работают. Меня сбила с толку фраза про «интересно играть в прототип». Бой на мечах в том же скайриме совершенно неинтересен. Как и ловушки и схематичные противники. Там вообще боевка весьма убога. Чтобы скайрим был интересен в нем нужен весь его лор и все его разнообразие, это именно что игра про отыгрыш в большом и интересном мире. Или я неправ и основные фичи таки должны быть в МВП?
Основные фичи должны быть в МВП, это именно то что будет цеплять игроков, это уникальность проекта. Без нее это будет безликая серая масса. Именно фичи делают МВП интересным.
Безусловно есть сложные фичи для реализации, они вводятся позже.
Тогда я искренне не понимаю что, по-вашему, должно было быть в прототипе скайрима. Нет, я согласен что прототип нужен и с ним обычно лучше чем без, но вот приведенный вами же в посте пример совершенно не корректен. Потому что что у скайрима, что у морровинда основные фичи — не махание мечом и не драконы с орками. Система прокачки и боя в этих играх такая же как во многих других.
От простого к сложному, сначала создаем перемещение и противников, прокачку.

Затем локации открытые и параллельно делаем пещеры и помещения, собираем кусок готовый, идем дальше и наращиваем.

Где то в бэкграунде пишется сюжет, диалоги и прочее.

Масштабируйте, начинается все с малого.
От простого к сложному, сначала создаем перемещение и противников, прокачку.
Но ведь в этом нет той самой фишки, которая отличает эту игру, от сотни других основанных на том же принципе. А вы сами в предыдущем же комментарии говорили что в прототипе она должна быть.
Ну это зависит, насколько комплексную игру хотите сделать.
Для скайрима с его фишками возможно правильно — взять обливион и начать пилить к нему мод.
Перемещение и махание мечом — действительно не самое важное.
Но если вы хотите сделать свой скайрим — вам тоже будет проще начать с модов, но выпустить игру на движке бесезды нельзя — рано или поздно нужен свой движок — а значит новые прототипы тех самых бегалок и махалок мечом.

Штука в том, что в скайриме не одна и не две фишки, отличающей эту игру от сотни на том же принципе.
А вы свою фишку к чему прикручивать будете? К базовой механике.
Если ваша фишка = базовая механика, то это новый жанр
Скайрим, как пример, не особо хорошо подходит, это не игра новичка. Первые игр, что бы их можно было доделать до конца, должны быть сильно проще. Посмотрите начальные зарисовки капхеад, игры, которая строится полностью на аудиовизуальном стиле. Там будет именно схематичный геймплей.

Можно, пожалуйста, ссылку на оригинал? Ну или в конце статьи добавьте упоминание, для всех

Мне кажется это не перевод.
Компьютерные игры это не только набор правил, это в первую очередь дизайн (в том числе и нарративный). Часто игры не имеют интересного геимплея, но дизайн заставляет просиживать там часами. Так же сильно влияет наличие и разнообразие контента.
Есть куча «танчиков/самолетиков/корабликов», но меня заинтересовала лишь одна, при этом между всеми различия на уровне погрешности.
При этом есть игры, которые совершенно принебрегают графической и сюжетной составляющей — Kerbal Space Program, но тут есть тот самый геимплей, но в KSP тянет играть, а в аналоги — нет.
Поэтому не все так просто, как вы описали, если рассматривать успешность и жизнеспособность игры. А вот при создании подход весьма уместный (но помоему очевидный).

Тоже хотел написать: примеры наводят на мысль о создании ещё одного Doom, коих и так 100500.
Разница между ними не в геймплее ведь.


А геймплей новый придумать это не знаю кем надо быть… Пажитновым наверное.

Правил нужна для того чтобы их нарушать )
Вы правы, безусловно, это не только набор правил. Но это стартовая точка.
Или вы начинаете делать что-то с конца?
Соблюдая принцип от простого к сложному, вы всегда получите хороший результат за достаточно быстрый промежуток времени.
Смысл не в том чтобы «сделать DOOM», но в том чтобы помочь появлению новых и крутых проектов, ведь если вы понимаете что в это интересно играть, то сомнения по поводу идеи и крутости игры отпадают.
Это большая проблема и развивается она в 2 ситуации
1 — проект вышел и не интересен игрокам
2 — проект никогда не выходит, потому что разработчик сомневается, а интересно ли это игроку?
порой самые очевидные вещи — труднее всего соблюдать.
все знают, что для похудения нужно тратить больше, чем потребляешь. но такую схему берутся реализовать лишь единицы и сотен людей.
все знают, что для достижения цели нужно не просто красиво сформулировать цель и почитать умных книжек, но и очень много трудиться, очень много стараться. в жизни уже довелось видеть примеры, когда такая схема работает. но остальные все продолжают лишь хотеть.
также, все знают, что сначала надо делать прототип и что надо вести подробный учет своих действий/результатов, это очевидно, но много ли так делают?
Это больше вопрос психологии, статья создана для того чтобы помочь ответить на вопрос
" что теперь делать и с чего начать". Безусловно лишь единицы оторвут пятую точку с насиженного места.
Мне остается надеется что те кто ищут информацию, ищут совета и действительно готовы делать, увидят этот материал и сделают выводы.
Если я сделаю их разработку проще, просто поделившись опытом, что должно меня останавливать?
Мы пытались на прототипах, но правополушарные креативщики и художники впадали в уныние от плоскостей и цилиндров. Им, видите ли, для каждого следующего шага нужна душевная картинка и возможность поиграться с их детищами, сотворёнными на предыдущем шаге. А технари, которые могут что-то придумывать прямо в формулах и коде, очень ограничены в своём потенциале креатива. Есть шанс только с грамотным архитектором/лидером/технологом, который распределит задачи и будет тщательно контролировать время выполнения.
Все так как вы сказали, очень часто с этим проблемы, не только у новичков.

Дело в организации процесса разработки. Это следующая тема, скоро напишу. Тут главное понимать вот что — для геймплея важна техническая часть в первую очередь. Можно код и графику делать отдельно до определенного момента, либо параллельно будет дизайнер уровней или сборщик, который все будет собирать. Либо он делает это когда все отлажено.

Я сейчас как раз проектирую такой мвп. Забил на графику, звуки, анимации — просто пишу игровую логику. Согласен с тем, что тут важно разделить зону ответственности — например, я вынес все сущности в json справочники, и теперь их при желании можно редактировать без пересборки игры(и это может делать даже не-программист). Графику(когда начну её внедрять) так же постараюсь прикрутить аккуратно сбоку, но в идеале вообще буду делать заказ художнику после того, как оттестирую механику и определюсь с сущностями которые нужно отрисовывать.
Хороший подход, успехов вам с проектом.
Правополушарные креативщики могут в это время готовить concept-art'ы, музыку, fakeshot'ы, и т.д. (даже видео!) Там свои «крупные мазки», движение от простого к сложному. Да и вряд ли кто будут против вдохновиться, если подобные asset'ы выйдут хорошими.
добавил ваш коммент в статью
Такие прототипы не работают в нынешнее время.
Selling point у игр — это погружение. Текстурки, звук, scenery, локации, лор. Уже после этих параметров идут игровые механики и их специфика.

В пример прототипа современной игры можно привести разработку одной локации размером в «несколько экранов». Создание концепт арта этой локации и впиливание этого концепт арта в виде статичных мешей в игровой мир, чтобы по нему можно было проехать камерой.
Затем создание какой-нибудь конкретной игровой фичи в «вакууме», которую можно тригернуть через консоль.
И уже потом, если необходимо, создание «вакуумной» игровой ситуации. Например, если у вас пошаговая рпг, то можно запилить один-два раунда пошагового боя с каким-нибудь мобом, в котором попытаться отразить как можно больше механик, соответствующих жанру (юз айтемов, свич союзников внутри команды, командная стойка/постановка, минимальный набор скиллов).

Да, это не 10-минутный прототип под чашечку кофе. Такие прототипы остались во временах, когда люди всё ещё переизобретали те жанры, которые сейчас уже являются стабильными и «устаканенными».
Результатами такого прототипа уже можно руководствоваться при решении, взлетит ли ваша идея или нет.
У всего есть точка отсчета, нужно правильно налаживать сложность и системы в игре для создания эффекта потока у игрока. Чем раньше начать это делать, тем раньше будет хороший результат.
Смысл не в том чтобы делать типовые прототипы, смысл в том чтобы делать прототип конкретной своей игры с ее фишками и тестировать.
Еще это позволяет хорошо распределить обязанности в команде, если есть ПМ с головой. Что в свою очередь опять увеличивает скорость разработки.

Как пример можем взять рисунок и искусство в целом. Колористика — набор правил. Есть множество техник мазка, техник работы мастихином и кистью, но у всего есть правила, золотое сечение, постановка руки.
Так вот разработчики пытаются нарисовать «9 вал» Айвазовского, но карандаш в руках никогда не держали, именно решение этой проблемы я пытаюсь дать.
Думаю, автор просто не перечислил достаточное количество примеров… Если игра про игромеханику — в мвп должна входить эта игромеханика. Если ваша игра про нарратив — художник может включить в мвп наброски будущего стиля. Если игра — визуальная новелла, стоит набросать пару сюжетных сцен с текстом и картинками. Всё это не отменяет того, что нужно сделать ядро с геймплеем, просто в зависимости от того, на чём фокусируется ваш проект — в мвп нужно включать те или иные дополнительные вещи. В любом случае — чтобы в прототипе оценить концепт арт, вам нужен механизм который позволит «проехать камерой», и желательно чтобы он соответствовал тому, как это будет делать игрок.
добавил ваш коммент в статью
С прототипами есть еще одна проблема: то что кажется интересным и замечательным при коротком тесте может в реальной игре через несколько часов надоесть.
Было так с несколькими играми — начинаешь играть — супер, но после N-часов игры, не дойдя даже до середины игры бросаешь, хотя вроде бы и все шло замечательно, но быстро стало рутиной и вызвало отвращение к дальнейшей игре…
А это уже геймдизайнерский косяк и дизайнера уровней, не говоря про тестеров. Если механика крута на старте, то на всем протяжении игры она должна развиваться, а не стоять на месте. Поэтому важно — тестирование. Смысл в прототипе — создать оболочку, затем все собирается и начинается тестирование по N часов в широком круге людей.

Это косяки разработчиков, которые хотят в первую очередь прибыли, а не интереса для игрока. Необходимы QA и QC тестировщики для контроля тестов, часто таких людей даже в штате нет…

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


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

Важное замечание. Но бумага — бумага, тут присутствуют тактильные ощущения и живое общение. В игре этого нет, там сухой геймплей в прототипе.
Да, безусловно, аналоговый прототип это хорошо, но он даст понимание о геймплее в конкретных условиях для конкретного игрока. Вы не сможете отправить его тестировщикам в Австралию, Германию, Украину, Китай и Россию быстро, а это важно.
Плюс вы не сможете понять какие трудности в технической части вам предстоит решить и как строить разработку с точки зрения визуала.

С прототипами из бумаги, здорово, но только если вы понимаете как их правильно применять, не думаю что большинство новичков готовы их использовать. Но найдутся единицы, которым это удобно и они отшлифуют механики без старта разработки, если вы так умеете, то это просто потрясающе.
Хочу добавить еще один пункт в важности прототипов: они отрезвляют ожидания разработчиков, особенно новичков.
После того, как новичок потратит уйму времени на разработку работающих примитивов, он сможет и более реально оценить, сколько же ему потребуется времени на итоговую разработку? А это спасет его от вечной недоделанной альфы.
Не против если добавлю коммент в статью?
Не против, на хабре это вроде нормальная практика.
Я сейчас читаю «Чистую архитектуру» Роберта Мартина — он бы точно одобрил такой подход.

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

Во-вторых, отделив базовые механики от конкретных реализаций, мы, как правило, получаем более независимые слои архитектуры. Художники и творцы будут постоянно придумывать что-то и правки в финальный контент будут требоваться постоянно. Поэтому, чтобы эти правки не превращались в мучительные кранчи — надо отделять ядро игры от конкретной реализации.

То есть Роберт Мартин согласился бы с вами, но с обязательным условием — прототип должен быть сделан как достаточно независимый компонент, на который будет легко повесить любую конкретную реализацию. Потому что понятно, что прототип можно развить в финальную игру без всяких архитектурных изысков, просто делая «хардкодную» реализацию того, что увидит игрок, прямо в код прототипа.

В идеале в этом смысле нам нужен не просто прототип — а такой прототип, который будет использовать конкретный набор моделей, спрайтов и правил взаимодействий между ними как легко заменяемые скины (Роберт Мартин употребляет слово «плагины», но для игр привычнее скины ))
О, кстати, а как Hzpriezz увидел бы в шарАх и кубиках прототип следующего концепта:
— глобальная стратегия в дополненной реальности (на реальной карте)
— юниты и строения как в Total Anniglation, крафт запчастей для них
— добываемые ресурсы, сгенерированные руины и обломки юнитов в привязке к реальным объектам на карте: органика (леса), железо (рудники, шахты, железные дороги), энергия (линии электропереач, электростанции), радионуклиды (рудники, шахты, обогатительные комбинаты), вода (водоёмы, реки), сгенерированные «ничейные» юниты и станции (заправки, вокзалы, депо, заводы...).
— никакой телепортации юнитов и ресурсов. Все юниты должны ехать за ресурсами и обратно с небольшой скоростью своим ходом. У юнитов инвентари. Доступна локальная передача предметов.

Из всего вышеперечисленного следуют фермы, "корованы" и куча способв это все грабить=).

Можно крафтить квест заворачивая в него награду и условие выполнения.
Доступ к управлению, инвентарю и обзору любого юнита или станции регламентируется наличием соответствующего цифрового «ключа» в профиле игрока. Такой «ключ» можно скрафтить в игровой предмет или отправить SMS-кой. Это значит, что можно дать порулить своими юнитами кому-то, или поручить кому-то квестом построить цепь оборонительных турелей или ферму.
В «незанятых» административных центрах всех населенных пунктов время от времени «зарождается» NPC станция, которая выдаёт квесты на постройку оборонительных турелей. По факту сдачи у турелей будут заменены ключи и настроен режим подавления любой локальной агрессии. В таких зонах новички могут безопасно строить фермы начального уровня, ставить автоматические торговые станции для продажи ресурсов и предметов. За пределами таких территорий дикий запад, «корованы» и веселье.
Сегодня дам развернутый ответ, интересная задачка, мне понравилось. Как раз будет конкретный пример.

Спасибо :)
Приступим-с.
Для начала отсеем лишнее.Крафт запчастей мы сможем добавить после, ресурсы разного типа тоже. Система создания квестов нужна, это фишка, так же как «дать порулить». Фермы, административные центры и прочее потом.
Юниты
— пехотинец шар
— крупный наземный юнит крупный шар
— летающий юнит пирамидка
Свои юниты синего цвета, вражеские красные, аналогично.

Взаимодействие с дополненной реальностью.
Ввести ИИ врага или реального противника( нам нужен противник)
Все постройки — кубы, с распределением задач по цвету.
Работники — зеленые шарики.

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

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

Третий этап — ввод крафта зданий, административных центров и квесты с станции. Введем пределы безопасных зон и станции продажи.Ввод крафта ресурсов для юнитов.

Четвертый — ввод инвентаря для юнитов. Ввод фишки «дай порулить»

Более конкретно тут сложно ответить, всегда нужно смотреть. Я просто постарался разбить крупную задачу на мелкие, масштабировать одним словом. Это помогает.
У вас очень сложная и комплексная система, нужно смотреть цифры, геймдизайн документ и составлять список примитивов и присваивать всему цвета.
Хех, ну вы почти все угадали=)
На сегодняшний день у меня крафта действительно нет. Механизм размещения на огромной карте ресурсов есть, но системы ленивой генерации их на основе OSM пока нет. Да и ресурсы-то невидимы. Об их наличии мы делаем вывод по тому, что у нас на реальной карте размещено. Ну и геологический модуль будет для юнитов. Когда-нибудь.

Квесты сейчас программируются на питоне в отдельных файлах внутриигрового реестра. Там нужно рефакторить, но не много. Фактически для элементов квеста нужно наделать джинериков и систем вложенных контейнеров. Сейчас квест — это конечный автомат с плоским набором состояний. Хочу сделать состояния вложенными.
«порулить» — штука простая. не вижу каких-либо проблем чтобы запилить это пораньше.

Из станций сейчас только мины и ящики есть. Большой вопрос по верстке интерфесов для них. У меня нет фронтендера.

По концепции игровой вселенной (а она старается быть максимально правдоподобной и близкой к реальности на сколько это будет оставаться интересным) действие разворачивается в реальном мире с небольшим сдвигом в направлении одного из свернутых измерений нашего многомерного пространства. Юниты, ресурсы, всё что происходит — это среди нас, на нашей планете.
Получив возможность манипулировать материей в «соседних слоях» (игра называется Sublayers) люди «удалённо» начали делать там простые автоматы, а потом и сложных роботов. Они как призраки снуют среди нас невидимые и неощутимые. Под нашим управлением они могут манипулировать субматерией, добывать ресурсы строить и немного даже сражаться. Субматерия имеет какую-то ценность как специфические катализаторы или что-то типа того.

Мы получаем от них телеметрию и отправляем им сигналы с помощью сложной аппаратуры на спутниках в составе распределенной орбитальной группировки. Считается, что конкуренция и даже война способна подстегнуть прогресс в освоении новой перспективной отрасли перед лицом глобальной угро… так, что-то я увлекся=)

Короче, на первом этапе мы не имеем пирамид, шаров и кубиков, у нас самописный «leaflet» на канвасе с плавным масштабированием и скроллом, карта OSM с кастомными стилями пофутуристичнее, и пиктограммки для станций и юнитов. Это даже проще, чем ваши шарики, коллега.

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

Юниты будут ехать куда сказали, можно прокликать простенький маршрут, есть режим обороны, отступления… ну как в древнем старкрафте, чуть со своей спецификой.

Никаких караванов я добавлять не планирую. Их придется делать людям, чтобы более-менее безопасно перевозить барахлишко с фермы, построенной в прошлые выходные, когда ездили на пикник за город. У нас все локально: где клиент засветился геолокацией, там и аватар. Группа ведущих юнитов, остальные цепляются за ними по иерархии как ведомые или охранающие. Так и ходят толпой или гуськом, как настроишь следование.

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

Да, я знаю, что все у меня наизнанку. Именно поэтому игре уже черт ее знает сколько лет, а она еще в разработке=)
Ну и да, так-то идей полно, конечно. Можно парсить железные дороги и ADSB-треки самолетов с fr24 чтобы обогатить дополненную реальность контекстом. Захватываем аэропорт, ставим там свою станцию и сможем монтировать на вылетающие авиа-рейсы своих грузовых роботов. Прикол в том, что самолеты по-настоящему видны с земли и благодаря дополненной реальности события, происходящие вокруг приобретают особый смысл. Ресурсы по миру распределены неравномерно, так или иначе торговля (реальная а не декоративная) — это необходимость.

Имея очень крутых прокачанных роботов на «урановых батарейках», можно разогнать их не как обычно 5-10 км/ч, а вплоть до 100. Тогда появится смысл ехать в другой город с реально своим караваном. Можно десантировать из электрички отрд юнитов-поселенцев, а потом забрать их поджидающих на обратном пути. Можно вводить в игру сколько угодно временных уникальных ресурсов, за них можно скидки в кафешках делать.
Рассматривался даже вариант сувенирного аппаратного Bluetooth брелока-дететора ресурсов. Цвет свечения показывает тип ресурса, а частота и яркость свечения — количество.

Вопрос остается только один. Если всего этого еще не сделали, то, может быть, это все нахрен никому не интересно будет? Пока что это действительно игра которую я уже больше чем «джва года ждал» и даже сам писать начал=).
Я думаю вам нужно сесть и сделать геймдизайн документ. Систематизировать и упорядочить все что у вас есть. Идей очень много, это здорово, нужно определить МВП, и реализовать это быстро.

Можем по скайпу/дискорду созвонится, разберем ваш проект, помогу чем смогу. Пишите в ЛС
Спасибо. Кстати я тоже начал с диз-дока. По мере разработки первого прототипа появился побочный проект, где был применен серверный движок, который на тот момент поддерживал видимость и движение. Ввиду перманентной нехватки времени Sublayers все это время развивался крайне медленно.
С удовольствием приму советы на счет MVP и баланса, но…
Я не рассматриваю этот проект как коммерческий. Я вижу вокруг множество коммерческих игр и понимаю, что моё видение этой игры врятли жизнеспособно в этом смысле. В моих приоритетах скорее большая и довольно сложная песочница, чем наиболее полный охват играющей аудитории.
Вэтом смысле мне импонируют такие игры как EVE Online, Minecraft и Colobot, нежели что-то более «играбельное». Меня восхищает синергетическая сложность, рождающаяся не из формальных усложнений и надуманных ограничений, а из компактного лаконичного набора разумных правил и правдоподобных «квазифизических» ограничений гармоничного игрового мира. В пределах сеттинга все технческие моменты хочется оставить максимально адекватными реальности. Отсюда идея криптоключей для доступа к юнитам, отсюда же запрет на телепортацию юнитов и мгновенный трасфер ресурсов. Проще же было бы сделать абстрактную торговлю, как в других стратегиях, но это бы рушило логику моего мира.
Не знаю как ещё понятнее изложить мои приоритеты.
У меня странное чувство от статьи. По моим наблюдениям, обычно как раз делают прототип, долго на него смотрят, потом решают, что годится, и выкладывают его в продакшн.
ХАХАХАХХАХАХАХХА, вы сделали мой день!))
К сожалению, нет) Часто пилят первый уровень, с любовью его дорисовывая, переделывая раз за разом, а потом надо бы развивать игру — но в ядро забыли добавить функционал, который нужен начиная со второго-пятого уровня, и правки в ядре ломают первый уровень, сделанный с любовью… А дальше проект забрасывается)
Прототип не должен ложиться в основу будущего проекта, он должен выброситься)
Возможно, в случае если он не подходит либо количество изменений велико и затрагивает ключевые аспекты разработки, на которых держится игра.

Делаем следующую версию и тут опять не зашло. Выкидывать?

Я считаю так — выкидывать можно что то бесполезное.
Если ваши прототипы не могут быть основой для будущего проекта, то это техническое демо какой-то конкретной фишки, в другом случае непонятно зачем это вообще сделано. Для того чтобы что?
Зачем делать дешевые прототипы рпг или шутера, если можно взять готовые рпг и шутер и «пощупать механику» там?
Зачем делать игрокам разную скорость движения? Зачем делать разную скорость прыжка? зачем менять меч на пулемет? Зачем делать антагонистов драконами, все ненавидят демонов же!

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

Вы все еще уверены что сможете «пощупать» механику СВОЕГО проекта в чужой игре?
Есть огромное количество показателей, которые вводят разработчики для скорости, хп, прыжка, атаки, задержки атак, доля секунды решает.
Но это ведь просто балансировка — эти параметры могут измениться по 100 раз на любом этапе разработки. И вряд ли скорость прыжка или количество хп — это то, что будет выделять игру в жанре.
Да, но эти цифры формируют ощущение от геймплея, его скорость и плотность.
Кстати скорость перемещения очень влияет — гоночный симулятор VS симулятор катания на самокате, механика схожа, разница в цифрах, но сколько на них завязано.
Посмотрите высоту прыжка, от высоты прыжка строится целый мир! Либо игрок может запрыгнуть, либо нет.
А как влияет скорость перезарядки оружия на геймплей?
Это не балансировка, это создание механики, ядра, ощущения. Поменяйте скорость бега в CS 1.6 и будет другая игра. Да не новая, но играться будет по-другому.
Посмотрите высоту прыжка, от высоты прыжка строится целый мир! Либо игрок может запрыгнуть, либо нет.
Я всегда думал что наоборот — сначала решается куда игрок может запрыгнуть, а куда — нет и потом высота прыжка определяется в этом интервале. Для построения мира не принципиальны точные значения, важна относительность — вот это слишком высоко, вот это — стандартная ступенька, а вот здесь у нас секрет доступный, но на верхнем пределе возможностей.
А как влияет скорость перезарядки оружия на геймплей?
Это не балансировка, это создание механики, ядра, ощущения.
Тогда можно сказать что близард в своем овервотче каждый патч ядро игры меняют. Там все время у кого-то то скорость бега, то скорость перезарядки, то высота прыжка меняется.
Мне кажется, что люди еще неправильно воспринимают прототипы.
В примеры приводятся игры про нарратив или с сильным визуальным рядом.
Вполне может быть, что для них прототипами должны быть диалоги, картинки или наборы эффектов (если игра — про визуальный ряд или какие нибудь особенности, например, строительство геймплея из музыки).
Это все непросто, и, возможно, для комплексной игры типа ведьмака это должны быть несколько прототипов или достаточно сложный прототип.
Совет предназначен для начинающих — часто в игру еще нельзя играть, а для нее уже делают графику и третьесортные, но интересные фичи. Прототипы помогают сосредоточиться.
Прототипами для скайрима скорее всего были моды на основе обливиона, новые прототипы графики и боевки, а не просто серые квадратики.
Ваша правда! Добавлю в статью.

А как должен выглядеть прототип для квеста полу-хорора, в котором вот просто тупо нет противников? Только окружение.И сюжет неразрывно впутан в дизайн помещений...

Давайте определимся и добавим конкретики.
1 — объекты рассказывают историю?
2 — ключевое это атмосфера?
3 — ходьба и взаимодействие с объектами есть?

Если есть 3 пункт, то делается ходьба и взаимодействие с дверьми, книгами, выключателями и прочими крупными штуками. Можно сделать комнату квадратную, в центре кресло, в него можно сесть и взять почитать книгу, в ней появится текст. Рядом с креслом будет свеча, ее можно взять, свет в комнате только от нее, пусть освещает комнату. Игрок со свечой в руке ходит по темной комнате, берет книгу с полки, читает и ставит обратно. Игрок идет к двери, открывает ее и демо закончено. Дальше вам нужен сюжет и лвл дизайн, а обьекты будут делаться параллельно.

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

Sign up to leave a comment.

Articles