95 ответов в теме

[alexflim]

 

омг... Разрабы танков, которые активно привлекают к моделлингу аутсорс (со всего СНГ, думаю, пресловутые выпускники щуки туда тоже входят) как-то упоминали, что на полную разработку одной модели (все этапы, от эскиза/референсов до финальной приемки) в среднем проходит месяц.

Эта не может быть от слова совсем- если всё так как ты описываешь, либо что более вероятно над моделью работает 1.5 человека поэтому и делают месяц.
 

Что касается играть в свою собственную игру - я, хотя и приверженец этой позиции, тем не менее не очень понимаю, каким образом это является существенным критерием оценки качества работы администратора БД, программиста серверного бэкенда, operations engineer, да вообще половины геймдевовских IT профессий напрямую не связанных с гейм балансом/гейм мастерингом.

Ну гляди программист Петя Йохансонн придумал и воплотил TiDi - и доволен собой, поиграв при TiDi 10% он поймёт что надо работать более лучше и например, не смешивать боевую механику \с остальной механикой\ с записью и обращениями к БД (а спайк лага при бомбёжке например вызывается именно обращениями к БД)
Потому сейчас у них вообще всё в одном треде и гейммеханика (вообще вся от копки до планетарки) , и обращения к скилам и итем менджемент и транзакции в БД (и не удивлюсь если БД на HDD)

В текущей ситуации адекватного программиста днем с огнем не сыщешь, так пускай вместо отдыха между периодами вбивания пикселей в монитор он тратит свое свободное время на заправку ПОСов с целью что-то доказать ТСу? Боюсь, не самая лучшая идея.

Ты пропустил поинт ТС - он считает что в ЦЦП нет адекватных программистов , ну или они не работают над евой.
 

Геймдев и так не самая прибыльная отрасль для разработчика, особенно сейчас. Подобные чудо-предложения способны только загубить кое-как живущий проект, но никак ему не помочь.

Да лан в плане загубления ЦЦП и так сделало всё что могло 

 

Это нормально для любой дискуссии. Это я так, к слову.

В смысле не знать но с умным видом советовать? к сожалению да.
 
 

Я, к примеру, музыкант. Но если у меня спросят про принципы построения фуги - я абсолютно естественно пошлю собеседника за информацией в специализированную литературу. Так как объяснять долго, да и бессмысленно в рамках диалога с непрофессионалом на каком-то форуме. И вообще, с непрофессионалами на профессиональные темы говорить бессмысленно, в чем я убеждаюсь уже в течении многих лет. Думаю, аналогия ясна.

Ну вот гляди ты музыкант , а мы рассуждаем за тех процесс изготовления саксафонов, (ане простроения фуги- что побольшому счёту процесс творческий и может выполнен как за три часа так и за три года- те это сильно плохая аналогия)
Ну там литьё, ковка фрезеровка. Я вот лично саксафонов (перситент серваков на 100.000 ccu) не делал , но много работал с горнами (шардованные сервера на 4.000 ccu) и считаю саксафон не намного сложнее, ну да там клапана сложнее больше фрезеровки , но литьё и ковка те же самые так что цена и время будут укладываться в разы от горна а не в порядки. К томуже я слежу за индустрией и знаю например что мэйл сейчас разрабатывает новый саксофон, полифонический и стоит это не о мой бог на фоне горнов. (не шардованный сервер на 1.000.000 ссu и там онюдь не 100 программеров и оне получают отнюдь не по 100тыс баксов в год.)

И тут появляется некто и говорит что саксофоны это настолько омфг сложно что работать непереработать
Когда же его спрашивают -чего же там такого сложного - он прыгает в кусты. Знающий человек указал бы на фрезеровку (ну например на проблемы с синхронизацией между множественными многопоточными серверами игромеханик, ну или там типа фронтенд намиллион клиентов сделать сложно-хотя ничего особо сложного)
что уже повод для обсуждения, а нет аргументов нет и нормального обсуждения.

 

P.S. Гипотетический будущий владелец CCP с такой бизнес моделью разорит компанию, при чем стремительно.   

 Ну если с текущей политикой не разорилась - то любой новый может только помочь

Сообщение отредактировал alexflim: 13 August 2013 - 8:00

[Psihius]

alexflim

