Публичная разработка игры. Часть 5.

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

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

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

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

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

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

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

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

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

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

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

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

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


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


Автор: Elsper.ru


VN:F [1.9.14_1148]
Rating: 10.0/10 (1 vote cast)

Публичная разработка игры. Часть 4.

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

По итогам прошлых частей у меня 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


VN:F [1.9.14_1148]
Rating: 10.0/10 (2 votes cast)

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

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

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

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

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

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

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

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


Автор: Elsper.ru


VN:F [1.9.14_1148]
Rating: 10.0/10 (1 vote cast)

Публичная разработка игры. Часть 2.

Позади 5 часов и техническая реализация возможности просто отображать и двигать фон.

Что дальше?

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

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

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

____

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

Уменьшил в два раза сектор. Оставил стоять столы с старой привязкой к секторам.

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


Автор: Elsper.ru


VN:F [1.9.14_1148]
Rating: 7.0/10 (3 votes cast)

Публичная разработка игры. Часть 1. Начало.

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

В этот раз все совсем иначе.

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

Зачем?
1) Just for fun
2) Второй мотив примерно такой же как и публикация итогов месяца, а именно возможность поэтапно отслеживать процесс изменения.
3) Публичная разработка позволит мне систематизировать процесс применительно именно ко мне, а не к абстрактному новичку. И не теоретически, а на реальном проекте. Я сам смогу в следующий раз более реально оценивать те или иные куски работы, и проект в целом. Систематизировать какой-нибудь проект, про который не буду писать, мне просто лень.

Не боюсь ли я что игру у меня украдут, если я ее буду подробно описывать?
Не боюсь. Сразу по нескольким причинам.
1) Некому.
2) Гораздо выгодней взять уже ГОТОВУЮ игру из топа гроссинга (топа прибыльности) и сделать ее клон, кстати сам все хочу эту схему провернуть, да все какая-то неприязнь к клонированию.

Как часто я буду писать?
Чтобы не захламлять ленты я планирую писать через каждые пять-десять-пятнадцать часов, потраченных на разработку игры, по обстоятельствам. Чтобы понять, что это не так уж и часто, хочу заметить, что у меня всё программирование занимает 40-70 часов в месяц. И в это время умещаются несколько разных проектов, а не какая-то одна конкретная игра.

Финансовая сторона?
Раз уж это реальный проект, то почему бы и не подойти к нему как к бизнес проекту и не прикинуть его себестоимость.
1) Арт: Заложим 1000-1500$ за весь арт. Вряд ли я выйду за эти рамки как в меньшую, так и в большую сторону.
2) Анимация: Анимацию делает моя девушка, но это тоже труд и его тоже надо оценить. Заложу на анимацию 300-500$. Мы в последнее время делаем активно анимацию, так, что, думаю, будет чем заняться.
3) Моя работа: 50$ в рабочий час. Вообще я совмещаю в себе условного программиста за 20$, и геймдизайнера за 30$. Но работаю быстрей поэтому сам себе могу назначить такую оплату. К сожалению не каждый час может быть засчитан как рабочий. Выше я уже писал, что выжимаю только 40-70 таких часов в месяц.
Сколько это отнимет времени я пока не знаю. Но попробую заложить 50-100 часов. То есть 2500-5000.
4) Помощница. Снова моя девушка. Я ей делегирую многие нудные задачи, которые явно не стоят того, чтобы за них платили «мою» ставку в 50$ в час. Заложим 500$ на проект.

Итого игра должна принести 4300-8500$, чтобы окупить затраты сил. А так, как половину забирает издатель, то игра должна заработать 8600-17000$ за все время жизни.
Чтобы получить верхний результат придется реально потрудиться и сделать качественный продукт. Уровень нижней планки выглядит гораздо более реальным. В любом случае, если игра не наберет даже нижней планки, это будет просто значить, что мой труд и труд девушки стоят де факто дешевле, чем я оценил. Чтож, это не сильно критично. Но в любом случае пусть в сознании будет пометка «делаем игру на 17000$»

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

Перейдем наконец к делу!

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

Поэтому игра будет экономическая айдл-стратегия с элементами кликкера. Если делать то, что нравится, то разработка будет идти гораздо веселей и будет доставлять больше удовольствия.

Игру хочется сделать няшной. Поэтому она будет про хомяков.

Общий вектор задан. Теперь ставлю себе вопрос, «как это будет выглядеть?»

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

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

Общая идея сформирована.

Задачи которые она за собой тянет:
1) Код для реализации главной сцены.
2) Арт хомяков
3) Анимации хомяков.
4) Арт рабочих мест.
5) Их анимации.
6) Арт нерабочих мест. и анимация.
7) Придумать какие производственные цепочки использовать в игре.
8) Придумать больше целей внутри игры.
9) Представить, как игрок будет управлять всем этим.
10) Дополнительные окна и сцены.
11) Цветовое решение и стилистика интерфейса.
И т.д… хватит пока тех, что пришли в голову.

Задачи по арту сразу скидываю помошнице и жду эскизов.

Пункт 8 самый важный в начале разработки. Пытаюсь набросать игровые цели
Цели:
1) Открытие контента.
2) Прокачка боса.
3) Прокачка сотрудников.
4) Прокачка компании
5) Соревнование с другими компаниями
6) Производство, маркетинг, и внутрекомпанейские дела.
7) По цепочке производства изобрести что-то супер крутое.
По мере разработки этот список может меняться, но проектировать игру лучше имея в голове список целей и процессов, которыми игрок будет эти цели достигать.

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

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

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

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

….

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

Первые пять часов проекта позади.

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

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


Автор: Elsper.ru


VN:F [1.9.14_1148]
Rating: 10.0/10 (3 votes cast)
Страница 2 / 6« 1 2 3 4 5 6 »

Спoнcopcкиe ссылки