[Перевод] Основы боевой системы в играх

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

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

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



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

Среди многообразия вариантов достижения наших целей я выделяю две ключевые характеристики:

• У каждого навыка своя уникальная функция: для оглушения соперника нажми сюда.


• Баланс навыков с точки зрения риск-выгода.

Давайте окунемся глубже в эти характеристики на примере игры Call of Duty.

1. У каждого навыка своя уникальная функция.

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

• Ближний бой. Охватывает зону перед игроком на близком расстоянии. Можно использовать только в упор, но убивает с одного удара.


• Обычный выстрел. Основное, часто используемое в любой момент времени умение игрока. Оптимально использовать на средней дистанции.


• Стрельба с прицелом. Идеально для точных выстрелов в голову на дальних расстояниях. Опасно использовать из-за потери преимущества периферического зрения.


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

Представляете какое многообразие вариантов “нажать нужную кнопку в нужное время” возникает у игрока с учетом использования любой из этих способностей в любой момент времени.

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

2. Риск VS награда. Компромисс для каждого навыка.

Помимо индивидуальных особенностей, каждый навык обладает своими достоинствами и недостатками. Давайте исследуем это на примере файтинга Street Fighter II.



Существует великое множество преимуществ и компромиссов, которые геймдизайнер может заложить в определенный навык.

Вот пример часто используемых в играх жанра экшн:

Преимущества: урон, оглушение, толчок, затяжной урон, ослепление, регенерация.

Компромиссы: расходуемые единицы, перезарядка, время активации, время восстановления.

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



Некоторые навыки позволяют вам не только атаковать соперника, но и совершать контратаки. Поэтому использование навыка в неподходящий момент приводит к промахам или что еще хуже к потерям HP. Контратака – это тоже определенный риск, который игрок берет на себя.

Три задачи.

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

Оценка расстояния

• Необходимо оценить расстояние до цели чтобы определиться со способностью.


• Нужно спрогнозировать место нахождения персонажа после использования способности.

Оценка времени

• Время необходимое для выполнения способности.


• Предвидеть продолжительность способности.

Сообразительность и предчувствие

• Необходимо предвидеть последовательность выполнения действий в различных ситуациях.


• Знать какие способности использовать для отражения атаки соперника.

Одна из главных целей присутствия врагов в игре – постепенное обучение игрока механикам игры каждый раз создавая интересные задачи.

Соперник – задача для игрока.

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

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

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

• Как игрок может атаковать и уничтожить врага?


• Как игрок может защищаться от атак врага?

Когда нужно продумать целую кучу разных соперников, мы стараемся создавать различные способы победить каждого из них. Вот пару примеров из игры Spider-man:





Как видно из примеров, разные соперники предлагают разные задачи для игрока, когда ему приходится защищаться от них:

• Лучшая способность игрока для защиты от ниндзя — увернуться. Главная задача для игрока — правильно использовать тайминги.


• Лучшая способность игрока для защиты от камикадзе — выстрелить паутиной. Главная задача для игрока — правильно оценить расстояние.

Возможности навыков игрока

Помимо продумывания различных задач для каждого соперника весьма интересно продумать слабости врагов против конкретного оружия. Необходимо продумать функции каждого оружия чтобы быть более или менее эффективным против разных противников. Вот зачем все это нужно:

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


• Помогает игроку узнать особенности каждого оружия.


• Подталкивает игрока к формированию собственной тактики при использовании способностей.

Пример из игры Halo иллюстрирующий это:



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

Основные архетипы врагов в играх жанра экшн

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

• Они предлагают решить простую для понимания задачу.


• Они легко узнаваемы.


• Игрок понимает без дополнительных инструкций как их одолеть.

Вот список наиболее часто встречающихся архетипов в экшн играх:

• Враг со щитом: задача для вышей точности.
  
  


• Танк: нужна мощная атака или оружие для уничтожения.
  
  


• Снайпер: атака на расстоянии чтобы попасть.
  
  


• Подрывник: ближний бой с ограничением по времени.
  
  

Подклассы и вариации архетипов.

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

Главная задача подклассов – подтолкнуть игрока к ограничению системы боя. Играя по знакомым ему правилам, добавить новые способности врагам, которые вынуждают игрока прокачивать другие навыки. До этого главное было отреагировать быстро, а теперь нужно еще и быть точным.

Хорошо если при создании соперников мы проанализируем выгодные свойства и усложняющие особенности каждого соперника.

Выгодные свойства врага позволят игроку использовать их для нанесения урона другим соперникам.

Усложняющие особенности врага усложнят задачу по его убийству.

Давайте посмотрим, как это работает на примере Mario:

Вот обычный архетип врага

• Он просто патрулирует маршрут и двигается в сторону игрока.


• Нужно прыгнуть на него чтобы одолеть.


• В результате его панцирь можно использовать для убийства других врагов.

А вот подкласс вражеского архетипа

• Он просто патрулирует маршрут и двигается в сторону игрока.


• Он может двигаться по воздуху (усложняющая особенность).


• В результате его панцирь можно использовать для убийства других врагов.

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

