Здравствуйте, retalik, Вы писали:
R>"Как не надо". R>Фактически, на каждом компьютере запускалась самостоятельная игрушка...
Сетевая игра всегда является компромиссом. Между динамикой игровых объектов (быстродействием) и синхронизацией их действий во всех экземплярах игры, между загруженностью канала связи и временем реакции на событие, ... Можно долго перечислять эти компромисы, их состав и баланс будет зависеть от игры: её жанра, самого игрового процесса. Последним в списке будет компромис между желаниями и возможностями реализующего сетевую подсистему игры программиста.
Считается, что просчитывать и воспроизводить графику — святая обязанность игрового движка. Но вот про расчёт физики игрового мира тоже забывать не стоит, если игра динамичная, то эти действия будут занимать немалое время работы процессора. Удачный движок должен красиво всё рисовать, просчитывать физику взаимодействия игровых объектов и иметь запас времени на всякий случай: на обмен информацией по сети, обработку ввода игрока, действия операционной системы и др. всякие случайности.
Использованный в игре описанный метод не так уж и неудачен (порочен). Надо просто правильно подойти к физике игрового мира. Например, учёту и квантованию времени в условных единицах, достаточных для динамичности, но далёких от предельного разрешения таймеров. Например, учёту координат объектов в условных единицах, далёких от разрешения экрана. Скажем, применительно к обсуждаемой игре, известны начальное положение, направление, ускорение и скорость движения самолёта. Их не нужно передавать всем игровым клиентам, обеспечивая тем самым синхронизацию. Достаточно передать эти данные вначале, и далее каждый клиент сумеет правильно, с учётом физики, нарисовать положение самолёта на каждый момент времени. Но если игрок дёрнул за рычаг и изменил положение элеронов (или что там меняет направление полёта), добавил или убавил газ (изменил ускорение — скорость движения) или не дай бог нажал на гашетку (породил один или несколько новых игровых объектов), тогда по сети полетят пакеты модификации игрового мира. Должны полететь. И должны гарантированно успеть долететь до всех игровых клиентов за принятый в игре квант времени. Иначе новое положение будет воспроизведено клиентами некорректно. Это проблема всех динамичных игр — пропускная способность сети, модель распространения информации об изменениях (от одного всем, от каждого из оповещённых кому-то из неоповещённых, ...).
Чем меньше информации передаётся по сети, тем меньшая пропускная способность будет задействована, тем выше будет быстродействие коммуникаций, но большая доля работы ляжет на плечи конкретного экземпляра игры (конкретного компьютера, процессора, видеопроцессора и т.п.)
Всегда надо искать компромисс: увеличивать квант времени, увеличивать загрузку сети... Да и сеть — среда сама по себе непостоянная. То потухнет, то погаснет...
R>... на каждом компьютере все события обсчитывадись самостоятельно. Поэтому был возможен такой сценарий: R>
R>На машине_1 выпущен снаряд. Он тут же добавлен в список объектов на машине_2.
R>Снаряд прошел на расстоянии в 1 пиксель от самолета по рассчетам на машине_1, но достиг самолета на машине_2
R>(скажем, частота обсчета была чуть иной).
R>
Тут просто надо было перейти от зависимых от аппаратуры (разрешения экрана) единиц к независимым, например, от пикселей к метрам. И столкновения считать с точностью до метра, грубо говоря. Если обеспечивается присутствие в одинаковых координатах в определённый квант времени нескольких объектов — значит, они столкнулись. Нужна реалистичность — переходим к меньшим единицам — сантиметрам. Для вывода на экран пересчитываем их в пиксели. Коэффициент пересчёта может быть самым "непредсказуемым". Даже один к одному.
Если на каждом компьютере таймеры ну очень сильно расходятся и сбивают физику (из-за выбранного малого кванта игрового времени, чтобы соответствовать физике игрового мира) — придётся посылать синхроимпульсы "точного времени" (специальные пакеты, содержащие само время или просто признак его изменения) от одного "эталона" (рядового экземпляра игры) самому себе и другим игровым клиентам. Помните: "Начало шестого сигнала соответствует пятнадцати часам..." Всё давно уже придумано и валяется под ногами. Только глаза пошире успевай открывать...
R>"Как надо" R>Да все очень просто: клиент-сервер.
Просто, да не просто. Удобно для одних жанров — неудобно для других. Если ИИ настолько нелинеен, что его действия на каждом компьютере будут разными — значит его надо расчитывать в одном месте и оповещать остальных. Либо изменить его поведение так, чтобы он вёл себя одинаково при одних и тех же начальных условиях на разном оборудовании. Скажем, для стратегий клиент-сервер идеален, особенно пошаговых, т.к. нет жесткого квантования состояния игрового мира по времени. Хотя и здесь не помешало бы одинаковые для всех экземпляров игры действия не рассылать, а воспроизводить.
Другой аспект пошаговых стратегий заключается в том, что пока игрок думает, как походить, процессорные мощности простаивают, тратя ничтожную (или иногда чтожную, но не оправданную) мощность на ожидание и обслуживание ввода игрока. И только потом грянет гром, и ИИ зашевелится. А ведь за время хода (мыслительного процесса) живого человека ИИ вполне может расчитать свой ход. Иногда даже неоднократно. Реалтаймовые стратегии в этом плане более критичны. Они либо должны успевать за квант времени пересчитать все действия ИИ (поэтому и соперников мало, иначе они тупеют, и берут они человека не умением, а числом), либо иметь возможность за квант времени выбрать приоритеты, оценить критичность ситуации, и обработать критичную часть. А полный цикл просчёта действий ИИ провести за конечное число квантов времени.
Почти как человек, если его (человека) привлечёт какой-нибудь фрагмент игрового мира (карты, город, скопление юнитов, ...), то в другом месте хоть трава не расти. Это вроде как называется концентрацией внимания, и ИИ тоже может и должен уметь внимание концентрировать. И как и человеку, ИИ может не хватать кванотов времени на обсчёт всего и вся.
Ну а вернувшись к обсуждаемой игре могу сказать, что не всегда может хватить быстродействия на цепочку: ввод клиента — на сервер — обсчёт всех клиентов — возврат на клиента — новое положение — отрисовка — ввод клиента.
Для динамичных игр надо искать пути сокращения временных и пр. затрат на эту цепочку, а то и исключать те или иные звенья.
Всё высказано не в претензии на абсолютное знание, но обсуждения ради...
Я рад, что обсуждение пошло в плодотворном ключе. Можно и поспорить .
[Очевидности пропущены]
A>Но если игрок дёрнул за рычаг и изменил положение элеронов (или что там меняет направление полёта), добавил или убавил газ (изменил ускорение — скорость движения) или не дай бог нажал на гашетку (породил один или несколько новых игровых объектов), тогда по сети полетят пакеты модификации игрового мира. Должны полететь.
Мысль понятна, и этот принцип вполне можно использовать для распределения вычислительной нагрузки с сервера на всех клиентов. Главное только вслух сказать: "кванты синхронизации" должны доставляться всем участникам игрового процесса и в том случае, если они содержат принципиально новую информацию. Например, послан новый снаряд, где-то скрипт создал новый объект, кто-то из участников убит. Такие события нельзя отдавать на откуп самостоятельным вычислениям — они повлияют на все дальнейшие события.
Такое решение применяется и в оптимизированном для модемов коде в современном мультиплеере. Скажем, в Q3 игрок с высоким пингом "проскочит" на своем компьютере выстрел из рейлгана и свернет за угол, но сервер пришлет ему информацию, что он-таки убит. Расчеты расчетами, но здесь уже дело рисованием не ограничивается: надо фраги считать
A>Тут просто надо было перейти от зависимых от аппаратуры (разрешения экрана) единиц к независимым, например, от пикселей к метрам. И столкновения считать с точностью до метра, грубо говоря. Если обеспечивается присутствие в одинаковых координатах в определённый квант времени нескольких объектов — значит, они столкнулись.
Для меня очевидно, что при любой системе счета будет разница в результате, если вычислительная мощность или лаг сильно различаются. Обмен информацией о состоянии неизбежен!
Другой аргумент — читерство. Недобросовестный игрок может модифицировать код клиента и, например, "всегда стрелять первым". Если сервер не пресечет такое — налицо либо рассинхронизация, либо обман.
A>придётся посылать синхроимпульсы "точного времени" (специальные пакеты, содержащие само время или просто признак его изменения) от одного "эталона" (рядового экземпляра игры) самому себе и другим игровым клиентам.
Так зачем все-таки посылать синхроимпульсы времени, если есть "вехи"-события?
A>А ведь за время хода (мыслительного процесса) живого человека ИИ вполне может расчитать свой ход. Иногда даже неоднократно.
А вот это очень хорошая мысль. Опять таки, с оглядкой на синхронизацию. "Мысли" AI вполне можно отдать на откуп клиентам — пока этот AI не нажал на гашетку При этом мы разгружаем сервер, но не создаем рассогласований.
A>Ну а вернувшись к обсуждаемой игре могу сказать, что не всегда может хватить быстродействия на цепочку: ввод клиента — на сервер — обсчёт всех клиентов — возврат на клиента — новое положение — отрисовка — ввод клиента.
Ну обсчет всех клиентов — дело обязательно централизованное. Обратных примеров не знаю. Есть такие?
А все остальное, действительно, поддается распределению. Можно, например, оптимизировать трафик, посылая клиентам индивидуальные "выжимки" -только из видимых объектов, например. Хотя, опять же, это где у нас такой трафик дорогой?
A>Всё высказано не в претензии на абсолютное знание, но обсуждения ради...
Здравствуйте, retalik, Вы писали:
R>Я рад, что обсуждение пошло в плодотворном ключе. Можно и поспорить .
Спорить пока незачем, можно и просто пообщаться и поделиться знаниями.
Я лично специализируюсь на стратегиях и конкретно пошаговых стратегиях, но играю в разные игры. И иногда интересно бывает, как они устроены...
R>..."кванты синхронизации" должны доставляться всем участникам игрового процесса и в том случае, если они содержат принципиально новую информацию. Например, послан новый снаряд, где-то скрипт создал новый объект, кто-то из участников убит. Такие события нельзя отдавать на откуп самостоятельным вычислениям — они повлияют на все дальнейшие события.
Я это и имел ввиду. Что для реалтаймовых игр следует линейное неприрывное время отквантовать (разбить на кусочки, дискретизировать) таким образом, чтобы у играющих сохранился эффект непрерывности, но за выбранный шаг дискретизации каждый из участников игрового процесса гарантированно бы получал информацию о изменениях в игровом мире.
R>...в Q3 игрок с высоким пингом "проскочит" на своем компьютере выстрел из рейлгана и свернет за угол, но сервер пришлет ему информацию, что он-таки убит. Расчеты расчетами, но здесь уже дело рисованием не ограничивается: надо фраги считать
А с чего он проскочит, если мы дискретизируем время? Только сначала предположим, что всё в "стерильных" условиях, без модификации кода, чита и пр. Высокий пинг позволяет принять/передать пакет, а дальше игровой мир должен ждать прихода следующего кванта времени, чтобы изменить мир, прореагировать на ввод игрока и т.п. Быстрый компьютер справится с задачей отрисовки нового состояния игрового мира играющему, опросит ввод, сеть, возможно, просчитает ИИ, и даже может послать себе и другим пакеты изменения игрового мира, но должен ждать кванта, чтобы начать реагировать на изменения. Те же, кто пыхтеть будут из последних сил, чтобы в квант времени уложится со всеми действиями — и будут определять минимальные требования к игре, ниже которых играть уже нельзя.
Вопрос в том, как поступить — просто написать, что играть нельзя, или же потестировать возможности играть на конретной аппаратуре, и тоже оповестить, или же реализовать возможности пропуска квантов времени, что будет выражаться, например, в эффекте листания картинки на экране...
Есть ещё один интересный аспект — увеличение игровых объектов и их отсечение по области видимости для конкретного игрока. Тут будет правильнее не поддерживать полностью состояние такого игрового мира на всех клиентах, а наоборот переложить всё на сервер, а клиентам выдавать только то, что им видно и полезно для принятия решений живыми игроками. ИИ тоже может функционировать с учётом области видимости, и не обязательно только на сервере, где известно всё_обо_всём.
Такой пример. Халва, я и двое в комнате с одной дверью, за которой коридор, в коридоре пятеро, дверь закрыта. Я командую "посмотреть направо, посмотреть налево". Что оптимальнее — передать на сервер, который передаст мои действия всем, или пусть посчитает видимость и передаст только двоим, что рядом, или же я передам инфу тем, кто рядом напрямую, да и то если они лицом ко мне стоят. А вот кто кого видит — будет говорить сервер, ему я буду посылать координаты и вектор направления лица (и другие будут).
R>Для меня очевидно, что при любой системе счета будет разница в результате, если вычислительная мощность или лаг сильно различаются. Обмен информацией о состоянии неизбежен!
Вот и идея в том, что в квант времени должны укладываться все необходимые расчёты. В выборе этого кванта для конкретных требований к игре и её физике.
R>Другой аргумент — читерство. Недобросовестный игрок может модифицировать код клиента и, например, "всегда стрелять первым". Если сервер не пресечет такое — налицо либо рассинхронизация, либо обман.
Тут как обычно, три пути.
Один — скрывать информацию (данные) от простого изменения в памяти. Для динамических игр отсутствие отклика от играющего в течении кванта времени уже повод для прерывания игры, т.к. не соответствует минимальным требованиям. Нет мгновенных сканеров ОЗУ, которые ещё и позволяют мгновенно модифицировать ОЗУ нанужный лад. Остаётся только модификация кода.
И тут есть Второй путь. Вычислять контрольные суммы, версии кода, при начале игры их сверять и допускать в игру или не допускать.
Дополнительно можно согласовывать всякие коэффициенты (скорость пуль, торпед, движения игроков) однотипных игровых объектов на всех игровых клиентах по одному из клиентов, например, тому, кто создал игру. Тогда что бы ты не поменял в настроечках (если поменял), оно будет перезаписано. А если замешкаешься с реакцией на квант времени (захочется модифицировать обратно) — тебя кинут по несоответствию по минимальным требованиям по быстродействию.
R>Так зачем все-таки посылать синхроимпульсы времени, если есть "вехи"-события?
Музыкальные инструменты (правильнее сказать, играющие на них) используют метроном (тикающая такая штучка) для синхронизации мелодии. Если принять скрипки и балалайки за экземпляры игры, то это позволит им уменьшить кванты времени без начала рассогласования. Т.е. больший квант будет позволять лучше синхронизироваться, но при этом динамичность и игровая непрерывность будут уменьшаться. И когда-нибудь играющий заметит "рывки" в реалтайме. А это недопустимо. Синхроимпульсы погут просто содержать инкрементируемый счётчик, что позволит также оценить и пропадание пакетов.
В пошаговых стратегиях, имеющих ограничение на время хода, надо дать играющим необходимое количество локального времени, но также следует его ограничить, чтобы кто-то не перевёл текущие часы-будильник назад и не получил дополнительные 30 секунд. Но это я отклоняюсь...
A>>А ведь за время хода (мыслительного процесса) живого человека ИИ вполне может расчитать свой ход. Иногда даже неоднократно. R>А вот это очень хорошая мысль.
Мне тоже нравится, но на практике ею пренебрегают, говоря что на отрисовку нашей офигенной графики и fps нужна уйма времени. Врут, не врут — не знаю. Для стратегий пошаговых, по моему, очень подходит.
R>Ну обсчет всех клиентов — дело обязательно централизованное. Обратных примеров не знаю. Есть такие?
У меня тоже нет живых примеров. Чтобы пальцем показать — вот мол, так и сделано. Но почему нет? Почему только по шаблону клиент-сервера идти, почему нельзя распределить расчёт действий ИИ...
Например, есть два живых игрока (два компьютера) и два игрока компьютерных. Пусть они все противники. Клиент-сервер попросит собрать действия первого живого, второго живого, потом расчитать действия двух ИИ, наложить их действия и раздать новое состояние живым для раздумий. А можно один ИИ привязать к одному живому, второго — ко второму, таким образом распараллелив вычислительную нагрузку по принятию решения, а по наложению действий и раздачи нового состояния делегировать выделенному (или невыделенному) игровому серверу. А теперь захочется пойти дальше, уложить эти все расчёты в квант времени, тогда кто быстрее справится — подождёт другого.
R>Хотя, опять же, это где у нас такой трафик дорогой?
Если речь о деньгах, то это Онлайн игры в Интернет. Если речь о загруженности каналов связи, то разные ситуации бывают на разных предприятиях. Пока кто-то играет, кто-то может и работать, занимаясь как бы более приоритетным делом в плане коммуникаций. Или, что более к практике — хочу и файл тянуть, и в Халву гонять. Даже в ЛВС попробуем копирнуть чего по сети, пусть она хоть 100 МБит во лбу...
Здравствуйте, akasoft, Вы писали:
R>>Я рад, что обсуждение пошло в плодотворном ключе. Можно и поспорить . A>Спорить пока незачем, можно и просто пообщаться и поделиться знаниями.
А мне-то как вас читать интересно
A>Что для реалтаймовых игр следует линейное неприрывное время отквантовать (разбить на кусочки, дискретизировать) таким образом, чтобы у играющих сохранился эффект непрерывности, но за выбранный шаг дискретизации каждый из участников игрового процесса гарантированно бы получал информацию о изменениях в игровом мире.
Тут штука в том, что можно сделать этот квант можно весьма большим, до долей секунды. Но отрисовываться все должно тем не менее плавно. То есть для каждого объекта имеется текущее положение и положение в конце кванта, ну и известно время окончания кванта, и как там процессор успевает считать, столько промежуточных положений ( не обязательно связыть положения прямой линией, кстати ) и отрисовывать в течение кванта, на медленных машинах можно даже меньше единицы.
пакет от сервера:
Номер кванта, т.е. текущее время.
Положения интерсующих объектов к концу кванта.
пакет от клиента:
Номер кванта.
Управляющие воздействия за время кванта.
Сервер получает действия за N-ный квант. Рассчитывает с их учетом новые положения объектов к концу (N+2)-ого, и отправляет.
Клиент к началу N-ного кванта знает положение объекта в начале и в конце кванта, этого достаточно, чтобы в течение кванта плавно отображать движение.
Здесь нажатия кнопок за N-ный квант будут действовать во время (N+2)-ого кванта. Зато все в равных условиях и ясно, как отслеживать недостаточную скорость сети.
ИМХО размер кванта здесь может быть чуть не до 1/4 секунды, тогда за полсекунды мы получим результат на экране, что вполне достаточно.
A>Есть ещё один интересный аспект — увеличение игровых объектов и их отсечение по области видимости для конкретного игрока. Тут будет правильнее не поддерживать полностью состояние такого игрового мира на всех клиентах, а наоборот переложить всё на сервер, а клиентам выдавать только то, что им видно и полезно для принятия решений живыми игроками.
Это имеет смысл только для больших миров.
A>ИИ тоже может функционировать с учётом области видимости, и не обязательно только на сервере, где известно всё_обо_всём.
А ИИ имеет смысл реализовать через тот же интерфейс, что имеют удаленные игроки. Впрочем локального игрока тоже имеет смысл делать через тот же интерфейс — это позволит легко реализовать режим "двое за одной машиной".
R>>...в Q3 игрок с высоким пингом "проскочит" на своем компьютере выстрел из рейлгана и свернет за угол, но сервер пришлет ему информацию, что он-таки убит. Расчеты расчетами, но здесь уже дело рисованием не ограничивается: надо фраги считать
A>А с чего он проскочит, если мы дискретизируем время?
А там предсказание есть. Т.е клиент пытается предсказать движения объектов. Порой это доходит до того, что ты спокойно заруливаешь в коридор, проходишь пару метров, а тут тебе прилетает пакет с реальным твоим расположением — упертым в стенку рядом с входом в коридор . Без предсказания играть в такие игры, как CS, TF с плохим пингом (от 200) было бы практически невозможно — постоянные рывки.
Дошел тут до 37 уровня.
Кроме всего прочего эта игрушка субъективно увеличивает скорость работы ПК. Ощущение, что все просто летает. Даже мышка быстрее ездит.
Здравствуйте, WFrag, Вы писали:
WF>А там предсказание есть.
Слово-то какое. На ум приходит всякий спиритизм, гадание и шаманы. Мне же кажется, что должно быть чистое знание, того что должно быть. По-другому, математика, т.е. расчёт на основе имеющейся информации.
Хотя теперь мне слово "предсказание" не кажется таким неуместным... Оно даже оригинальное.
WF> Т.е клиент пытается предсказать движения объектов. Порой это доходит до того, что ты спокойно заруливаешь в коридор, проходишь пару метров, а тут тебе прилетает пакет с реальным твоим расположением — упертым в стенку рядом с входом в коридор .
Это уже будет некорректное предсказание. Тот же рывок, только с видимостью плавности. "Плавный рывок". А всё из-за того, что сеть штука медленная по отношению к цепочке процессор-память и даже П-П-видеосистема-глаз.
Здравствуйте, Рома Мик, Вы писали:
РМ>ИМХО размер кванта здесь может быть чуть не до 1/4 секунды, тогда за полсекунды мы получим результат на экране, что вполне достаточно.
Достаточно или нет, сказать не могу, т.к. опыта нет. Но по моему обмен по сети будет занимать больше времени, нежели расчёт сцены и показ её играющему.
A>>Есть ещё один интересный аспект — увеличение игровых объектов и их отсечение по области видимости для конкретного игрока. Тут будет правильнее не поддерживать полностью состояние такого игрового мира на всех клиентах, а наоборот переложить всё на сервер, а клиентам выдавать только то, что им видно и полезно для принятия решений живыми игроками.
РМ>Это имеет смысл только для больших миров.
Ну почему-же. Узкое место сетевой игры сама сеть. Т.е. цепочка клиент1-сеть-другой клиент или сервер-сеть-клиент1. Поэтому надо стремиться передавать по сети меньше и только то, что нужно. Без чего никак играть нельзя. И если два игрока друг друга не видят, то им незачем передавать те же координаты друг друга.
Пусть такой пример. Две комнаты, без окон, только по закрытой двери в каждой, каждая дверь выходит в корридор. Игрок1 давит кнопки движения, водит мышью, и камера любезно рисует ему интерьер нашей комнаты, текстурки там красивые (или некрасивые). Игрок может посмотреть в любую сторону, рассмотреть стену поближе, к двери подойти. То же самое может делать и второй игрок. И ещё любое их количество, заточённые в одиночные камеры, выходящие в коридор нашей Бастилии. Но! Передавать по сети ничего не надо. Ни серверу, ни каждому из клиентов. Сеть спит, не задействована.
А теперь пусть игрок1 откроет дверь в коридор. Теперь надо узнать, есть ли кто в коридоре. И если нет — то снова штиль в сети. Узнавать будем у сервера. И сервер же оповещать, что мы открываем дверь в коридор.
Теперь пусть игрок1 изучает коридор, а игрок2 тоже откроет дверь. Что будет? Игрок2 сообщит серверу об открытии двери, сервер должен будет сказать, что коридор не пуст, должен будет дать инфу о изменении видимости игроку1 (тот услышит звук открываемой двери) и игроку2 тоже. И теперь возможны варианты. Либо игроки 1 и 2 будут общаться через сервер, что накладно по времени, но зато не нужен прямой канал между игроками; либо же сервер выдаст коммуникационную информацию обеим игрокам, и они будут передавать свои координаты и вектор камеры напрямую друг другу, что будет быстрее, но требует прямого канала связи между всеми игроками.
Видно, что за областью видимости следит сервер. Переходы между областями видимости вполне конкретны: смена помещения, открытие двери. Дополнительно можно учитывать и вектор направления камеры (лица, взгляда играющего), и наличие тумана, и горизонт, и просто определить, что дальше 5-ти метров игроки нифига не видят, аки близорукие.
Вот такой простой например.
РМ>А ИИ имеет смысл реализовать через тот же интерфейс, что имеют удаленные игроки. Впрочем локального игрока тоже имеет смысл делать через тот же интерфейс — это позволит легко реализовать режим "двое за одной машиной".
Особенно это хорошо для пошаговых стратегий. Все подумали, и отдали свои приказы. Причём ИИ может думать независимо от действия живых игроков, и параллельно их раздумьям. А потом сервер собирает приказы, проверяет их корректность, расчитывает и выдаёт новое состояние игрового мира...
Здравствуйте, akasoft, Вы писали:
A>Особенно это хорошо для пошаговых стратегий.
Так все игры почти пошаговые, только некоторые с автоматическим концом хода.
Здравствуйте, akasoft, Вы писали:
A>Слово-то какое. На ум приходит всякий спиритизм, гадание и шаманы. Мне же кажется, что должно быть чистое знание, того что должно быть. По-другому, математика, т.е. расчёт на основе имеющейся информации.
prediction
A>Хотя теперь мне слово "предсказание" не кажется таким неуместным... Оно даже оригинальное.
WF>> Т.е клиент пытается предсказать движения объектов. Порой это доходит до того, что ты спокойно заруливаешь в коридор, проходишь пару метров, а тут тебе прилетает пакет с реальным твоим расположением — упертым в стенку рядом с входом в коридор .
A>Это уже будет некорректное предсказание. Тот же рывок, только с видимостью плавности. "Плавный рывок". А всё из-за того, что сеть штука медленная по отношению к цепочке процессор-память и даже П-П-видеосистема-глаз.
Корректное. Фича в том, что клиент как бы играет только на своем компе — все объекты обсчитываются у него. А с сервера время от времени приходят эталонные даные, по которым клиент синхронизуется. Если сервер/клиент исполняют одинаковый код, то клиент более-менее правильно экстраполирует положения объектов. Без этого, если происходит потеря пакетов в течении полусекунды, например, клиент бы просто висел. А так хоть видимость действий. Более подробно можно на gamedev.net почитать, там вроде было.
Здравствуйте, akasoft, Вы писали:
A>Разве что о пошаговых стратегиях.
Думаю былобы интересно. A>В других жанрах опыта разработчика нет, только догадки, умозаключения, наблюдения и пожелания...
Но судя по этому топику ты еще можешь не плохо написать "Домыслы и умозаключения об организации сетевых игр." ну и "догадки, умозаключения, наблюдения и пожелания об организации игр" тоже может быть неплохо.
ЗЫ Думайте сами решайте сами...(С)Непомню.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re: Я тут игрушку выложил...
От:
Аноним
Дата:
25.12.03 13:20
Оценка:
Здравствуйте, retalik, Вы писали:
R>Подробности здесь
Здравствуйте, Виталий,
прочитал всю нить, попробовал игрушку и мне стало интересно чем же закончилась история
Удалось ли довести игру до ума и продать ее?
Если да, поделитесь пожалуйста впечатлениями.
Здравствуйте, Аноним, Вы писали:
А>прочитал всю нить, попробовал игрушку и мне стало интересно чем же закончилась история А>Удалось ли довести игру до ума и продать ее? А>Если да, поделитесь пожалуйста впечатлениями.
Да пока ничем. Слишком много проектов висит, а это — "для души", тут суетиться не хочется.
Потихонечку переношу исходники под VC++ (они на древнем WATCOM), собираюсь улучшить графику (скорее всего, перенести движок на DirectX).
Игрушка-то хоть захватила? Мне интересны мнения других людей.
Здравствуйте, retalik, Вы писали:
R>Здравствуйте, Аноним, Вы писали:
А>>прочитал всю нить, попробовал игрушку и мне стало интересно чем же закончилась история А>>Удалось ли довести игру до ума и продать ее? А>>Если да, поделитесь пожалуйста впечатлениями.
R>Да пока ничем. Слишком много проектов висит, а это — "для души", тут суетиться не хочется.
да...дело такое...а проекты денежные?...ладно, я сам лентяй R>Потихонечку переношу исходники под VC++ (они на древнем WATCOM), собираюсь улучшить графику (скорее всего, перенести движок на DirectX).
R>Игрушка-то хоть захватила? Мне интересны мнения других людей.
Игрушка понравилась, но до "захватила" ей еще далеко. Как насчет того что бы сделать под нее сайт, а?
Тогда появится заинтересованная аудитория, отзывы, пожелания....можно даже исходники выложить кто знает что из этого выйдет....вот только после этого на ней не заработаешь...
Вот такие вот размышления.
.
R>Интересует ваше мнение по заданным вопросам.
REtalik я давно скачал твою игру.
Какие в ней глюки тебе уже выложили выше в полной мере.
Я ту дашел до 136 уравня очков около 2млн. жизней 150. потом я забался. а все потому, что как только я появлялся ВСЕ сразу взрывалось.
А вообще мне понравилось. Задумка прикольная.
Прикольно былобы туда еще человечиков впаять с калашами. А танки ездить заставить. А воздух украсить верталетами. Ну в общем творческих успехов.
Жду твоих обновлений.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Рома Мик, Вы писали:
РМ>>Здравствуйте, retalik, РМ>>116 уровень! ~1800000 очков. Слабо?!
A>Тоже поломал?
Да не, зачем? Последние 40 уровней все само взрывалось и я переходил на следующий. Но вот под конец какая-то шилка не взорвалась и стояла так, что я на такой скорости в нее никак не мог попасть, я даже развернуться не мог.
.
