В порядке шутки — грязный, но рабочий хак. Пихаем эту игру в отдельный ифрейм на странице, пихаем вторую игру во второй ифрейм, дописываем на Window.postMessage общение с родительской страницей — а уже в родительской странице делаем общую логику и даже полное отключение компонента.
Я так не делал и никому не советую, но в разумных пределах iframes + postMessage иногда работает как решение для сборки самых разных компонентов от самых разных разработчиков на одной странице. Как минимум, я знаю кейс, когда игру, которая писалась на игровом фреймворке, так подключали к странице, на которой крутился обычный фронтенд — и уже на ней показывались баллы, время, отведенное на игру и другие параметры, которые менялись на самой странице согласно гениальному плану организаторов всего проекта.
PS: не делал и не советую — в смысле, рефакторить такие кейсы подобным образом.
тут проблема в том, что обновление DOM сама по себе довольно затратная операция и со сложным макетом, особенно при эффектах типа анимированной смены экранов, подтормаживание будет заметно, даже если писать на ванилле (я писал) — поэтому в принципе для реал-тайма лучше взять что-то, что рисует на canvas хотя бы. Если будете дальше идти в том направлении и нужна будет скорость анимаций в html5, то попробуйте Phaser.js — но вот с управлением состоянием игры там придется рисовать свои архитектурные велосипеды
синглтон луп то сам по себе вещь нормальная, просто нужно не редактировать его, а иметь механизм загрузки и выгрузки задач для него. В фреймворке Phaser единый loop, который обрабатывает методы update всех живых объектов. Так что если бы мне поставили задачу расширять именно такой пример — я бы писал что-нибудь, что регистрировало бы функции в списке, по которому бы проходился loop
вот что касается стора — тут я в затруднении, поскольку недостаточно хорошо читаю Svelte/React-подобные исходники. По моим прикидкам, для сплитскрина один игровой экран должен быть вью-компонентом с инкапсулированным состоянием. Два таких компонента можно связать с общей моделью состояния, на изменения которого подписана логика соревнования и общий тайминг.
А тут одна общая модель для всех? Можно ли не хранить сиюминутные состояния экрана в общем сторе, сделать какой-нибудь свой отдельный стор-обсервабл?
если идти дальше и делать онлайн-матчи — то игровой экран придется сделать исполнителем для приходящих команд для изменения вью и отправителем команд нажатия — а логику обработки команд и внутреннего выносить на сервер. Но вряд ли кто-то даст денег под такой концепт игры )
Я не автор, я использовал вопрос как задачку для себя, поскольку работаю в похожей области и на горизонте как раз наклевывается мультиплеер. Если где-то мои рассуждения кажутся глупыми — не стесняйтесь указать более изящное решение.
если корпус данных действительно большой, то следующая ступень — это ввести контекст собеседника (тип собеседника), тогда в беседе «по работе» бот будет выдавать больше «рабочих» фраз, а в беседе с девушками — то, что чаще выдавал оригинал в беседе с девушками (конечно, эти множества пересекаются, поэтому надо как-то добавить и одновременное использование контекстов)
переключать контексты в процессе отладки можно вручную, а в финальном продукте можно предусмотреть отдельный блок «определения контекста»
это скорее размышление вслух, а не предложение или что-то еще. Я просто тоже хочу сделать себе такого бота и думаю, как его реализовать. Но учебник TensorFlow еще не дочитан, через пару лет сообщу. Или мой двойник сообщит
Добавлю — в идеальных условиях, когда дома вообще никого нет, может возникнуть странный психологический эффект «я в подводной лодке», когда днями не видишь людей и отрываешься от мира. С приятелем мы по отдельности долго работали фрилансерами на удаленке, потом питались от своих проектов, отмечали оба такой эффект.
я не могу раскрывать данные, но могу свидетельствовать, что видел проект на Svelte для одной крупной компании, сделанный одним из ведущих JS-разработчиков Рунета (он является организатором одной из крупных конференций по JavaScript).
Респект.
У меня был скрипт, который позволял верстать в Adobe Illustrator экраны для игр.
Для этого я группировал все объекты, которые должны были выводиться спрайтом и называл их, как нужно. Скрипт проходил по структуре документа, по всем слоям, брал с них верхние группы (не заходя в их иерархию), вычислял их размеры, копировал их в отдельный новый документ того же размера и уже из него выводил PNG с прозрачностью.
после вывода всех PNG — скрипт же выводил JSON-файл c именами и координатами, где нужно на сцене располагать соответствующие спрайты. Ну и по этому JSON-файлу построить сцену в игре было уже элементарным делом
я больше скажу — именно такие стратегии привели к тому, что в конце 80х, когда я спрашивал «когда начнем работать», старшие рабочие хватали меня за рукав и говорили
— садись лучше в покер поиграем
PS: имеется в виду «стратегия повышения нормы при сохранении зарплаты»
Я так не делал и никому не советую, но в разумных пределах iframes + postMessage иногда работает как решение для сборки самых разных компонентов от самых разных разработчиков на одной странице. Как минимум, я знаю кейс, когда игру, которая писалась на игровом фреймворке, так подключали к странице, на которой крутился обычный фронтенд — и уже на ней показывались баллы, время, отведенное на игру и другие параметры, которые менялись на самой странице согласно гениальному плану организаторов всего проекта.
PS: не делал и не советую — в смысле, рефакторить такие кейсы подобным образом.
хотя у меня был когда-то период God Object, а затем меловая эпоха толстых контроллеров
вот что касается стора — тут я в затруднении, поскольку недостаточно хорошо читаю Svelte/React-подобные исходники. По моим прикидкам, для сплитскрина один игровой экран должен быть вью-компонентом с инкапсулированным состоянием. Два таких компонента можно связать с общей моделью состояния, на изменения которого подписана логика соревнования и общий тайминг.
А тут одна общая модель для всех? Можно ли не хранить сиюминутные состояния экрана в общем сторе, сделать какой-нибудь свой отдельный стор-обсервабл?
если идти дальше и делать онлайн-матчи — то игровой экран придется сделать исполнителем для приходящих команд для изменения вью и отправителем команд нажатия — а логику обработки команд и внутреннего выносить на сервер. Но вряд ли кто-то даст денег под такой концепт игры )
Я не автор, я использовал вопрос как задачку для себя, поскольку работаю в похожей области и на горизонте как раз наклевывается мультиплеер. Если где-то мои рассуждения кажутся глупыми — не стесняйтесь указать более изящное решение.
На каких машинах тестировали?
переключать контексты в процессе отладки можно вручную, а в финальном продукте можно предусмотреть отдельный блок «определения контекста»
это скорее размышление вслух, а не предложение или что-то еще. Я просто тоже хочу сделать себе такого бота и думаю, как его реализовать. Но учебник TensorFlow еще не дочитан, через пару лет сообщу. Или мой двойник сообщит
я не могу раскрывать данные, но могу свидетельствовать, что видел проект на Svelte для одной крупной компании, сделанный одним из ведущих JS-разработчиков Рунета (он является организатором одной из крупных конференций по JavaScript).
У меня был скрипт, который позволял верстать в Adobe Illustrator экраны для игр.
Для этого я группировал все объекты, которые должны были выводиться спрайтом и называл их, как нужно. Скрипт проходил по структуре документа, по всем слоям, брал с них верхние группы (не заходя в их иерархию), вычислял их размеры, копировал их в отдельный новый документ того же размера и уже из него выводил PNG с прозрачностью.
после вывода всех PNG — скрипт же выводил JSON-файл c именами и координатами, где нужно на сцене располагать соответствующие спрайты. Ну и по этому JSON-файлу построить сцену в игре было уже элементарным делом
мне кажется, я не мог на ревю назначить ревьюеров и assigneroв, еще что-то по мелочи — пришлось использовать хром
если вам интересно знать, что на самом деле творится в кореях — погуголите Асмолово и tttkkk
В Северной Корее уже давно рыночная экономика с сохранением видимой роли коммунистической партии
— садись лучше в покер поиграем
PS: имеется в виду «стратегия повышения нормы при сохранении зарплаты»
а хочу я или нет такие операционки — это я не говорил
но искренне интересуюсь — FreeRTOS, она как .kkrieger в мире операционок, дает такой же вид, как аналогичные операционки-гиганты?