ВНИМАНИЕ!
Наша конференция посвящена космической тематике и компьютерным играм.
Политические вопросы и происходящие в мире события в данный момент на нашем сайте не обсуждаются!
|
| » Абстрактное мусоление движения и стрельбы | страница 1 |
|
|
|
|
Канал Игры Мечты: «Абстрактное мусоление движения и стрельбы» |
|
|
|
Sh.Tac.
 151 EGP
 
Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426
Зарегистрирован: 27.07.2005
  |
|
| Kann : |
|
цифры выраженные в векторах и математических расчетах,а не физические объекты размещаемые в сцене как в случае с клиентом
|
кстати да, одна из идей которые приходят в голову, после того как сетевая часть написана и отлажена, что на серваке есть немного "лишнего" CPU которое можно было бы использовать с "видимой" пользой, например считать физику
или даже ещё "лучше", считать физику на GPU, ядрён-ть GPU ща по терафлопсам уделывают любые CPU как сосунков
физика понятие достаточно сложное, если взять обычное движение, там сплошь дифференциальные уравнения, которые впадлу самому решать, проще взять готовый физический движок и не париться
он и работает кста быстро даже в software, а уж на GPU в hardware так и вообще миллион чуваков просчитает на раз
к тому же Havok или PhysX писали чуваки которые не ровня нам, любителям, они не лажают, все решения обкатаны не первый год, я бы даже сказал не первый десяток лет
всё хорошо конечно, но физдвиг принципиально не подходит для ММО 
GPU можно даже не рассматривать всерьёз, т.к. результат надо ещё получить обратно (в отличие от графики, которая тока в одну сторону или вообще на видяхе живёт), и медленная шина/медленная память убивает всю замечательную производительность
во-первых выясняется, что инерциальная физика как бы не тогось, не очень-то и играбельна, а "самолётную" модель можно сделать либо грубым хаком, либо тщательным указанием всех действующх сил и противосил практически для каждого манёвра
во-вторых, если кто читал про то как сделаны шутеры и решил например сделать классическую лагокомпенсацию на сервере, то столкнётся с тем, что физические сцены надо уметь откатывать назад во времени и пересчитывать, а затем возвращаться к актуальной симуляции, чего физдвиг делать не умеет, и придётся применять решения разной степени костыльности, а вообще для ММО про это лучше забыть совсем, откаты и пересчёты это ложный путь
та же беда, нельзя никого просчитать индивидуально, все считаются одной кучей по заданному рейту (частоте обновления), к тому же если у вас в каждый момент времени скорость может принимать произвольное значение, (т.е. активация движителя это сила/ускорение), то будьте готовы к тому что с сервера придётся высылать не только посчитаные координаты, но и [средние] скорости, линейные [и угловые], в противном случае интерполяция на клиенте будет работать неправильно, если там брать скорость по пришедшим координатам и временнЫм отметкам
да, про повороты, даже не пытайтесь их считать на сервере и отсылать клиенту
вкратце резюме такое, систему движения надо делать и настраивать самим, ручками, причём это решение должно работать идентично, как на сервере, так и на клиенте
тут всплывает ещё один момент, в Юнити встроен PhysX, казалось бы идентичность гарантирована, если на сервере тоже будет PhysX, ан нет, откаты при ошибочных построениях на клиенте совсем невозможны, т.к. физдвиг работает только в одном треде, и к тому же выясняется, что даже в одном этом треде работает он неровно, т.е. на сетевые лаги накладываются флуктуации работы GC и ещё бог знает чего
ну и система движения она очень зависит от того, на какие упрощения готовы пойти создатели игры, а на какие нет, и будут стоять насмерть в плане управления и ощущений от игры
напоследок даже click&go при всей своей простоте можно сделать неправильно, к тому же наверное не каждый сможет проассоциировать click&go со свободным прицеливанием, хотя прицеливание убивается совсем другим механизмом target lock
вот такое вот абстрактное размусоливание получилось 
_________________
This is what you get ...
(c) Radiohead |
|
|
|
Kann
64 EGP
Рейтинг канала: 3(45)
Репутация: 7
Сообщения: 232
Откуда: Москва
Зарегистрирован: 11.04.2008
|
|
| Sh.Tac. : |
всё хорошо конечно, но физдвиг принципиально не подходит для ММО
во-первых выясняется, что инерциальная физика как бы не тогось, не очень-то и играбельна,
|
согласен что физика не очень то подходит для ММО так как играть в такое довольно сложно
так же думаю что режим КС для ммо очень специфичен, из последних игр могу припомнить только Мир танков, где возможно потребуются откаты и пересчет, в классическом ммо критичность попадания с 3х километров белке в глаз стремится к нулю, отсюда допуски довольно велики, да и игра в ммо с пингом выше 500 уже практически самоубийство,(если ммо не о раскладывании пасьянса  )
|
|
|
|
Sh.Tac.
151 EGP
Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426
Зарегистрирован: 27.07.2005
|
|
ну и парочка обещанных безумных идей, которые легко отвергаются по принципу "так никто не делает"
это всё такое влобное, наверняка на ЕГ не раз обсуждавшееся, но потом уличённое в обычном нубстве
1)
всё пространство тупо разбить на кубы, например 2х2х2 км.
каждый куб обслуживать одним симулятором (процессом/тредом)
транслировать видимости на соседние кубы, т.е. на 26
форкать симуляторы по мере необходимости для залётных чуваков
также их гасить за ненадобностью
2)
навеяно click&go которая почти что рельсы, настолько там всё предсказуемо
а что если эти рельсы в кубе проложить заранее, а игрок просто будет переводить стрелки? 
при этом оставить видимость прямого управления со всеми степенями свободы
_________________
This is what you get ...
(c) Radiohead |
|
|
|
Guest
2075 EGP
          
