Продолжаю рассказывать про человеческий маркетинг. Когда Англия вошла во Вторую Мировую, был очень примечательный эпизод. Военная пропаганда – это то, чему обычно не все и не всегда верят. Официальные каналы преуменьшают потери, преувеличивают успехи. Я сейчас не уверен в числах, но первое же радиосообщение с фронта про воздушный бой было про то, что сбито 40 английских истребителей. Позже пришла информация, что меньше – 34. Через пару дней нашли ещё пилота, совершившего аварийную посадку.

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

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

Доброго времени суток!

Предисловие

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

Введение

У меня за спиной огромный опыт работы с PHP, но сейчас я работаю Rails разработчиком. Огромную сложность для большинства людей, которые пытаются освоить что-то новое — это сам процесс обучения. Когда вы владеете каким-либо языком или фреймворком и знаете его вдоль и поперёк, переход на что-то новое не представляется необходимым.

Однако, изучение Ruby on Rails является достаточно простым занятием. Это невероятно мощный фреймворк, который имеет огромное сообщество, продвигающее его вперёд. Итак, у нас возникает вопрос: какой способ изучить Rails является лучшим? Вот он — план занятий.

Здравствуйте всем!

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

Удобочитаемый синтаксис, прост в обучении, высокоуровневый язык, Объектно-Ориентированый язык программирования (ООП), мощный, интерактивный режим, масса библиотек. Множество иных плюсов… И это всё в одном языке.
Для начала окунёмся в возможности и узнаем, что же умеет Python?

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

Есть один курс, который я бы добавил в программу обучения по всякой инженерной специальности, и он не о компиляторах или сложности алгоритмов. Это “Введение в реальность индустрии”, ибо об этом не говорят и это приводит к никому не нужным обломам. Эта статья претендует стать README.txt для молодого инженера в деле построения карьеры. Ее цель — сделать вас счастливее, заполнив пробелы в образовании относительно того, как работает реальный мир. Я не призываю следовать написанному как подробному руководству, но я надеюсь, что эта информация окажется для вас более ценной, чем то ничто, что вам рассказали об этом в университете.

Здравствуйте! Не прошло и суток с момента публикации первой части статьи, а я не могу спать, так как есть незаконченное дело и нужно дописать статью. Приступим.

Здравствуйте! Я решил попробовать себя на поприще game-dev'а и заодно рассказать и показать как это было. Вторая часть здесь.

Игра представляет собой экран, на котором расположены созвездия. Каждая звезда этого созвездия имеет свой цвет (нота). Например, ноту «До» обычно представляют красным цветом, а «Ми» — желтым. Вот что получится в итоге:



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

Писать будем, используя фреймворк libGDX. Мне он больше всех понравился, как новичку в этом деле. Да и информации по нему я нашел больше. Итак, приступим.

Это вторая часть статьи (первая часть — try-catch-finally), посвященной такому языковому механизму Java как исключения. Она имеет вводный характер и рассчитана на начинающих разработчиков или тех, кто только приступает к изучению языка.

Также я веду курс «Scala for Java Developers» на платформе для онлайн-образования udemy.com (аналог Coursera/EdX).

1. Магия checked/unchecked
2. Пессимистичный механизм
3. throws с непроверяемым (unckecked) исключением
4. Множественные исключения
5. Или catch, или throws
6. Поведение компилятора/JVM
7. Overriding и throws
8. Передача свойства по наследству

1. «Магия» checked/unchecked

Механизм исключительных ситуация в Java связан с двумя элементами «магии», т.е. поведения, которое никак не отражено в исходном коде:
1. «Магию» java.lang.Throwable — в throw, catch и throws могут стоять исключительно Throwable или его наследники (мы уже разбирали в предыдущей лекции). Это «право» находиться в throw, catch и throws никак не отражено в исходном коде.
2. Все исключительные ситуации делятся на «проверяемые» (checked) и «непроверяемые» (unchecked). Это свойство присуще «корневищу» (Throwable, Error, Exception, RuntimeException) и передается по наследству. Никак не видимо в исходном коде класса исключения.

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

Java задумывалась как объектно-ориентированный язык в 90-е годы, когда объектно-ориентированное программирование было главной парадигмой в разработке приложений. Задолго до этого было объектно-ориентированное программирование, были функциональные языки программирования, такие, как Lisp и Scheme, но их преимущества не были оценены за пределами академической среды. В последнее время функциональное программирование сильно выросло в значимости, потому что оно хорошо подходит для параллельного программирования и программирования, основанного на событиях («reactive»). Это не значит, что объектная ориентированность – плохо. Наоборот, вместо этого, выигрышная стратегия – смешивать объектно-ориентированное программирование и функциональное. Это имеет смысл, даже если вам не нужна параллельность. Например, библиотеки коллекций могут получить мощное API, если язык имеет удобный синтаксис для функциональных выражений.

Главным улучшением в Java 8 является добавление поддержки функциональных программных конструкций к его объектно-ориентированной основе.

Это первая часть статьи, посвященной такому языковому механизму Java как исключения (вторая (checked/unchecked) вот). Она имеет вводный характер и рассчитана на начинающих разработчиков или тех, кто только приступает к изучению языка.

Также я веду курс «Scala for Java Developers» на платформе для онлайн-образования udemy.com (аналог Coursera/EdX).

1. Ключевые слова: try, catch, finally, throw, throws
2. Почему используем System.err, а не System.out
3. Компилятор требует вернуть результат (или требует молчать)
4. Нелокальная передача управления (nonlocal control transfer)
5. try + catch (catch — полиморфен)
6. try + catch + catch + ...
7. try + finally
8. try + catch + finally
9. Вложенные try + catch + finally