Пример управления рисками и выгодой:

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

Например, есть враг со щитом и слабой зоной на спине. Если игрок попадет в нее несколько раз, соперник взорвется.



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



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

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

[Перевод] Простое объяснение движения денег в банковской системе

От переводчика:В последние месяцы в жизнь многих людей прочно вошли новости сферы финансов. Одна из недавних тем — возможное отключение России от системы SWIFT. Угроза выглядит очень серьезно, но что на самом деле грозит стране, если события будут развиваться по этому сценарию? Наш сегодняшний материал призван помочь разобраться с тем, как все устроено в глобальном мире финансов.

На прошлой неделе [статья опубликована в ноябре 2013] Twitter сошел с ума из-за того, что кто-то перевел почти 150 миллионов долларов за одну транзакцию в криптовалюте. Появление такого твита было в порядке вещей:

Транзакция 194 993 биткоинов стоимостью в 147 миллионов долларов порождает много тайн и спекуляций

Было много комментариев о том, насколько дорого и сложно было бы это реализовать в обычной банковской системе, и, вполне возможно, что так оно и есть. Но при этом я обратил внимание вот на что: по своему опыту знаю, что почти никто не понимает, как на самом деле работают платежные системы. То есть: когда вы «перечисляете» денежные средства поставщику или «производите платеж» на чей-либо счет, как деньги переходят с вашего счета на счета других?

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

Для начала найдем точки соприкосновения

Думаю, прежде всего, нужно понимать, что банковские депозиты являются обязательствами [банка перед вами]. Когда вы кладете деньги в банк, фактически у вас нет депозита. Это не мешок с деньгами, на котором написано ваше имя. Вместо этого, вы дали взаймы эти деньги банку. Он должен их вам. Эти деньги становятся одним из обязательств банка. Именно поэтому мы говорим, что наши деньги находятся на кредитном счету: мы предоставили банку кредит. Аналогично, если вы превышаете кредит и оказываетесь должны банку, это становится уже вашим обязательством и их активом. Чтобы понимать, как движутся деньги, важно понять, что каждую запись в бухгалтерском отчете можно рассматривать с этих двух точек зрения.

Перевод средств на счет клиента того же банка

Начнем с простого примера. Представьте, будто вас зовут Элис, и вы являетесь клиентом, скажем, банка Barclays. Вы должны 10 фунтов своему другу по имени Боб, который тоже пользуется услугами Barclays. С Бобом легко расплатиться: вы говорите банку о своих намерениях, он снимает денежные средства с вашего счета и вносит 10 фунтов на счет вашего друга. Процедура осуществляется в электронном виде через автоматизированную банковскую систему Barclays, все предельно просто: деньги ни поступают в банк, ни выводятся из него; происходит лишь обновление системы счетов. Банк должен вам на 10 фунтов меньше, а Бобу – на 10 фунтов больше. Все уравновешивается, и все происходит внутри банка: говорят, что транзакция «зафиксирована» в бухгалтерских книгах банка. Это представлено на схеме ниже: участие принимают лишь три стороны – вы, Боб и Barclays. (Естественно, тот же анализ можно провести, если вы осуществляете транзакцию в евро через Deutsche Bank или в долларах через Citi и т.п.)

Но что происходит, когда вам нужно перевести деньги на счет клиента другого банка?

Здесь ситуация интереснее. Представьте, что вам нужно заплатить некоему Чарли, клиенту банка HSBC. Возникает проблема: банку Barclays несложно снять 10 фунтов с вашего счета, но как им убедить HSBC, чтобы те увеличили счет Чарли на 10 фунтов? Зачем банку HSBC соглашаться на то, чтобы быть должными Чарли больше, чем раньше? Они же не благотворительная организация! Ясно, что ответ заключается в том, что, если мы хотим, чтобы HSBC были должны Чарли немного больше, им нужно быть должными кому-то другому немного меньше.

Кем же должен быть этот «другой»? Это точно не Элис: если помните, она никак не связана с HSBC. Методом исключения выясняется, что единственный возможный вариант – это Barclays. И первое, что при этом приходит на ум: что, если HSBC откроет счет в Barclays, а Barclays откроет счет в HSBC? Каждый из банков мог бы открыть счет в другом банке и регулировать эти счета для решения такого рода проблем…

Вот как можно поступить:

• Barclays могут снять 10 фунтов со счета Элис


• Затем Barclays могут добавить 10 фунтов к счету HSBC, открытому в банке Barclays


• После этого Barclays могут послать сообщение HSBC о том, что они увеличили их счет на 10 фунтов и хотели бы, чтобы те, в свою очередь, увеличили на 10 фунтов счет Чарли


• HSBC получили бы это сообщение и, зная, что у них есть лишние 10 фунтов на депозите в Barclays, могли бы увеличить счет Чарли.

Все уравновешивается для Barclays и HSBC. До этого Barclays были должны 10 фунтов Элис, теперь они должны 10 фунтов банку HSBC. HSBC до этого были на нуле, теперь они должны 10 фунтов Чарли, а Barclays должны 10 фунтов им.

