Поддержу автора. Есть пример, это как в gamedev приходят к архитектурному паттерну ECS. Паттерн помогает избежать кучи гемора, связанного с ООП. Больше не нужно конструировать сложные классы и придумывать как они должны взаимодействовать. Данные отделены от представления, легко писать логику, легко проверять. И главное работает быстро, из-за TypedArray.
Везде рассказывают про архитектуру в вакууме, забывая рассказать о специфике браузерной среды. Расскажите лучше про это. Это очень важно, если вы делаете что-то сложнее чем формы и вывод контента, например, игры. Я никогда особо не обращал внимание на то, что браузер может засыпать, что приводит к остановке некоторых вычислений. То есть "железную" логику легко поломать, если просто переключить фокус на другой таб.
Ничего не осталось, к сожалению. Мне показалось такое моделирование это переусложнение, так как может понадобиться любой внешний API, разные среды исполнения и т. д., и реализовать это в таком редакторе будет очень заморочено. Проще продолжать писать это привычно кодом, а ту самую необходимую визуализацию тщательно документировать в Obsidian на canvas.
Библиотека правда хорошая, но лапшекод можно сделать на чём угодно.
Проблема Effector и других похожих инструментов, это отсутствие визуализации.
Чтобы даже небольшой граф состояний понять, надо прочитать код и создать картинку со всеми связями у себя в голове, и это приходится делать каждый раз.
Чтобы хоть как-то избавиться от этого я пытался сделать редактор графа состояний поверх Effector, но это оказалось полумерами, которые сильно ничего не упрощали.
Кроме того, если мы говорим про DX, то нужно упомянуть немного о тестировании.
> а в качестве gui допускается использовать обычные react/html Можно, но в таком случае вы теряете кучу возможностей анимировать свой gui через tweens, использовать частицы и др.
> IDE это конечно хорошо, но ее отсутствие не мешает мне писать свой мультиплеер. Это про другое, такого рода логику приходится писать как обычно, IDE для phaser поможет именно организовывать ассеты, сцены, префабы и другую рутину.
Разработка через код усложнена тем, что приходится каждый раз в голове восстанавливать геймлей, это терпимо для маленьких проектов. Для больших это становиться бедствием. Правда, попробуйте использовать предложенный редактор, он поможет структурировать проект, вы действительно не теряете ничего как разработчик, а наоборот приобретаете ещё возможности. Также редактор добавляет к Phaser концепт, не существующий в фазере, но уже давно привычный в других движках — это prefab (по сути это как компонент в React).
Ну и про DebugPanel закину, тоже оверхед, можно подключить тот же dat.gui и не колхозить ничего :D В любом случае желаю вам успехов ;)
Пытаюсь представить себе как можно разрабатывать игру на голом фазере, это же страдания, не? Вы приводите ссылки на материалы, но они туго объясняют как структурировать игровой проект. Phaser действительно может много как движок, но его отличие от других движков, это то, что у него нет официальной IDE. И это затрудняет ваши продвижения в разработке. Для начинающих и не только могу посоветовать неофициальную, но очень мощную IDE https://phasereditor2d.com/
Любопытно посмотреть ещё какие-нибудь материалы на тему, так как сами разрабатываем многопользовательскую игру, точнее переносим в веб настолку.
Я наблюдаю за развитием whatsup, как-будто глоток свежего воздуха, реактивность, производительность, нативность, минимализм api, jsx тоже есть и многое другое.
Интересно посмотреть на живой пример/ну или gif, когда сами поля строятся динамично. Например для поля `ru_passport` есть поле `ru_passport_id` (с масками и валидацией, и т. д.), но при переключении на `foreign_passport` выводим уже `foreign_passport_id` (уже другая маска, валидация...) плюс `foreign_passport_expire-date`.
Тоже не понимаю. Вы выбрали запись массивами в угоду удобства сериализации данных вместо человеко-читаемости? Как-будто, можно найти решение через описание грамматики для парсеров (PEG), оставив при этом простую и понятную запись. У Алексея Охрименко есть хороший доклад на эту тему.
раздуваются стили, исправление ожидается (можно решить временно с помощью csso минификации { restructure: true })
некоторые свойства пробрасываются в html, что раздует разметку при ssr (можно решить соглашением именования пропертей, например $size или _size вместо size, или другое название проперти не из whitelist)
Видимо слишком революционные идеи :D
Поддержу автора.
Есть пример, это как в gamedev приходят к архитектурному паттерну ECS. Паттерн помогает избежать кучи гемора, связанного с ООП. Больше не нужно конструировать сложные классы и придумывать как они должны взаимодействовать. Данные отделены от представления, легко писать логику, легко проверять. И главное работает быстро, из-за TypedArray.
На хабре уже есть очень хороший материал об этом https://habr.com/ru/articles/819005/
Там раскрывается порочность Promise и преимущества генераторов.
Генераторы, не? :D
Везде рассказывают про архитектуру в вакууме, забывая рассказать о специфике браузерной среды. Расскажите лучше про это. Это очень важно, если вы делаете что-то сложнее чем формы и вывод контента, например, игры. Я никогда особо не обращал внимание на то, что браузер может засыпать, что приводит к остановке некоторых вычислений. То есть "железную" логику легко поломать, если просто переключить фокус на другой таб.
Меня заинтересовала ваша реализация кубов. Расскажите, пожалуйста, в чём преимущество такого подхода, почему это может быть лучше живой генерации?
Не вижу, чтобы кто-то упомянул про OmniDiskSweeper для мак.
Мне нравится использовать для
wip?Плашки и подложку в сетку сам наверстал, а для стрелочек я нашёл `react-archer`.
Ничего не осталось, к сожалению.
Мне показалось такое моделирование это переусложнение, так как может понадобиться любой внешний API, разные среды исполнения и т. д., и реализовать это в таком редакторе будет очень заморочено. Проще продолжать писать это привычно кодом, а ту самую необходимую визуализацию тщательно документировать в Obsidian на canvas.
Библиотека правда хорошая, но лапшекод можно сделать на чём угодно.
Проблема Effector и других похожих инструментов, это отсутствие визуализации.
Чтобы даже небольшой граф состояний понять, надо прочитать код и создать картинку со всеми связями у себя в голове, и это приходится делать каждый раз.
Чтобы хоть как-то избавиться от этого я пытался сделать редактор графа состояний поверх Effector, но это оказалось полумерами, которые сильно ничего не упрощали.
Кроме того, если мы говорим про DX, то нужно упомянуть немного о тестировании.
Читали эту книжку, самая занимательная история это у Stardew Valley, остальное как под кальку, со всеми случилось одно и то же.
> а в качестве gui допускается использовать обычные react/html
Можно, но в таком случае вы теряете кучу возможностей анимировать свой gui через tweens, использовать частицы и др.
> IDE это конечно хорошо, но ее отсутствие не мешает мне писать свой мультиплеер.
Это про другое, такого рода логику приходится писать как обычно, IDE для phaser поможет именно организовывать ассеты, сцены, префабы и другую рутину.
Разработка через код усложнена тем, что приходится каждый раз в голове восстанавливать геймлей, это терпимо для маленьких проектов. Для больших это становиться бедствием. Правда, попробуйте использовать предложенный редактор, он поможет структурировать проект, вы действительно не теряете ничего как разработчик, а наоборот приобретаете ещё возможности. Также редактор добавляет к Phaser концепт, не существующий в фазере, но уже давно привычный в других движках — это prefab (по сути это как компонент в React).
Ну и про DebugPanel закину, тоже оверхед, можно подключить тот же dat.gui и не колхозить ничего :D
В любом случае желаю вам успехов ;)
Пытаюсь представить себе как можно разрабатывать игру на голом фазере, это же страдания, не? Вы приводите ссылки на материалы, но они туго объясняют как структурировать игровой проект. Phaser действительно может много как движок, но его отличие от других движков, это то, что у него нет официальной IDE. И это затрудняет ваши продвижения в разработке. Для начинающих и не только могу посоветовать неофициальную, но очень мощную IDE https://phasereditor2d.com/
Любопытно посмотреть ещё какие-нибудь материалы на тему, так как сами разрабатываем многопользовательскую игру, точнее переносим в веб настолку.
Я наблюдаю за развитием whatsup, как-будто глоток свежего воздуха, реактивность, производительность, нативность, минимализм api, jsx тоже есть и многое другое.
Интересно посмотреть на живой пример/ну или gif, когда сами поля строятся динамично. Например для поля `ru_passport` есть поле `ru_passport_id` (с масками и валидацией, и т. д.), но при переключении на `foreign_passport` выводим уже `foreign_passport_id` (уже другая маска, валидация...) плюс `foreign_passport_expire-date`.
Тоже не понимаю. Вы выбрали запись массивами в угоду удобства сериализации данных вместо человеко-читаемости? Как-будто, можно найти решение через описание грамматики для парсеров (PEG), оставив при этом простую и понятную запись. У Алексея Охрименко есть хороший доклад на эту тему.
Натыкался как-то на react ui либу стилизованную под win95 https://github.com/arturbien/React95
Так и девтул под хром есть https://github.com/binaryage/cljs-devtools
Пример с модификатором
Минусы:
{ restructure: true })$sizeили_sizeвместоsize, или другое название проперти не из whitelist)