Leaderboard

new Dungeon Test ... Suggestions are welcomed

new dungeon Test ... suggestions are welcomed

Привет да, временно убрали VIP Систему, перепишем её и запустим заново) Спасибо за интерес к нашей проблеме.

C# прост, да согласен C++ войдет в шарп быстро, а поймет ли он функциональность dotnet'a так, чтобы поддерживать на равне с плюсами не могу даже догадываться, т.к не работал. Если вы считаете что он прост и плюсовик легко за 1-2 дня разберётся, спорит не буду, поверю на слово. Но для меня это было бы странно) Основная кодовая база C++, а сервер на C#. Надо понимать, что тогда нужно повторять остальной код предназначенный для обеих сторон с C++ на C#. Мне кажется переводить сервер на C# из-за одного dotnet'a это серьёзный шаг) Имейте ввиду что за собой нужно тянуть odbc, libdbc, common. Последующая доработка может усложнить работу) А всё ещё усложнится в GameServer'e, где есть LUA, который может с сетью работать. Мне кажется вы не видите множество других проблем, рекомендую хорошо подумать. Сделаете, поймёте что придётся много дорабатывать, закончится свободное время и бросите проект. Имели мы опыт, когда приглашали C++ разраба специально на работу с серверами. Оказалось что человек хорошо знает Java и вообще раньше писал сервера на Java. Как только он меня не уговаривал переписать сервера на Java, аргументы типо быстрее, лучше, безопаснее да и вообще это круто отлетали быстро из-за простой бизнес модели о которой я говорил выше. Открывать вакансию в штате на должность, где у человека только 1 узконаправленная работа (сервер) - глупо, либо всё переписать на Java, либо придерживаться одной кодовой базы, чтобы доработка была проще. В соло весь проект не потащишь, а как начинаешь расширять команду появляется вопрос порога вхождения, требования и заработной платы. Брать C++ разраба с задачей идти разобраться с C#? Думали над этим, но пока не собираемся. Я бы не назвал основные города непрерывными, там нету караванов или других мероприятий. Только данжи, которые тоже нельзя назвать непрерывными. А даже если они и были, дамп слепка игрового мира и его загрузка с доп. логикой решит проблему непрерывности.

Ну такой себе аргумент. С++ разраб разберется с С# за 1-2 дня, а вот наоборот - это может быть проблема. У каждого свое видение на то, как оно должно быть Можно подставить любой язык - Java, Scala, Kotlin, golang и т.д. Вы с другими системами работали? Проблемы которые они успешно решаются в С++, в других системах просто не существуют. Хм.. доверяете ли вы платформе enterprise уровня на которой работают миллионы критичных сервисов? Ну да, доверяю. Доверяю JVM, доверяю golang, дотнету тоже доверяю. Почему нет то?) Ну молодцы. С сообществом, полагаю не поделились?) Мне он ничего не даст, возможно кому-то из разработчиков что-то подскажет. Обычная схема скейлинга, с микросервисами и т.д. Сам могу про такое долго рассказывать. WorldOfTank отлично скейлится, потому что там игровой процесс ограничен картами, которые существуют, пока идет игра. А вот когда мир непрерывный это совершенно иная задача. В рабочее время я занимаюсь системой подобной этой Вот тут почитать можно https://networking.docs.improbable.io/welcome/spatialos-concepts/offloaded-and-zoned-servers/ А в свободное решил заняться корсарами. В них есть что-то ламповое) Даже не знаю, как этот вывод получился. Выдержать DDOS = отразить DDOS. Это не ко мне, это к Вам.

Ну и по поводу DDos, защищать его на серверной стороне нынче глупо, ИМХО. Шаблонные TCP фильтры отобьют 90% атак различных стрессеров, остальные 10% нужно вкладывать в специфичный софт на стороне роутера и логику самого микросервиса коим наша пиратия и является (Gate, Group, Account, Game). Чтобы банально каждое новое подключение не вызывать конструктор на фулл класс клиента и закрывать общий пул мьютексом, а при большом количестве подключений распределять нагрузку между 2 и более первыми точками входа (Gate) через какой-нибудь load-balancer. Рекомендую посмотреть очень интересный ролик про микросервисную архитектуру World Of Tanks К слову мы в своё время переписали все сервера ( почти)) Гейм остался ) и запихнули их в докер и дальше в кубер с настройкой авто-скейлинга. Любой трафик просто распределиться между всем. Останется только 1, переписать гейм сервер чтобы не 1 карта - 1 гейм, а по координатам, с автозапуском если в эту локацию кто-нибудь заходит. И сервера готовы выдержать десятки тысяч клиентов. P.s на любом языке Но давать + dotnet'у за отражение DDos атак, такое себе))

