Gamedev Gregory Radovilskiy
2 935

Как обмануть себя и перестать бояться

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

В закладки

Немножко обо мне

Предыстория примерно такова. В геймдеве я с 2006 года. Прошёл полный путь от тестера, до продюсера, работая в известных и не очень компаниях над, в основном, никому не известными или давно забытыми играми. Так часто бывает. И была у меня распространенная среди геймдизайнеров, проблема: очень хотелось делать то, в чём руководство компании не видело смысла. Тут вообще много вопросов возникает к моим продюсерским умениям, но не о них речь. Особенно, учитывая то, что прямо продюсированием я занимаюсь не так давно (и тут мой внутренний голос такой: «На самом деле достаточно давно, ты никого не обманешь»).

Так вот под давлением желания сделать что-то своё я периодически брался за это неблагодарное дело. Но порой не хватало тех самых продюсерских навыков, чтобы ограничить как-то свои желания (да, я научился немножко кодить на AS3 и Python для сервера, но так и не придумал, что интересного я осилил бы сам сделать). Иногда приходили продюсерские навыки и «говорили», что пора заканчивать уже мучить тушку мегаоригинальной супер-пупер игры с механикой «Сапёра». Просто не придумал монетизацию.

Ищу инвестора

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

Впрочем, один раз меня DTF все-таки засветили со статьей о «Поиске здорового метагейма», которую я написал по горячим следам, оставленным разработчиками из SuperCell в Твиттере. Ну и теперь у меня есть несколько глав книги про то, как вообще делаются компьютерные игры.

Сразу о проблемах

Моя проблема в плане самостоятельного творчества заключается в том, что мне совершенно не интересно то, что сейчас называется, инди-играми. Даже если они успешны. Последние лет восемь, наверное, я занимаюсь «социалочками», последние лет пять — «мобилками». Я любою F2P.

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

Я хочу просто заработать денег сделав правильный продукт. Будь то в рабочее или в свободное время (если такое вообще бывает). Это довольно сильно ограничивает минимальные требования к игре, отметая всё, в чём я не разбираюсь хотя бы чуть-чуть.

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

Если что, я делаю её с августа 2017 года.

Собственно, начало

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

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

Мне не очень нравится по поводу и без впадать в депрессию, поэтому я решил для себя три основополагающие вещи.

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

У меня уже был некоторый опыт работы с Unity 3D (я на нем «Сапёра» делал, да), поэтому вопроса движка для меня не стояло. Да и окружающие программисты, в основном, были именно специалистами по C # в контексте Unity. Опять же, во времена работы над «Сапёром» я выработал довольно удачную на мой вкус структуру интерфейсов, основанную на простенькой стейтмашине. Так что старт получился достаточно шустрым. Ну да, повозился немного с перемещением объектов в 3D, с которым раньше никогда не работал. Не страшно.

Вот так у меня выглядела игра через пару недель после начала разработки

Поначалу конфиги у меня хранились в обыкновенных текстовых файлах в формате JSON. И про эту часть, думаю, стоит рассказать подробнее.

Технологии

У меня есть некоторое представление о том, как должен выглядеть проект, чтобы с ним было удобно работать, чтобы в него было удобно вносить изменения. Но это только представления. Я никогда не работал в качестве программиста в команде профессиональных программистов. Да я последние лет пять вообще только с документацией работаю. Всё, что я делал и делаю сейчас — это результат моего опыта, то есть потраченного времени.

Я бы хотел сказать что-нибудь типа «не делайте так». Но я не знаю, как надо делать. Правило «осуждаешь — предлагай» не выполняется.

Мой опыт очень ограничен задачами, которые я решал раньше. Например, та же стейтмашина интерфейсов. А вот с конфигами я никогда раньше не работал. Вернее, конечно, у «Сапёра» были конфиги, но они были настолько примитивными, что этот опыт на ферму вообще никак не переносился. Ну, просто где конфиг со списком уровней пазла (который даже не обязательно было делать в виде JSONа) и где конфиг построек, рецептов, магазинов.

В результате, разработка таких вещей — это как прыжок веры в Assasin's Creed, только внизу вместо стога сена контейнер с граблями. А когда вылезаешь из этого контейнера, то обнаруживаешь себя на собранном из граблей велосипеде. С которого не можешь слезть.