Рейтинг канала: 5(167)
Репутация: 376
Сообщения: 27975
Откуда: Моск.
Зарегистрирован: 12.10.2004
 |
|
этааа...
1) ну вот он пересекает границу куба туда-назад-обратно. Осциллирует тама, таксказыть. Часто. Очень часто. По такту. Переносить надо всю информацию. И какой от этого прок?
2) аэтокак? 
_________________
Трещит земля как пустой орех
Как щепка трещит броня |
|
|
|
Sh.Tac.
151 EGP
Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426
Зарегистрирован: 27.07.2005
|
|
| Guest : |
|
ну вот он пересекает границу куба туда-назад-обратно. Осциллирует тама, таксказыть
|
вот эти вот пресловутые 2х2 (20х20, неважно) это центральные зоны, симулятор умеет считать немного дальше, т.е. получается внахлёст
примерно так, переходная зона синхронизации двух смежных симуляторов А и В заштрихована
| Код: |
+-------+-------+-------+-------+-------+
| | |///////| | |
| | |///////| | |
| | |///////| | |
+-------+-------+-------+-------+-------+
| | |///////| | |
| | A >|///////| B | |
| | |///////| | |
+-------+-------+-------+-------+-------+
| | |///////| | |
| | |///////| | |
| | |///////| | |
+-------+-------+-------+-------+-------+
|
соответственно при переходе чувака, отмечен "птичкой", из А информация о нём пересылается на удалённый симулятор В вместе с таймстемпом и уравнением движения
и пока симулятор В "тупит" А продолжает вести чувака, собсно в какой-то момент инфа поступает уже от обоих симуляторов, но инфа от А режектится некоей шлюзовой компонентой, собсно к которой и подсоединены все чуваки в терминах IP
и если чувак вдруг заметался на границе А и штрих-зоны, то периодически будут посылаться через шлюз-компоненту на В инфа о чуваке и, скажем, cancel по этому чуваку
| Guest : |
|
Переносить надо всю информацию
|
инфа о чуваке на симуляторе это только то, что нужно для движения и стрельбы, т.е. характеристики корабля, которые могут быть в пределе ну очень типовые и кодироваться одним числом
вообще при таком подходе вся остальная логика, в том числе и бафы на скорость, должна считаться на какой-то отдельной логической компоненте, где и лежит полная инфа о чуваке, т.к. симуляторы должны быть предельно лёгкими ввиду их возможного немеряного количества
а это пока х.з. на уровне интуитивной догадки 
есть аналогия в реальном мире, ты находясь в зоне действия массы и обладая ограниченной энерговооружённостью корабля не можешь летать как попало, грубо говоря все твои орбитальные переходы квантованы и известны заранее, неизвестно тока какой именно ты выберешь
добавлено спустя 25 минут:
З.Ы. про переходы наверное немного не так, каждый симулятор ещё мальца заползает на центральную зону чужого симулятора, это чтобы разрешить метания чуваков в переходных зонах
как раз в short'e есть ещё немного неиспользованного диапазона
_________________
This is what you get ...
(c) Radiohead
Последний раз редактировалось: Sh.Tac. (13:55 26-02-2011), всего редактировалось 1 раз |
|
|
|
Kann
64 EGP
Рейтинг канала: 3(45)
Репутация: 7
Сообщения: 232
Откуда: Москва
Зарегистрирован: 11.04.2008
|
|
| Sh.Tac. : |
|
ну и парочка обещанных безумных идей
|
я честно сказать не въехал, для чего это ? что это даст полезного ?
|
|
|
|
Guest
2075 EGP
Рейтинг канала: 5(167)
Репутация: 376
Сообщения: 27975
Откуда: Моск.
Зарегистрирован: 12.10.2004
|
|
| Sh.Tac. : |
|
инфа о чуваке на симуляторе это только то, что нужно для движения и стрельбы
|
А полный импульс и действия? А если он там стреляет в это время?
_________________
Трещит земля как пустой орех
Как щепка трещит броня |
|
|
|
Sh.Tac.
151 EGP
Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426
Зарегистрирован: 27.07.2005
|
|
| Kann : |
|
что это даст полезного ?
|
перед вами горизонтально (да и вертикально) масштабируемая система, которая может занять столько железа, скока дашь
при этом есть надежда, что ни один из отдельно взятых симуляторов не сдохнет от перенагруза, ибо просчитываемый объём достаточно мал
| Guest : |
|
А если он там стреляет в это время?
|
стрельбу я думал рассматривать после движения, но в каких-то принципиальных моментах её конечно надо втиснуть в предлагаемую систему
тут будет зависеть от того куда чувак стреляет:
1. если в центральную (и далее отстоящие) зону B, находясь в А то тут да, передача параметра луча на симулятор В т.к. на А просто нет мишени
2. в противном случае пока стреляющий чувак не долетел до центральной зоны В вся стрельба остаётся на А, а если долетел, то вариант 1 с инверсией ролей симуляторов
3. ещё вариант, что чувак стреляет в переходную зону, но мишень в ней не успела синхронизироваться, т.е. например летит наоборот из В в А, тогда вариант 1
в общем получается что команда стрельбы передаётся на ведущий симулятор, а уже он строит луч и отправляет его параметры на симулятор, который находится дальше по лучу
поскольку понятие ведущего зависит от временных задержек, то фактически в какой-то момент команда стрельбы будет рассовываться на оба симулятора, как с движением
варианты ответов, ответил или тот или другой, если оба, то второй ответ игнорируем
добавлено спустя 24 минуты:
З.Ы. тут вот на этом примере кста сразу видно насколько click&go проще, клиент сразу передаёт отрезок, куда он летит и в кого стреляет, при этом клиенту нет никакого смысла врать
_________________
This is what you get ...
(c) Radiohead
Последний раз редактировалось: Sh.Tac. (19:20 26-02-2011), всего редактировалось 1 раз |
|
|
|
Zachesa
151 EGP
Рейтинг канала: 4(95)
Репутация: 13
Сообщения: 1415
Откуда: Хабаровск
Зарегистрирован: 12.11.2007
|
|
| Sh.Tac. : |
это всё такое влобное, наверняка на ЕГ не раз обсуждавшееся, но потом уличённое в обычном нубстве
1)
всё пространство тупо разбить на кубы, например 2х2х2 км.
каждый куб обслуживать одним симулятором (процессом/тредом)
транслировать видимости на соседние кубы
|
Позволю себе заметить, что в моём проекте (UEF) пространство разбито на фазы эшелонов, а так на счёт отдельного экземпляра обработчика событий и перекрытий между фазами эшелона и смежными фазами разных эшелонов, по видимости, я также говорил неоднократно.
Вот на счёт рельс и стрелок немного перебор, можно конечно что-то намутить подобное и даже некоторое псевдонаучное объяснение притянуть за уши, но дискретный космос это что-то прямо противоположное "свободе среди звёзд"!
_________________
Язык Образов, для ситуационного моделирования, программирования и как язык мысли, думающей машины. |
|
|
|
Kann
64 EGP
Рейтинг канала: 3(45)
Репутация: 7
Сообщения: 232
Откуда: Москва
Зарегистрирован: 11.04.2008
|
|
| Sh.Tac. : |
перед вами горизонтально (да и вертикально) масштабируемая система, которая может занять столько железа, скока дашь
при этом есть надежда, что ни один из отдельно взятых симуляторов не сдохнет от перенагруза, ибо просчитываемый объём достаточно мал
|
а каковы исходные данные ? то есть что вы в принципе проектируете в итоге ?
единый сервер на 1 миллион человек ? в таком случае чем это отличается от распределенных серверов ? и каков смысл выдерживать нагрузки в 100500 человек в одной точке если такое не отрисует не когда в жизни клиентская сторона, даже если не брать вариант что клиент может играть через модем и тупо не осилит входящий трафик ?
а так же почему бы просто не обрабатывать каждого нового клиента подключившегося к серверу в отдельном потоке, и потоки эти может обрабатывать любое количество железа которое дадите ? по большей части по моему тут стоит вопрос целесообразности а не реализации.
|
|
|
|
Sh.Tac.
151 EGP
Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426
Зарегистрирован: 27.07.2005
|
|
| Zachesa : |
|
Вот на счёт рельс и стрелок немного перебор
|
хотелось бы развёрнутой критики или конкретного вопроса
с какой стороны это плохо?
я могу сказать что со стороны клиента это хорошо, потому как если у сервера есть возможность смотреть хотя бы на шаг вперёд и извещать клиента о том, что произойдёт через некоторое время, например скорость изменится, то клиенту нет необходимости ничего откатывать и пересчитывать у себя, - предупреждён значит вооружён
| Kann : |
|
в таком случае чем это отличается от распределенных серверов?
|
тут единое игровое пространство без врат, размеры этого пространства практически не влияют на серверную сторону, важна лишь нагрузка по чувакам
| Kann : |
|
и каков смысл выдерживать нагрузки в 100500 человек в одной точке
|
тут смысл обратный, куб ограничен по размерам и туда просто не набъётся 100500 человек
| Цитата: |
|
если такое не отрисует не когда в жизни клиентская cторона
|
Unity возможно и не отрисует, чуваки из EVE как-то рисуют же
| Цитата: |
|
даже если не брать вариант что клиент может играть через модем и тупо не осилит входящий трафик?
|
на самом деле это вплотную примыкает к отрисовке, по идее сервер может не присылать того чего не видит клиент, но это куда более нетривиальная и неподъёмная система т.к. достоверно сервер не знает куда на клиенте ща сморит отдельно взятый чувак
предлагаемый подход гарантирует что клиент не увидит ничего далее одного куба в любую сторону, плюс кубы выбраны малыми по объёму, так чтобы туда действительно не набилось немеряно чуваков
| Цитата: |
|
а так же почему бы просто не обрабатывать каждого нового клиента подключившегося к серверу в отдельном потоке?
|
мне эта парадигма незнакома, как строится при этом взаимодействие персонажа/корабля с локацией и другими персонажами?
я так предполагаю, что всё умрёт на мьютекс локах
к тому же процы, если не путаю, тянут до 250 тредов на ядро
хотя... 250 чел. на ядро это фантастический результат
| Цитата: |
|
по большей части по моему тут стоит вопрос целесообразности а не реализации
|
ага, этот подход уже признан нецелесообразным, но у меня есть желание убедиться в этом практически, теперь уже в свободное время
_________________
This is what you get ...
(c) Radiohead
Последний раз редактировалось: Sh.Tac. (22:14 26-02-2011), всего редактировалось 1 раз |
|
|
|
Kann
64 EGP
Рейтинг канала: 3(45)
Репутация: 7
Сообщения: 232
Откуда: Москва
Зарегистрирован: 11.04.2008
|
|
| Sh.Tac. : |
тут единое игровое пространство без врат, размеры этого пространства практически не влияют на серверную сторону, важна лишь нагрузка по чувакам
|
отлично это на сервере оно безгранично,(тут один только код) а что мы будем делать на клиенте ? там игровое пространство очень даже как ограниченно, у нас что у пользователей дома стоят сервера с безграничными ресурсами ? нам так же придется подгружать ресурсы на клиенте как не крути, можно это делать динамически не спорю, но в момент загрузки получим тормоза это по любому(пример еве, влет в астерное поле или скопление кораблей) так что с таким же успехом можно использовать асинхронные сокеты для незаметного(для клиента) переподключения на следующий сервер во время например перелета между ключевыми точками(игровыми локациями)
| Цитата: |
Unity возможно и не отрисует, чуваки из EVE как-то рисуют же
|
чуваки из еве рисуют квадратики, и война там по приборам при скоплении на экране более 500 человек
| Цитата: |
на самом деле это вплотную примыкает к отрисовке, по идее сервер может не присылать того чего не видит клиент, но это куда более нетривиальная и неподъёмная система т.к. достоверно сервер не знает куда на клиенте ща сморит отдельно взятый чувак
|
все правильно, но только я говорю о скоплении народу в одной точке, стоит только клиенту посмотреть в сторону скопления кучи игроков и его канал загнется(опять же не берем игры аля поинт-клик и типо Мир танков, там они вообще уже радостно рапортуют о 120к перцах на одном сервере )
| Цитата: |
предлагаемый подход гарантирует что клиент не увидит ничего далее одного куба в любую сторону, плюс кубы выбраны малыми по объёму, так чтобы туда действительно не набилось немеряно чуваков
|
и сколько это если в теории ? учитывая что у нас игра будет не поинт -клик а полноценное прямое управление
| Цитата: |
ага, этот подход уже признан нецелесообразным, но у меня есть желание убедиться в этом практически, теперь уже в свободное время
|
не подход, а поставленные цели, просто изначально вы не дали не каких данных, чего хотите получить на выхлопе, отсюда вывод зачем городить такой огород....
|
|
|
|
Sh.Tac.
151 EGP
Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426
Зарегистрирован: 27.07.2005
|
|
| Kann : |
|
а что мы будем делать на клиенте ? там игровое пространство очень даже как ограниченно
|
вообще-то нет
никто не мешает забахать логарифмический z-buffer, правда точно не знаю, в DX11 уже есть возможность задать свою функцию или нет?
все статические объекты известны заранее и их расположение не меняется
так что речь идёт только об ограничении динамической видимости, обычно просто считают сферу вокруг чувака и всё что входит то входит, но это к сожалению не решает вопрос масштабирования системы на сервере
| Цитата: |
|
отсюда вывод зачем городить такой огород
|
я пытаюсь убить двух зайцев, естественное масштабирование системы + отказ от расчётов динамической видимости в пользу статической
вообще "нарисовать" для каждого чувака сферу на сервере и чекать кто туда вошёл, а кто вышел, раз плюнуть, так что тут выигрыша почти никакого
вот, а натянуть одну локацию на N серверов по-другому по-моему никак нельзя
| Цитата: |
|
и сколько это если в теории ? учитывая что у нас игра будет не поинт -клик а полноценное прямое управление
|
теория не даст на это ответа, только эмпирика
много параметров, которыми можно варьировать:
полноценное управление оно сложнее на сервере считается, так что тут можно просто упереться в CPU, если много чуваков
также размер куба (в метрах) зависит от максимальной скорости полёта кораблей
зная размер кораблей опять же в метрах можно прикинуть сколько их поместится в куб
от геймдизайна зависит насколько эпическими планируются быть баталии
на это накладываются ограничения клиента сколько он сможет реально переварить
если сильно намельчить, то количество процессов на отдельно взятом физическом сервере может стать неудобоваримым, особенно если чуваки не будут сбиваться в кучи, а будут летать максимально разреженно
в общем куда ни кинь, - везде клин
_________________
This is what you get ...
(c) Radiohead |
|
|
|
Kann
64 EGP
Рейтинг канала: 3(45)
Репутация: 7
Сообщения: 232
Откуда: Москва
Зарегистрирован: 11.04.2008
|
|
| Sh.Tac. : |
вообще-то нет
|
я имел в виду графический контент, и его подзагрузку, все равно например в бою чето грузить это самоубийство, отсюда выходит что грузить надо во время нечего не делания на стороне клиента выходит что лучший момент во время перелета на большое расстояние, а так проблема больших пространств решается не так сложно, просто двигая объекты вокруг игрока а не наоборот в зоне динамической видимости
| Цитата: |
а натянуть одну локацию на N серверов по-другому по-моему никак нельзя
|
ну так а вариант с асинхронными сокетами и переходом между серверами не ? все равно как я писал выше нам понадобится момент подзагрузки контента в клиенте, в это же время переходим на следующий сервер,(где и как это делать решение больше геймдизайнерское) а расположение объектов собственно не важно так как на клиенте игрок всегда стоит на месте мы лишь говорим с сервера какие объекты ему показать в зоне динамической видимости
|
|
|
|
Sh.Tac.
151 EGP
Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426
Зарегистрирован: 27.07.2005
|
|
| Kann : |
|
проблема больших пространств решается не так сложно, просто двигая объекты вокруг игрока
|
вообще дополнительной целью "кубирования" пространства является возможность оперирования в локальных координатах, например в пределах двух байтов
недостатком такого King's Bounty (ещё самого древнего) является то, что нет разницы между динамическими и статическими объектами, надо всё включать в трафик, а статическими вполне могут быть поля астероидов например
_________________
This is what you get ...
(c) Radiohead |
|
|
|
Kann
64 EGP
Рейтинг канала: 3(45)
Репутация: 7
Сообщения: 232
Откуда: Москва
Зарегистрирован: 11.04.2008
|
|
дык а что там того трафика то ? мы передаем только вызов интересующего игрового объекта на клиенте, далее все двигаем локально, например имеем зону видимости в 5км, на сервере мы входим в астероидное поле, посылаем на клиент информацию об инстансе этого объекта согласно локальному представлению на клиенте, и двигаем вокруг игрока уже тупо локально, синхронизацию проводим относительно статических объектов на сервере, того же астероидного поля,(если у нас в зоне видимости 10 полей и планета то все равно информацию посылаем только о положении единственного объекта, так как все это статика и не куда не убежит и на основании этих данных мы можем скорректировать все остальное локально),(короче стандартная схема только корректируем не самого игрока а объекты вокруг) тут выигрыша по трафику по сравнению с обычным способами нет, выигрыш только в неограниченном пространстве, а вот динамические объекты вроде других игроков тут да, придется постоянно передавать данные о местоположении так как просчитать локально не представляется возможным
|
|
|
|
Sh.Tac.
151 EGP
Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426
Зарегистрирован: 27.07.2005
|
|
а ну я понял, это такой специфичный хак
думаю желающих воспользоваться им будет столько же, сколько делать "кубатуру" сервера
как-то классические решения предпочтительнее почему-то оказываются
_________________
This is what you get ...
(c) Radiohead |
|
|
|
Kann
64 EGP
Рейтинг канала: 3(45)
Репутация: 7
Сообщения: 232
Откуда: Москва
Зарегистрирован: 11.04.2008
|
|
| Sh.Tac. : |
думаю желающих воспользоваться им будет столько же, сколько делать "кубатуру" сервера
|
это точно так как я сам использую стандартную схему с "вратами", тут вопрос целесообразности, думаю что если такие идеи и пытаться воплотить в жизнь то только в одиночку, так как кроме себя любимого понять глубину замысла а тем более осилить не сможет не кто, ну и уже с готовым решением выходить в "люди"
|
|
|
|
Zachesa
151 EGP
Рейтинг канала: 4(95)
Репутация: 13
Сообщения: 1415
Откуда: Хабаровск
Зарегистрирован: 12.11.2007
|
|
| Sh.Tac. : |
|
хотелось бы развёрнутой критики или конкретного вопроса
|
Как бы это вопрос не раскрыт достаточно, чтоб было что критиковать
Могу предположить, что под вторым пунктом имелась в виду ещё более глубокая дискретизация, то есть те кубы, что описаны в первом ещё дальше делятся на те же вложенные кубики. В итоге игровые объекты находятся в узлах образованных этими кубиками решётки, а передвигаются строго по граням. В данном случае можно строго ограничить сколько объектов может находится в узле (да хоть только один).
Плюс -- всё очень хорошо просчитывается заранее и легко прогнозируется. Соответственно игровая механика строится с учётом данной модели представления мира.
Минус -- менее гибкая система управления, вполне приемлемая для стратегии и неудобная для аркады (сесть за штурвал истребителя и атаковать транспорт неприятеля в данном случае проблематично).
_________________
Язык Образов, для ситуационного моделирования, программирования и как язык мысли, думающей машины. |
|
|
|
Sh.Tac.
151 EGP
Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426
Зарегистрирован: 27.07.2005
|
|
| Zachesa : |
|
те кубы, что описаны в первом ещё дальше делятся на те же вложенные кубики. В итоге игровые объекты находятся в узлах образованных этими кубиками решётки, а передвигаются строго по граням
|
ну зачем же сразу по граням? можно ведь и жучка/ежа внутри кубика "нарисовать"
вообще сами рельсы и стрелки это лишь аналогия, суть не в рельсах
вот если ты за машиниста на полных парах несёшься, когда стрелку-то переведёшь (допустим есть такая возможность) ?
вот и я хочу чтобы игрок всё делал немного заранее, а не в самый последний момент, а потом ещё негодовал, почему всё лагает
_________________
This is what you get ...
(c) Radiohead |
|
|
|
|
|
|
|
|
Канал Игры Мечты: «Абстрактное мусоление движения и стрельбы» |
|
|
| К списку каналов | Наверх страницы |
Цитата не в тему: Проснулся в воскресенье, называется.. Армия терракотовых бактерий, масонские дамы со жгутиками.. да ну нафиг это ЗК, пойду дальше спать.. (ворчит HeadHunter)
|
| » Абстрактное мусоление движения и стрельбы | страница 1 |
|
