• Будьте внимательны, не попадайтесь на уловки мошенников и при возможности используйте наш сервис. Также ознакомьтесь - Рекомендации по защите от мошенников.
  • Из-за обновления GTA 5 (был добавлен новый патч) может временно не работать вход в RAGE Multiplayer.

    Ошибка: Ваша версия Grand Theft Auto V не поддерживается RAGE Multiplayer.
    ERROR: Your game version is not supported by RAGE Multiplayer.

    Данная ошибка говорит о том, что GTA V обновилась до новой версии (GTA Online тоже). Вам необходимо обновить саму игру в главном меню вашего приложения (Steam / Epic Games / Rockstar Games).
    Если после этого RAGE:MP все равно не работает - вам нужно дождаться выхода патча для самого мультиплеера (обычно это занимает от нескольких часов до нескольких дней).

    Новости и апдейты Rockstar Games - https://www.rockstargames.com/newswire/
    Статус всех служб для Rockstar Games Launcher и поддерживаемых игр: https://support.rockstargames.com/ru/servicestatus


    Grand Theft Auto 5 (+ GTA Online) последний раз были обновлены:

Slash

Участник портала
BackEnd developer
10 Янв 2023
154
18
53
Не силён в попытках реализовать такое в жта, но чисто на уровне базовой девопс логики и того как работает жта-сервер - это звучит как ПОЛНАЯ хуйня буквально от начала до конца.

Поясню
SQL - не цпу-баунд, он сидит в асинк-эвейте и ждёт ответ.
Нода ПРЕКРАСНО справляется с этим внутри себя.
При нормальном пуле и архитектуре, конечно.
Всё что ты получаешь, разделяя серверную логику и бд через хттп - это ещё один нахуй не нужный промежуточный слой, который по факту тебе увеличивает задержку, требует дублирования у себя моделей\дто в каком бы ты там виде данные не держал и потенциально добавляет тебе точку отказа ещё одну
Хочешь разгрузку - используй пул, очереди задач, отдельный тяжёлый модуль - но не хттп, аллаха ради.

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

Хочешь тестить серверную бизнес-логику - напиши сервис, ну юнит тесты там, отдельные интеграционные вызовы
хттп - это вообще не средство для изоляции логики, это буквально просто ну, транспорт
Максимум - ты сдвинешь латенси который получается из-за хуёвого решения в коде на две секунды правее за апи

