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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Автор: Elsper.ru


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

Публичная разработка игры. Часть 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)

«Дилемма заключенного» и выводы которые из нее следуют.

Классическая дилемма заключенного звучит так:

«Двое преступников — А и Б — попались примерно в одно и то же время на сходных преступлениях. Есть основания полагать, что они действовали по сговору, и полиция, изолировав их друг от друга, предлагает им одну и ту же сделку: если один свидетельствует против другого, а тот хранит молчание, то первый освобождается за помощь следствию, а второй получает максимальный срок лишения свободы (10 лет). Если оба молчат, их деяние проходит по более лёгкой статье, и каждый из них приговаривается к полугоду тюрьмы. Если оба свидетельствуют друг против друга, они получают минимальный срок (по 2 года). Каждый заключённый выбирает, молчать или свидетельствовать против другого. Однако ни один из них не знает точно, что сделает другой. Что произойдёт?»

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

Теперь вернемся к «Дилемме заключенного» и ответьте сами себе на вопросы

1) Как вы поступите, если вторым человеком будет ваш самый близкий человек?
2) Как вы поступите, если вторым человеком будет ваш хороший друг.
3) Как вы поступите, если вторым человеком будет ваш просто знакомый?
4) И как вы поступите, если вторым человеком будет просто рандомный человек?

И как вы думаете поступят эти люди?

Можно использовать более приземленный вариант
(первый пришедший мне в голову)
Перед вами шведский стол. На нем два главных блюда — что_нибудь_вкусное_1 и что_нибудь_вкусное_2, они расположены на разных концах стола.
Вы и группа людей одновременно подходите к столу. Вы хотите вкусно покушать и по возможности отведать оба вкусных блюда.
Вы стоите перед одним из блюд,
1) вы можете набрать немножко, чтобы осталось другим и пойти на другой конец стола за вторым блюдом.
2) или можете набрать побольше, вдруг на другом конце ничего не останется, пока вы дойдете, ну и тоже идете на другой конец стола.

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

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

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

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

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

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

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

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

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

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

Собственно, именно понимание дилеммы заключенного, остудило мое революционное сердце и мой интерес к политике.
Ведь либералы как раз и хотят чтобы люди относились друг к другу по доброму.
И если рассматривать либеральные 11% и ватные 89% как участников дилеммы заключенного, то либеральные 11% всегда в проигрыше будут.

Ссылка на соответствующую статью на вики Дилемма заключенного


Автор: Elsper.ru


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

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

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

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

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

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

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

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

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


Автор: Elsper.ru


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

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