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

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

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

Что дальше?

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

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

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

____

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

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

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


Автор: Elsper.ru


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

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

Отл. турники настенные 3 в 1 www.turnik-tut.ru/turnik-nastenniy-3-v-1 .