свои небольшие пять копеек вставлю: 1. libdbc - по идеи 3rdparty library, которая должна быть и тут и там. При доработке сетевой части клиента - отдельно дорабатывать C# сервер.. Иметь C++ и C# разраба (если ты сам не делаешь и то и то) в штате в таком случае глупо, унификация кода экономит деньги и время. 2. Non boost asio - https://think-async.com/Asio/ 3. Мы перенести libdbc на linux и уже давно оттестировали. Всего 35 #ifdef _WIN32 во всём libdbc (включая udp сокет), при этом 8-15 - это отключить дебильный WSA от WinAPI. Буквально фулл день с тестами и последующие мелкие фиксы в процессе работы. Такой текст в защиту C# может написать только тот кто работал с dotnet долгое время и доверяет этой библиотеке. Тут осуждать считаю глупо, каждый Д**чет как он хочет ))

С одной стороны компиляторы для C++ дают высоко оптимизированный код и вроде как плюсы должны быть быстрее. Но, в реальности все гораздо сильнее зависит от того, как, где, когда и на чем будет работать код. Начнем с типа задач - есть IO (Input\Output) задачи и есть CPU задачи. В IO задачах почти не важно, насколько быстрый код - все зависит от задержек ввода\вывода при обращениях к БД, сети, файлам. Выигрыш, который дает оптимизированный компилятор тут будет вообще не будет на уровне погрешности из-за ожидания операций ввода\вывода. Применяя С++, Delphi, Go, Ocaml, .NET, Java, Rust мы получим одинаковое время работы. Если берем CPU задачу, то здесь выполнение зависит от применяемых алгоритмов, архитектуры и т.д. Ок, при прочих равных С++ в числодробилках будет быстрым. Насколько быстрым? - Неизвестно. Нужно поводить замеры, по крайней мере при работе с векторами, матрицами С++ будет очень быстрым, позволяет отлично векторизовать эти операции и тут с ним сложно сравниться. Поэтому 3D игрушки\драйвера\библиотеки для работы с графикой\алгоритмы CV(computer vision ) и пишут на плюсах - огромное кол-во матриц, векторов, и прочего требуется перемножать друг с другом. Гейт - это типичное IO приложение и его основная задача перекладывать из одного сокета байты в другой, делая небольшие операции над ними. Основная операция, которая тут будет - это копирование байтов из одного источника в другой - эти операции одинаково быстро выполняются в любом языке. Казалось бы - почему его на плюсах не написать? Вот тут и начинаются сложности с С++ - когда начинаем писать реальное приложение. Оказывается, что в С++ нет системы пакетов (которые почти в любом языке есть в XXI веке), поэтому нужно тащить кучу исходников в свой код что добавляет проблем при компиляции, когда у одного заводится, у другого - нет. Например нормальный логгер. Когда доходим до сетевой части - все ещё интереснее. В C++ нет дефолтной либы boost не предлагать для работы с сетью, есть только стандартный API сокетов, который работает так себе. 3к сокетов это предел для текущего гейта(теоретический предел 5к). Чтобы была возможность держать больше сокетов, чтобы операции выполнялись быстрее (вот то самое, что обеспечит ускорение для работы гейта) нужно прикручивать IOCP в windows, в linux - epoll тащить. Ну или прикручивать libuv. Затем, хорошо бы прикрутить метрики которые бы показывали текущую ситуацию на гейте, например на основе прометея. Когда все эти кусочки собираем в гейте, то получаем кучу кода, написанную в разных стилях, по разному инициализирующуюся, и как следствие - трудно поддерживаемую и понимаемую. Чтобы это все перенести на linux, нужно ещё кучу времени потратить на компиляторы gcc & clang и обмазаться @ifdef в куче мест. Если берем дотнет (C#), то у нас куча вещей идет из коробки - автоматическая поддержка windows\linux\macos для которой и напрягаться не нужно. Быстрые сокеты, которые смогут и DDOS атаку выдержать и кучу клиентов, асинхронный ввод\вывод. Пакеты, которые ставятся из хранилища пакетов и в них уже есть почти вся необходимая функциональность и гораздо меньшее количество кода, который реализует ту же логику на плюсах (да и писать на C# гораздо быстрее чем на С++). Отсутствие всяких проблем с переполнениями буферов, порчей памяти, с неинициализированными значениями и т.д.. На порядки лучшая диагностическая информация. Я не говорю о медленных строках в С++ и медленном аллокаторе памяти из коробки. И еще один важный момент - код очень похож на С++ который в сообществе знают. Ну я не говорю уже о том, что многие вещи гораздо быстрее\лучше и безопаснее на C# реализовываются при высокой скорости работы.

Привет. А зачем писать новый гейт на шарпе? Он нативно будет работать медленнее плюсов. Если уж и решитесь переносить всё это дело и обновлять, не имеет ли больше смысла переписать на модернизированном с++?

Разве то что я сказал касается геймплея? Геймплей мне как раз очень нравится, замечательная игрушка, с интересной прокачкой. Именно благодаря этому я и решил привести сервер в нормальное состояние. Эта игрушка с душой. С клоуном может и перегнул. Но. Желание это все отрефакторить никак не связано с тем, что испытываешь, когда это все рефакторишь. Совершенно не связанные друг с другом вещи. Комментарии про горящую жопу еще будут - она у всех горит, когда видишь определенные места. Это только начало - приведение проекта в стадию, когда он может хотя бы по человечески запускаться, билдится и стартовать. Я собираюсь по всем сомнительным моментам отдельно пройтись подробными комментариями почему так не надо и как надо. Есть несколько тем: Сетевая часть Внутренняя логика парсинга пакетов, сетевых вызовов и т.д. Протокол Передача параметров, контроль границ, вывод содержимого, формат Пул команд, буферов, подсчет ссылок, reader's & writer's Поддержка нескольких протоколов, легаси и т.д. Шифрование Защита от повторной пересылки пакетов Защита от просмотра пакетов Защита от DDOS Сетевое общение серверов Варианты топологии Варианты технологий обмена Логирование Текстовые логи Игровые события База данных Оптимизация ORМ для работы Хранение ресурсов, шмоток, индексы, статистика, ключи и т.д. Работа со шмотками (транзакционность, как избавиться от дюпа) Работа с гильдиями и группами Чат Локализация в игре Магия Карты, перемещение Работа с Lua С какой начать? P.S. Нужно чтобы кто-нибудь посмотрел клиент и добавил необходимые ресурсы, да и вообще запустил и посмотрел, насколько он хорошо работает. Потому что он глючит периодически (возможно в процессе рефакторинга могло что-то перестать инициализироваться, так как оно по ошибке инициализировалось)

_UpdateObjHeightmap function inside mpmapeditor suppose to do that when you click f9

Dicas para criar um tópico em "Dúvidas & Ajuda" Olá! Neste tópico darei alguns conselhos que podem te ajudar a obter uma resposta rápida e direta para sua pergunta. (Traduzido do tópico Tips for making a topic in "Questions & Help"). 1. Use a pesquisa do fórum! Você pode tentar traduzir sua pergunta ou partes da sua pergunta para o inglês e usar a ferramenta de busca. Muitos erros são recorrentes e já foram solucionados anteriormente. Para uma busca mais restrita, lembre-se de selecionar a seguinte opção: 2. Formule o problema de forma clara e explícita. O nome do tópico deve refletir o problema. Nomes genéricos como "Ajuda!", "Erro", "Preciso de ajuda" não são permitidos, bem como o abuso de pontos de exclamação. Alguns exemplos de nomes adequados: "Erro conectando o GameServer ao SQL Server", "Script do NPC não funciona", "Como criar um novo item?". 3. Articule o problema de forma clara. Tente deixar o texto da sua dúvida o mais claro possível para que outros membros possam te ajudar. Descreva o problema em todos os detalhes, fornecendo os passos para reproduzir o problema e quais arquivos/programas está utilizando. Um texto bem articulado já contém metade da resposta. Capturas de tela do problema também são bem-vindas. 4. Seja paciente. Após criar um tópico, seja paciente enquanto espera uma resposta. Não 'bumpe' o tópico muito frequentemente e não peça ajuda imediata. Enquanto espera por ajuda, você pode tentar resolver o problema sozinho e/ou atualizar seu tópico com informações adicionais, que podem auxiliar outros membros a descobrir o problema. 5. Certifique-se que seus executáveis rodam em outros PCs. Durante a resolução de um problema, pode ser que você compartilhe seus executáveis com outros membros. Nestes casos, é importante que você deixe claro todos os passos extras necessários para a execução do seu programa. Por exemplo, você pode ter alterado o argumento de inicialização "startgame" para "iniciarjogo". O mesmo pode acontecer com uma porta de conexão alterada ou uma .dll faltando. Além disso, fornecer um escaneamento do VirusTotal junto ao tópico pode convencer membros a baixarem seu executável e testá-los em suas máquinas. 6. Não mande mensagens diretas (DMs/PMs, Skype, Discord, etc.) para outros membros pedindo ajuda. Não importune outros membros com mensagens diretas contendo perguntas para resolução de problemas. Todos temos nossas outras atividades e, ao manter as perguntas nas seções adequadas, garantimos que outros membros poderão acessar as respostas no futuro. 7. Use o botão de "Obrigado" para agradecer outros participantes. Ao final de todo post existe um botão que pode ser utilizado para agradecer outros participantes por colaborações importantes. Fazendo isso, você recompensa outro membro pelo tempo investido, mostra seu agradecimento e instiga outros usuários a participarem das discussões. Use com sabedoria!