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

Cамое подходящее объяснение повторного прохождения игр – получение игроком уникального игрового опыта. То есть, каждый последующий раз, игрок будет открывать в игре для себя что-то новое, что не было сделано в предыдущих попытках. Эта мысль проходит красной нитью через каждый слайд презентации. С теорией всё, дальше практические примеры.

Понятие «фан» пришло к нам с запада и многие ассоциируют его с удовольствием, но я с этим не совсем согласен. Человек может получать удовольствие от еды, от массажа, от загорания на пляже или от того, что плюхнулся в мягкое кресло после тяжёлого трудового дня.

За выходные весь интернет облетело видео выступления CEO компании Twitter Дика Костоло перед выпускниками Мичиганского университета. В своей речи глава социальной сети посоветовал начинающим специалистам быть смелее и делать то, что их вдохновляет, не смотреть на окружающих и следовать выбранному пути.

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

• Если тестировать, то чужой код (см. про бережное отношение к своему коду выше)
• Обсуждайте набор тестов с тестировщиками
• Расширяйте сценарии после анализа окружения, конфигурации, набора данных, с которые будут задействованы в сценариях.
• Тестируйте эвристически: принцип SFDEPOT

SFDEPOT нам дает:

T(ime) – когда он будет использован

Шаг 3 Что делать, когда запускаются тесты

1. Записывайте новые идеи того, что нужно проверить, “баги” в которые воткнулись и которые нужно зарепортить (звучит как совет КО, имхо лучше сразу чинить. Вы же разработчик С другой стороны, правильно отмеченные проблемы помогут вам на рестроспективах)
2. Не забывайте про работу с граничными значениями (большие/маленькие файлы, специфичные даты, максимальные/минимальные числовые значения и тп)
3. Размышляйте о негативных сценариях (например пропадание электричества и тп)
4. Старайтесь смотреть шире. При проверке конкретной функциональности, смотрите вокруг: что происходит с продуктом и его окружением.
5. Боритесь с селективной слепотой (слепотой по невниманию - Inattentional Blindness). Этот ролик поясняет в чем суть. Вы увлекаетесь одним предметом и не замечаете того, что происходит вокруг.

Шаг 4 Что делать, когда (как вам кажется) вы закончили тестировать
Даже когда вам кажется, что вы закончили, вы не должны успокаиваться. Подумайте где и что вы бы могли проверить.
Вот несколько практик

• Делайте перерывы, займитесь другими делами. А потом проанализируйте заново что вы проверяли и что нашли. Обычно помогает освежить мозги.
• Расскажите вашим коллегам о том, что и как вы проверяли. Самое удивительное, что в процессе этого, к вам в голову будут приходить новые идеи.
• Посоветуйтесь со спецами (наверняка у вас есть крутаны-тестировщики). Они обязательно придумают вам еще 100500 сценариев, которые вы забыли проверить.

А на самом деле, кто в итоге будет тестировать: разработчики, тестировщики или совместно – не важно. Главное чтобы: “пацан наШкодил – пацан исправил” А кто эту шкоду нашел, какая разница?

Но ведь пацаны пишут все правильно и без ошибок, не так ли? ;)Почему? Потому что используют TDD.
Uncle Bob (aka Robert C. Martin) недавно замутил очередную бурю по этому вопросу. Две интересные статьи всколыхнули прогрессивную общественность The Start-Up Trap и The Pragmatics of TDD. Читаем и задумываемся.Так нужно ли учить разработчиков тестировать? Наверно нужно. Постоянно появляются статьи про то, что тестировщикам нужно уметь программировать . Так почему же разработчики не должны понимать базовые принципы тестирования. Это позволит команде говорить на одном языке.

Источник: maxshulga-ru.blogspot.com

Уроки, которые на своем опыте извлекли команды Dropbox(облачное хранилище данных) и Xobni(расширяет и улучшает email контакты):

Kevin Rose делится секретами активного роста аудитории на примерах Digg иWeFollow.

Недавно ряд компаний Рунета провел и опубликовал исследование «Монетизация веб-проектов Рунета в 2013 году». В исследовании рассматриваются средние показатели пользователей Рунета, владельцев российских сайтов, разновидности рекламной модели монетизации: CPM, CPC, реклама с оплатой за действия и за продажи, SEO и т.д.

Исследование показало, что большинство владельцев сайтов в Рунете управляют 2-5 сайтов, средняя посещаемость которых составляет от 300 до 5 тыс. пользователей в день (около 27% опрошенных назвали среднюю посещаемость на уровне 1-5 тыс., 25% — на уровне 300 — 1 тыс.). 16% участников опроса определили свои ресурсы, как относящиеся к бизнесу, 11% — к досугу, 9% — к играм. Наиболее популярным форматом веб-сайта является контент-ресурс в тематике «Бизнес».

Афера программиста, имя которого не называется, была раскрыта после того, как его компания обратилась к Verizon с просьбой расследовать подозрительную активность в корпоративной сети. Проведя аудит внутренней системы безопасности, Verizon обнаружила входы с IP-адресов, принадлежащих городу Шэньян в Китае. Сначала администраторы сети решили, что в странных записях виноват опасный вирус или крупный сбой, поскольку компания внедрила надежную защиту: подключаться к закрытой сети мог лишь тот, кто у кого есть RSA-токен — брелок с ЖК-дисплеем, на котором каждую минуту меняются числа-пароли.

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

Типичный рабочий день программиста выглядел примерно так. Он приходил на работу к 9:00 утра и проводил несколько часов играя в компьютерные игры и смотря YouTube, в 11:30 обедал, в 13:00 совершал покупки на Ebay, а после 14:00 — дальше играл в игры . В 16:30 отчитывался о проделанной работе, а через полчаса уходил домой.