Квант безделья

q_of_idleness Yoqadi 0

Личный канал @leodigrigio
Геймдев, еда, overtwitter
Kanal tili va GEOsi
Rossiya, Rus tili


Muallifga yozish
Kanalning GEOsi
Rossiya
Kanal tili
Rus tili
Toifa
O'yinlar va ilovalar
Indeksga qo'shilgan
14.05.2018 14:26
So'nggi yangilash
17.12.2018 12:38
48
obunachilar
~0
1 ta nashr qamrovi
~3
kunlik qamrov
N/A
bir kundagi postlar
N/A
ERR %
0.02
tsitatalash indeksi
So'nggi nashlar
Удалённые
С упоминаниями
Repostlar
Хотел про реализацию чата вкратце написать, но меня слегка понесло.

Надеюсь, что кому-то это будет интересно.

https://medium.com/@di.grigio/%D0%B8%D0%B3%D1%80%D0%BE%D0%B2%D0%BE%D0%B9-%D1%87%D0%B0%D1%82-%D0%B2-mmo-63ebae81a897
Неделю назад на стриме показывал простую программку под названием Dialog Reactor.

Я её когда-то написал для представления в виде графов и редактирования диалогов в AuroraRL, но из-за универсальности формата она может использоваться и для других игр.

Код открыт, написана на C# (WPF). Репозиторий и ссылки на скачивание тут:
https://bitbucket.org/diGrigio/dialog-reactor/downloads/

А инструкцию к ней же нашел на одном сайте мододелов:
http://falcon-lair.com/tutorials/article/40-dialog-reactor/

В общем, авось кому пригодится.
Минут через 10 стартану. Посмотрим, что из этого получится.
Кстати в честь начала осени (не календарной, а погодной) и по совместительству в пятничный вечер, думаю замутить стрим в 9 вечера по Москве. Часов за 6 попробую написать маленькую и бестолковую игру, которая никому никогда не будет нужна. Хотя на самом деле мне нужно чуть отвлечься от всего на свете. В общем, заглядывайте.

https://www.twitch.tv/di_grigio
build 29
Пропущу стандартные оправдания о плохой погоде, осенней апатии и сотнях побочных дел, но признаю, что этот месяц был отвратительно непродуктивным в плане разработки игры.

В общем и целом, я реализовал варп по звёздной системе, что и демонстрируется на видео ниже.

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

Звучит хорошо, но только вот что-то пошло не так. Так уж вышло, что нужно было бы написать вот тот самый препроцессор, который принимает на входе текущее состояние корабля, набор точек куда игрок его послал лететь, а на выходе выдавал последовательность из команд для стейт-машины. И вот тут я залип на две недели. Получился какой-то дикий, жуткий и неповоротливый монстр, который сильно всё усложнил на самом деле. Поэтому я пока решил это “улучшение” выпилить, сделать всё погрязнее, но попроще, а потом вернусь к этой идее, когда все механики движения будут готовы и их просто нужно будет оптимизировать по производительности. Не всё сразу в общем.

Кстати занимательной задачкой для подумать стал вопрос о выборе стратегии движения в повороте. Допустим, что у вас есть вектор скорости, который можно вращать лишь на определённый угол в секунду, а также изменять модуль вектора на какое-то значение в секунду (т.е. тормозить или ускорять). Имеется и максимальное значение модуля (максимальная скорость). К координате материальной точки плюсуют этот вектор скорости через равные промежутки времени, а точка таким образом двигается. Так вот, как лучше поступить, если мы знаем угол поворота вектора скорости, его модуль, а также конечную точку, в которой материальная точка должна остановиться за минимальное время: тормозить и поворачивать, ускоряться и поворачивать, не менять скорость и поворачивать, как-то может по-особому нужно делать? Борода задачи в том, что я не смог вывести какое-то обобщённое решение, поэтому если у вас получится, то пишите мне (@leodigrigio). Так или иначе, в частных случаях выходит, что лучше всегда тормозить в повороте, но веры мне в этом нет.