Технологии и развитие на сегодняшний день и 13 лет назад, когда ева только зараждалась - разные миры. Переделать движок евы сегодня на порядок сложнее, чем написать всё с 0. Писать всё с 0 никто не будет - потому что переделать нужно будет вообще ВСЁ - серверную часть, клиента, ассеты и вагон и маленькую тележку всего прочего. За те 10 лет резила в еве столько фитч, что разрабатывать будут лет 5 в лучшем случае, а то и дольше.

Занимаются распланированным размеренным апгрейдом подсистем, оптимизацией и рано или поздно дойдёт до самого ядра. Само ядро у них необходимости переписывать пока нету срочной - у них есть пачка более приоритетных подсистем, обновление которых даст гораздо больший эффект - "Brain in a box" всплывает в памяти к примеру. Так-же проблема существующих проектов в том, что им нужно не сломать всё то, что работает с данной конкретной подсистемой. И не важно какую игру возьми - времени и ресурсов на это нужно гораздо больше, чем писать с 0.

Сообщение отредактировал Psihius: 13 August 2013 - 14:13

[Ashu]

Я б еву удалил

[one_sk]

 
Эта не может быть от слова совсем- если всё так как ты описываешь, либо что более вероятно над моделью работает 1.5 человека поэтому и делают месяц.

 

Почему 1.5 человека делают месяц это по-твоему нормально? Бухой выпускник щуки за полчаса с бодуна же? Надо быть последовательным в своих убеждениях.

 

Это просто факты, сходу пруф не нагуглю, но он был. Разрабам танков в таком вопросе не к чему врать.

 

 

Потому сейчас у них вообще всё в одном треде и гейммеханика (вообще вся от копки до планетарки)

 

 

Открою страшную тайну - в Python есть GIL (Global Interpreter Lock), из-за которого разносить логику по потокам не то что не выгодно, а порою даже вредно для производительности. Само собой, я говорю про интерпретируемый код - нативные расширения вполне могут молотить на нескольких ядрах. Поэтому параллелят методом "один поток на процесс, процесс на ядро". Работает довольно неплохо при адекватной архитектуре.

 

Прежде чем ругаться на Python, замечу, что все критичное (навроде обсчета физики, ракет и пушек) у CCP давно спущено в нативные расширения. На момент же старта разработки евы (97-й год, на секундочку), адекватного языка с green threads кроме Stackless Python не было.

 

Предлагать же "переписать все на плюсах чтобы было быстро" могут только школьники, не понимающие сути проблем в производительности.

 

не смешивать боевую механику \с остальной механикой\ с записью и обращениями к БД (а спайк лага при бомбёжке например вызывается именно обращениями к БД)

 

 

 

Опять же, в девблогах упоминалось, что ортогональными функциями занимаются отдельные ноды - есть маркет ноды, чат ноды, грид ноды.  Маркет в жите никак не мешает ганкать в Akora.

Что до обращения к БД, то persistence внезапно очень важная вещь. Между откатами и лагами многие разработчики выберут лаги (потому что откаты по рассинхронам это очень мерзкая вещь, лучше их убивать в зародыше).

 

(и не удивлюсь если БД на HDD)

 

 

 

То, что для хранения БД CCP использует DRAM SSD производства RAMSAN, знают даже люди, очень далекие от евы. Быстрее на настоящий момент нет ничего. Афаик у Texas Memory Systems CCP первый гражданский клиент (до этого были строго американские военные)

 

он считает что в ЦЦП нет адекватных программистов

 

 

 

Адекватных программистов вообще мало. Это суровая реалия жизни. Таких, чтобы шарили в распределенном программировании со всеми его нюансами - вообще мизер. Странно что CCP  в такой маленькой стране как Исландия вообще смогли найти такие кадры, и при этом подняться с ног без жирного иностранного наукоемкого middleware.  Местами получилось не очень, но то, что получилось вообще - это феномен. Возьми любой город в РФ с населением Исландии (320к) и представь, что местные программисты основали контору которая способна породить продукт уровня EVE. Верится? Слабо. 

 

И тут появляется некто и говорит что саксофоны это настолько омфг сложно что работать непереработать
Когда же его спрашивают -чего же там такого сложного - он прыгает в кусты. Знающий человек указал бы на фрезеровку (ну например на проблемы с синхронизацией между множественными многопоточными серверами игромеханик, ну или там типа фронтенд намиллион клиентов сделать сложно-хотя ничего особо сложного)
что уже повод для обсуждения, а нет аргументов нет и нормального обсуждения.

 

 

 

 

Я вот лично саксафонов (перситент серваков на 100.000 ccu) не делал , но много работал с горнами (шардованные сервера на 4.000 ccu) и считаю саксафон не намного сложнее

 

 

 

