И ещё. Люди по экономической системе ЕВЫ диссертации защищают, а в самой компании в штате состоит не один экономист далеко не нулевого уровня.

Мне кажется, вопрос «куда игрокам девать иски» у них уже давно не стоит.

В вашей логике изъян. Вы не учитываете стоимость модулей, которые не покрываются страховкой и зачастую стоят в 2 раза дороже самого корабля (а то и больше). Плюс расходники. Плюс налоги. Плюс содержание ПОСа. Плюс содержание ТКУ.

Если совсем быстро и на пальцах:
1) у покупателя есть 100 миллионов, у производственника 0, в общей экономике 100 миллионов.
2) производственник добывает ресурсы, затрачивая своё время, общей экономике по прежнему 100 миллионов + ресурсы
3) из ресурсов строится корабль, модули, патроны, расходники и продаётся покупателю. Теперь у покупателя 0 иск и корабль-модули-расходники. У производственника 100 миллионов и нет ресурсов. Общее количество благ в экономике 100иск + корабль-модули-расходники.
4) корабль уничтожается, модули по большей части уничтожаются, расходники тратятся и уничтожаются. За корабль приходит 2 ляма страховки.
Теперь у производственника 100 миллионов, у покупателя 2 миллиона и пара модулей за ещё пяток-другой миллионов, а в общей экономике 100 миллионов + модули.
5) Производственник, если не дурак, покупает плекс за 50 миллионов.
6) А теперь начинаем считать прочие расходы?..

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

Блин, дык бои же, в них и утекает. Матценности, по вашему, не денег стоят, что ли?

the legendary EVE Moonspeak, да ) Перевод нужен, или и так норм?

Именно так. Кто первый влез — того и тапки. Можно набить систему парой тысяч яиц и шаттлов, главное чтобы в них игроки сидели, и туда уже никто больше не залезет.

Ой, да какие тут могут быть атаки. :) Собрать толпу побольше у TCU, да развесить кемпы по гейтам. Когда придут гости — только primary да secondary вовремя объявлять. Вот и вся тактика в подобных свалках. :)

Все вопросы по числам — к килборде солярок.

Значит я не понял первоначальной формулировки сказанного. «Технические ограничения» могут быть разными :) Техническое ограничение — это «мамашип не пролезает в гейт». А «часами висели на блекскрине» — это проблемы железа EVE, которое не справлялось с нагрузкой. :)

В данном контексте я под обороняющимися имею ввиду N3PL, т.к. они пытались спасти свою потерянную систему. Ну и в целом я написал «у русских и у обороняющихся» — в драке между N3PL и CFC/RUS русские только одни. Сложно не догадаться, кто именно подразумевался под обороняющимися. ;)

Я в курсе что они не прыгают через гейты, сам в прошлом дредовод. Что мешало своим цину поднять где-нибудь внутри B-R5RB и присуммонить пачку капов и/или бридж титана?

Почему проблемы были у n3pl — известно. Закемпили соседние системы так, что никто пройти не мог. А у союзников-то проблемы почему были?

Слаженность и опыт? More like двухкратное преимущество в титанах, я бы сказал. 143 титана у CFC и 72 у N3PL. 273 мазершипа против 172-х. 56 логистов против 0. 817 (!) дредноутов против 355. 616 батлшипов против 1 (!). И только рядовых карьеров меньше — 233 против 414.

Ну и в целом у русских в бою засветился 3671 корабль, а у обороняющихся — 1615. Всего лишь перевес в два раза. А так да, конечно, слаженность и опыт игроков.

Вы тег irony забыли. Некоторые ведь и всерьез воспринять могут… :)

TDD хорошо когда есть четкое ТЗ и понимание что структура завтра не поменяется из-за изменившихся требований. Когда разработчик знает что «вот я щас напишу тесты, напишу код, всё заработает, и мне не надо будет это всё переделывать потом». К сожалению, реалии зачастую таковы, что клиент по ходу дела хочет то, хочет это, а потом так, сяк, и ещё эдак. И его не останавливает уже ПМовское «изменения > время > деньги». У него есть деньги, он хочет капризы. И когда 30-50% проекта переписывается, 15-25% codebase выбрасывается, а какой-то участок меняется уже четвертый раз, задумываешься — а стоит ли каждый раз писать тесты?.. В итоге примерно 15-20% времени разработчика улетает в пустоту. Коту под хвост. И опять, опять писать эти чёртовы тесты на эти чёртовы изменившиеся требования.

Разработка с TDD, как вы ожидаете это будет: написали тесты, написали код, выкатили, проверили, получили фидбек, утвердили, пошли дальше.
Как это есть на самом деле: написали тесты, написали код, выкатили, проверили, получили фидбек, не утвердили, переписали тесты, доправили код, повторили итерацию сначала ещё 2-4 раза.
Разработка code first: написали, выкатили, проверили, утвердили/не утвердили (и повторили 2 шага итерации), покрыли тестами, двинулись дальше.
Экономим время (но и хрен бы с ним), экономим нервы (а вот это уже ценно).

Не стоит считать что TDD — панацея. Стоит четко понимать, когда TDD стоит применять (четкое, неизменное ТЗ), а когда это просто не выгодно и безсмысленно. В частности в гибком и часто меняемом проекте TDD скорее лишний груз, который тянет команду назад. Который заставляет тратить время на то, что потом будет выброшено на помойку а результатом будет только излишнее раздражение команды.
В конце концов, все разработчики делятся на два типа: те кто не любит писать тесты, и те кто пи… врут.

С другой стороны, возможно в связи с этим сертификаты хоть немного упадут в цене.

Прелесссстно. А интеграция в будущем с ActiveMerchant (ruby) планируется?

А поддерживаете ли вы recurring payments? Если нет, то будете ли в будущем? В насколько далеком? А как у вас с API? А проведение платежа идёт с переходом через ваш сайт (а-ля робокасса)? А проведение платежа server side only (чтобы юзер даже и не знал о вашем существовании)? А recurring payments без участия клиента в дальнейшем (подписался — и раз в месяц деньги списываются)?

Ну, раз вы такой умный, расскажите нам, неучам, пожалуйста, в чем соль. Я без троллинга и без наезда, я абсолютно серьезно.