В общем, так и живём. Следующий билд постараюсь не заниматься фигнёй, а буду добавлять простенький чат. Тут придётся чуть расширить GUI-движок (у меня нет текстовых инпутов), написать отдельный серверок для чата, всё это связать с существующей инфраструктурой. В общем как обычно всё очень весело.
Это я к чему. От центра звёздной системы до орбиты Сатурна, например, в среднем 9.5 астрономических единиц (au). После масштабирования планет и их орбит это расстояние пролетается за 8 часов на самом (пока) быстром корабле.

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

Поэтому нужно сократить время полёта до адекватных временных значений. 15-20 секунд на au – это вполне комфортно. Сравнимо по ощущениям с перелётами между звёздными системами в Космических Рейнджерах.

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

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

Вечерком засяду прототипировать.
Маленькая полезная мелочь для измерения расстояний в астрономических попугаях.
build 28
Реализовал процесс взлёта и посадки на-с планеты.

Исходно была идея 1 в 1 повторить как было в Космических рейнджерах, где игрок просто тыкал на планету и корабль на неё садился, исчезал как объект звёздной системы и там делал свои планетарные дела. Её я и реализовал, но после слегка прикинул, что с этой всей схемой будет в будущем.

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

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

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

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

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

В общем, космос будет огромным сам по себе, но доступным по временным затратам.
#сохранёнки #backend

https://www.youtube.com/watch?v=x-Uk5xBsstA
Смена дня и ночи. У меня где-то записана идея механики использования солнечных батарей по этому поводу.
Attached file
Первые шейдеры для визуализации поверхности планет
build 27
Импровизированный отпуск закончился, а значит пилю игру дальше, и я закончил очередную версию.

Основной вывод: интерфейс экипировки персонажа (в моём случае оборудования для корабля) должен влезать в одно окно. Без прокруток. Если хочется сделать интересную систему обвеса, но для этого придётся жертвовать UX’ом, то к чёрту такую систему.

Другой вывод, в принципе, очевидный для сетевых игр: игрок всегда врёт. Сервер всегда тоже немного врёт, но ему можно. Для гарантий, что игрок не сможет потерять предметы, например, при перетаскивании из инвентаря в эквипмент, либо что он не сможет их “дюпнуть” (склонировать) – нужно реализовать весьма надёжную систему хранения и обновления состояния, где только сервер всегда будет решать судьбу конкретного предмета.

Типовая цепочка событий для авторитарного сервера: игрок решил переместить предмет – отправил об этом уведомление на сервер – сервер проводит проверки на существование этого самого предмета, проверяет доступность слотов для перемещения – после этого либо разрешает клиенту перемещение, либо отказывает – в случае разрешения обновляет запись в БД, в случае отказа пишет в лог, что вот есть такая ошибка.

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

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

Вторая критичная проблема: транзакция перемещения предмета должна быть законченной, даже если на игровой сервер упадёт ядерная бомба. Думаю, заядлые игроки в ммо попадали в ситуацию, когда убиваешь моба, собираешь с него редкий предмет, секунду радуешься, а после этого события сервер язвительно заявляет «лол-кек, дисконнект» и после переподключения предмет пропадает, т.к. не успели сохранить предмет в базе и вообще убивай моба заново – у нас тут откат состояния. На данный момент у меня нет оптимальных решений этой проблемы.

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

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

https://youtu.be/TOa292kdegw
Халявный Оруэлл

https://www.humblebundle.com/store/orwell
#сохранёнки #java #jvm #graal

https://habr.com/post/419637/
Еще зачем-то твиттер завёл.

Оказывается, что у пользователей твиттера есть нехилая такая фора в получении мемасиков часов на 5-10.

Не скажу, что это очень нужно в жизни, но если любишь закатывать глаза, со словами "это же баян!", то вот самое оно.

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

Надеюсь, что вы там тоже не унываете.