Ну внезапно 100к ццу и 4к ццу это разница в 25 раз Ты лукавишь говоря что разница небольшая, ну или не имел опыта работы с такими проектами. По факту:

 

1) Твой траффик с внешних интерфейсов столь велик что способен завалить магистральный провайдер

2) Внутренняя сеть кластера на гигабит перестает справляться, а апгрейд до инфинибенда это сложно и дорого

3) Вылет винта, памяти, процессора на одной из машин - это статистически не редкость допускающая даунтайм, а нечто,  происходящее раз в сутки

4) Любое провисание, вызванное отвалом коннекта БД, сетевыми лагами, partition в сети - порождает за минуты бэклоги, которые синхронизируются часами, а при этом в этом inconsistent state надо работать.

 

У меня есть опыт масштабирования таких масштабов, и поверь, проблемы начинаются уже на 10к, и каждый новый рубеж порождает новые ботлнеки. Шардинг - это реально в разы проще. БелАЗ это не легковушка увеличенная в сто раз, это принципиально другая машина.

 

Если вспомнить те же танки, то они в свое время уперлись в 250к ццу на одном кластере, после чего ушли в шардинг с центральной БД. При этом шарды больше 150к теперь не создают. Хотя казалось бы, что может быть проще по масштабированию, чем бои 15 на 15.

 

Ну если с текущей политикой не разорилась - то любой новый может только помочь

 

 

 

Тьфу-тьфу, а последний год CCP имхо няшки и большую часть вещей делают правильно. Не сглазь. От добра добра не ищут

 

[Psihius]

one_sk

Тяжело с людьми, которые не понимают, что нагрузка не линейна и в какой-то момент начинает расти в геометрической прогрессии в лучшем случае, а в худшем вообще по экспоненте  А когда речь начинает идти о сетях и что разница в трафике между 100 и 1000 юзеров внезапно не в 10 раз, а в худшем случае в 100 раз - не понимают как это так

Сообщение отредактировал Psihius: 13 August 2013 - 15:02

[Solovey_R]

Deathclaw Я хочу спросить тебя как музыкант музыкант; Вы знаете принципы построения фуги?

[Deathclaw]

Deathclaw Я хочу спросить тебя как музыкант музыкант; Вы знаете принципы построения фуги?

 

Изучал..

Правда, писать не довелось, не до того было.

 

P.S. Впрочем, оффтоп.. 

[alexflim]

 

alexflim
Технологии и развитие на сегодняшний день и 13 лет назад, когда ева только зараждалась - разные миры. Переделать движок евы сегодня на порядок сложнее, чем написать всё с 0. Писать всё с 0 никто не будет - потому что переделать нужно будет вообще ВСЁ - серверную часть, клиента, ассеты и вагон и маленькую тележку всего прочего. За те 10 лет резила в еве столько фитч, что разрабатывать будут лет 5 в лучшем случае, а то и дольше.

Разрабатывать можно и 100 лет. Вопрос в том какикими силами и за какие деньги.
Я указал силы и деньги - и с такими силами и деньгами нет проблем написать с нуля еву в два раза лучше чем была.
Второе у евы глобально три затыка
1)Однопоточность
2) Питон
3) Дерьмовый мейн луп сервера- куда впихано и обращение к бд и гейммеханика и вообще всё

Так вот написать с нуля новое серверное ядро (мб сразу "облачное") это в разы легче чем переделывать то овно что ццп называют сервером с его корявым и уже никому не известным (об чём они сами признаются) легаси кодом.
Далее клиент не имеет НИКАКОГО отношения к серверу - ничто не мешает переписать сервер в ноль и оставить тот же клиент и теже данные в БД и тото же контент в клиенте.

Занимаются распланированным размеренным апгрейдом подсистем, оптимизацией и рано или поздно дойдёт до самого ядра. Само ядро у них необходимости переписывать пока нету срочной - у них есть пачка более приоритетных подсистем, обновление которых даст гораздо больший эффект - "Brain in a box" всплывает в памяти к примеру.

Брейн ин а бокс это всего навсего убирание из мейн лупа игромеханики пересчёта скилов (всех) каждый раз при смене шипа - это вообще не подсистема , а то что не надо было делать с самого начала и если уж сделали то должно было быть исправлено еще 5 лет назад.