Такая модель обработки платежей (и ее более сложные разновидности) известна как деятельность банков на основе корреспондентских отношений. Графически ее можно представить подобно схеме, представленной ниже. В качестве основы берется предыдущая схема и добавляется второй коммерческий банк; важно отметить, что наличие корреспондентских отношений позволяет банкам облегчить выплату платежей соответствующим клиентам.

Схема работает довольно неплохо, но возникают некоторые сложности:

• Наиболее очевидно, что такое возможно лишь в случае, когда два банка поддерживают непосредственную связь друг с другом. В противном случае либо у вас не получится произвести платеж, либо вам нужно будет проложить маршрут через третий (или четвертый!) банк, пока вы не завершите путь из пункта А в пункт Б. Безусловно, это увеличивает расходы и степень сложности. (Некоторые специалисты ограничивают использование понятия «корреспондентские отношения» ситуациями с участием различных валют, однако мне кажется, что данный термин полезно применять даже в более простых ситуациях)


• Больше беспокойства вызывает тот факт, что это еще и рискованно. Взгляните на ситуацию с позиции банка HSBC. Результатом произведенного ими платежа стала повышенная уязвимость со стороны Barclays. В нашем примере – всего на 10 фунтов. Но представьте, что сумма составила 150 миллионов фунтов, и банком-корреспондентом был не Barclays, а менее крупная и, возможно, менее надежная организация: у HSBC возникли бы большие неприятности, если бы этот банк разорился. Один из путей решения – внести небольшое изменение в самой модели: вместо того чтобы зачислять средства на счет HSBC, Barclays могли бы попросить HSBC списать деньги со счета, которым пользуется Barclays. Тогда не было бы нужды в крупных межбанковских расчетах. Однако при таком подходе возникают другие сложности и, так или иначе, взаимозависимость, присущая этой модели, является достаточно большой проблемой.

В дальнейшем мы поговорим о некоторых из этих сложностей.

[Замечание: это не то, что происходит сегодня *на самом деле*, так как вместо этого используются системы, описанные далее, но я считаю, что было логично начать историю именно так, чтобы вы четко могли представить происходящее]

Погодите… зачем все усложнять? Нельзя ли просто воспользоваться системой SWIFT [англ. Society for Worldwide Interbank Financial Telecommunications – Международная межбанковская система передачи информации и совершения платежей] и покончить с этим?

Как правило, во время обсуждения платежных систем обязательно найдется человек, который будет махать руками, кричать «SWIFT» и считать, что вопрос решен. По-моему, это только подтверждает, что такие люди, наверняка, не понимают, о чем говорят.

Сеть SWIFT позволяет банкам беспрепятственно обмениваться друг с другом электронными сообщениями. Один из типов сообщений, который поддерживается сетью SWIFT – это MT103. MT103 дает возможность одному банку давать указания другому банку, чтобы последний перечислил сумму на счет одного из своих клиентов, в то время как та же сумма списывается со счета организации, посылающей сообщение, в банке, принимающем его, так чтобы все уравновешивалось. Можете представить, как сообщение MT103 применялось бы в случае, описанном в предыдущей части.

Таким образом, в результате отправления сообщения MT103 в сети SWIFT деньги «пересылаются» между двумя банками, но особенно важно понять, что же происходит на самом деле: сообщение по сети SWIFT – всего лишь указание; движение денежных средств осуществляется при их перечислении на некоторые счета и зависит от банков, имеющих счета в других банках (непосредственно или через банки-посредники). Просто махать руками и кричать: «SWIFT!», – значит скрывать эти сложности, и поэтому препятствовать пониманию системы.

Ладно… Понятно. А как быть с ACH, EURO1, Faster Payments, BACS, CHAPS, FedWire, Target2 и так далее, и так далее????

Стоп… Давайте-ка сначала вкратце повторим.

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

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

Кроме того, мы обсудили, как системы электронного обмена сообщениями вроде SWIFT могут управлять потоком информации между двумя банками и следить за тем, чтобы переводы осуществлялись быстро, надежно и дешево.

Но у нас есть, что еще обсудить… так как возникают такие серьезные вопросы, как риск контрагента, ликвидность и расходы.

Сначала рассмотрим ликвидность и расходы.

Нам необходимо решить проблему ликвидности и расходов

Во-первых, нужно учесть, что сеть SWIFT стоит денег. Если бы Barclays нужно было посылать сообщение по сети SWIFT банку HSBC каждый раз, когда вы захотите перевести на счет Чарли 10 фунтов, в скором времени вы бы обнаружили существенные затраты в своей выписке. Но что хуже, возникает более серьезная проблема – ликвидность.

Подумайте, сколько денег понадобилось бы Barclays, чтобы каждый день находиться на связи со всеми банками-корреспондентами, если бы система, описанная ранее, применялась на практике. Им нужно было бы иметь крупные суммы на счетах во всех других банках на случай, если один из их клиентов захочет перевести деньги на счет клиента HSBC, Lloyds, Co-op или куда-нибудь еще. Эти наличные можно было бы вложить, дать взаймы или еще каким-либо образом потратить.

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

