Рубрика: Игры

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

Поэтому задачи которые я вижу сейчас:

1) Вставить в игре необходимые постройки-комнаты.
2) Подумать о процессе генерации сохранения и загрузки игрового процесса. Точнее даже не генерацию. А сброс сцены в ноль.

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

1) Супер активная разработка, как это было с движком, наверное даже и не нужна. Все равно вперед арта сильно не убежать.
2) Изначально срок моей части разработки был оценен в 50-100 часов. Разработка движка была чистой неожиданностью удлинив срок на 30-40 часов. Поэтому получается, что первоначальный срок должен быть увеличен до 80-140 часов. А значит чтобы выдать игру мне так и так надо отработать еще 30 часов минимум. И да, хотя у меня и ступор, но можно попробовать зайти к проекту не от его наполнения, а от времени которое он должен отнять, а наполнение просто будет следствием работы.
Или другими словами забить на эффективность конкретного часа, и сосредоточиться на их количестве. Например, 4 часа с эффективностью 50% лучше, чем 2 часа с эффективностью 75%
3) Ну и все же как-то чуток в голове уложил, чуток структурировал проект за эти дни.

Сейчас 53 часа. 20 августа.

Проектировал окно заданий

Кстати, тут видно новые элементы интерфейса.

Подправил окно выбора для строительства (кстати только сейчас заметил, что фон чисто черный, буду искать и исправлять причину)

Само окно тоже буду переделывать. Буду переделывать и карточки.

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

Начал прикидывать обучение и сюжет.

Довел до 60 часов, и думаю можно публиковать наконец пост.
Итого сейчас 331кб кода и 20 сцен.
Большая часть этих сцен просто наброски, но с ними лучше чем без них.

Автор: Elsper.ru

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

Что у меня там?
1) Встроить комнаты в порядок отображения. Там не все так просто. Хомяки и предметы постоянно меняют порядок отображения, то хомяк перед столом, то позади, то он позади стола, но перед картиной которая висит на стене. В общем не очень сложная, но полноценная задача.

2) Доделать более сложное и правильное распределение задач по хомякам.

3) Не совсем понятная задача связанная с бронированием ячеек. Точнее она очень даже понятна, но надо решить, как ее сделать с минимумом нагрузки на процессор.

4) Ну и наверное приступать к игровым интерфейсам.

…

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

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

Это точно будут:

1) Здания. Самая понятная часть. Понятно какие здания за какими будут следовать и понятно, как цепочку наук можно будет развивать в будущем (добавлять здания)
2) Какие-то игровые возможности. Тут уже сложней
3) Просто бонусы, повышающие какие-то параметры. Сюда скидывать все по остаточному принципу.

Поразмышлял о том, как это сделать и пока набросал такой вариант

(Напомню, арт левый от других игр)
Если не придумается ничего лучше, то такой экран и будет в итоге.

Думаю над тем как получше оформить получение уровня и что за него давать.

Думаю о окне хомяков. Текущий эскиз такой

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

Ломаю голову над тем как добавить хомяка. Думаю дать выбор из 3-4 хомяков.

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

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

…

Сейчас 50 часов. И я понял, что хочу сделать баланс более профессиональным. То есть не, как левая пятка захочет, как у меня обычно бывает, а рассчитанный баланс.

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

Центральным ресурсом всегда является само время. И к времени это все в итоге будет сводиться, но внутри игры нужен какой-то более понятный связующий ресурс. И пусть это будут абстрактные «производственные мощности».
Купили хомяка? Увеличили производственные мощности.
Поставили новый рабочий стол в здание? Увеличили производственные мощности.
Прокачали науку? Увеличили производственные мощности.
Расширили здание? Увеличили производственные мощности.

И эти производственные мощности перемноженные на время дадут «ценность». А за эту ценность можно будет приобрести новые производственные мощности.

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

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

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

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

…

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

Чуть чуть поработал над отображением комнат. Решил вернуться к наукам, и понял, что слишком много наук придумать не получится и прежний набросок окна наук неактуален…

Придумал новое представление наук (На выбор будет три варианта, вместо всех и игрок будет или выбирать из имеющихся или обновлять за кристаллы страницу в поисках интересующей его науки)

Кстати о кристаллах. Нужно придумать побольше мест, куда вставить эти кристаллы. Потратил на придумывание пол часа.

(Пока придумывал куда вставить кристаллы, заодно придумал игре два новых блока, записал и отложил их в сторонку)

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

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

Решили какое первое задание игрок получит, как он его будет выполнять, чтобы не запутаться, а разобраться в игре. Второе задание. Как провести его по самым ключевым элементам игры, чтобы он понял, чем она хороша (а она хороша), чтобы понял, что это не просто примитивное «построил домик — заработал деньги», а что-то более глубокое.

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

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

Следующим шагом обучения вводим в игру потребность еды.

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

В общем надеюсь разработка снова пойдет бодрее.

Сейчас 52 часа.

Автор: Elsper.ru

По итогам прошлых частей у меня 39 часов 45 минут. И объем 158кб

Сроки немного пугают. Ожидалось что к 40 часам будет уже что-то играющее, но проект оказался слишком трудным. Впрочем теперь уже поздно что-то менять, да и не надо ничего менять. И этот осилю.

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

Уже 43 часа. Я все еще пилю менеджер задач.
Медленно(хотя как медленно, файл весит уже 21кб)
Но верно. Время потраченное на рефакторинг поиска пути оправдывается. Часть задач требует A*, часть требует широкий поиск. И главное не запутаться где какая задача и какой поиск, почему ей нужен поиск именно этого типа, и куда потом девать его результаты.

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