Так-же проблема существующих проектов в том, что им нужно не сломать всё то, что работает с данной конкретной подсистемой. И не важно какую игру возьми - времени и ресурсов на это нужно гораздо больше, чем писать с 0.

Я один вижу протеворечие с первым абзацем?

 
 

Почему 1.5 человека делают месяц это по-твоему нормально? Бухой выпускник щуки за полчаса с бодуна же? Надо быть последовательным в своих убеждениях.

Следи за руками. Бухой выпускник щуки НАРИСУЕТ тайфун- на бумажке. За пол часа , да даже за десять минут и с бодуна.
Что никак не связано с тем что варгейминги тратят на новый танк 1 месяц

Это просто факты, сходу пруф не нагуглю, но он был. Разрабам танков в таком вопросе не к чему врать.

Модель в игре? (имплементированая уже как ассет) или модель вообще?


 

Открою страшную тайну - в Python есть GIL (Global Interpreter Lock), из-за которого разносить логику по потокам не то что не выгодно, а порою даже вредно для производительности. Само собой, я говорю про интерпретируемый код - нативные расширения вполне могут молотить на нескольких ядрах. Поэтому параллелят методом "один поток на процесс, процесс на ядро". Работает довольно неплохо при адекватной архитектуре.

Прежде чем ругаться на Python, замечу, что все критичное (навроде обсчета физики, ракет и пушек) у CCP давно спущено в нативные расширения. На момент же старта разработки евы (97-й год, на секундочку), адекватного языка с green threads кроме Stackless Python не было.

Да но сейчас 2013 и поэтому стоило бы переписать сервак.
 

Предлагать же "переписать все на плюсах чтобы было быстро" могут только школьники, не понимающие сути проблем в производительности.

Под аллоды ядро сервера переписывалось дважды при уже запущенном проекте.
 

Опять же, в девблогах упоминалось, что ортогональными функциями занимаются отдельные ноды - есть маркет ноды, чат ноды, грид ноды. Маркет в жите никак не мешает ганкать в Akora.
Что до обращения к БД, то persistence внезапно очень важная вещь. Между откатами и лагами многие разработчики выберут лаги (потому что откаты по рассинхронам это очень мерзкая вещь, лучше их убивать в зародыше).

Но ничто не мешает сделать отдельный диспетчер обращений к БД (виртуально шардированную) и работать через репликацию чтобы сохранять свой любимый персистанс, а не лазать туда из игромеханики и тормозить ея

То, что для хранения БД CCP использует DRAM SSD производства RAMSAN, знают даже люди, очень далекие от евы. Быстрее на настоящий момент нет ничего. Афаик у Texas Memory Systems CCP первый гражданский клиент (до этого были строго американские военные)

SSD нормально собранная база должна жрать 5000-7000 tps -тогда не было бы спайка лага при бомбёжке при уже работающем TiDi
Как вариант система обращений кривая и смерть шипа вызывает более чем 1 транзакцию (СИЛЬНО более чем одну- тк их не 3000 тыс зараз гибнет)

Адекватных программистов вообще мало. Это суровая реалия жизни. Таких, чтобы шарили в распределенном программировании со всеми его нюансами - вообще мизер. Странно что CCP в такой маленькой стране как Исландия вообще смогли найти такие кадры, и при этом подняться с ног без жирного иностранного наукоемкого middleware. Местами получилось не очень, но то, что получилось вообще - это феномен. Возьми любой город в РФ с населением Исландии (320к) и представь, что местные программисты основали контору которая способна породить продукт уровня EVE. Верится? Слабо.

Да исландия это опа. Но это не помешало иметь ЦЦП Шанхай и ЦЦП КФ - захотели бы сделали "программерский офис" в штатах
 

Ну внезапно 100к ццу и 4к ццу это разница в 25 раз Ты лукавишь говоря что разница небольшая, ну или не имел опыта работы с такими проектами. По факту:

По факту с игровыми проектами на 100к ццу имело дело столь малое количество людей что хватит пальцев чтоб всех пересчитать.
Однако оне есть.

1) Твой траффик с внешних интерфейсов столь велик что способен завалить магистральный провайдер
2) Внутренняя сеть кластера на гигабит перестает справляться, а апгрейд до инфинибенда это сложно и дорого
3) Вылет винта, памяти, процессора на одной из машин - это статистически не редкость допускающая даунтайм, а нечто, происходящее раз в сутки