То есть что, если бы мы продолжали отслеживать все многочисленные платежи в течение дня и фиксировали бы только разницу? При таком подходе у каждого из банков могло бы быть гораздо меньше наличных на каждом из корреспондентских счетов, и каждый смог бы вложить свои деньги эффективнее, сокращая при этом затраты и (хотелось бы надеяться) пересылая часть этих денег в ваш банк. Такие рассуждения привели к появлению систем отложенных нетто-расчетов (СОНР). В Великобритании такой системой является BACS, и в любой стране можно найти ее аналоги. В таких системах не обмениваются сообщениями через сеть SWIFT. Вместо этого, сообщения (или файлы) попадают в центральную «клиринговую» систему (такую как BACS), которая отслеживает все платежи и затем в определенные сроки рассчитывает нетто-сумму, которую каждый из банков должен любому другому банку. После этого они проводят между собой определенные операции (возможно, пересылая денежные средства на/со счетов, которые каждый из банков имеет в другом банке) или применяют систему RTGS, описанную далее.

Такой метод значительно сокращает требования к затратам и ликвидности и дополняет нашу схему еще одним блоком:

Стоит обратить внимание на то, что таким же образом (как СОНР) можно описать механизмы использования кредитных карт и даже системы PayPal: все они характеризуются процессом расчета внутренних транзакционных издержек, результатом которого является только нетто-сумма, определенная для крупных банков.

Но и при таком подходе возникает потенциально более серьезная проблема – потеря завершенности расчета. Вы можете отправить указание по вашему платежу утром, однако банк-получатель не сможет получить (чистые) денежные средства до определенного момента.

Поэтому банку-получателю приходится ждать получения (чистого) расчета по счету на случай возможного банкротства отправителя во время перевода: было бы опрометчиво перечислять средства принимающей стороне заранее. В результате возникает задержка.

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

Можно ли достичь и завершенности расчета, и нулевого риска контрагента?

Здесь как раз и складываются все кусочки мозаики. Ни один из подходов, рассмотренных ранее, нельзя применить в ситуациях, где нужно быть абсолютно уверенным, что платеж осуществится быстро, и его нельзя будет отменить, даже если банк-отправитель впоследствии разорится. Вам крайне необходима такого рода гарантия, например, если вы намерены создать систему расчетов по операциям с ценными бумагами: никто не предоставит вам 150 миллионов долларов облигациями или акциями, если есть риск, что эти 150 миллионов не будут выплачены, или их нельзя будет вернуть!

Необходима система, подобно первой из тех, что мы рассматривали (Элис переводит деньги на счет Боба в том же банке) – так как в ней все происходит действительно быстро – но которая будет работать при участии более чем одного банка. Многосторонняя межбанковская система, рассмотренная ранее, вроде бы работает, но становится довольно запутанной при переводе достаточно крупных сумм и при наличии вероятности того, что тот или иной банк может разориться.

Вот если бы банки могли иметь счета в таком банке, который не сможет обанкротиться… своего рода банк, который находился бы в самом центре системы. Можно придумать ему название. Назовем его центральным банком!

Следуя этой логике, возникает идея системы валовых расчетов в режиме реального времени [англ. Real-Time Gross Settlement system, RTGS].

Если все крупнейшие банки страны будут иметь счета в центральном банке, они смогут переводить деньги из одного банка в другой, просто давая указания центральному банку на списание средств с одного счета и их зачисление на другой. Для этого и предназначены системы CHAPS, FedWire и Target 2, которые занимаются переводами фунтов, долларов и евро соответственно. Эти системы осуществляют движение денежных средств в режиме реального времени между счетами, которые банки имеют в соответствующем центральном банке. Итак, это система:

• Валовых – никакого учета задолженностей (иначе система не смогла бы быть мгновенной)


• Расчетов – наличие завершенности; никакого возврата средств


• В режиме реального времени – расчеты осуществляются мгновенно.

Эта система завершает нашу схему:

Я думал, эта статья как-то связана с Bitcoin

Хорошо, что напомнили. Теперь встает вопрос: можно ли поместить в эту модель Bitcoin?

Мне кажется, что Bitcoin очень сильно напоминает систему RTGS. В ней нет учета задолженности, (очевидно) нет корреспондентских отношений между банками, и все расчеты валовые, завершенные.

Однако «традиционный» финансовый ландшафт интересен тем, что большинство розничных сделок сегодня осуществляются не через систему RTGS. К примеру, прямые электронные платежи между жителями Великобритании осуществляются через систему ускоренной оплаты FPS [англ. Faster Payments system], выполняющей зачет встречных требований несколько раз в день, не мгновенно. Почему так? Я бы сказал, потому что, в первую очередь, FPS – (почти) бесплатная, в то время как стоимость платежей в системе CHAPS составляет 25 фунтов. Многие клиенты, наверняка, пользовались бы системой RTGS, если бы она была такой же удобной и дешевой.