В общем, я очень хочу посоветовать тем, кто не имеет опыта в программировании или только изучает его, предварительно изучить теорию и почитать какую-нибудь литературу. Но опять же, не могу, потому что не знаю какую.

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

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

Например механизм конфигов я переписывал почти с нуля три раза.

Первые конфиги были реализованы в виде JSON, который, как я уже написал выше, хранился в текстовом файле. Довольно быстро я пришёл к выводу, что больше пяти строк в таком конфиге перестают быть читаемыми. Очень важным аспектом является то, что в формате JSON все перечисляемые типы отображаются в виде чисел, а не строк. Помнить, какое число в каком месте за какое значение отвечает, невозможно. Правда, у JSON есть и один очень важный и полезный для меня плюс, но тогда я о нем не знал.

Второй конфиг был реализован в виде таблицы в Google Docs. Соответственно, я искал (о, это отдельное приключение) и нашел плагин, с помощью которого загружал этот конфиг в игру. Но и тут всё было не просто.

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

В-третьих, табличный конфиг не позволяет работать с вложенными объектами. Например, есть постройка и есть рецепт. Удобно же смотреть на рецепты одной постройки и редактировать их. Но в формате таблиц все постройки будут в одной табличке, а рецепты — в другой. И всё, каша из рецептов, нечитаемо и нередактируемо. Я знал про этот недостаток таблиц (я три года работал на проекте, в котором конфиги хранились в mySQL-базе данных), но понадеялся, что моей мотивации хватит на то, чтобы перетерпеть страдания.

Третий, и, надеюсь, финальный конфиг я стал делать из сочетания всего приобретенного мной опыта и некоторых ограничений выбранного мной сервера. И на этот раз я потратил три недели. Я сделал в Unity свой редактор, который удовлетворял бы моим требованиям, с выгрузкой в JSON и хранением в Scriptable Object. Причём самое обидное заключается в том, что я бы сразу так сделал, если бы тогда знал о существовании плагина Odin Inspector, который радикально облегчает разработку интерфейсов для редактора Unity (разобраться в родных средствах разработки я не смог). Кстати, на том проекте, в котором конфиги хранились в mySQL-базе, я, в итоге, тоже сделал свой редактор на OpenOffice Base (не думаю, что о существовании такой штуки вообще кто-то знает).

Вот так у меня выглядит редактор конфигов

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

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

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

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

У страха глаза велики

Хранить свой проект я решил просто в облаке. Для этих целей пригодился One Drive. Всё равно же есть, почему бы не использовать? Ну, и что может пойти не так с облаком? Особенно если между двумя рабочими компьютерами полтора часа езды — достаточное время, чтобы они успели синхронизироваться.

Но в один прекрасный момент, у меня умер файл сцены со всеми настройками интерфейсов и логики. Это был знак, что пора перестать ныть и научиться пользоваться репозиториями на Git. Да, когда я последний раз что-то руками делал, SVN всё ещё был в моде. И да, сразу начать пользоваться Git мне мешал именно страх. Страх того, что будет сложно разобраться, и что придется просить помощи.

За помощью я обращаться жутко не люблю. И причина не только в том, что я стесняюсь, а ещё вот в чём. Если кто не знает, у репозиториев на Git есть специальный файл в котором перечисляются файлы и папки которые следует игнорировать при сохранении изменений в проекте. По интернету ходит множество файлов, предназначенных для проектов на Unity 3D и не все они хорошие. Мне посоветовали плохой.

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

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

В итоге, как бы ни смешно это звучало для человека, проработавшего больше 10 лет геймдизайнером, без документации обойтись не получается. Сама по себе документация не является решением проблем, но она является единственным действенным способом найти эти самые решения. И даже если решение не приходит с первого раза, даже с точки зрения ведения дневника, лучше уж потратить время на переписывание документации до тех пор, пока решение не будет найдено, чем прокрастинировать как-то ещё.

И ещё немного

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

За прошедшее время я как-то научился находить задачи, решать те, которые вообще не нужно. Даже точки зрения человека, который значительную часть работы делает ради самообмана.

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

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

Когда же логика отделяется от отображения переездом на сервер... С одной стороны появляется необходимость — игрок может подделать сообщение с клиента, поэтому не стоит доверять клиенту отправку информации о выполнении условия. Но, вместе с тем, появляется и понимание того, когда именно эта необходимость действительно возникнет: когда появятся игроки. То есть, копирование на сервер функции проверки условий можно отложить в долгий ящик. Главное — вспомнить про этот ящик когда придёт время.