1. Ключевые слова: try, catch, finally, throw, throws

Механизм исключительных ситуаций в Java поддерживается пятью ключевыми словами

• try
• catch
• finally
• throw
• throws

«Магия» (т.е. некоторое поведение никак не отраженное в исходном коде и потому неповторяемое пользователем) исключений #1 заключается в том, что catch, throw, throws можно использовать исключительно с java.lang.Throwable или его потомками.

Примечание от переводчика: если вам позволяет знание английского языка, то я настоятельно рекомендую ознакомиться с оригиналом. Её автор — один из основателей студии Mode 7, которые выпустили Frozen Synapse. Статья очень большая по объёму текста, поэтому, если у вас не получится осилить её за 1 подход, я бы предложил отложить на потом, и продолжить в другой день.

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

Ниже будет перевод статьи.

От переводчика: Предлагаем вниманию наших читателей перевод еще одной статьи с французского сайта Usabilis.Com. Статья посвящена эргономическим аспектам разработки игрового ПО. Игровые приложения представляют собой совершенно особый тип программ.
Некоторые игры можно считать своеобразными произведениями искусства, в которых пользователь одновременно выступает в качестве актера и режиссера. Разработка интерфейсов игровых программ предполагает не только решение сугубо утилитарных задач, связанных с обеспечением простоты и удобства управления игрой, но еще и создание у пользователя определенного эмоционального настроя. Хорошая игра должна, во-первых, увлекать и всецело затягивать, а во-вторых — вызывать чувство эстетического удовлетворения. Как сделать игру увлекательной, красивой и удобной? Есть ли какие-то отличия между интерфейсами игр и интерфейсами прочего ПО? Какие моменты следует учитывать при проектировании игровых приложений? Приглашаем к обсуждению этих вопросов на материале приводимой статьи.

Мы любим игры для мобилок, а ещё очень ценим цифры. Но когда мы ищем в вебе статистику о трендах в разработке мобильных игр, мы быстро понимаем, что в общем-то нет единого места, где бы всё это добро было собрано. Так что вот оно, куча статистики индустрии мобильных игр, которая сделает вас очень популярным на следующей игровой конференции, или коктейльной вечеринке, когда вас спросит какой-нибудь скептик…

“Неужели люди действительно тратят так много времени на видео-игры?” Да, мы действительно тратим.

(прим. переводчика: автор частенько повторяется, простим ему это)


(Примечание к фото: мы никогда не смотрим выше)

Музей современного искусства в Нью-Йорке начал собирать коллекцию компьютерных игр. Планируется, что там разместится около 40 наиболее заметных явлений. Пока в список попали 14 компьютерных игр. В том числе и тетрис Алексея Пажитнова.



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

Пока не очень понятно, как будут выставляться игры. Список уже отобранных игр:

• Pac-Man (1980)
• Tetris (1984)
• Another World (1991)
• Myst (1993)
• SimCity 2000 (1994)
• vib-ribbon (1999)
• The Sims (2000)
• Katamari Damacy (2004)
• EVE Online (2003)
• Dwarf Fortress (2006)
• Portal (2007)
• flOw (2006)
• Passage (2008)
• Canabalt (2009)

Так же уже известно, что организаторы будущей коллекции хотят включить в музейную экспозицию «Змейку», «Спейс Инвайдерс», «Зорк», «Супер Марио», «Грим Фанданго».

А так же объявлено, что самой молодой игрой в коллекции станет Minecraft.

Хотела написать что-то умное, но потом решила схалявить, так что поговорим вот о чём — почему же у нас девушки не играют в компьютерные игры? Нет, некоторые, конечно, могут и сильному полу фору дать в какой-нибудь стрелялке. Но чаще всего это не так. Девушка самозабвено и с предвкушением выбирающая в магазине очередной шутер, или пусть даже РПГ, или вообще какую-то игру — редкое зрелище. Почему?
Мне вот как-то говорили даже, что был такой доклад на КРИ — почему девушки не играют. Сказали, доклад был странный, и какой-то феминистически настроенный, с главным месседжем — девушки не играют потому, что игры делают тупые мужики. Ну это со слов очевидцев, сама я не берусь утверждать, был ли доклад плох или хорош — не присутсвовала.
И всё же подумалось, а кстати, почему не играют? Так я стала раскладывать всё по полочкам, и вырисовалась такая картинка.

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

Вот что у нас получилось.

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

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

Оригинал: Starting out on Game Programming

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

Вы только что закончили ваш первый курс по С++ и хотите начать делать игры. Кто-то указал вам на этот сайт и вы, возможно, поэкспериментировали немного с руководством. Вы изучили несколько лаконичных примеров, но не нашли руководства о том, как сделать целую игру. И на то есть причина.

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

До того как я стал разработчиком игр, я (да и все в моем окружении) считал себя дизайнером сайтов.
Не плохим, кстати, но дизайнером сайтов. Профессия, которая почти никак не используется в разработке игр.


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

После одного игрового проекта со стримом всего процесса разработки мне часто пишут начинающие разработчики, что-то спрашивают, что-то показывают и на что-то жалуются. Недавно мне пришлось влезть в спор двух ребят, где темой спора было: “Что круче знать 3д-моделирование или программирование, если собираешься разрабатывать игры?”. Влез к ним в спор с предложением сделать первый шаг из схемы, что родилась в процессе участия в игровых проектах и создания своих.

Доброго времени суток, Хабр!

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

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


Именно так я представляю себе обобщенную структуру новых компьютерных игр. И чем-то она напоминает мне структуру сущностей в древнегреческой мифологии…