1) ? это вы неподумавши игровой проект же
2) Чтож я такое передаю что у меня гигабита нехватает (вся бд будет пол террабайта дай бог)
3)Ну если у вас гугловый датацентр то наверно да, если у вас кластер на 100к кку то нет.
PS
Деградация SSD вполне предсказуемое явление и следовательно решается своевременной заменой.

4) Любое провисание, вызванное отвалом коннекта БД, сетевыми лагами, partition в сети - порождает за минуты бэклоги, которые синхронизируются часами, а при этом в этом inconsistent state надо работать.

У меня есть опыт масштабирования таких масштабов, и поверь, проблемы начинаются уже на 10к, и каждый новый рубеж порождает новые ботлнеки. Шардинг - это реально в разы проще. БелАЗ это не легковушка увеличенная в сто раз, это принципиально другая машина.

В игровом сервере отвал БД это падение сервера - тк операции с предметами(весь итем менеджмент) перестанут проходить (а если они у вас проходят при отвалившейся БД то у вас дико кривой код гейм механик серверов и архитектору надо оторвать руки)
PS
И что масштабировал? просто интересно.
 

Если вспомнить те же танки, то они в свое время уперлись в 250к ццу на одном кластере, после чего ушли в шардинг с центральной БД. При этом шарды больше 150к теперь не создают. Хотя казалось бы, что может быть проще по масштабированию, чем бои 15 на 15.

250к кку это достойная цифра применительно к еве этого было бы более чем достаточно. (онлайн за пять лет практически не изменился если не упал тк я помню цифры в 65к кку - сейчас в основном даже в выходные 50к кку)
PS
В случае с варгеймингами шардирование натуральное решение и можно было бы дробить хоть по 3к - просто резать более крупными кусками удобнее вплане обслуживания

PPS
Мэйловцы обещают на скафордже масштабирование до 1 млн кку.

Тьфу-тьфу, а последний год CCP имхо няшки и большую часть вещей делают правильно. Не сглазь. От добра добра не ищут

А чего там у нас такого было вообще сделано в последний год? ТиДи вроде в прошлом ещё, кружочки вместо квадратиков?

[Psihius]

Незнаю как вы, а я после последнего сообщения заблочил всё от alexfilm  Поздравте его, он первый за 6 лет моего прибывания на форуме

[one_sk]

Разрабатывать можно и 100 лет. Вопрос в том какикими силами и за какие деньги.
Я указал силы и деньги - и с такими силами и деньгами нет проблем написать с нуля еву в два раза лучше чем была.
Второе у евы глобально три затыка
1)Однопоточность
2) Питон
3) Дерьмовый мейн луп сервера- куда впихано и обращение к бд и гейммеханика и вообще всё

 

 

 

Однопоточность при подходе "один поток на один процесс" и "все через ipc" - внезапно работает.  Питон не зло. Спроси у гугла и NASA. Надо знать ограничения и правильно готовить. Судя по отдельным презенташкам в открытом доступе и инсайду из CCP - у них такое понимание есть. Да, легаси мешает. местами очень сильно, но проблемы решаются (stackless i/o, eve64, и т.д.)

 

Следи за руками. Бухой выпускник щуки НАРИСУЕТ тайфун- на бумажке. За пол часа , да даже за десять минут и с бодуна.
Что никак не связано с тем что варгейминги тратят на новый танк 1 месяц
Модель в игре? (имплементированая уже как ассет) или модель вообще?

 

 

 

омг, какое отношение имеет эскиз на бумажке к ассету в игре? В игре мы не на бумажках летаем, а на 3д моделях.

 

Не стоит передергивать, речь про полный процесс разработки модели от эскиза через моделлинг и текстуринг до ассета. С ее оценкой ты ошибся где-то на порядок. 

 

Да но сейчас 2013 и поэтому стоило бы переписать сервак.

 

 

 

Переписывать редко хорошая идея, практически в любом software engineering. Всегда есть чем заняться вместо, с большим выхлопом. Поэтому все так молятся на рефакторинг как на компромисс.

 

Насчет 2013 - называй альтернативы. Вот мне реально интересно, чем ситуация кардинально изменилась за это время, что питон перестал быть одной из очень серьезных альтернатив.

 

Под аллоды ядро сервера переписывалось дважды при уже запущенном проекте.

 

 

 

Личная просьба - мейлрушечку в целом и ололоды в частности в пример приводить не стоит, ок?

 

 

Да исландия это опа. Но это не помешало иметь ЦЦП Шанхай и ЦЦП КФ - захотели бы сделали "программерский офис" в штатах

 

 

 