Поэтому мой вопрос, оставшийся без ответа: останется ли система платежей Bitcoin лишь подобием традиционной RTGS, осуществляющей только наиболее значимые переводы? Или же изменения в базовой сети (ограничения по размерам блоков, каналы для микроплатежей и т.д.) произойдут и будут происходить достаточно быстро с увеличением объемов сделок, позволяя системе оставаться доступной как для более значимых, так и для менее значимых платежей?

Мне кажется, вопрос еще остается открытым: я уверен, что Bitcoin изменит мир, но вместе с тем я не так уверен, что мы будем жить в мире, где каждая транзакция, проведенная с помощью сети Bitcoin, «пройдет» через базу Blockchain.

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Доступ к аккаунту GoDaddy удалось получить с помощью фотошопа

Недавно была опубликована статья, о том, как удалось обойти многоуровневую систему защиты крупнейшего регистратора GoDaddy при помощи фотошопа.

Автор статьи Стив Рейган провел эксперимент: он попросил знакомого специалиста по безопасности Винни Троя, директора Night Lion Security, взломать его аккаунт. Взлом оказался успешным, и все, что для этого понадобилось — звонок в техподдержку и несколько часов работы в фотошопе.

Процедура восстановления оказалась легкой. Разговор с девушкой из техподдержки начался с подтверждения личных данных, легко доступных через Whois. Когда понадобился адрес электронной почты, на который был зарегистрирован домен и который Троя не знал, он вошел в роль расстроенного подчиненного, которому не дали полной информации, и о сложных правилах внутри организации. Шум играющей дочери во время разговора также создал подходящую атмосферу для того, чтобы подавить на жалость оператору техподдержки.

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

Эту особенность работы операторов часто используют мошенники.

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

После этого она направила Троя на страницу, через которую владелец домена может восстановить свои права на него, представив фото документа, удостоверяющего личность.

Около четырех часов понадобилось взломщику на то, чтобы подделать водительское удостоверение на имя Стива Рейгана. Также он создал адрес электронной почты Gmail и аккаунт в Google+ на его имя. Этого было сделано для того, чтобы создать иллюзию присутствия Троя в сети как Стива Рейгана.

Оператора удовлетоврили полученные данные. Соответствие фотографии в «удостоверении», сделанном в фотошопе реальной фотографии Рейгана никто проверять не стал. Не было и никаких других проверок личности заявителя.

Последним ее вопросом были данные о юридическом лице, на которое были зарегистрированы домены. Троя также честно ответил, что у него нет информации об этом. На что она сама пошла навстречу взломщику, сказав, что это обычное дело, и многие регистрируют домены на несуществующие фирмы.

После этого аккаунт был перерегистрирован на почтовый адрес Троя, и тот получил к нему полный доступ. Операция завершена успешно.

Стоит отметить и то, что Стив Рейган получил уведомление о смене данных аккаунта не сразу, а только через несколько дней. Если бы взлом был настоящим, вернуть домены, скорее всего, было бы невозможно: их бы уже продали или перевели к другому регистратору.

Функция восстановления доступа через фото документа ненадежна, и многие регистраторы не пользуются ей как раз потому, что каждый может нарисовать что угодно в фотошопе. Однако у крупнейшего регистратора в мире GoDaddy она есть. Эта возможность была введена для того, чтобы пользователи могли восстановить права на домены, зарегистрированные много лет назад. Пользователи часто не помнят номера старых кредитных карт и другие данные.

Однако риск взлома аккаунтов GoDaddy с ее помощью очень высок, и регистратору стоит изменить эту процедуру. Интересно, что, например, Network Solutions также восстанавливает права на домены через личные документы, только их необходимо передавать по факсу, а не загружать фото с компьютера.

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

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Mirantis OpenStack 6.0: теперь с плагинами

Авторы: Николай Марков, Илья Стечкин, Ирина Поволоцкая

Неудержимо приближается глобальный OpenStack-саммит. Эта заоблачная тусовка проходит два раза в год в разных городах мира (в этот раз, например, чести принимать мероприятие удостоился Ванкувер) и дает возможность всем, кто так или иначе заинтересован в развитии экосистемы OpenStack, обменяться новостями и заодно определить, в каком направлении будет развиваться платформа. А кроме того, саммит дисциплинирует разработчиков, заставляя оперативно допиливать новые версии дистрибутивов, чтобы представить их почтеннейшему собранию. Mirantis — не исключение.

Мы готовим доработки к нашему актуальному — шестому — релизу Mirantis OpenStack (или MOS, как называют его для простоты). Но все-таки главные изменения уже произошли. А мы с вами отстаем от жизни — только что успели поговорить про изменения, произошедшие в предыдущем релизе и связанные с контейнеризацией приложений при помощи Docker.

Между тем, ничто не стоит на месте. В MOS 6.0 контейнеризация, безусловно, используется. Но главным новшеством стал переход на архитектуру, предоставляющую возможность работы с плагинами (pluggable architecture). Это важно уже хотя бы потому, что у вас теперь есть возможность встраивать собственные плагины во Fuel — инструмент развертывания MOS-клауда и дальнейшего управления им. Но мы уже рассказывали о Fuel подробнее в предыдущем посте. А в этом нас больше интересуют плагины.