Внезапно понял очевидную вещь. Не обязательно обсчитывать все задачи, которые есть в игре. Нужно лишь обсчитать первые Х, по количеству свободных хомяков. Оптимизация ))
Хотя есть и проблема. Как одновременно совместить приоритет задач и при этом давать хомяку задачи ближние к нему. Да всякие коэффициенты можно придумать, но это опять переписывать коды… Надо подумать.

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

Блин я еще прежний вариант не допилил, а уже усложнил идею (((

Решил для начала реализовать то, что наметил, потому, что усложнение ни капли не отменит существующий код, а только дополнит.

И в итоге на 45 часу хомяк сам выполняет задачу! Ну наконец-то!!

Правда осталось еще разобраться с бронированием, порядком отображения некоторых слоев и вообще во время тестов вылезли какие-то неожиданности, но в целом разработка двигается вперед.

Разобрался еще с несколькими вещами, хотя и довольно мало работал на выходных

И по итогам 47 часов и почти ровно 200кб могу показать вот это.

Хомяк обнаруживает, что есть коробка до которой он может дойти и которую он может донести на (пока что невидимый) склад.

Автор: Elsper.ru

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

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

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

Итого + 40минут, — 10,5 кб и на выходе более понятная структура!

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

Переписал отображение и позиционирование.

Время разработки 29 часов 10 минут.

И наверное надо бы что-то игровое, чтобы разработка не выглядела, как только разработка движка.
…
Придумал что сделать игрового, но это снова уперлось в движок. Поэтому вставляем в движок предметы (товары) расположенные на клеточках.

Теперь заставим хомяка их переносить.

Создам комнату «Склад», это просто.
А вот дальше для хомяков буду пилить что-то типа обработчика заданий.

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

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

Этот алгоритм уже был почти реализован, но… я только что понял, что для реализации именно алгоритма поиска в ширину, а не просто алгоритма A* мне все же понадобится трехмерное представление домика. Видимо работа над движком продолжается.

Однако похоже можно не переписывать полностью, а просто сделать «оценку каждой комнаты на соответствие цели». Проще говоря, если в комнате в принципе есть искомая точка, то не важно в каком именно месте комнаты она расположена, мы можем допустить, что именно предмет в этой комнате ближний к хомяку (в реальности это не всегда так, но и хомяки не гении, чтобы искать 100% самый лучший маршрут)

Хотя все же значительный кусок придется переделать.

32h 30m
Хомяк находит и приходит к коробке. Теперь надо решить, как отображать коробку (и прочие предметы) в лапах хомяка. Усложняется ситуация еще и разными ракурсами этого хомяка, то он со спины видим, то с мордочки, то просто с боку.

Наверное графику отложу на попозже, а пока продолжу логику.

Пара строчек и коробка берется.

Теперь несем на склад. Но сначала стоит подумать, достаточно ли я продумал работу склада.

1) Мы должны знать заполненность складов, и не просто абстрактное «10 мест из 20 свободны», а наличие места для коробки конкретного типа. Не хочу превращать склады в свалку..
2) Мы должны «бронировать» это место под конкретную коробку, чтобы на одно место десять хомяков не побежало.
3) Принести коробку на склад — это как бы итак очевидно.

…

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

Задумался тут о оптимальности кода. Сейчас у меня каждый хомяк, у которого нет задачи, сканирует область сначала в поисках предмета и если найдет его, то ищет для него склад. И если не найдет, то в следующий обсчет он будет делать это же самое и остальные хомяки тоже. Надо как-то не от хомяков идти, а от складов думаю. То есть, наверное, все же, сначала игра должна знать, что такая задача актуальна и только потом предлагать ее хомякам…

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

Однако поразмыслив еще я пришел к идее менеджера задач. То есть задача высчитывается один раз и потом просто вручается хомяку. Пересчитывать весь стек задач можно раз в 10-20-30 секунд или еще реже.

В общем, снова работа над движком… Я уже думаю, что с таким объемом «движковой» работы можно было бы уж и полноценную аксонометрическую стратегию делать… впрочем успеется еще.
Да и работы у меня всего 34 часа на данный момент. Вроде немало, но я смог втиснуть их в 8 дней, и за 8 дней я сделал неплохой объем.

А теперь приступим к менеджеру, а то хочется все же закончить пост с какой-нибудь картинкой, на которой видно что игра продвигается ))

Но менеджеру нужен снова чуток измененный поиск пути. Ох… Снова рефакторинг, уже устал от того, что у меня постоянно вылезает что-то кривое.

Переписал.

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

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

Впрочем нет предела совершенству и поспав я нашел способ его ускорить еще (убрал лишние проверки соответствия клетки искомому состоянию), но это уже пара строк.

Наконец вернусь к менеджеру задач.

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

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

Пилю менеджер.

Итак 39 часов 45 минут. Объем 158кб Забавно, за 15 часов общий объем кода вырос только на тысячу, но функционал стал явно шире и качественней

Сейчас уже пару часов пишу менеджер задач. Похоже он и будет самой сложной и большой частью логики. Пишу сейчас часть, отвечающую за поиск предметов, которые надо отнести и за поиск мест, куда их можно отнести. Уже 8кб написал, и все еще не доделал. И ведь это только один тип задач (хотя и основной)

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

Автор: Elsper.ru

Позади 15 часов разработки.

По итогам прошлого поста у меня уже есть возможность строить первые столы и лестницы.

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

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

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

И еще маленькая проблема с лестницами была, но уже решена. Состояние на 16 часов.

Continue reading «Публичная разработка игры. Часть 3.» →

Автор: Elsper.ru