Базово то что ты говоришь - в целом абсолютно разумно, местами хороший, уважаемый подход - но только не для жта.
Микросервисная архитектура уровня нетфликса здесь просто не нужна, а разделять логику по транспортам без причины - это нахуй не нужная избыточность, которая типа призвана лечить проблему, которая должна лечиться совсем не так и не здесь, которая в итоге становится просто безумным нагромождением инфраструктурной логики.
Ну возможно с точки зрения бизнеса это не окупится, но если есть возможность такое реализовать почему бы не оставить на основном сервере только обработку самой гта. К тому же если говорить за сокеты, то там появляется возможность реализовать синхру в реальном времени(конечно можно что-то похожее сделать и на рейдж апи, но на сокетах оно будет проще и быстрее. Ну и с экспресом тоже свои приколы делать можно, по типу запросов с тг/дискорд ботов или сайта
 

Inoi

/dev/null
Команда форума
Moderator
VIP
15 Окт 2020
3,900
1,926
208
35
Ну возможно с точки зрения бизнеса это не окупится, но если есть возможность такое реализовать почему бы не оставить на основном сервере только обработку самой гта. К тому же если говорить за сокеты, то там появляется возможность реализовать синхру в реальном времени(конечно можно что-то похожее сделать и на рейдж апи, но на сокетах оно будет проще и быстрее. Ну и с экспресом тоже свои приколы делать можно, по типу запросов с тг/дискорд ботов или сайта
Да ну не, дело не в бизнесе, прям уж там пиздец траты конечно
Мы же говорим о схеме сервер - хттп\всс (похуй) - экспресс апи - скл, я правильно понимаю?
Просто уточнить
Сокеты не между цефом и экспрессом же?
 

Slash

Участник портала
BackEnd developer
10 Янв 2023
154
18
53
Да ну не, дело не в бизнесе, прям уж там пиздец траты конечно
Мы же говорим о схеме сервер - хттп\всс (похуй) - экспресс апи - скл, я правильно понимаю?
Просто уточнить
Сокеты не между цефом и экспрессом же?
Ну сокеты между цефом и экспрессом никакого смысла не несут, скорее наоборот.
Я в целом про преимущества 2 бека, экспресс и сокеты как частный пример просто
 

Inoi

/dev/null
Команда форума
Moderator
VIP
15 Окт 2020
3,900
1,926
208
35
Ну сокеты между цефом и экспрессом никакого смысла не несут, скорее наоборот.
Я в целом про преимущества 2 бека, экспресс и сокеты как частный пример просто
Ну вот и эти - на самом деле тоже.

Это буквально архитектурная катастрофа, кроме шуток.
Че ты получаешь - сериализацию, десериализацию, лишний латенси, при этом экспресс - это просто прокси по сути.
Не какой-то асинхронный брокер, не кэш - просто прокси. Ну, ты просто добавляешь сетевой слой абсолютно без причины.

Тейк "убрать возможные задержки" - буквально не работает, потому что запрос-экспресс-скл-ответ-экспресс-альтв работает ну, дольше, очевидно.
Ты тупа увеличиваешь латенси ради "разделения логики", которое на самом деле - тоже кривое.
Ты теряешь типизацию, инъекцию зависимостей, контекст вызова, разъёбывая инкапсуляцию в процессе.
В хттп запросе тупа даже прямая связь с образным alt.player или как там это у вас - теряется, вообще гарантий нет что запрос не curl просто дёрнул.

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

Ну да, это изолирует логику от игрового движка
А нахуя? Ну, это не оптимизация, это архитектурный онанизм.

Тебе не нужно изолировать логику ОТ игрового движка, тебе нужно разделить логику ВНУТРИ сервера по слоям.
Изолировать ответственности, а не процессы и технологии, архитектура - она про это.

Это всё буквально можно сделать внутри одного процесса, через нормальный орм, асинк вызовы и слои бизнес-логики.

Ну и чего там у вас в ноде есть, воркер-треды, редис в конце концов.
Но не хттп запрос в соседний процесс же

Чтобы быть честным, когда подобное имеет место быть
Когда у тебя какая-то легаси архитектура, огромный бек с бизнес-логикой, и альтв - просто один из игровых мостов, например.
Когда нужна зачем-то жесткая изоляция - если альтв почему-то в какой-то небезопасной среде.
Но ну
Да

Даже при условии "сайты", "боты" и так далее - да напиши сервис для них прямо на серваке со своим апи-ендпойнтом, который будет точно так же обрабатываться асинхронно этой же нодой - это ровным счётом никак не повлияет на сервак.
Ну будут тебя дудосить через телегу - повесь рейт-лимиты, изолируй роуты, да хоть таймер въебаш

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

Ну в целом не говоря про то, что на самом деле ты не решаешь проблему, которая считаешь что есть - а только увеличиваешь её, ещё и попутно плодя лишнюю инфраструктуру.
Вот
 
Реакции: Walk1ee

UchihaMadara

Старожил
FrontEnd developer
27 Окт 2020
648
237
121
Поэтому мне в целом удивительно, что Учиха вообще диалог продолжил сам, после того как его увидел.
Не. Так в целом-то одна из многих вакансий, которая действительно интересная. Начиная от типа занятости(что мне подходит на 100%), заканчивая тем, что интересно было посмотреть как это вообще работает. Чисто для опыта, чтобы потом на собесах накидывать интересные моменты.

Как бы в целом, поднять express js, накидать эндпоинты можно было. Но супер очень не хотелось ебаться с PostgreSQL, таблицы создавать, коннекты, настройки все вот эти.

Но по итогу оказалось, что мозгоёбство началось с момента знакомства. Я такие вещи супер ненавижу. Проходил уже много собесов. Вот когда так мозги ебут, хочется чела на спарринг пригласить. Что-то вроде "НУ ЧТО ТЫ ЗА ПИДАРАС? НЕУЖЕЛИ НЕЛЬЗЯ ОТВЕТИТЬ НОРМАЛЬНО? ТЫ ЧЕЛОВЕК ВООБЩЕ?" :ROFLMAO:
 
  • RoflanEbalo
Реакции: Inoi

Inoi

/dev/null
Команда форума
Moderator
VIP
15 Окт 2020
3,900
1,926
208
35
Подумал тут ещё в довесок
Что ну ДОПУСТИМ можно представить что у тебя есть сайт, где охуенно много инфы про плеера
Ну как в варкрафте было - персонажа видно, инвентарь там, аччивки
Очевидно много инфы, много запросов (допустим), которые ещё и почему-то хуёво оптимизированны

И окей, вот тут можно поставить апи-прокладку отдельно от сервера, звучит легитно и разумно
Но опять таки, экспресс здесь - не должен быть "бэком банкомата".

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

сервер - постгря\редис
боты\сайт\вебуи любой - экспресс апи - постгря\редис

Ну то есть они просто живут отдельно, если очень надо
Вот разве что так
Иначе это ну, ошибка же, пиздец
 

Inoi

/dev/null
Команда форума
Moderator
VIP
15 Окт 2020
3,900
1,926
208
35
Тут же важно ещё учитывать, какой сервер сам по себе - Statefull или Stateless.
Так экспресс как раз - по хорошему должен быть стейтлесс-сервером, разве нет?
А альтв ну, всегда стейтфул

То есть по логике топика мы как будто хотим перекладывать состояния в экспресс, делая из него второй стейфул-сервак
У которого при этом никакой связи с игровой сессией и вообще каких-то гарантий например что плеер ещё существует - нет
Всё ещё с двумя источниками истины

Это ж тока подтверждает мои рассуждения

Ну либо иначе мы идём в какой-то тупой альтв + умный экспресс, где сервак превращается в толстого клиента с цефом и вебсокет-обёрткой
Но это ж вообще какое то гибридное уродство, блять))
 