Почему плагины?

Невозможно предугадать все уникальные потребности пользователей: кому-то нужен NFS, а кто-то жить не может без LbaaS (Load-Balancing-as-a-Service)… Вместо того, чтобы каждый раз создавать уникальный дистрибутив под задачи конкретного клиента (а это увеличивает сроки развертывания облака и стоимость проекта), мы сделали из MOS конструктор. И теперь для кастомизации дистрибутива достаточно создать соответствующий плагин. Мы начали собирать коллекцию сертифицированных плагинов: банк типовых решений позволит нашим клиентам еще более ощутимо экономить деньги и время (и это при том, что решения Mirantis уже сейчас выгодно отличаются ценой от других поставщиков облачных решений, играющих на российском рынке).

Что такое сертификация плагинов?

Процедура сертификации не является обязательной для разработчиков плагинов. Однако если вы все-таки решились, то нужно понимать, что при сертификации к плагину предъявляется ряд требований и он проходит более тщательную проверку. Для нас “сертифицированный плагин” — это, в первую очередь, проверенный, надежный, безопасный для использования, то есть такой, который ничего не поломает в окружении. Когда мы обещаем тщательную проверку, это значит, что тестирование плагина будет производиться непосредственно PI (Partner Integration) командой согласно тест-репорту: берется ряд кейсов из репорта и повторяется нашими специалистами. Это значит, что перед сертификацией плагин уже должен быть протестирован согласно установленной процедуре и результаты этого теста должны быть представлены в PI нашей компании. Таким образом наша проверка — повторная. Полученный результат сравнивается с тем, что описан в репорте. Еще раз обращаем внимание на то, что процедура сертификации является сугубо добровольной. Наличие у плагина сертификата означает только то, что Mirantis гарантирует его стабильную работу и поддержку.

Плагины с точки зрения пользователя

1) Зайдите в каталог плагинов на сайте Mirantis;

2) выберите плагин и скачайте его;

3) скопируйте выбранный плагин на мастер ноду при помощи secure copy:

scp fuel_plugin_name-1.0.0.fp root@:master_node_ip:/tmp

cd /tmp

fuel plugins --install fuel_plugin_name-1.0.0.fp

4) После того, как вы создадите новое окружение, в пользовательском интерфейсе Fuel, во вкладке “Настройки” (Settings) поставьте “галочку” в чекбоксе (при необходимости — заполните дополнительные поля для плагина);

5) доконфигурируйте окружение;

6) раздеплойте облако;

7) с удовольствием пользуйтесь плагином.

Обратите внимание: для работы с плагином его нужно установить ПЕРЕД тем, как развертывать и конфигурировать окружение. В противном случае вам придется повторить процедуру развертывания окружения, чтобы получить возможность подключить установленный плагин.

Плагины с точки зрения разработчика

Напишите код плагина, который выполняет его бизнес-логику, а также составьте описание плагина так, как описано в инструкции (Engl).

Когда готово — возьмите fpb и постройте свой плагин, чтобы его можно было поставить (в процессе разработки это просто код и пакеты).

Для того, чтобы упростить разработчикам процедуру создания новых плагинов, мы разработали инструмент под названием Fuel Plugin Builder, который, по сути является простой утилитой для командной строки, позволяющей быстро и без лишних усилий создавать “скелет” для вашего будущего плагина. Как вы уже поняли, мы не меценаты — нам выгодно, чтобы как можно больше новых разработчиков пополняли банк сертифицированных плагинов. Только поэтому мы заботимся о разработчиках! ;)

Что еще новенького в MOS 6.0, кроме плагинов

Но не плагинами едиными богат MOS 6.0. Мы традиционно подгадываем обновления дистрибутива к выходу новой версии платформы, поэтому нет ничего удивительного в том, что MOS 6.0 поддерживает релиз Juno. Ну и кроме того теперь у пользователей, привыкших к VMware, есть возможность выбрать в качестве гипервизора для своего OpenStack-кластера — vCenter, а в качестве сетевого решения — NSX (спасибо нашей команде Partner Integration). Также, при использовании vCenter доступна поддержка хранилища данных vSphere в качестве бэкенда для Glance. Указать свои предпочтения можно с помощью чек-боксов в UI.

Естественно, мы помним о том, что в мире облачных технологий огромное значение имеют стабильность и масштабируемость платформы. Тестируя MOS 6.0 в нашей лаборатории на реальном оборудовании, мы получили возможность утверждать, что Fuel сможет развернуть облако в окружении из 100 узлов. Но и это еще не все: о дополнительных изменениях читайте в материале по итогам майского саммита. А мы дальше поговорим с вами о каталоге приложений Murano.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Дайджест новостей игровой индустрии: февраль-март

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

Создание игр

На gamasutra.com рассказали, как избежать визуальной неразберихи в играх.

Игровые механики: как создать AI игры про хоккей.

Мобильная разработка на HTML5 – доклад с Brisbane Game Tech Meetup.

Как создать эффект пыли в Unity.

Советы и подсказки по оптимизации скелетной анимации.

