Как мне кажется, тут нет смысла как-то серьёзно обсуждать, поднимая пыль с холивара "третьи герои vs четвертые". Это разные игры. Автор не ставил себе задачу вот прям сравнить тонко механики, баланс и ламповость двух игр - тут всё решили 3 момента:
вкусовщина
так исторически сложилось
разница во времени между открытием 4 и 3 героев у автора (например, желание активно разбираться в 3 героях как в новой для себя игре может пропасть с годами, эффект "ёлочных игрушек, что не радуют")
Также многие комментаторы упоминают баланс как преимущество/недостаток. Вот на этом пункте хочу остановиться и отметить, что прежде нужно упомянуть, как игрок какой категории вы сравниваете 2 игры. Вот пример категорий:
Ностальгирующий казуал PvE (например: собиратель архиличей в 3 героях)
Казуал-хотситер (просто побегать с другом, зарашить капитолий)
Киберкотлета (разбиваемся героем, идём пробивать ГО на 121, боремся с таймером)
Баланс - очень важная, даже жизненно-важная вещь в соревновательной игре, где средний уровень задротства постоянно растёт - а с ним растут и требования ко всё большему соблюдению баланса. Ведь когда в сообществе много не самых опытных игроков - некоторый дизбаланс не так критичен для оппонентов, оба допускают ошибки. Для киберкотлет - уже каждый шажок, каждая секунда таймера на счету. Но это всё - речь о соревновательной игре. Для казуалов же, кто начинал играть в героев (третьих или четвертых - не важно), некоторый дизбаланс является той самой вещью, без которой игра для него станет унылой. Есть игровые механики, которые хорошо заходят PvE-игроку (механики с положительной обратной связью, где получение преимущества позволяет получить ещё больше преимущества) и именно они зацепляют начинающего игрока. Но в то же время, такие механики только лишь вносят больший дизбаланс и недопустимы в соревновательной игре, к которой не все игроки стремятся. Да, не каждый любитель покатать героев с ботами вечерком стремится стать киберкотлетой. И такой игрок запускает вечером игру, сидит в сладком ожидании собрать тысячи скелетов, собрать плащ короля нежити и обрушить всю эту несбалансированную мощь на компьютерного оппонента. Баланс? Такой игрок, установив хоту, сильно разочаруется, когда узнает, что все его любимые дизбалансные юниты - сильно понерфлены во имя соревновательного баланса, что игра развивается в направлении не для таких, как он. Тут нет смысла искать какую-то логику, просто игрок, как и автор, нашел то, что его зацепило когда-то, и просто хочет испытывать те же чувства, как когда-то. А в другой игре - будь то другая циферка версии или же другой аддон - уже не то.
Кажется, это была шутка как продолжение мысли в статье - "не тратьте время на неважные вещи". Комментатор на полпути осознал, проникся и поступил соответствующе совету из самой статьи. Ну и оценка статьи как "неважной". Почему тогда необходимость сообщить об этом в комментариях оказалось важной - вот это уже вопрос.
В этой линии сходу виднеется проблема: это же один сплошной bottleneck. Выход из строя любого важного элемента инфраструктуры может обрубить связь между двумя концами. И чем ближе к центру - тем больше потенциальный урон. Ладно электроэнергия, но жд, водопровод всякие должны быть как минимум продублированы на случай аварии - особенно жд (в 200 метров ширины не сильно много впихнешь). Ну и если параноить - на случай какого-нибудь карантина изолировать кусок "линии" будет непросто.
В детстве смотрел "битву роботов" - вот если бы статья была про постройку робота для подобного шоу - было бы интереснее. Там хоть и ограничения всякие, но роботы хотя бы боевые!
Если я правильно понял посыл, автор предлагает замести под ковер все неожиданные ситуации при работе с апи, мол, давайте апи будет заботиться о том, что кто-то может недостаточно тщательно подойти к тестированию (или невнимательно читать документацию) . Ну уж нет: явное лучше неявного. Если в системе нету принтеров, и в результате - о боже - вылетит исключение, то если его забыли обработать на этой системе - виноваты разработчики этой системы, а не апи (если, конечно, в документации апи явно указано, что такое-то исключение может быть брошено). Тем не менее, я соглашусь с тем, что изначально апи стоит проектировать так, чтобы оно не бросало исключений - в разных средах обработка исключений может быть тяжелой (привет с++) - лучше возвращать коды ошибок.
Так как по сути сроки решают за меня, я просто делаю задачи в обычном для меня темпе и в большинстве случаев успеваю. Нередко мне удается подвинуть сроки только лишь потому, что мои навыки все же ценят - просто кроме меня данную задачу мало кто сможет сделать так же быстро, ведь те, кто сможет - в таких конторах надолго не задеживаются.
Я работаю в Японии в бодишопе, и хотел бы рассказать, как на моем примере обстоят дела с разработкой в Японии.
Я как-то однажды об этом уже писал: в Японии разработка ПО, по сути, относится к сфере услуг, со всеми вытекающими. Помните знаменитые фразы "покупатель всегда прав" и прочее? Вот тут это возведено в абсолют, из-за азиатского менталитета "угодить покупателю заказчику любой ценой". И сроков это тоже касается. Твой менеджер спрашивает у тебя сроки, но они всегда упираются в "сделаем максимум за месяц", потому что заказчик имеет свое расписание, а дополнительных людей на проект выделять никто не будет. Также стоит держать в голове, что сторонними библиотеками почти наверняка пользоваться нельзя, ибо заказчик скорее всего не захочет возиться с лицензиями - так что никаких "кирпичиков", как пишут некоторые. За множество однотипных проектов собрал свои наработки в библиотеку? Тебе не разрешат ее использовать в следующем проекте, потому что это лишняя dll, хотя никаких причин для этого нет - разве что "заказчик может не захотеть", о чем заказчика менеджер на самом деле спрашивать не станет. Заказчик захотел 3д в приложении? Пиши на opengl с нуля. Ну как с нуля, приходится чуть ли не умолять менеджера, чтобы разрешил использовать glfw и glew (и то, представьте, когда вы сидите на митинге с заказчиком и менеджер заискивающим тоном сначала неловко спрашивает об этих 2 библиотеках, и тут же оговаривается, что в принципе можно обойтись и без любой из них, если заказчику "неуютно"). Когда тебя спрашивают почему ты хочешь их использовать - отвечаешь резонное "потому что имею опыт работы, в 3д-области это важно" - и тебе менеджер делает замечание, что так заказчику говорить нельзя, мол, я навязываю тем свой выбор... В общем, нельзя беспокоить заказчика, а точнее - как либо потенциально обременять. Чтобы вы понимали специфику - в Японии работники сферы услуг вечно кланяются и благодарят покупателей-посетителей за любой чих, и даже извиняются за то, что просто оказались на пути вашего взгляда до нужной вам полки с товаром. И вот подобное поведение проецируется и на разработку. Даже если это поведение вредит результату. Еще раз уточню - я не говорю за всех, но когда на корпоративах спрашиваешь у местного начальства, они утверждают, мол, это нормальный подход в японских компаниях.
Использую домашний NAS-диск, в который встроен transmission. Таким образом, пока комп выключен/спит, железка сама качает в себя. Покупал ради бэкапов, встроенный в железку торрент-клиент оказался приятным бонусом.
Вместо интерфейса я бы хотел обратить внимание на другое - цветовую гамму. Я никогда не понимал, как дизайнерам варкрафта - и его последователям (ВоВ, дота и прочие) пришло в голову взять и запихать всю цветовую палитру радуги одновременно на экран - когда даже трава на фоне своей яркостью соревнуется за внимание игрока. В той же доте - когда начинается драка, непривыкшему игроку будет трудно разобрать, где свои, где чужие, где среди них - мой персонаж, а вообще где курсор... И только спустя много сеансов выжигания сетчатки, начинаешь адаптироваться. Боковым зрением трудно разглядеть происходящее на миникарте, ибо даже миникарта начинает сливаться со всем цветовым разнообразием. Как хороший на мой взгляд пример - было сделано в WoT танках, где события на миникарте сразу замечались одним лишь боковым зрением. Ну или та же Lineage 2, где многим все может показаться тусклым, но лично я предпочитаю тот вариант, где самая большая яркость на экране "зарезервирована" только теми элементами, которые нужно будет найти сразу боковым зрением и при этом не будет тонуть в феерверке спецэффектов или, не дай бог, фона.
В Японии ездил на таком - особенно классно, когда такое "метро" выходит на поверхность и наоборот - едет по мосту над землей: обзор из лобового стекла просто шикарен!
Для повседневных нужд использую встроенный в Visual Studio гит. Да, в нем многого нет, но мне нравится его киллер-фича - поддержка синтаксиса в диффе (а с решарпером можно смотреть локальное изменение, не отрываясь от строчки в исходнике). Для всего остального - гит через консоль.
Тогда можно пойти ещё дальше и написать "компилятор", который распознает main(), но не распознает его содержимое - тогда наверняка можно ужать размер до феноменального минимума
Видел одно полезное применение таким видео: на стриме, где музыка/видео за донат, когда случается наплыв из донатов всяких гачи/русского рэпа и начинают вянуть уши, иногда находится донатер-спаситель и ставит вот такой вот видос с тишиной (даже пусть 5 минут тишины только - уже хорошо).
В мелькающей статье вроде бы было написано про банки по большей части. У нас в обычной софтверной фирме стоят системники без флоппи-дисководов, но еще с DVD-дисководами (часть лицензионного софта до сих пор выдают на дисках).
Как мне кажется, тут нет смысла как-то серьёзно обсуждать, поднимая пыль с холивара "третьи герои vs четвертые". Это разные игры. Автор не ставил себе задачу вот прям сравнить тонко механики, баланс и ламповость двух игр - тут всё решили 3 момента:
вкусовщина
так исторически сложилось
разница во времени между открытием 4 и 3 героев у автора (например, желание активно разбираться в 3 героях как в новой для себя игре может пропасть с годами, эффект "ёлочных игрушек, что не радуют")
Также многие комментаторы упоминают баланс как преимущество/недостаток. Вот на этом пункте хочу остановиться и отметить, что прежде нужно упомянуть, как игрок какой категории вы сравниваете 2 игры. Вот пример категорий:
Ностальгирующий казуал PvE (например: собиратель архиличей в 3 героях)
Казуал-хотситер (просто побегать с другом, зарашить капитолий)
Киберкотлета (разбиваемся героем, идём пробивать ГО на 121, боремся с таймером)
Баланс - очень важная, даже жизненно-важная вещь в соревновательной игре, где средний уровень задротства постоянно растёт - а с ним растут и требования ко всё большему соблюдению баланса. Ведь когда в сообществе много не самых опытных игроков - некоторый дизбаланс не так критичен для оппонентов, оба допускают ошибки. Для киберкотлет - уже каждый шажок, каждая секунда таймера на счету. Но это всё - речь о соревновательной игре. Для казуалов же, кто начинал играть в героев (третьих или четвертых - не важно), некоторый дизбаланс является той самой вещью, без которой игра для него станет унылой. Есть игровые механики, которые хорошо заходят PvE-игроку (механики с положительной обратной связью, где получение преимущества позволяет получить ещё больше преимущества) и именно они зацепляют начинающего игрока. Но в то же время, такие механики только лишь вносят больший дизбаланс и недопустимы в соревновательной игре, к которой не все игроки стремятся. Да, не каждый любитель покатать героев с ботами вечерком стремится стать киберкотлетой. И такой игрок запускает вечером игру, сидит в сладком ожидании собрать тысячи скелетов, собрать плащ короля нежити и обрушить всю эту несбалансированную мощь на компьютерного оппонента. Баланс? Такой игрок, установив хоту, сильно разочаруется, когда узнает, что все его любимые дизбалансные юниты - сильно понерфлены во имя соревновательного баланса, что игра развивается в направлении не для таких, как он. Тут нет смысла искать какую-то логику, просто игрок, как и автор, нашел то, что его зацепило когда-то, и просто хочет испытывать те же чувства, как когда-то. А в другой игре - будь то другая циферка версии или же другой аддон - уже не то.
Кажется, это была шутка как продолжение мысли в статье - "не тратьте время на неважные вещи". Комментатор на полпути осознал, проникся и поступил соответствующе совету из самой статьи. Ну и оценка статьи как "неважной". Почему тогда необходимость сообщить об этом в комментариях оказалось важной - вот это уже вопрос.
Есть простой способ проверить глаза на "битые пиксели":
Делаем так, чтобы на мониторе был одноцветный фон (главное, чтобы курсор мыши контрастировал с фоном).
Закрываем один глаз.
Смотрим одним глазом в центр монитора, строго в одну точку, не двигая глазом (можно смотреть расфокусированно вдаль, как будто насквозь).
Двигаем курсор мыши по экрану в разные стороны и следим за ним периферийным зрением.
Если в каких-то местах экрана курсор внезапно пропадает из виду - значит он попал в область с "битыми пикселями".
Повторяем для другого глаза.
Это ж какие умные часы должны быть, чтобы к ним надо было покупать два таких чемодана
А может он до сих пор не попался, раз о нём никто ничего не услышал)
В этой линии сходу виднеется проблема: это же один сплошной bottleneck. Выход из строя любого важного элемента инфраструктуры может обрубить связь между двумя концами. И чем ближе к центру - тем больше потенциальный урон. Ладно электроэнергия, но жд, водопровод всякие должны быть как минимум продублированы на случай аварии - особенно жд (в 200 метров ширины не сильно много впихнешь). Ну и если параноить - на случай какого-нибудь карантина изолировать кусок "линии" будет непросто.
В детстве смотрел "битву роботов" - вот если бы статья была про постройку робота для подобного шоу - было бы интереснее. Там хоть и ограничения всякие, но роботы хотя бы боевые!
Если я правильно понял посыл, автор предлагает замести под ковер все неожиданные ситуации при работе с апи, мол, давайте апи будет заботиться о том, что кто-то может недостаточно тщательно подойти к тестированию (или невнимательно читать документацию) . Ну уж нет: явное лучше неявного. Если в системе нету принтеров, и в результате - о боже - вылетит исключение, то если его забыли обработать на этой системе - виноваты разработчики этой системы, а не апи (если, конечно, в документации апи явно указано, что такое-то исключение может быть брошено). Тем не менее, я соглашусь с тем, что изначально апи стоит проектировать так, чтобы оно не бросало исключений - в разных средах обработка исключений может быть тяжелой (привет с++) - лучше возвращать коды ошибок.
Так как по сути сроки решают за меня, я просто делаю задачи в обычном для меня темпе и в большинстве случаев успеваю. Нередко мне удается подвинуть сроки только лишь потому, что мои навыки все же ценят - просто кроме меня данную задачу мало кто сможет сделать так же быстро, ведь те, кто сможет - в таких конторах надолго не задеживаются.
Я работаю в Японии в бодишопе, и хотел бы рассказать, как на моем примере обстоят дела с разработкой в Японии.
Я как-то однажды об этом уже писал: в Японии разработка ПО, по сути, относится к сфере услуг, со всеми вытекающими. Помните знаменитые фразы "покупатель всегда прав" и прочее? Вот тут это возведено в абсолют, из-за азиатского менталитета "угодить
покупателюзаказчику любой ценой". И сроков это тоже касается. Твой менеджер спрашивает у тебя сроки, но они всегда упираются в "сделаем максимум за месяц", потому что заказчик имеет свое расписание, а дополнительных людей на проект выделять никто не будет. Также стоит держать в голове, что сторонними библиотеками почти наверняка пользоваться нельзя, ибо заказчик скорее всего не захочет возиться с лицензиями - так что никаких "кирпичиков", как пишут некоторые. За множество однотипных проектов собрал свои наработки в библиотеку? Тебе не разрешат ее использовать в следующем проекте, потому что это лишняя dll, хотя никаких причин для этого нет - разве что "заказчик может не захотеть", о чем заказчика менеджер на самом деле спрашивать не станет. Заказчик захотел 3д в приложении? Пиши на opengl с нуля. Ну как с нуля, приходится чуть ли не умолять менеджера, чтобы разрешил использовать glfw и glew (и то, представьте, когда вы сидите на митинге с заказчиком и менеджер заискивающим тоном сначала неловко спрашивает об этих 2 библиотеках, и тут же оговаривается, что в принципе можно обойтись и без любой из них, если заказчику "неуютно"). Когда тебя спрашивают почему ты хочешь их использовать - отвечаешь резонное "потому что имею опыт работы, в 3д-области это важно" - и тебе менеджер делает замечание, что так заказчику говорить нельзя, мол, я навязываю тем свой выбор... В общем, нельзя беспокоить заказчика, а точнее - как либо потенциально обременять. Чтобы вы понимали специфику - в Японии работники сферы услуг вечно кланяются и благодарят покупателей-посетителей за любой чих, и даже извиняются за то, что просто оказались на пути вашего взгляда до нужной вам полки с товаром. И вот подобное поведение проецируется и на разработку. Даже если это поведение вредит результату. Еще раз уточню - я не говорю за всех, но когда на корпоративах спрашиваешь у местного начальства, они утверждают, мол, это нормальный подход в японских компаниях.Живя в Японии, меня больше волнует физическая целостность сего девайса, на случай землетрясения (у всех своя паранойя).
Он живет в локальной домашней сети, для работы торрент-клиента пробрасывается порт - и все делов.
Использую домашний NAS-диск, в который встроен transmission. Таким образом, пока комп выключен/спит, железка сама качает в себя. Покупал ради бэкапов, встроенный в железку торрент-клиент оказался приятным бонусом.
Вместо интерфейса я бы хотел обратить внимание на другое - цветовую гамму. Я никогда не понимал, как дизайнерам варкрафта - и его последователям (ВоВ, дота и прочие) пришло в голову взять и запихать всю цветовую палитру радуги одновременно на экран - когда даже трава на фоне своей яркостью соревнуется за внимание игрока. В той же доте - когда начинается драка, непривыкшему игроку будет трудно разобрать, где свои, где чужие, где среди них - мой персонаж, а вообще где курсор... И только спустя много сеансов выжигания сетчатки, начинаешь адаптироваться. Боковым зрением трудно разглядеть происходящее на миникарте, ибо даже миникарта начинает сливаться со всем цветовым разнообразием. Как хороший на мой взгляд пример - было сделано в WoT танках, где события на миникарте сразу замечались одним лишь боковым зрением. Ну или та же Lineage 2, где многим все может показаться тусклым, но лично я предпочитаю тот вариант, где самая большая яркость на экране "зарезервирована" только теми элементами, которые нужно будет найти сразу боковым зрением и при этом не будет тонуть в феерверке спецэффектов или, не дай бог, фона.
Если с титаном случился "чпок", то с титаником - "хрясь". И у обоих не выдержал корпус в столкновении с суровой физикой
В Японии ездил на таком - особенно классно, когда такое "метро" выходит на поверхность и наоборот - едет по мосту над землей: обзор из лобового стекла просто шикарен!
Для повседневных нужд использую встроенный в Visual Studio гит. Да, в нем многого нет, но мне нравится его киллер-фича - поддержка синтаксиса в диффе (а с решарпером можно смотреть локальное изменение, не отрываясь от строчки в исходнике). Для всего остального - гит через консоль.
Тогда можно пойти ещё дальше и написать "компилятор", который распознает main(), но не распознает его содержимое - тогда наверняка можно ужать размер до феноменального минимума
Видел одно полезное применение таким видео: на стриме, где музыка/видео за донат, когда случается наплыв из донатов всяких гачи/русского рэпа и начинают вянуть уши, иногда находится донатер-спаситель и ставит вот такой вот видос с тишиной (даже пусть 5 минут тишины только - уже хорошо).
В мелькающей статье вроде бы было написано про банки по большей части. У нас в обычной софтверной фирме стоят системники без флоппи-дисководов, но еще с DVD-дисководами (часть лицензионного софта до сих пор выдают на дисках).