Они появились когда ева относительно взлетела. До этого они работали чуть ли не за еду, и поначалу толком не верили что у них хоть что-нибудь получится.

 

 

По факту с игровыми проектами на 100к ццу имело дело столь малое количество людей что хватит пальцев чтоб всех пересчитать.

Однако оне есть.

1) ? это вы неподумавши игровой проект же
2) Чтож я такое передаю что у меня гигабита нехватает (вся бд будет пол террабайта дай бог)
3)Ну если у вас гугловый датацентр то наверно да, если у вас кластер на 100к кку то нет.
PS
Деградация SSD вполне предсказуемое явление и следовательно решается своевременной заменой.

 

 

 

1) Отнюдь - 10 гбит с шарда достигаются легко, если twitch controls, а не евастайл. Если это TCP, то цифры вполне терпимые, однако если трафик идет по UDP и имеет тенденцию к спайкам, то банально начинаются переполнения FIFO у маршрутизаторов, ресенды и дропы шкалят, паника, баны, звонки в 3 ночи. Это суровая реальность.

 

2) Если наружу уходит 10 гбит,  то внутри с не таким оптимизированным протоколом может быть еще больше. Большая часть сообщений ходит внутри нод через память, однако то, что надо прокинуть по rpc, может легко достигать существенных значений. Сотня метров в секунду - это тлен же, достаточно легко уперется даже не гоняя ассеты вроде серверных коллижен форм (а с ними еще проще).

 

3) Кластер на 100кку это на секундочку 30-150 server grade машин в зависимости от оптимизации. Ксеоны, 6 ядер,  2-4 проца, десятки-сотни гигабайт ecc ram - по-взрослому все. Да, не датацентр гугла, но симптомы намечаются.

 

Отвал никогда не является предсказуемым явлением. MTBF в 50000 часов не значит что ровно через 50к часов из ссд пыхнет сизым дымом и он отправится на небеса. Первое слово - mean, "среднее". Он может и через час откинуться, а может и никогда. По факту у гугла на среднем воркере может отваливаться до 10 винтов за день. На кластере в 100кку отвал винта, кернел паник у машины, сизый дым из сетевухи могут возникнуть раз в неделю. Останавливать из-за этого кластер - не вариант. На 4к это столь несущественно, что может считаться emergency.

 

В игровом сервере отвал БД это падение сервера - тк операции с предметами(весь итем менеджмент) перестанут проходить (а если они у вас проходят при отвалившейся БД то у вас дико кривой код гейм механик серверов и архитектору надо оторвать руки)

 

 

 

Игрокам глубочайше срать на то, что у тебя отвалился или протормаживает коннект к какой-то дальней базе. Поэтому в случае отвала с ограничением на некоторые операции можно и нужно жить, складируя транзакции в локальной базе, а потом реплицируя изменения. На суровых онлайнах за минуты их натекает столько, что репликация потом может затянуться на часы, и при этом надо сохранять консистентность. Ей богу, у тебя все так просто, нахера только CAP теорему выдумывали?

 

PS
И что масштабировал? просто интересно.

 

 

 

Извиняй, на этом форуме я предпочитаю оставаться лоусечным бичьем. Если реально важно - могу рассказать в ЛС. Хотя с большего очевидно ведь.

 

250к кку это достойная цифра применительно к еве этого было бы более чем достаточно. (онлайн за пять лет практически не изменился если не упал тк я помню цифры в 65к кку - сейчас в основном даже в выходные 50к кку)
PS

 

 

 

Думаю капасити сервера в списке причин, по которым кку евы невысок, находится где-то на предпоследнем месте. Как мысленный эксперимент представь себе фритуплей еву - вот там железо сразу затрещит.

 

 

В случае с варгеймингами шардирование натуральное решение и можно было бы дробить хоть по 3к - просто резать более крупными кусками удобнее вплане обслуживания

PPS
Мэйловцы обещают на скафордже масштабирование до 1 млн кку.
А чего там у нас такого было вообще сделано в последний год? ТиДи вроде в прошлом ещё, кружочки вместо квадратиков?

 

Шардирование - это плохо. Шардирование режет игроков по реалмам, накладывает ненужные ограничения. Танки хотели жить без шардов, а не смогли. По твоим словам там можно хоть 10 миллионов сделать.

 

А ты просто не учитываешь миллион нюансов, которые сходу и не видны, и большая часть из них связана с относительной рахитностью современного оборудования. Причем я не про SSD и процессоры, а про сети. В них основной затык.

 