Вот так выглядела у меня игра до того, как я её сломал

В результате

Я сделал механику, необходимую для работы фермы, в том виде, в котором хотел, и упёрся в контент. Об арте я ещё даже не думал. Контент оказалось просто сложно редактировать, и я переделал конфиги. Переделал я их достаточно сильно, чтобы расковырялась вся игра. Я подумал: «Если всё равно ничего не работает, а не вынести ли мне логику на сервер?». В качестве сервера я решил использовать сервис GameSparks. В итоге, последние пару месяцев я занимаюсь фактически не игрой, а баловством всяким.

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

#опыт

Материал дополнен редакцией
{ "author_name": "Gregory Radovilskiy", "author_type": "self", "tags": ["\u043e\u043f\u044b\u0442"], "comments": 35, "likes": 34, "favorites": 40, "is_advertisement": false, "subsite_label": "gamedev", "id": 22815, "is_wide": false }
{ "id": 22815, "author_id": 4351, "diff_limit": 1000, "urls": {"diff":"\/comments\/22815\/get","add":"\/comments\/22815\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/22815"}, "attach_limit": 2, "max_comment_text_length": 5000 }

35 комментариев 35 комм.

Популярные

По порядку

Написать комментарий...

Andrey Apanasik

23

"Моя проблема в плане самостоятельного творчества заключается в том, что мне совершенно не интересно то, что сейчас называется, инди-играми. Даже если они успешны. Последние лет 8, наверное, я занимаюсь социалочками, последние лет 5 мобилками. Я любою F2P"
"Я хочу просто заработать денег сделав правильный продукт"

"Если у вас в чем-то нет опыта, то вы либо вообще не делаете это, либо миритесь с тем, что это придется переделывать несколько раз"
Либо возьмите готовое решение.

Да и куча других цитат, показывающие, что человек в одной области что-то узнал, в другой, но ни в одной не стал профессионалом. Этакий эникейщик.

Советы многие вредные.

Статья большая, вроде человек делится опытом, но пользы, к сожалению, почти не несёт.

Ответить

Gregory Radovilskiy

Andrey
1

какими будут ваши полезные советы?

Ответить

Andrey Apanasik

Gregory
14

Ну, раз вы уже просите, то по вашей же статье:
1) Не переделывать вещи по 3 раза, а сначала проанализировать.
2) Не тратить 3 недели на систему конфигов, лучше, в первую очередь, сконцентрироваться на более важных вещах, а именно, на прототипе игры.
3) Не все могут программировать. Если у вас не получается, то не надо мучиться и заставлять себя. Сосредоточьтесь на тех вещах, которые вы делаете хорошо.
4) " То есть копирование на сервер функции проверки условий можно отложить в долгий ящик". Не знаю, на чём сервер написан, но если серверный инстанс на том же Unity, то копировать ничего не надо, можно тот же клиентский код использовать.
5) Нормально воспринимать критику.

Ответить

Мимокрокодил

Andrey
2

1) Не переделывать вещи по 3 раза, а сначала проанализировать.

Не работает. Анализ дает результаты только если аналитик понимает в предмете
3) Не все могут программировать. Если у вас не получается, то не надо мучиться и заставлять себя. Сосредоточьтесь на тех вещах, которые вы делаете хорошо.

А как игру в одиночку сделать в таком случае?)
4) " То есть копирование на сервер функции проверки условий можно отложить в долгий ящик". Не знаю, на чём сервер написан, но если серверный инстанс на том же Unity, то копировать ничего не надо, можно тот же клиентский код использовать.

Подозреваю, автор имел ввиду "перенос логики проверки условий на сервер", а не копирование

Ответить

Andrey Apanasik

Мимокрокодил
2

"А как игру в одиночку сделать в таком случае?) "
Да никак. Если человек не умеет в программирование, то очень маловероятно, что у него в принципе что-то выйдет. Пускай найдёт напарника или наймёт кого-нибудь.

"Подозреваю, автор имел ввиду "перенос логики проверки условий на сервер", а не копирование"
Ну, я тут и плюсы, и минусы вижу. С одной стороны, можно быстро прототип накидать, с другой, 100% что-то потом забудешь, не будешь это валидировать на серваке, клиент будет читерить.

Ответить

Мимокрокодил

Andrey
3