Persistent Mapped Buffers в OpenGL – новый способ перемещения данных из CPU в GPU.

Визуальные инструменты для исправления багов в игре.

Михаил Лужанин продолжает знакомить нас с таинствами создания игры с помощью Blend4Web.

На Gamedev.ru появилась статья, в которой подробно расписано, как новичку сделать первую игру и продать ее в Steam.

Команда AuraSoft обновила свой игровой движок Skyline до версии 0.9.2.

На портале GCup можно посмотреть официальные уроки Unity3D и DAZ Studio с переводом на русский язык.

Видео: на канале ИгроМикс рассказали, как добавить игру в Steam Greenlight.

Вышло обновление конструктора 2D-игр GameSalad для Mac. Версия 0.13.6 позволяет использовать геймпады для Android, Kindle, Fire TV и десктопных игр на Mac, также добавилась возможность издания проектов для Amazon Fire TV.

Компания Clockwork Chilli выпустила свой игровой HTML5-движок WADE, обновленный до версии 2.1.

Фундаментальные понятия боевой системы в играх.

Интересная статья о мобильном геймдизайне от портала gamasutra.com.

Новости

Фил Спенсер рассказал о планах насчет Xbox One, HoloLens и Windows 10.

Появились новости о стриминге игр с Xbox One на компьютер или планшет с Windows 10.

Николас Доуцет рассказал, как разработчики планируют совместить PlayStation 4 и Project Morpheus.

Глава Microsoft Фил Спенсер рассказал, почему компания всё еще не участвует в гонке устройств, поддерживающих VR.

Nvidia представили новую графическую карту Titan X с 12 GB RAM.

Sony поделились своими планами на будущее.

SuperData утверждают, что к 2016 году в мире будет около 11 миллионов людей, использующих VR-устройства.

EA закрыли студию Maxis Emeryville, основанную в 1987 году, которая запомнилась многим геймерам такими франчайзами, как SimCity и The Sims.

Вместе с исходными кодами UE4, выложенными в бесплатный доступ, разработчики будут получать и C++ исходники PhysX 3.3.3, а также библиотеки обработки тканей и разрушений. Это значит, что теперь все пользователи UE4 могут модифицировать коды данного физического движка, предоставляя свои улучшения для включения оных в будущие версии PhysX и UE4.

Epic Games организовали достаточно большой фонд по поддержке работающих с Unreal Engine 4 – Unreal Dev Grants.

Компания Google анонсировала новые инструменты для разработчиков на Android.

Выручка от мобильных игр достигнет $34 млрд к 2019 году.

Джон Ричителло заверил, что Unity в ближайшее время не будет продаваться и останется независимой.

Совладелец Curve Джонатан Биддл уходит в инди-разработку.

Йоан Фанис, который проработал 14 лет в Ubisoft и создал Valiant Hearts, покинул компанию.

Apple Watch поступят в продажу 24 апреля.

App Annie опубликовала список самых кассовых мобильных издателей.

Crytek опубликовали еще несколько скриншотов движка CryEngine.

Sony закрывает PlayStation Mobile.

Компания WapStart провела масштабное исследование российской аудитории мобильного Интернета за 2014 год.

Стали известны победители BAFTA в области видеоигр.

Фил Гаррисон покидает Microsoft. Три года он работал на позиции вице-президента.

Microsoft ведут консольную индустрию к free-to-play.

Это интересно

Дизайнер Oblivion, конечно, сожалеет о чем-то, но точно не о знаменитой лошадиной броне за 2 доллара.

Автор портала Polygon потрогал финальную (вроде бы) версию Steam controller.

Интересная статья о моральных ограничениях в историях с сюжетом.

Процесс создания дизайна для Half-Life.

Восемь классических жанров видеоигр, которые снова могут стать актуальными.

Джинджер Маседа из ЕА рассказала, как привлечь женщин в игровую индустрию.

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

Что требуется в игре для победы: о навыках, удаче, йоми.

Девять редких и недооцененных жанров видеоигр.

Hobbygamedev рекомендуют: пока ты новичок в индустрии, выбирай цели, которые тебе по силам.

Эдриэль Воллик рассказала, как использовать лимиты и ограничения себе во благо.

Честный обзор Nvidia GeForce GTX 970.

Борат Пфайфер посоветовал инди-разработчикам не связываться с издателями.

120 разработчиков устроили Gaim Jam (Train jam) прямо по пути на GDC. Им удалось создать 50 игр во время 52-часового путешествия.

Нэйтан Грейсон поделился своими мыслями о будущем Steam Greenlight.

Портал alistdaily представил 10 лучших видеоблогеров, которые рассказывают об играх.

Инфографика о том, насколько выросла игровая индустрия за последнее время.

Must read: 150 полезных книг для разработчиков игр.

Как инди-разработчику попасть на консольный рынок?

Что такое Twine?

Интерактивная игровая музыка в LittleBigPlanet 3.

Постмортем игры Tropico 5.

Предсказания в игровой индустрии: статья о важности аналитики.

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

Рами Исмаил, сооснователь и глава отдела стратегического развития в независимой голландской студии Vlambeer, рассказал, что не так с игровой индустрией и почему это нормально.