Inoi

/dev/null
Команда форума
Moderator
VIP
15 Окт 2020
3,900
1,926
208
35
А или я не обратил внимания что ты на конкретно отдельный случай указал, именно во втором посте

Так там всегда стейтлесс естественно
Тебе похуй, что альтв-стейтфул, когда у тебя сторонняя апи для сайта, если она пассивная, ты же просто статические данные отдаёшь
 

UchihaMadara

Старожил
FrontEnd developer
27 Окт 2020
648
237
121
А альтв ну, всегда стейтфул
Там нужно умело маневрировать.

Все моменты, где игрок готов подождать (Авторизация, Спавн и тд) - стейтлесс получается.
А вот UI - Инвентарь, Меню игрока, ну ещё что-нибудь, должны быть по сути Stateful.

Ну как в варкрафте было - персонажа видно, инвентарь там, аччивки
И окей, вот тут можно поставить апи-прокладку отдельно от сервера, звучит легитно и разумно
Как ты хочешь переложить Инвентарь на микросервис?))

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

Inoi

/dev/null
Команда форума
Moderator
VIP
15 Окт 2020
3,900
1,926
208
35
Там нужно умело маневрировать.

Все моменты, где игрок готов подождать (Авторизация, Спавн и тд) - стейтлесс получается.

А вот UI - Инвентарь, Меню игрока, ну ещё что-нибудь, должны быть по сути Stateful.

Как ты хочешь переложить Инвентарь на микросервис?))

И опять же, все эти микросервисы должны быть в роли Геттера без чувствительных данных. Безопасность и вот это всё.
Стейт - это про то, хранит ли сервер контекст между запросами.

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

Ну типа по интерфейсу стейтлесс ага, но под капотом - да вообще нихуя не факт.

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

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

UchihaMadara

Старожил
FrontEnd developer
27 Окт 2020
648
237
121
Стейт - это про то, хранит ли сервер контекст между запросами.

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

Ну типа по интерфейсу стейтлесс ага, но под капотом - да вообще нихуя не факт.

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

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