Если человек не умеет в программирование,

Никто не умеет программировать с рождения, все этому учатся
С одной стороны, можно быстро прототип накидать, с другой, 100% что-то потом забудешь, не будешь это валидировать на серваке, клиент будет читерить.

Он же там прямым текстом говорит "пока игроков нет" - прототип

Ответить

Andrey Apanasik

Мимокрокодил
0

"Никто не умеет программировать с рождения, все этому учатся"
Так я про тех, кому это тяжело даётся. Если человек хорошо рисует, но ну никак не может в программирование, то зачем туда лезть? Совершенствуйся как художник. А то получится ни то, ни сё. Мастеров на все руки по пальцем пересчитать можно.

"Он же там прямым текстом говорит "пока игроков нет" - прототип"
Да все так говорят. А потом "ой, забыли" (:

Ответить

Мимокрокодил

Andrey
1

Да все так говорят. А потом "ой, забыли" (:

Забудет перенести - игроки будут получать больше ресурсов -> он будет получать меньше денег (это ж ферма). Его цель - деньги. В его же интересах не забыть)

Ответить

Gregory Radovilskiy

Andrey
0

Так в долгий ящик пока игрок не появится. Ясный перец что когда игрок появится это место будет дырой. Но когда он еще появится? Я и так, как вы справедливо заметили, много времени трачу на странные задачи, так что экономлю как могу. Ну и я таки пользуюсь таск-менеджером (craft.io). Так что откладываю я задачи не в небытие, а в беклог.

Ответить

Andrey Apanasik

Gregory
0

Просто у нас был похожий опыт. Мы часть вещей на серваках не валидировали, а потом после запуска про некоторые такие вещи забыли)

Ответить

Мимокрокодил

Andrey
1

"Нет ничего более постоянного, чем временное"
Но все равно, проблемы надо решать по мере поступления

Ответить

Gregory Radovilskiy

Andrey
2

спасибо.
1) систему конфигов я переделывал 3 раза потому что мне не хватило опыта в анализе. я пытался решить задачу максимально простым способом из тех, про которые знал. на какое-то время этого хватало, но потом работать с выбранным решением становилось невозможно.
2) я специально выбрал такую игру, которой не нужно было бы делать прототип, а можно было бы сразу заняться чем-то, что меня порадовало бы. я понимаю что это не правильно, но до проверки моей модификации игрового цикла я сам без этого просто не дошел бы. а так дошел.
3) этот проект все-таки хобби. я не инди-разработчик, вряд ли имею право так называться. просто игры в которых я что-то понимаю и которые хотел бы делать сложнее чем я могу осилить, тем более работая в одиночку. но любой может программировать на уровне хобби и получать приемлемый результат. у меня конечно не очень много примеров, но есть знакомый артдир, который квест сам делал. просто в его случае попытка важнее результата.
4) я использую не поднятый где-то сервер, а сервис предоставляющий услуги сервера. он работает со скриптами на JS. решил что мне так будет легче. но скорей всего это не так, так что советовать такую фигню точно никому не буду. могу только предложить что возможно вот такое решение.
5) спасибо за критику. просто я предпочел бы чтобы вы с этого начали, но получилось как получилось.

Ответить

Мимокрокодил

Gregory
1

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

Идеи выдавать совсем не прошу, интересно просто, есть ли такой план :)

Ответить

Gregory Radovilskiy

Мимокрокодил
1

Ну это не секрет особо. Тем более что я об этом пишу в своем дневнике, на которую ссылку дал уже. Моя идея заключается в том, что есть довольно широкая аудитория мужчин-казуалов, которые почти не окучены играми и вынуждены давиться играми, которые не предназначены для них. Грубо говоря, Hay Day слишком женский, а Clash of Clans слишком агрессивный. По моему представлению в этой нише сейчас сидит только Hastle Castle. То есть моя игра должна быть больше наполнена приключениями чем Hay Day, но быть понятной как Hay Day. Под приключениями я имею ввиду механики таких игр как Hastle Castle или Shop Heroes. В итоге, я надеюсь покорить еще неокученную, по моему мнению, аудиторию, а не конкурировать с теми, кто уже захватил свой рынок.

А на тему вылизанности картинки... Да, Hastle Castle выглядит очень круто. Но вот есть, например, Endless Frontier, который породил целый поджанр айдл-рпг - выглядит он будто сделан на коленке, но денег заработал, на сколько я понимаю, более чем хорошо.

