![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
о симуляторах и железе
Feb. 8th, 2013 01:33 amtl;dr: почему у нас до сих пор нет игр с супер-пупер живым миром? а вот почему.
я вот недавно жаловался на то, что железо современное плохое и не подходит для симуляторов ( http://wizzard0.livejournal.com/278128.html )
и вот расписал, как именно оно плохое ( http://wizzard0.livejournal.com/282769.html )
короче самое печальное что из этих эстимэйтов можно вывести - что если любое вычисление выполняется за константное время (==это таблица ранее вычисленных значений), то можно выполнить за кадр не более 150к независимых вычислений. зависимых - в 50 раз больше, в идеальном случае (тупое последовательное копирование) - в 500 раз. но реально таки 150к вычислений.
т.е. игрушка написанная "в лоб" на нынешнем железе может симулировать со скоростью 60 кадров в секунду 75к разных энтитей (считая одну операцию на изменение состояния энтити, и одну операцию на отрисовку)
Вроде бы, не так уж мало.
"можно закрасить экран iPad обьектами площадью в 10 пикселей" -- vgrichina
Для 2D игр, действительно, достаточно. А вот с 3D и мультиплеером - ситуация уже не столь радостная.
1. давеча thesz тут ( http://thesz.livejournal.com/1359825.html ) ужасался использованию Stackless Python в EVE Online и тому, что одновременно на узле могут присутсвовать "всего" 3000 игроков.
Если вспомнить, что кораблик в EVE - это далеко не материальная точка, плюс есть еще дроны, управляемые ракеты и прочий такой мусор - внезапно мы приходим все к той же магической цифре в 75к обьектов.
2. Если мы хотим *симулировать* сколько-нибудь большой мир - мы вынуждены делать либо пошаговую игру, либо упрощать обьекты вдалеке от игрока. Само по себе это не так плохо, и для single-player очень даже работает.
А вот в мультиплеере бюджет обьектов сьедается очень быстро, ведь, хоть игроки и кучкуются, но все равно у нас получается уже N "окрестностей игрока", а не 1 окрестность
3. Даже в "одной окрестности", если мир трехмерный, симулировать 50 метров по высоте и 400 м по ширине (квартал города в GTA) означает 8 млн куб.м. По 100м^3 на обьект. Или по материальной точке (точнее, обьекту, который описывается конечным автоматом, таблица состояний которого помещается в RAM) через каждые 4 метра. При этом изрядную часть этого бюджета сьедает графика.
Minecraft? Нет, не пойдет. Там ландшафт статичен. Хотя даже там дистанция отрисовки ненамногим больше магических 200 метров, хотя из динамических обьектов только коровы, лампочки и redstone.
Roblox ( http://www.youtube.com/user/roblox ) гораздо ближе. Вообще, Семен призывается в тред рассказать, какие у них реально получаются там размеры сцен.
4. "динамически понижать детализацию по удалению от игрока" - можно. и нужно. Но уметь надо. Для user-generated content это ой как непросто. Никого в GTA не раздражало, что если преследуемая машина свернет за угол (а то и если просто ненароком камеру повернуть) - она исчезнет навсегда? Вот я примерно об этом.
Comments welcome.
я вот недавно жаловался на то, что железо современное плохое и не подходит для симуляторов ( http://wizzard0.livejournal.com/278128.html )
и вот расписал, как именно оно плохое ( http://wizzard0.livejournal.com/282769.html )
короче самое печальное что из этих эстимэйтов можно вывести - что если любое вычисление выполняется за константное время (==это таблица ранее вычисленных значений), то можно выполнить за кадр не более 150к независимых вычислений. зависимых - в 50 раз больше, в идеальном случае (тупое последовательное копирование) - в 500 раз. но реально таки 150к вычислений.
т.е. игрушка написанная "в лоб" на нынешнем железе может симулировать со скоростью 60 кадров в секунду 75к разных энтитей (считая одну операцию на изменение состояния энтити, и одну операцию на отрисовку)
Вроде бы, не так уж мало.
"можно закрасить экран iPad обьектами площадью в 10 пикселей" -- vgrichina
Для 2D игр, действительно, достаточно. А вот с 3D и мультиплеером - ситуация уже не столь радостная.
1. давеча thesz тут ( http://thesz.livejournal.com/1359825.html ) ужасался использованию Stackless Python в EVE Online и тому, что одновременно на узле могут присутсвовать "всего" 3000 игроков.
Если вспомнить, что кораблик в EVE - это далеко не материальная точка, плюс есть еще дроны, управляемые ракеты и прочий такой мусор - внезапно мы приходим все к той же магической цифре в 75к обьектов.
2. Если мы хотим *симулировать* сколько-нибудь большой мир - мы вынуждены делать либо пошаговую игру, либо упрощать обьекты вдалеке от игрока. Само по себе это не так плохо, и для single-player очень даже работает.
А вот в мультиплеере бюджет обьектов сьедается очень быстро, ведь, хоть игроки и кучкуются, но все равно у нас получается уже N "окрестностей игрока", а не 1 окрестность
3. Даже в "одной окрестности", если мир трехмерный, симулировать 50 метров по высоте и 400 м по ширине (квартал города в GTA) означает 8 млн куб.м. По 100м^3 на обьект. Или по материальной точке (точнее, обьекту, который описывается конечным автоматом, таблица состояний которого помещается в RAM) через каждые 4 метра. При этом изрядную часть этого бюджета сьедает графика.
Minecraft? Нет, не пойдет. Там ландшафт статичен. Хотя даже там дистанция отрисовки ненамногим больше магических 200 метров, хотя из динамических обьектов только коровы, лампочки и redstone.
Roblox ( http://www.youtube.com/user/roblox ) гораздо ближе. Вообще, Семен призывается в тред рассказать, какие у них реально получаются там размеры сцен.
4. "динамически понижать детализацию по удалению от игрока" - можно. и нужно. Но уметь надо. Для user-generated content это ой как непросто. Никого в GTA не раздражало, что если преследуемая машина свернет за угол (а то и если просто ненароком камеру повернуть) - она исчезнет навсегда? Вот я примерно об этом.
Comments welcome.