И когда мейловцы покажут 1 млн кку на одном кластере - тогда и будет о чем говорить. В этом мире слишком много громких обещаний

Сообщение отредактировал one_sk: 14 August 2013 - 13:20

[alexflim]

 

Однопоточность при подходе "один поток на один процесс" и "все через ipc" - внезапно работает.  Питон не зло. Спроси у гугла и NASA. Надо знать ограничения и правильно готовить. Судя по отдельным презенташкам в открытом доступе и инсайду из CCP - у них такое понимание есть. Да, легаси мешает. местами очень сильно, но проблемы решаются (stackless i/o, eve64, и т.д.)

гугол и наса (при всём моём уважении к первому) не игровые компании. при всём моём уважении к питону - думаю мы оба понимаем что java+ что нибудь (хоть тот же постгресс) были бы быстрее при прочих равных.
 
 

омг, какое отношение имеет эскиз на бумажке к ассету в игре? В игре мы не на бумажках летаем, а на 3д моделях.

Если ты помнишь то про выпускника щуки мной было сказано в ответ на тезис о невероятной художественной ценности корабликов над которыми художник должен всздыхать не менее месяца. 

Не стоит передергивать, речь про полный процесс разработки модели от эскиза через моделлинг и текстуринг до ассета. С ее оценкой ты ошибся где-то на порядок.

Процесс эскиз->Задача->Согласование на модель и анимацию кней аутсорсерам в минск-> Согласование на текстуру высокой проработки в китай -> готовый ассет в игре
происходил на моих глазах неоднократно и занимал от 3 дней до недели
 

Переписывать редко хорошая идея, практически в любом software engineering. Всегда есть чем заняться вместо, с большим выхлопом. Поэтому все так молятся на рефакторинг как на компромисс.
 
Насчет 2013 - называй альтернативы. Вот мне реально интересно, чем ситуация кардинально изменилась за это время, что питон перестал быть одной из очень серьезных альтернатив.

Если компания не знает как работает её код (а ццп призналось что не знает) переписывание это необходимость
а не альтернатива.
Если говорить о конкретных реализация лично я бы думал в сторону Java+ постгресс
но с интересом услышу и твой вариант
чтоб ты взял при расчёте что надо держать 8к юзеров на локацию (чтоб на вырост)

Личная просьба - мейлрушечку в целом и ололоды в частности в пример приводить не стоит, ок?

Почему нет? я вот так не возьмусь сходу назвать РФ компанию с опытом написания поддержания и вообще эксплуатация ММО с такой инстал базой и кку. Ну Nikita таже - но шарды сферы это много скромнее и по кку и по аккам.
 

Они появились когда ева относительно взлетела. До этого они работали чуть ли не за еду, и поначалу толком не верили что у них хоть что-нибудь получится.

Угу появились как ева взлетела и что характерно совсем не для того чтоб еву бенефитить
 

1) Отнюдь - 10 гбит с шарда достигаются легко, если twitch controls, а не евастайл. Если это TCP, то цифры вполне терпимые, однако если трафик идет по UDP и имеет тенденцию к спайкам, то банально начинаются переполнения FIFO у маршрутизаторов, ресенды и дропы шкалят, паника, баны, звонки в 3 ночи. Это суровая реальность.

Если у тебя прямой клавиатурный ввод то это по факту udp , но сколько у тебя людей на шард что udp кушает 10гбит\с ? или сколько раз в секунду ты собираешь слать юдп пакет? 80 раз?
Ну и наконец у евы клик-бай с опросом раз в секунду- так что плотность трафа не проблема.

 

2) Если наружу уходит 10 гбит,  то внутри с не таким оптимизированным протоколом может быть еще больше. Большая часть сообщений ходит внутри нод через память, однако то, что надо прокинуть по rpc, может легко достигать существенных значений. Сотня метров в секунду - это тлен же, достаточно легко уперется даже не гоняя ассеты вроде серверных коллижен форм (а с ними еще проще).

Это плохо написанный сервер\протокол
В нормальном случае внутренний траф всегда меньше\равен внешнему тк внутри пересылать udp на ввод- никчему
я поверю что между фронт-енд->гейммеханика может  быть высокая загрузка (тк там собсвтенно основные пакеты то и снуют) но это решается тупым увеличением серваков с собственными каналами (вполть до максимума площадки- ева вроде в лондоне хостится -врядли там большие проблемы с каналом)
 