Ответить

Andrey Apanasik

Gregory
0

"Сначала добейся" что ли?

Ответить

Severomor

Andrey
0

"Статья большая, вроде человек делится опытом, но пользы, к сожалению, почти не несёт."

Не везде нужно искать пользу. ) Лично я прочитал с удовольствием. Автору надо книги писать. )

Ответить

Gregory Radovilskiy

Severomor
0

Спасибо. Часть написанной книге о том как делаются игры уже написал.

Ответить

Ghar Undefeated

8

Эта статья вгоняет в депрессию меня.

Ответить

Gregory Radovilskiy

Ghar
0

Извините.

Ответить

Владимир Дегтярев

2

Ура! Ещё больше статей по разработке казуальных ферм без изюминки, в тексте которой между строк читается "я не знаю, зачем и для кого я написал эту статью"
Это ведь именно такой материал, какого мы хотим видеть больше на этом сайте.

Ответить

Николай Костоправ

0

Спасибо, интересный материал!
PS: всё время нахожусь в недоумении от слов "валидировать на сервере", когда у меня сервер всегда является первоисточником всей логики и событий. Как только люди ухитряются...

Ответить

Gregory Radovilskiy

Николай
1

Спасибо.
Я могу быть не прав, но мне кажется что сервер не может быть источником всех событий. Клиент может прислать все что угодно и даже если эти данные может быть не нужно проверять по сути, но их придется проверять на логику. Та же покупка построек у меня ограничена не только Холлом какого-то уровня, но и наличием ресурсов. Клиент конечно и сам проверяет и уровень Холла, и наличие ресурсов, но это не значит что игрок не может обойти эту проверку. И вообще может прислать покупку несуществующего лота. А значит на сервере все это тоже придется проверять. Наверное эта проверка и является по сути валидацией. Может просто термин не правильно используется?

Ответить

Andrey Apanasik

Николай
0

Ага, и события вместо игроков тоже он генерирует: двигает и спеллы юзает и т.п. У вас одни боты в игре?

Ответить

Николай Костоправ

Andrey
0

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

Ответить

Vitaly Efremov

0

Напишите, пожалуйста, что у Вас за книга. Очень интересно.

Ответить

Gregory Radovilskiy

Vitaly
0

Ответ вам случайно сбежал. Сылка на книгу http://gloomy-games.com/book/

Ответить

Vladislav Khromov

0

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

Ответить

Gregory Radovilskiy

Vladislav
0

Спасибо. Статья вообще вся про эмоции и переживания, а не про технологии. Технологии просто как фон.

Ответить

Evseichev Anton

–1

Я хочу просто заработать денег сделав правильный продукт.

Интересно а есть разработчики которые не хотят заработать денег? Которые хотят чтобы их игру никто не покупал? Если честно писать об этом несколько глупо, вы точно хотите заниматься творчеством в виде игр и вкладывать в них душу? Звучит как будто вы пришли на рынок торговать помидорами.

Ответить

Gregory Radovilskiy

Evseichev
0

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

Ответить

Evseichev Anton

Gregory
–1

Сам факт что разработчик хочет обогатиться выпустив игру никого не удивляет, и это не зазорно, но ставить это целью как минимум странно. Делать абстрактный "продукт" с какими-то там ценностями с "уровнем качества" тоже звучит странно. Когда есть желание сделать игру оно всегда исходит из какой то простой идеи: "хочу сделать пиксельный roguelike платформер, ведь их так мало сейчас" или "хочу свой PUBG но в фэнтезийном сеттинге", "хочу сделать симулятор хлеба! Это так оригинально!"

Ответить

Gregory Radovilskiy

Evseichev
0

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

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

Ответить

Владимир Дегтярев

Gregory
0

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

И не скажу за остальных, ну а мне вот не нравится ваша мотивация "мы делаем продукт в поте лица. Мы единственные делаем продукт, а вносить новое в жанр идите к кому-то другому, это они там бездельники и отдыхают".

Ответить

Gregory Radovilskiy

Владимир
–1

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

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

Ответить
0

Прямой эфир

Подписаться на push-уведомления
[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "clmf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fjog" } } }, { "id": 10, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "clmf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-250597-0", "render_to": "inpage_VI-250597-0-1134314964", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=clmf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Плашка на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudo", "p2": "ftjf" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fzvc" } } } ]