Игра и игровой сервер - это немного о другом. Вот ты говоришь «не потому что игрок готов подождать». А вот как раз наоборот. Именно поэтому.

Гта и мультиплеер. Я не знаю кто это придумал, но все разрабатывается как будто это веб приложение. Дизайн, логика сервера, логика клиента.

как будто знаешь, ты играешь ролеплей игры на форумах, только при этом тебе еще дают сверху побегать в 3д мире.

говорим о стейтфул и стейтлесс в контексте ммо игр.

Стейтлесс - это получается хранится в бд информация о деньгах персонажа. Вот прикинь, ты забежал в магаз 24-7 закупить аптечки допустим. Нажимаешь купить и у тебя лоадер ебучий. Потому что серверу нужно принять запрос, обработать че ты хочешь, послать запрос в бд, дождаться ответа, обработать остатки и сообщить клиенту может он или не может купить. И так каждый раз.

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

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

ну а такие вещи как Инвентарь должны открываться моментально. Чтобы игрок даже не чувствовал прогрузки. То есть здесь надо кешировать данные инвентаря на клиенте.
 

Slash

Участник портала
BackEnd developer
10 Янв 2023
154
18
53
потому что запрос-экспресс-скл-ответ-экспресс-альтв работает ну, дольше, очевидно.
Ты тупа увеличиваешь латенси ради "разделения логики", которое на самом деле - тоже кривое.
если я правильно понял, то альтв здесь это сервер? Если так то тебе не во всех случаях туда надо стучаться, в случаях с эксперсом это когда нужно взаимодействовать с rage api или пейдей выдать клиенту(с сокетами есть варик оставить запрос на сервер только когда нужно rage mp api) Как по мне есть смысл пожертвовать задержкой ради того, чтобы оставить на рейдж/альтв сервере обработку связанную только с гта плюсом получить фишки сокетов
это архитектурный онанизм.
я не совсем понимаю каким образом ломается архитектура, если ты по сути выполняешь те же действия только не на первом, а втором беке?

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

Inoi

/dev/null
Команда форума
Moderator
VIP
15 Окт 2020
3,900
1,926
208
35
Ты это рассматриваешь с точки зрения разработки веб приложения.

Игра и игровой сервер - это немного о другом. Вот ты говоришь «не потому что игрок готов подождать». А вот как раз наоборот. Именно поэтому.

Гта и мультиплеер. Я не знаю кто это придумал, но все разрабатывается как будто это веб приложение. Дизайн, логика сервера, логика клиента.

как будто знаешь, ты играешь ролеплей игры на форумах, только при этом тебе еще дают сверху побегать в 3д мире.

говорим о стейтфул и стейтлесс в контексте ммо игр.

Стейтлесс - это получается хранится в бд информация о деньгах персонажа. Вот прикинь, ты забежал в магаз 24-7 закупить аптечки допустим. Нажимаешь купить и у тебя лоадер ебучий. Потому что серверу нужно принять запрос, обработать че ты хочешь, послать запрос в бд, дождаться ответа, обработать остатки и сообщить клиенту может он или не может купить. И так каждый раз.

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

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

ну а такие вещи как Инвентарь должны открываться моментально. Чтобы игрок даже не чувствовал прогрузки. То есть здесь надо кешировать данные инвентаря на клиенте.
А я понял. Мысль так то понятная и справедливая, просто ты мне кажется термины чутка не так используешь.

Стейтлесс и стейтфулл - эт про состояние между запросами.
Если ты можешь каждый запрос обрабатывать как независимый - это стейтлесс.
Если тебе нужно что-то помнить - стейтфул.
Это о том, как сервер управляет СВОИМ состоянием между запросами.

У тебя может быть быстрый стейтфул - и медленный стейтлесс, легко.
Я уверен специалисты с рейдж мп про подскажут варианты.

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

Тут ну, какое "в контексте", если ну, оно про другое.

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

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




бля стока раз написал стейлесс стейтфул что уже путать начал
 
Последнее редактирование:

Inoi

