Нет, и не уверен, что буду пробовать, хотя расширения под него для этого есть. Все-таки этот фреймворк для каких-то сложных задач, а тут речь идёт о том, чтобы Flame потянул хотя бы простые.
Поставил как-то дедушке с бабушкой минт на базе 7.10, кажется. Потом, кажется, в 16 году у них скайп перестал работать, надо было обновиться.... А хренушки, ничего больше не обновляется, только всё сносить и заново ставить. Кое-как удалось только до 9.10 поднять, зеркалами старых репозиториев. С тех пор смотрю на системы без rolling-release с недоверием....
Затрудняюсь обобщить по жанру, но чтобы вот совсем не было проблем, игра должна соответствовать следующим критериям:
Небольшое игровое поле, желательно чтобы тупо помещалось в экран
Не должно быть очень динамичного экшена, 3-5 активно движущихся взаимодействующих объекта, не более.
Пошаговые игрушки - вообще идеально, думаю какой-нибудь Battle for Wesnoth отлично бы работал. А вот Transport Tycon или Sim City - уже не очень, т.к. там мир живёт "в фоне", независимо от действий игрока.
Это то, что можно запустить на Flame без финтов ушами, которые я тут описывал.
Но даже и с финтами, боюсь, границы "творческого выражения" будут весьма тесными - я не удовлетворен полученным уровнем производительности, а альтернативных путей не вижу. Разве что сесть шейдеры писать самому, но это уже перебор и выход за рамки фреймворка, проще тогда уж вообще его сменить.
Сейчас провожу "опыты" над Flame, заставляя работать с большими картами и множеством игровых объектов. И, к сожалению, вынужден констатировать, что производительности катастрофически не хватает, приходится изощряться, оптимизировать базовые компоненты и выбрасывать куски ненужной (в конкретном частном случае) логики, чтобы получить 60 FPS хотя бы на мощном десктопе, не то что на дохлой мобилке.
В этом плане, гипотетическая возможность получить 3D - любопытный эксперимент, но на практике, боюсь, пока абсолютно бесполезный. Фреймворку бы пока с 2D научиться справляться...
Но для простеньких игр на один экран, конечно, хватит с лихвой.
В целом мне кажется любой просчёт FPS внутри функции update будет не совсем корректным, т.к. это не частота кадров графического движка (который, я уверен, может рендерить гораздо быстрее) а, скорее, частота вычислений по игровой логике. Но если у нас update из-за перегруженности пересчитывается редко, то и и картинка не будет успевать за движком, так что....
Ну, довольно легко всё далось, правда это спустя 3 года после открытия, а не в первый день, плюс пришлось подождать, пока среднесписочная численность достигнет нужного значения. А так - просто подал заявление, потом просто пришел ответ, что "ок". Никаких хитростей.
Да, спасибо, смотрел эту конференцию, в том числе рекомендовал ваше выступление посомтреть всем интересующимся. Очень вдохновляет... с одной стороны. С другой - подход работает, но как мне кажется, во многом за счёт неимоверного скилла людей, стоящих у технических истоков проекта. Это совсем другое дело, чем если думать о том, как же запилить проект в ограниченный бюджет, с легко подменяемыми и быстро обучаемыми разработчиками и т.п. Вон, выше в комментариях и сайты на Go люди пишут, и этот подход тоже работает, но в скольких специфических случаях он экономически выгоден?
Что я пока вижу - на дарте и в бэк, конечно, тоже можно, но в подавляющем большинстве случаев все-таки не нужно, а во-вторых неизвестно, что будет через год, два, пять.... библиотеки под него рождаются так же быстро, как и умирают, и если нет решимости и целесообразносити вкладываться в собственные разработки, то без внятных сторонних библиотек для бэкенда сам по себе дарт не очень-то и нужен.
Самым неожиданным, как я уже говорил выше, был вау-эффект от того, что всё сразу работает, как задумывалось, ещё при первом запуске. Я бОльшую часть своего кода в жизни написал на PHP, и там вот довольно типичная ситуация, что написал один раз - теперь начинай гонять свой код в различных условиях, потому что где-то обязательно в переменной будет совсем не то, что ты ожидаешь. При этом сам ты можешь писать просто идеальный код, но достаточно одной какой-то или довольно старой библиотеки, или либы, которую автор написал, спустя рукава, несколько неопределённых аннотаций - и даже максимально строго настроенный линтер в IDE уже не спасёт. А у многих он настроен же вообще кое-как, если вообще есть привычка обращать внимание на его предупреждения. В Dart же такие вольности невозможны, как бы ни был убог твой личный редактор кода - проект просто не скомпилится. И это хорошо! В остальном я бы не сказал, что язык меня как-то удивил своими синтаксическими возможностями. Даже напротив, после PHP я чувствовал себя "немного связанным", но со временем научился выкручиваться. Больше всего меня удручает система наследования, а именно то, что статические методы и свойства не наследуются. Просто раздражает каждый раз копипастить один и тот же кусок кода, чтобы сделать класс синглтоном. И ещё раздражает необходимость прокидывать каждый именованный параметр в конструктор класса-родителя, когда наследуемся. Сам Flutter вдоль и поперёк завален этими простынями кода, в котором просто параметры прокидываются из одного конструктора в другой. И при этом разработчики не морьщась заявляют, что они борятся с лишним кодом, они за простоту, лаконичность и так далее и так далее... Как так?! Так что дизлайков Dart от меня тоже получил.
Нет, руками ничего не правил, чему, признаться, был приятно удивлён. Я ожидал, что мне придётся искать какой-то способ выкинуть из проекта импорт класса, работающего на изолятах, но даже этого не пришлось делать: проект прекрасно работает, только при рендере зависимого виджета выскакивает эксепшн. Скрыл зависимый виджет - решил проблему.
Не возникало такой ситуации. В целом я очень осторожно подходил к выбору библиотек на проект, если было подозрение, что либа "слишком web-ориентирована" или "слишком мобильно-ориентирована" - я старался найти альтернативы.
Ага, понимаю, о какой проблеме вы говорите :-) Я её видел, но мне показалось несущественным, пожтому просто махнул рукой. Ведь скорее всего все эти экраны с документацией при регулярном использовании просто поотключают да и всё. А уж ребятам, кто раньше игры вёл, такие вещи и вовсе не нужны. Более насущная пробелма вскрылась, когда мы собрались тестировать игру в реальных условиях. Предполагается, что мобильник с картами будет передаваться по кругу между игроками. И несколько раз вознгикла ситуация "Ой, я тут случайно кнопку нажал, разблокируй телефон обратно, плиз". Телефон разблокировали, а андроид тем временем прибил приложение. Не страшно. если играем без "магии" - ну, перемешабтся карты, переживём. Но мы играли с "магией", то есть там игрок мог оставить "бомбу", которая "взорвалась" бы через несколько ходов и принудила бы дроугого игрока менять свою историю в соответствии с заданными условиями. И вот это всё потерялось. Тут -то я и понял, что совсем забыл о сохранении состояния, чего на мобилках забывать непростительно.
Лайк :-)
Да попросил у ребят скинуть мне сканы колод, которые у них уже были в бумаге. Где уж они их брали - не ведаю, наверняка просто надёргали как-то из интернета. Вообще в былые времена движуха была куда активнее, у многих были "кастомные" колоды под себя, даже специально тренировали гейм-мастеров, проводили "экзамены", но потом @may-cat стало скучно всем этим заниматься, и я могу его понять :-) На самом деле я даже не знаю, когда точно всё это начиналось. Ну, лет 10 назад как минимум, потому что тогда мы с Игорем только познакомились. Но, скорее всего, ещё больше.
Не пробовал, но уверен, что да... эхх, вот бы под Mac/iOS можно было бы билдить в докере и тестить на эмуляторе... Ну, для друзей-яблочников, собственно, я и поднял web-версию.
Ну setState обновляет весьма массово - всё дерево виджетов, которое под ним...
С другой стороны, разработчики говорят, что делает он это весьма экономно, всё объекты, которые можно сохранить, система сохраняет, просто цепляет старые инстансы состояния к новым инстансам виджетов, не более.
Понятно, что стрелять setState как из пулемета - не очень хорошо.
С другой стороны, вот у меня в приложении виджет с карточкой, он одновременно может проигрывать анимацию переворачивания, перетаскивания, а сверху ещё виджет-прелоадер. И всё это я оптимизировал примерно никак - просто использовал готовые модули, заворачивая один написанный кем-то виджет с анимацией в другой, тоже с анимацией... А каждый кадр анимации - это, на секундочку, setState... Нууу, согласен, в веб-версии оно, пожалуй, уже лагает...
Я боюсь, что чтобы оценить пользу стейт-менеджера для своего проекта, надо всё-таки на старте понимать, с какой проблемой ты столкнется, плюс понимать особенности работы самого стейт-менеджера, чтобы понимать, что его механика работы действительно решает твою проблему.
Иначе это будет просто слепое копирование паттерна, "потому что мне так в учебном курсе сказали".
Конечно, не дело давать "экспертные заключения", посмотрев сайт проекта с мобильника, но похоже, что это решение больше подходит под шеринг бизнес-логики, а уже слой интерфейса придется пилить каждый раз заново, используя доступный для каждой платформы свой API...
Согласен, поскольку эти подозрения меня самого никогда не покидали.
Но когда у тебя такой богатый выбор инструментов, как понять, что А будет лучше Б, С и Д? Про какой ни прочтёшь, так они все хорошие, а значит обязательно где-то притаились грабли :-)
А раз пока нет четкого понимания, что именно мне требуется, кроме простоты, то считаю лучшим выбором взять и опробовать то, что лежит в основе. По крайней мере пока что привычка "искать недостающие ответы в исходниках ядра" меня ещё не подводила :-)
Немного странное желание видеть по каждой минорной задаче готовый кейс её решения кем-то ещё...
Когда мне понадобился свой бот, достаточно было знакомства с API teledart, и использования мозга, чтобы адаптировать его под свои задачи... И потом ещё немного аналитики и мозга, чтобы реализовать свою либу поверх teledart, потому что мне требовалась не просто подписка на событие, а конкретная сущность "команда", которая в зависимости от состояния может сработать, а может и нет.
В общем, чем меня лично триггерят подобные посты - в них нет "научной новизны" и "исследования вопроса", это просто компиляция чужих мануалов в туториал, простота и очевидность шагов которого вызывает вопросы в его нужности.
Нет, и не уверен, что буду пробовать, хотя расширения под него для этого есть. Все-таки этот фреймворк для каких-то сложных задач, а тут речь идёт о том, чтобы Flame потянул хотя бы простые.
Поставил как-то дедушке с бабушкой минт на базе 7.10, кажется. Потом, кажется, в 16 году у них скайп перестал работать, надо было обновиться.... А хренушки, ничего больше не обновляется, только всё сносить и заново ставить. Кое-как удалось только до 9.10 поднять, зеркалами старых репозиториев. С тех пор смотрю на системы без rolling-release с недоверием....
Затрудняюсь обобщить по жанру, но чтобы вот совсем не было проблем, игра должна соответствовать следующим критериям:
Небольшое игровое поле, желательно чтобы тупо помещалось в экран
Не должно быть очень динамичного экшена, 3-5 активно движущихся взаимодействующих объекта, не более.
Пошаговые игрушки - вообще идеально, думаю какой-нибудь Battle for Wesnoth отлично бы работал. А вот Transport Tycon или Sim City - уже не очень, т.к. там мир живёт "в фоне", независимо от действий игрока.
Это то, что можно запустить на Flame без финтов ушами, которые я тут описывал.
Но даже и с финтами, боюсь, границы "творческого выражения" будут весьма тесными - я не удовлетворен полученным уровнем производительности, а альтернативных путей не вижу. Разве что сесть шейдеры писать самому, но это уже перебор и выход за рамки фреймворка, проще тогда уж вообще его сменить.
нОминальным ?
Сейчас провожу "опыты" над Flame, заставляя работать с большими картами и множеством игровых объектов. И, к сожалению, вынужден констатировать, что производительности катастрофически не хватает, приходится изощряться, оптимизировать базовые компоненты и выбрасывать куски ненужной (в конкретном частном случае) логики, чтобы получить 60 FPS хотя бы на мощном десктопе, не то что на дохлой мобилке.
В этом плане, гипотетическая возможность получить 3D - любопытный эксперимент, но на практике, боюсь, пока абсолютно бесполезный. Фреймворку бы пока с 2D научиться справляться...
Но для простеньких игр на один экран, конечно, хватит с лихвой.
Дык кто ж его знает-то? Вопрос не изучен, и именно поэтому я здесь. А маркетинговый отдел может вещать что угодно...
В целом мне кажется любой просчёт FPS внутри функции update будет не совсем корректным, т.к. это не частота кадров графического движка (который, я уверен, может рендерить гораздо быстрее) а, скорее, частота вычислений по игровой логике. Но если у нас update из-за перегруженности пересчитывается редко, то и и картинка не будет успевать за движком, так что....
Ну i5 второго поколения для рабочих задач (веб, документы, веб-разработка, ютубчик) очень даже неплох, справедливости ради.
Ну, довольно легко всё далось, правда это спустя 3 года после открытия, а не в первый день, плюс пришлось подождать, пока среднесписочная численность достигнет нужного значения. А так - просто подал заявление, потом просто пришел ответ, что "ок". Никаких хитростей.
Да, спасибо, смотрел эту конференцию, в том числе рекомендовал ваше выступление посомтреть всем интересующимся. Очень вдохновляет... с одной стороны. С другой - подход работает, но как мне кажется, во многом за счёт неимоверного скилла людей, стоящих у технических истоков проекта. Это совсем другое дело, чем если думать о том, как же запилить проект в ограниченный бюджет, с легко подменяемыми и быстро обучаемыми разработчиками и т.п. Вон, выше в комментариях и сайты на Go люди пишут, и этот подход тоже работает, но в скольких специфических случаях он экономически выгоден?
Что я пока вижу - на дарте и в бэк, конечно, тоже можно, но в подавляющем большинстве случаев все-таки не нужно, а во-вторых неизвестно, что будет через год, два, пять.... библиотеки под него рождаются так же быстро, как и умирают, и если нет решимости и целесообразносити вкладываться в собственные разработки, то без внятных сторонних библиотек для бэкенда сам по себе дарт не очень-то и нужен.
Самым неожиданным, как я уже говорил выше, был вау-эффект от того, что всё сразу работает, как задумывалось, ещё при первом запуске. Я бОльшую часть своего кода в жизни написал на PHP, и там вот довольно типичная ситуация, что написал один раз - теперь начинай гонять свой код в различных условиях, потому что где-то обязательно в переменной будет совсем не то, что ты ожидаешь. При этом сам ты можешь писать просто идеальный код, но достаточно одной какой-то или довольно старой библиотеки, или либы, которую автор написал, спустя рукава, несколько неопределённых аннотаций - и даже максимально строго настроенный линтер в IDE уже не спасёт. А у многих он настроен же вообще кое-как, если вообще есть привычка обращать внимание на его предупреждения. В Dart же такие вольности невозможны, как бы ни был убог твой личный редактор кода - проект просто не скомпилится. И это хорошо!
В остальном я бы не сказал, что язык меня как-то удивил своими синтаксическими возможностями. Даже напротив, после PHP я чувствовал себя "немного связанным", но со временем научился выкручиваться. Больше всего меня удручает система наследования, а именно то, что статические методы и свойства не наследуются. Просто раздражает каждый раз копипастить один и тот же кусок кода, чтобы сделать класс синглтоном. И ещё раздражает необходимость прокидывать каждый именованный параметр в конструктор класса-родителя, когда наследуемся. Сам Flutter вдоль и поперёк завален этими простынями кода, в котором просто параметры прокидываются из одного конструктора в другой. И при этом разработчики не морьщась заявляют, что они борятся с лишним кодом, они за простоту, лаконичность и так далее и так далее... Как так?! Так что дизлайков Dart от меня тоже получил.
Нет, руками ничего не правил, чему, признаться, был приятно удивлён. Я ожидал, что мне придётся искать какой-то способ выкинуть из проекта импорт класса, работающего на изолятах, но даже этого не пришлось делать: проект прекрасно работает, только при рендере зависимого виджета выскакивает эксепшн. Скрыл зависимый виджет - решил проблему.
Не возникало такой ситуации. В целом я очень осторожно подходил к выбору библиотек на проект, если было подозрение, что либа "слишком web-ориентирована" или "слишком мобильно-ориентирована" - я старался найти альтернативы.
Ага, понимаю, о какой проблеме вы говорите :-) Я её видел, но мне показалось несущественным, пожтому просто махнул рукой. Ведь скорее всего все эти экраны с документацией при регулярном использовании просто поотключают да и всё. А уж ребятам, кто раньше игры вёл, такие вещи и вовсе не нужны. Более насущная пробелма вскрылась, когда мы собрались тестировать игру в реальных условиях. Предполагается, что мобильник с картами будет передаваться по кругу между игроками. И несколько раз вознгикла ситуация "Ой, я тут случайно кнопку нажал, разблокируй телефон обратно, плиз". Телефон разблокировали, а андроид тем временем прибил приложение. Не страшно. если играем без "магии" - ну, перемешабтся карты, переживём. Но мы играли с "магией", то есть там игрок мог оставить "бомбу", которая "взорвалась" бы через несколько ходов и принудила бы дроугого игрока менять свою историю в соответствии с заданными условиями. И вот это всё потерялось. Тут -то я и понял, что совсем забыл о сохранении состояния, чего на мобилках забывать непростительно.
Лайк :-)
Да попросил у ребят скинуть мне сканы колод, которые у них уже были в бумаге. Где уж они их брали - не ведаю, наверняка просто надёргали как-то из интернета. Вообще в былые времена движуха была куда активнее, у многих были "кастомные" колоды под себя, даже специально тренировали гейм-мастеров, проводили "экзамены", но потом @may-cat стало скучно всем этим заниматься, и я могу его понять :-) На самом деле я даже не знаю, когда точно всё это начиналось. Ну, лет 10 назад как минимум, потому что тогда мы с Игорем только познакомились. Но, скорее всего, ещё больше.
Не пробовал, но уверен, что да... эхх, вот бы под Mac/iOS можно было бы билдить в докере и тестить на эмуляторе... Ну, для друзей-яблочников, собственно, я и поднял web-версию.
Ну setState обновляет весьма массово - всё дерево виджетов, которое под ним...
С другой стороны, разработчики говорят, что делает он это весьма экономно, всё объекты, которые можно сохранить, система сохраняет, просто цепляет старые инстансы состояния к новым инстансам виджетов, не более.
Понятно, что стрелять setState как из пулемета - не очень хорошо.
С другой стороны, вот у меня в приложении виджет с карточкой, он одновременно может проигрывать анимацию переворачивания, перетаскивания, а сверху ещё виджет-прелоадер. И всё это я оптимизировал примерно никак - просто использовал готовые модули, заворачивая один написанный кем-то виджет с анимацией в другой, тоже с анимацией... А каждый кадр анимации - это, на секундочку, setState... Нууу, согласен, в веб-версии оно, пожалуй, уже лагает...
Я боюсь, что чтобы оценить пользу стейт-менеджера для своего проекта, надо всё-таки на старте понимать, с какой проблемой ты столкнется, плюс понимать особенности работы самого стейт-менеджера, чтобы понимать, что его механика работы действительно решает твою проблему.
Иначе это будет просто слепое копирование паттерна, "потому что мне так в учебном курсе сказали".
Спасибо, интересно! И правда, с беглого взгляда наискосок такого не узнаешь.
А вы на нём, если не секрет, какие вещи создавали?
Честно сказать, впервые от вас вот и услышал.
Конечно, не дело давать "экспертные заключения", посмотрев сайт проекта с мобильника, но похоже, что это решение больше подходит под шеринг бизнес-логики, а уже слой интерфейса придется пилить каждый раз заново, используя доступный для каждой платформы свой API...
Согласен, поскольку эти подозрения меня самого никогда не покидали.
Но когда у тебя такой богатый выбор инструментов, как понять, что А будет лучше Б, С и Д? Про какой ни прочтёшь, так они все хорошие, а значит обязательно где-то притаились грабли :-)
А раз пока нет четкого понимания, что именно мне требуется, кроме простоты, то считаю лучшим выбором взять и опробовать то, что лежит в основе. По крайней мере пока что привычка "искать недостающие ответы в исходниках ядра" меня ещё не подводила :-)
У всех задачи разные. На многих вполне серьёзных проектах вообще всё по-старинке, html+php+js, и на то есть свои веские основания.
До сей минуты я ещё сомневался, а правильно ли делаю, что не обновляюсь?
Больше не сомневаюсь.
Или откроет свою студию. Попутно став ещё и бухгалтером ?
Да, Crosswalk избавлял от части проблем, добавляя ~30 мегабайт к весу финального приложения, что бешено много для аппликейшена уровня "сайт".
В условиях, когда все операции вертятся в одном потоке, это всё равно не очень помогает, а тем более когда само железо устройства не сильно мощное.
Немного странное желание видеть по каждой минорной задаче готовый кейс её решения кем-то ещё...
Когда мне понадобился свой бот, достаточно было знакомства с API teledart, и использования мозга, чтобы адаптировать его под свои задачи... И потом ещё немного аналитики и мозга, чтобы реализовать свою либу поверх teledart, потому что мне требовалась не просто подписка на событие, а конкретная сущность "команда", которая в зависимости от состояния может сработать, а может и нет.
В общем, чем меня лично триггерят подобные посты - в них нет "научной новизны" и "исследования вопроса", это просто компиляция чужих мануалов в туториал, простота и очевидность шагов которого вызывает вопросы в его нужности.