Sumoman: история вывода игры на Steam Greenlight.

Грэхам МакАллистер рассказал о проблемах, которые возникают у разработчиков при определении целевой аудитории игры.

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

Портал thg.ru провел анализ производительности Dying Light.

Креативный директор Plarium развеял 8 мифов об игровых сценаристах.

Виктор Сурков дал несколько полезных советов создателям игры «Убойный хоккей».

На портале siliconrus.com разработчики поделились своими мыслями об обновлении Unity и бесплатном распространении UE4.

Почему разработчики мобильных игр покупают рекламу на Super Bowl?

Редакция ЦП разобралась, что Элону Маску и SpaceX понадобилось на конференции игровых разработчиков.

Tейг Келли, консультант в игровой индустрии и создатель популярного блога What Games Are, написал для TechCrunch колонку о проблеме игр-однодневок на мобильном рынке.

Как инди-разработчикам попасть в публикации изданий – советы редактора VentureBeat.

The Verge опубликовали материал о том, как создатели популярной МОВА-игры League of Legends борются с нецензурной лексикой и оскорбительными высказываниями во внутриигровых чатах.

Николай Армоник поделился с блогом EmpathyBox своими размышлениями о настоящем и будущем технологий виртуальной реальности.

Четыре разработчика рассказали, чему они научились у мобильных игр, релизы которых ни к чему не привели.

Двенадцать советов инди-разработчику.

Женские персонажи в раннерах обходятся дороже мужских.

Цвет волшебства: Терри Пратчетт и видеоигры.

Kitchen Riots рассказали о профессии игрового аналитика.

Новости VR

Немного обсуждений на тему, станет ли VR следующей «фишкой» видеоигр.

На eurogamer.net опубликовали статью о Steam VR.

Epic Games и Weta Digital на выставке продемонстрировали возможности системы Crescent Bay, показав небольшое демо игры Thief in the Shadows, в которой можно было повстречать Смауга.

Sony может показать первые полноценные игры для Project Morpheus во время E3.

Немного о HTC Vive, VR-системе от Valve.

Новости игр

Harmonix работают над Rock Band 4. Игра выйдет уже в этом году.

Была представлена игра Beyond Eyes, главная героиня которой – слепая девочка.

Wasteland 2 выйдет на Xbox One и PlayStation 4 этим летом.

Игра Heat Signature – второй проект Тома Фрэнсиса. В интервью порталу Polygon он поделился историей его разработки.

Журналисты портала Polygon поиграли в Boxboy – последний платформер от Nintendo.

Danganronpa 3 уже в разработке, но всё еще на очень ранних стадиях.

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

«Взрывающиеся котятки» собрали больше 8 миллионов долларов на Kickstarter.

Студия Game Freak создает игру для PS4, Xbox One и PC.

В Интернет попал архив старых игр, которые запускались под MS DOS.

Релиз Uncharted 4 перенесли на 2016 год.

Модер добавил локальный кооператив в Resident Evil: Revelations 2 на неделю раньше, чем это сделали Capcom.

Rockstar снова перенесла релиз GTA V на ПК.

Фильм по Halo, режиссером которого стал Ридли Скотт, уже можно посмотреть в цифровой версии.

Dragon Age: Inquisition стала игрой года по версии SXSW Gaming Awards.

Elite: Dangerous выйдет на Xbox One в этом году.

Holine Miami 2 заблокировали в Австралии.

Bethesda анонсировали Wolfenstein: The Old Blood.

Топ-20 самых популярных игр января.

Разработка сиквела Titanfall и его выход на разных платформах подтверждены.

Mortal Kombat X появится на мобильных устройствах.

This War of Mine портируют на iPad.

GDC

Новости GDC в пересказе «Отвратительных мужиков».

Дайджест конференции от портала Polygon.

Gamasutra поделились знаниями, полученными на GDC.

Питер Кардвел-Гарднер рассказал о паломничестве на первую в его жизни игровую конференцию.

Alistdaily рассказали, какие уроки преподнесла конференция.

Дайджест GDC от Plarium: часть первая, часть вторая.

Пресса

Вышел в свет новый номер электронного PDF-журнала DF MAG от Dendy Forever. Этот журнал целиком и полностью посвящен ретро-играм, эмуляции и прочим близким темам, так или иначе связанным с видеоиграми и игровой индустрией.

Вышел журнал FPS №34.

Подкасты

Техника и артистизм, выпуск 17 – Windows 10, HoloLens и новая Microsoft.

Техника и артистизм, выпуск 18 – Безопасность в цифровую эру.

Техника и артистизм, выпуск 19 – Патенты в сфере ИТ.

Техника и артистизм, выпуск 20 – Роль технологий в современном мире.

Подкаст AppTractor: новости мобильной разработки.

Мартовский Giant Bombcast.

Подкаст про игры: для детей.

Подкаст про игры: для Facebook.

Подкаст про игры: инди.

Подкаст про игры: жанр и сеттинг.

Подкаст про игры: мобильные игры и западный подход.

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.