Комментарии 47
А покажите машинки для ВКонтакта? Мы тоже делали машинки для ВКонтакта на Unity. :)
Перевозчик К сожалению, на данный момент его разработка заморожена.
А в демку то поиграться охота…
Непонятно, почему (если участвовал админ ру-коммунити) не было рассмотрено вот это: unity3d.ru/distribution/viewtopic.php?f=17&t=7429?
Так ведь сайт этого решения появился только в феврале этого года. Соответственно, на момент начала поиска данного движка еще не было в природе. Кроме того, если проект коммерческий, а не для себя, то всегда лучше выбирать решения проверенные временем, с хорошей поддержкой, коммьюнити, доками и т.д. и т.п.
А не смотрели в сторону protobuf/thrift/asn.1?
Эти технологии отлично решают задачу сериализации.
Особенно в геймдеве где довольно сложная логика и модель данных.
Эти технологии отлично решают задачу сериализации.
Особенно в геймдеве где довольно сложная логика и модель данных.
Сейчас точно не скажу. По-моему про protobuf и т.п. мы вспомнили уже после того, как запилили свою тулзу.
Просто там очень удобно получается. Описываются все объекты игровой логики, после чего можно, например, сделать автогенерацию кода для редактора статических данных, или для вэб интефейса редактирования игроков. В результате получается, что для добавления нового параметра (допустим игроку) надо написать только одну строчку в описании модели, остальное само поддтягивается)
Круто! У нас сейчас именно так и есть для данных, которые бегают по сети. Но эти данные в самой игровой логике постоянно не используются. Только для транспорта. В игровой логике в подавляющем большинстве случаев постоянно присутствуют другие классы, с другим набором данных.
Ну вот как раз унификация типов данных очень упростила разработку.
Мы всё сетевое взаимодействие строили по модели: запрос -> ответ(большей частью только статус: ок/не ок) + список эвентов.
Эвенты тоже были объектами модели данных и в них были все изменения.
Также сохраняли в базу в сериализованном виде.
Мы всё сетевое взаимодействие строили по модели: запрос -> ответ(большей частью только статус: ок/не ок) + список эвентов.
Эвенты тоже были объектами модели данных и в них были все изменения.
Также сохраняли в базу в сериализованном виде.
Я очень плохо представляю, как это можно унифицировать. Например, игрок стреляет из пушки. По сети передается только айдишник игрока и айдишник пушки. Сами классы игрока и пушки по сети не передаются. В нашем случае, это отдельный прокси-класс, который состоит из 2х айдишников и больше ничего не знает про классы игровой логики.
Выстрел — это эвент, в котором параметры примерно следюущие: кто, куда, чем и как.
Этот эвент передаётся по сети всем заинтересованным (кто в области видимости) игрокам.
Далее выстрел долетает до цели, генерируется эвент «попадание выстрела», который состоит из эвента «дамаг» и взрыв". Аналогично передается всем. Клиенты отрисовывают взыв.
Примерно так.
А полностью объекты передаются не часто, например, при заходе игрока в игру.
Этот эвент передаётся по сети всем заинтересованным (кто в области видимости) игрокам.
Далее выстрел долетает до цели, генерируется эвент «попадание выстрела», который состоит из эвента «дамаг» и взрыв". Аналогично передается всем. Клиенты отрисовывают взыв.
Примерно так.
А полностью объекты передаются не часто, например, при заходе игрока в игру.
В общем, мы про одно и тоже, только по разному. У нас, как это ни странно, все работает так же :)
Античит закладывали в архитектуру? Как контролируются игровые параметры на клиенте?
По минимуму. Здесь очень важно соблюсти баланс, чтобы из-за разработки всех античитов не увеличить сроки общей разработки вдвое.
А вы не боитесь если в какой-то момент читеры поломают полностью экономику игры? Мне кажется это очень важно, важнее чем скорость разработки.
Экономику читы никак не сломают, вся экономика на сервере. А вот бой испортить — это да. Тут уж постараемся по максимуму обезопасить остальных игроков от читеров.
Сервер есть машина (в идеале), которая рассчитывает только Ваш сервер и все. Сейчас вполне можно взять i7 о восьми ядрах с 24 гигами оперативки за 3-4 т.р. Экономить на операции проверки валидности данных — в пользу бедных. Напишите сначала то, что надо, а оптимизировать будете потом.
Больше похоже на то, что возиться просто было лень
Больше похоже на то, что возиться просто было лень
Зачем так ценник завышать? 2 килорубля за вот этот тариф (сам на таком сижу).
Проверка валидности — это одно, и мы ее конечно будем делать. А вот всю физику на серваке считать это уже другое. Тут среваков не напасешься.
А dead reconing, сглаживание и прочее вы писали вручную?
Что есть dead reconing? Ослабление цветов после смерти? Не помню точно, то ли юзали что-то готовое, то ли удаленщик нам сделал этот эффект.
Сглаживание — несмотря на то, что есть уже готовые шейдера для Anti Aliasing'a, тот же самый удаленщик написал нам отдельный шейдер для AA, по мотивам того, что используется в Скайриме, по-моему.
Сглаживание — несмотря на то, что есть уже готовые шейдера для Anti Aliasing'a, тот же самый удаленщик написал нам отдельный шейдер для AA, по мотивам того, что используется в Скайриме, по-моему.
Лол, нет, я про сеть. Сглаживание (smoothing) это интерполяция между текущей трансформацией объекта и новой пришедшей по сети, dead reconing это экстраполяция трансформации в ожидании следующего обновления. Необходимая вещь, так как частота обновления картинки на экране намного выше частоты обновлений из сети. Или у вас машинки стоят между получением пакетов и телепортируются на новое место с каждым апдейтом?
Я спросил, потому как это достаточно нетривиальные алгоритмы, а Смартфокс, кажется, сам не поддерживает таких вещей, занимаясь, грубо говоря, только доставкой пакетов.
Я спросил, потому как это достаточно нетривиальные алгоритмы, а Смартфокс, кажется, сам не поддерживает таких вещей, занимаясь, грубо говоря, только доставкой пакетов.
Присоединяюсь. Очень животрепещущие вопросы.
Статья из разряда «как я провел это лето». Насколько я понял, приложение тестировалось только локально, с коннектом «клиент-сервер» в локалке с 100 Мб/с, с отсутствием потери пакетов и прочего. Не рассмотрены вопросы, которые обязательно возникнут в реальной жизни, тем более что для MMO FPS вопрос синхронизации — первичный. Как бы не был красив клиент — с неотлаженной сетью это полная хрень
1. Вы поняли неправильно. Сервер изначально был не в локалке, альфатестирование на данный момент в самом разгаре и на лаги синхронизации никто еще не жаловался.
2. Вопросы синхронизации положения машинок — это отдельная огромная статья, которую когда-нибудь может и напишу. Цели осветить этот вопрос в данной статье не стояло.
3. Как бы не был красив клиент — с неотлаженной сетью это полная хрень. Обратное утверждение так же верно. Со стремным клиентом и идеально отлаженной сетью это тоже будет полная хрень. В реальной жизни приходится соблюдать баланс, и откладывать многие вещи до тех пор, пока не всплывет необходимость ими заниматься.
2. Вопросы синхронизации положения машинок — это отдельная огромная статья, которую когда-нибудь может и напишу. Цели осветить этот вопрос в данной статье не стояло.
3. Как бы не был красив клиент — с неотлаженной сетью это полная хрень. Обратное утверждение так же верно. Со стремным клиентом и идеально отлаженной сетью это тоже будет полная хрень. В реальной жизни приходится соблюдать баланс, и откладывать многие вещи до тех пор, пока не всплывет необходимость ими заниматься.
освещение вопросов того, как добиться приемлемых показателей по плавности изменения положений, как обрабатывать «честный» выстрел, который пришелся на момент лага, и прочее — гораздо более интересная статья. Ну или по крайней мере must have в анонсе.
Юнити, предоставляя возможность работать по сути с .NET, может использовать стандартные механизмы передачи данных. Построение серверной архитектуры — тот еще, конечно, вопросец, но в принципе ничего невозможного нет, достаточно полопатить MSDN. А вот вопросы синхронизации — гораздо глобальней.
Теперь что касается обратного утверждения. На данный момент я, волею свербения в заднице, так же пишу нечто подобное Вашему проекту. Но, до тех пор, пока не утверждена работа с сетью, я вообще не полезу в графику. Пофиг, что у меня по полю, залитому единой текстурой, катается нечто прямоугольное. Когда оно будет делать то, что ему сказано, и так, как ему сказано, а так же работать по сети и при этом не лагать, когда я напишу приложение — тест, которое создаст несколько тысяч подключений, раскидаю его по удаленным серверам и по знакомым и оттестирую под нагрузкой — вот тогда, и только тогда я начну заниматься графикой и присандаливать модели. И это правильно — сложно ожидать какого либо успеха в случае, когда одни из самых важных вопросов не выверены до конца
Юнити, предоставляя возможность работать по сути с .NET, может использовать стандартные механизмы передачи данных. Построение серверной архитектуры — тот еще, конечно, вопросец, но в принципе ничего невозможного нет, достаточно полопатить MSDN. А вот вопросы синхронизации — гораздо глобальней.
Теперь что касается обратного утверждения. На данный момент я, волею свербения в заднице, так же пишу нечто подобное Вашему проекту. Но, до тех пор, пока не утверждена работа с сетью, я вообще не полезу в графику. Пофиг, что у меня по полю, залитому единой текстурой, катается нечто прямоугольное. Когда оно будет делать то, что ему сказано, и так, как ему сказано, а так же работать по сети и при этом не лагать, когда я напишу приложение — тест, которое создаст несколько тысяч подключений, раскидаю его по удаленным серверам и по знакомым и оттестирую под нагрузкой — вот тогда, и только тогда я начну заниматься графикой и присандаливать модели. И это правильно — сложно ожидать какого либо успеха в случае, когда одни из самых важных вопросов не выверены до конца
Да, конечно, вопрос максимально точной синхронизации большой и интересный. Возможно, когда мы пройдемся по нему вдоль и поперек, я и напишу про это статью. Но раз уж Вы этим сами сейчас занимаетесь, буду рад почитать статью про ваши изыскания в данном вопросе.
«Построение серверной архитектуры — тот еще, конечно, вопросец, но в принципе ничего невозможного нет, достаточно полопатить MSDN. А вот вопросы синхронизации — гораздо глобальней.»
С одной стороны да. С другой стороны, Смартфоксы пилят свой серверный движок уже больше 8 лет. Не хочется с нуля повторять их опыт, читая мсдн, поэтому я за то, чтобы использовать готовые движки.
По поводу третьего пункта — если человек, который оплачивает Вашу разработку согласен на такой план, то нет проблем. Но чаще всего никто не согласится увеличивать разработку проекта на несколько месяцев (и соответственно платить всей команде зарплаты) только для того, чтобы некоторый процент игроков с лагающей сетью чувствовал себя комфортней. Звучит немного грубо, но это суровая правда жизни. Если у Вас не так — то это здорово, надеюсь Ваша синхронизация будет самой безглючной.
«Построение серверной архитектуры — тот еще, конечно, вопросец, но в принципе ничего невозможного нет, достаточно полопатить MSDN. А вот вопросы синхронизации — гораздо глобальней.»
С одной стороны да. С другой стороны, Смартфоксы пилят свой серверный движок уже больше 8 лет. Не хочется с нуля повторять их опыт, читая мсдн, поэтому я за то, чтобы использовать готовые движки.
По поводу третьего пункта — если человек, который оплачивает Вашу разработку согласен на такой план, то нет проблем. Но чаще всего никто не согласится увеличивать разработку проекта на несколько месяцев (и соответственно платить всей команде зарплаты) только для того, чтобы некоторый процент игроков с лагающей сетью чувствовал себя комфортней. Звучит немного грубо, но это суровая правда жизни. Если у Вас не так — то это здорово, надеюсь Ваша синхронизация будет самой безглючной.
Статью про изыскания в данном вопросе написать можно, но на данный момент я не ставлю перед собой таких задач. С одной стороны, мне откровенно лень это делать, с другой — я не уверен, что готов поделиться знаниями ввиду того, что знаний этих пока не достаточно. Как только наберусь граблей — не вопрос.
Выбор готового движка или работа над своим — вопрос религии. Я свой движок пилю уже 3 года, при том что он трудится в нескольких сетевых проектах, как игровых, так и бизнес-приложениях.
Ну и по поводу третьего — с чего Вы решили, что мне кто то платит? :)
Ну а что касается заказчиков — то тут вопрос спорный. Я всегда на предварительных переговорах говорю, что что то играбельно-тыкательное появится только по прошествии трети срока разработки. Как правило никто не спорит.
Выбор готового движка или работа над своим — вопрос религии. Я свой движок пилю уже 3 года, при том что он трудится в нескольких сетевых проектах, как игровых, так и бизнес-приложениях.
Ну и по поводу третьего — с чего Вы решили, что мне кто то платит? :)
Ну а что касается заказчиков — то тут вопрос спорный. Я всегда на предварительных переговорах говорю, что что то играбельно-тыкательное появится только по прошествии трети срока разработки. Как правило никто не спорит.
Надеюсь, что таки напишете. Когда в начале разработки гуглил поверхностно по этому вопросу ничего сверх полезного не нашел.
Ну, если вы пилите свой движок серверный (хотя может и не только серверный), то там всем сетевым вопросам должно быть уделено самое тщательное внимание, и на этом экономить конечно нельзя.
Ну, если вы пилите свой движок серверный (хотя может и не только серверный), то там всем сетевым вопросам должно быть уделено самое тщательное внимание, и на этом экономить конечно нельзя.
Тут опять же — что такое движок?:)
Под движком в данном случае я подрузамеваю механизмы передачи данных. Если о них — то да, кочует из проекта в проект, обросло проверками, подтвердило стабильность и прочее.
Если брать логику (в бизнесе — бизнес-логику), то она уникальна. В движках решается скриптами, но по мне — так проще отлаживать чистый код, чем какие то непонятные скрипты, тем более что доступ к функциям прост и понятен.
Для FPS наиболее сложным является расчет внешнего мира и взаимодействия с ним. Вот тут — вопрос баланса между производительностью и достоверностью вычислений. Я как правило делаю так — пишу то, как хочется, потом через анализатор получаю данные о быстродействии выполнения методов, и если меня что то не устраивает — начинаю оптимизировать. Да, этот метод долог и может быть коряв, но это позволяет получить стабильный, полностью прозрачный и отвечающий всем задачам код.
Под движком в данном случае я подрузамеваю механизмы передачи данных. Если о них — то да, кочует из проекта в проект, обросло проверками, подтвердило стабильность и прочее.
Если брать логику (в бизнесе — бизнес-логику), то она уникальна. В движках решается скриптами, но по мне — так проще отлаживать чистый код, чем какие то непонятные скрипты, тем более что доступ к функциям прост и понятен.
Для FPS наиболее сложным является расчет внешнего мира и взаимодействия с ним. Вот тут — вопрос баланса между производительностью и достоверностью вычислений. Я как правило делаю так — пишу то, как хочется, потом через анализатор получаю данные о быстродействии выполнения методов, и если меня что то не устраивает — начинаю оптимизировать. Да, этот метод долог и может быть коряв, но это позволяет получить стабильный, полностью прозрачный и отвечающий всем задачам код.
Ясненько. Я видимо разбалован такими движками, как Юнити и Смартфокс и под термином движок понимаю нечто большее, что позволяет абстрагироваться почти полностью от глубин стевого транспорта, или обсчета физики и рендеринга и сосредоточиться непосредственно на создании игровой логики. Хотя и при наличии данных замечательных движков процесс разработки все равно получается не быстрым.
Смартфокс это чисто сетевой двиг… там мало чего облегчается при разработке… и совсем не позволяет абстрагироваться почти полностью от глубин стевого транспорта… Из игровых абстракций там только комнаты. Ни вопросы физики, ни вопросы рендеринга он не решает. Обо всем этом вам придется заботится самому…
В общем реализует исключительно обмен сообщениями между сервером и клиентом. Ну да, упрощает работу с комнатами/зонами, они там уже есть.
На netty+protobuf аналог пишется примерно за месяц…
Тесты которые они приводят у себя на сайте, сравнивая netty и свой bitswarm очень древние, на сегодня netty если и не на много быстрее, то уж точно не медленнее.
За то открытые исходники спасут в ситуации, когда наткнетесь на какую-то проблему и сервис покупного движка может вам днями а то и неделями фиксить проблемы…
В общем для себя я выбрал этот вариант… он полностью развязывает руки разработчикам.
В общем реализует исключительно обмен сообщениями между сервером и клиентом. Ну да, упрощает работу с комнатами/зонами, они там уже есть.
На netty+protobuf аналог пишется примерно за месяц…
Тесты которые они приводят у себя на сайте, сравнивая netty и свой bitswarm очень древние, на сегодня netty если и не на много быстрее, то уж точно не медленнее.
За то открытые исходники спасут в ситуации, когда наткнетесь на какую-то проблему и сервис покупного движка может вам днями а то и неделями фиксить проблемы…
В общем для себя я выбрал этот вариант… он полностью развязывает руки разработчикам.
Сглаживание писали сами, машинки конечно же не телепортируются на каждый апдейт позиции. За основу взяли набросок скрипта то ли из демки юнити какой то, то ли из просторов сети, и изрядно ее допилили.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Клиент-серверное общение в Unity3d