/dev/null
Команда форума
Moderator
VIP
15 Окт 2020
3,900
1,926
208
35
есть смысл пожертвовать задержкой ради того, чтобы оставить на рейдж/альтв сервере обработку связанную только с гта плюсом получить фишки сокетов
Да нету смысла. Это антипаттерн. Отделяем не потому что "нужно", а потому что "можно".
Отказаться от мгновенной обработки чтобы ... перенести её туда, где её можно делать так же, но медленнее, не ну.
Ты ну, буквально ломаешь консистентность просто ради прикола
За каким хуем-то тебе "фишки сокетов", если функционала буквально становится меньше.

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

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

знать только клиент
проверки, основанные на том что "знает только клиент" )))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
)))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))
)))))))))))))))))))
 
Последнее редактирование:

UchihaMadara

Старожил
FrontEnd developer
27 Окт 2020
648
237
121
Я понимаю, что ты просто так называешь, в конкретном да контексте, но ну, так начинается какая-то путаница откровенная между возможностью подождать и фактом наличия состояния, а это вообще не тождественно.
Ну а как это назвать?) Если есть термин для такого, то будет интересно узнать. Исходя из прочитанного мною в интернете, я увидел параллель между всей этой делюгой. Поэтому так и называю.

Мы ранее уже говорили о том, где писать логику, на клиенте или на сервере. У тебя получается подход к разработке полностью web application. Хотя вся ГТА сфера болеет этим. На любой сервер гта заходишь - как будто заходишь на сайт, где тебе подгружают WebGL с 3д миром.

Даже САМП с его супер простым UI ощущались как единая игра.

@Slash тоже рассуждает о разработке архитектуры Бекенда как будто для Web.

Вот где самая большая путаница.
 

Inoi

/dev/null
Команда форума
Moderator
VIP
15 Окт 2020
3,900
1,926
208
35
Ну а как это назвать?) Если есть термин для такого, то будет интересно узнать. Исходя из прочитанного мною в интернете, я увидел параллель между всей этой делюгой. Поэтому так и называю.

Мы ранее уже говорили о том, где писать логику, на клиенте или на сервере. У тебя получается подход к разработке полностью web application. Хотя вся ГТА сфера болеет этим. На любой сервер гта заходишь - как будто заходишь на сайт, где тебе подгружают WebGL с 3д миром.

Даже САМП с его супер простым UI ощущались как единая игра.

@Slash тоже рассуждает о разработке архитектуры Бекенда как будто для Web.

Вот где самая большая путаница.
Латентность наверное больше всего подходит, если верить поисковикам, я так то с ходу тебе тоже не скажу, я не ебу, тут какие то как говорится академические знания отсутствуют

1749406347562.png



В остальном ты че то поплыл как будто бы
Сысле полностью веб-аппликейшен, почему? Самп - единая игра?)
Звучит как "ты не прав, потому что думаешь как инженер, а мы тут вообще то землянку роем из навоза", ы

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

Жда сервер точно такой же программный продукт, с кодом там, модулями, состояниями, юзерами, с нагрузкой и бизнес-логикой
Он должен быть так же архитектурно обоснован как и любой другой програмный продукт, иначе это необслуживаемое и не расширяемое говно
Почему веб то
Это просто здравый смысл

В сампе всё было едино, видимо потому что это был всегда монолит?
Я нихуя не знаю про PAWN особо, но примерно представляю насколько это было хуёво, это ж скриптовый язык, ы
 
Последнее редактирование:
  • Love
Реакции: enotit

UchihaMadara

Старожил
FrontEnd developer
27 Окт 2020
648
237
121
Латентность наверное больше всего подходит, если верить поисковикам, я так то с ходу тебе тоже не скажу, я не ебу, тут какие то как говорится академические знания отсутствуют

Посмотреть вложение 19976


В остальном ты че то поплыл как будто бы
Сысле полностью веб-аппликейшен, почему? Самп - единая игра?)
Звучит как "ты не прав, потому что думаешь как инженер, а мы тут вообще то землянку роем из навоза", ы

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