Отвал никогда не является предсказуемым явлением. MTBF в 50000 часов не значит что ровно через 50к часов из ссд пыхнет сизым дымом и он отправится на небеса. Первое слово - mean, "среднее". Он может и через час откинуться, а может и никогда. По факту у гугла на среднем воркере может отваливаться до 10 винтов за день. На кластере в 100кку отвал винта, кернел паник у машины, сизый дым из сетевухи могут возникнуть раз в неделю. Останавливать из-за этого кластер - не вариант. На 4к это столь несущественно, что может считаться emergency.

SSD это не HDD который работает работает потом бац умер- SSD деградирует овер тайм (помере того как ячейки выбирают предельное число циклов) - это отслеживаемый и предсказуемый процесс.

Игрокам глубочайше срать на то, что у тебя отвалился или протормаживает коннект к какой-то дальней базе. Поэтому в случае отвала с ограничением на некоторые операции можно и нужно жить, складируя транзакции в локальной базе, а потом реплицируя изменения. На суровых онлайнах за минуты их натекает столько, что репликация потом может затянуться на часы, и при этом надо сохранять консистентность. Ей богу, у тебя все так просто, нахера только CAP теорему выдумывали?

Я что то с трудом понимаю какую архитектуру ты имеешь ввиду и что есть "дальняя база"
Гляди есть диспетчер обращений к БД (ну он должен быть) с гейммеханики пришёл запрос на транзакцию
предмет id такоето перемещается в лут к пете васечкину. Он сливает его БД та перемещает предмет или там меняет его принадлежность , в общем проводит необходимые операции и возвращает ответ "предмет id такойто теперь у пети" после чего диспетчер возрващает прошедшую транзакцию на игромеханику а та сливает игроку и кликнет рисует появившийся у него в сумке лут.
Если БД вдруг не доступна - предмет тупо не переместиться (ответ от бд не вернулся) - и правильно сделает - тк если перместиться это прямой путь к дюпу и ряду других эксплойтов.
Я могу поверить что можно сделать резервную БД готовую в любой момент подставиться вместо первой - но я боюсь что 80% ресурсов тогда пойдёт на беспрерывную синхронизацию первой и второй
Тк сколько у вас будет транзакций на 100к кку? ну уж не меньше 5000 tps
Если же одна другую догоняет лишь во время ДТ и\или в момент падения нагрузки мне страшно представить все возможные проблемы с синхронизацией (что например делать если транзакция прошла и в основной и в резервной?)
помоему это будет плохо работать для мморпг

 

Шардирование - это плохо. Шардирование режет игроков по реалмам, накладывает ненужные ограничения. Танки хотели жить без шардов, а не смогли. По твоим словам там можно хоть 10 миллионов сделать.
А ты просто не учитываешь миллион нюансов, которые сходу и не видны, и большая часть из них связана с относительной рахитностью современного оборудования. Причем я не про SSD и процессоры, а про сети. В них основной затык.

Я имел ввиду шардирование БД (виртуальные шарды) - те когда юзеры разбиты между фрагментированной БД для оптимизации нагрузки - а не шардированный мир (что плохо) Касательно танков шардирование вообще не проблема тк юзеров можно кидать между шардами так что они даже и не заметят.  так что это лишь выбор более простого решения.

А касательно миллиона нюансов - конечно же я их не учитываю тк никогда не поднимал кластер на 100к кку .
Но напомню об чём начали спорить

Я считаю что 30 млн баксов и 3 лет времени более чем достаточно чтобы написать серверный код способный на такое. (а скорее дешевле раза так в 3)
Ты с этим не согласен? Если да- то кто тот затык что будет стоить дороже

Сообщение отредактировал alexflim: 14 August 2013 - 14:50

[Rekket]

Следи за руками. Бухой выпускник щуки НАРИСУЕТ тайфун- на бумажке. За пол часа , да даже за десять минут и с бодуна.

Не нарисует, в этом проблема.

[clop1000]

как всегда специалисты в любой области)))
я вобще удивляюсь как ццп живет))) а если ее улучшать то это вообще черевато)

[vizvig]

ЦЦП пилит дусты и ВоДы. А ева вылизана практически до блеска и занимает точно ту нишу  которую должна занимать, выпихивая оттуда всякие дейзи и фалауты-онлаены.

[Deathclaw]

Fallout - это святое! 

[Skyline]

Если разработчики будут играть,, то кто будет работать?

игроки то както работают.