Жда сервер точно такой же программный продукт, с кодом там, модулями, состояниями, юзерами, с нагрузкой и бизнес-логикой
Он должен быть так же архитектурно обоснован как и любой другой програмный продукт, иначе это необслуживаемое и не расширяемое говно
Почему веб то
Это просто здравый смысл

В сампе всё было едино, видимо потому что это был всегда монолит?
Я нихуя не знаю про PAWN особо, но примерно представляю насколько это было хуёво, это ж скриптовый язык, как это вообще можно сравнивать)
Бля, мне короче супер впадлу объяснять.

Web индустрия абсолютно срослась с ГТА мультиплеер сферой. Что по UI моментам, что по архитектуре. Покупаешь аптечку в 24-7, а тебе подкидывают Лоадер. Вы ахуели что ли? Я в игре должен ждать? Вот прикинь, ты играешь в Доту, и при покупке предметов тебе лоадер подкидывают. Или там скилл прожимаешь, а у тебя выскакивает нотифай окно "Успешно использование скилла" или такое же окно "Недостаточно маны". Что это вообще за хуита?
 

Inoi

/dev/null
Команда форума
Moderator
VIP
15 Окт 2020
3,900
1,926
208
35
Бля, мне короче супер впадлу объяснять.

Web индустрия абсолютно срослась с ГТА мультиплеер сферой. Что по UI моментам, что по архитектуре. Покупаешь аптечку в 24-7, а тебе подкидывают Лоадер. Вы ахуели что ли? Я в игре должен ждать? Вот прикинь, ты играешь в Доту, и при покупке предметов тебе лоадер подкидывают. Или там скилл прожимаешь, а у тебя выскакивает нотифай окно "Успешно использование скилла" или такое же окно "Недостаточно маны". Что это вообще за хуита?
А
Не ну тогда всё по факту
Что тут сказать
Именно это и будет происходить с геймлпеем через экспресс апи, кстати :roflanebalo:
 

enotit

Гений
High developer
BackEnd developer
13 Ноя 2020
1,568
494
187
21
Так вот, вообще тестовое - изрядно охуевшее
Как будто и да, и нет. В целом, со стороны "старших" ясны намерения посмотреть: знания sql на уровень ниже ORM, архитектурные /-аналитические умения, разбираться в ts.
Но, соглашусь, обосрались, ТыЗэ сырое. В целом то, делай / не делай - каждого воля. У меня с 21года висит "не делаю тестовые", когда чуваки за норм код предложили мне 25тр/мес, с учётом, что тех/со/тим/лид, СТО, дудец получает 35. ЗАТО! МАЙНДМАП НА ПОЛ КВАРТИРЫ. Хочешь узнать мои знания - велком в войс, распишу за всех.

Насчёт паттернов, то нет, веб и геймдев разные вещи. В вебе ты можешь мягко расположить рядом форточку, например, для мобилок. MVC в помощь. В геймдеве это не за чем. DI я тут слабо тоже представляю, либо какой это проект должен быть...
Фабрики можно сделать, не зная для чего нужен класс создатель по истине.
В вебе мы можем прикрыть левый глаз на оптимизацию (80% времени ресурсы на таймлайне лежат в запасе), в рейге нельзя.
Пересечения хорошо, но как по мне некоторые не догоняют "Зачем" (ни к кому это не относится, просто наблюдения за года).

Касаемо фабрик, спасибо, что подсветил, покекал.

я думаю, если хотим (как сообщество) использовать модные инструменты, то нужно развить геймдиз продукта. Так как, как по сему мало идей, чтобы хоть как-то привлечь инвестора. Просто мысли вслух.

проверки, основанные на том что "знает только клиент"
Я может из контекста выпал, но прикольный тейк давал жёлтый банк. Тезис: логику отдавали на клиент, но обрабатывали зашифрованный хеш, валидируя при этом только сумму. Если правильно помню, слушал с год назад. Но где тбанк и миндальРП (на базе Ra3.8).

Касаемо сообщений и игнора, то встану на защиту ТС.Бывает сидишь, работаешь, отвлекли - пропал.

Крайняя мысль, Серафим, а ты кто? ПМ же, не? Ты тренинги для ПМов не устраиваешь xD
 
Последнее редактирование: