Цель данной статьи: попытаться раскрыть понятие игры, а также её роли в творчестве. Понять, что отличает Игру от Искусства, Кино и Литературы?

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

Из всех подходов по выделению игрового сегмента продукта, наиболее интересным и простым для восприятия, на мой взгляд, является метод предложенный Крисом Кроуфордом. Крис Кроуфорд — геймдизайнер и писатель, отличившийся рядом отличных игр в 1980-х, основатель The Journal of Computer Game Design и организатор Конференции Разработчиков Компьютерных Игр.
В своей книге «Chris Crawford on game design», он определяет данный метод, как таксономию творческого самовыражения.

Рис.1 Таксономия творческого самовыражения по Кроуфорду

Всю сознательную программистскую деятельность я увлекался созданием игр и не любил делать редакторы и прочие утилиты. Главным моим редактором почти всегда был Paint. Но для игр, в которых уровень статичен и состоит из тайлов (Марио подобные и прочие танчики), это более-менее оправдано, т.к. одному пикселю из файла уровня, созданного в Paint, соответствует тайл в игре. А что если требуется создать игру, где нет тайлов, а игровая локация состоит из неровных скалистых пещер. Или игру, в которой много движущихся элементов (летающие платформы, лифты, циркулярные пилы, вращающиеся по окружности).

Создавать редактор для таких целей мне по-прежнему не хотелось. О том, как я это решил с помощью Paint опишу в этой статье.

Почему важно главное меню? Встречают, как говорится, по одежке. Думаю, никто не будет спорить, что первое впечатление очень важно. Главное меню — это то, что встречает пользователя перед входом в вашу восхитительную игру. Что же это будет? Вежливый опрятный дворецкий или туповатого вида небритый верзила, от которого разит перегаром?

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

Разработка игр в целом – очень увлекательный и интересный процесс. Особенно он интересен тогда, когда ты занимаешься этим один, независимо ни от кого, имея за плечами небольшой опыт во всем, что позволит создать полноценный продукт для индустрии развлечений. Казалось бы, если для этого есть время и возможности, то почему бы не переодеться в шкуру инди-разработчика и создать нечто интересное, что сможет понравиться людям и принесет прибыль? Конечно да, но только помимо множества явных подводных камней существуют и едва заметные грабли, которые лежат на последней ступени процесса создания игры и больно лупят по голове. После чего остается мысль — «Ведь я же старался, потратил много времени, но ничего не получил взамен», а следом — «Ничего, в следующий раз я сделаю лучше!». Под катом история о том, как на эти грабли мне пришлось наступить трижды.

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

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

Для раскрытия понятийного аппарата и определения точки с которой возможно развитие представленной ранее таксономии, необходимо прежде всего ответить на вопрос «Какие признаки игры используются в математической теории игр?».
Характеризующими признаками подобных игр являются:

1. Наличие нескольких участников игры.
2. Неопределенность поведения участников, связанная с наличием у каждого из них нескольких вариантов действий.
3. Различие (несовпадение) интересов участников
4. Взаимосвязанное поведение участников, поскольку результат получаемый каждым из них, зависит от поведения всех участников.
5. Наличие правил поведения, известных всем участникам.

Как мы видим, уже первый признак игры пересекается с вопросом-разветвителем таксономии Кроуфорда — «Наличие соперника», что переносит математические игры в категорию "Конфликт".
Второй признак дополняет данный вывод заявляя, что соперник должен быть действующим агентом, т.к. алгоритмы искусственного интеллекта рано или поздно можно просчитать.
Третий и четвертый признаки не позволяют выйти нам за пределы данной категории, т.к. они одновременно удовлетворяют требованиям категории "Соревнование" и категории "Игра".
Пятый признак соответствует категории "Забава", но т.к. у нас есть признаки категории более низкого класса "Конфликт", то для развития мы выберем именно её.

Типы игр в математической теории игр

— Кооперативные, некооперативные и гибридные игры

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

Слева направо: 1. Настольная игра Dungeons&Dragons 2. Настольная игра Монополия 3. Шутер от первого лица Halo 4. Файтинг Mortal Kombat

Гибридные игры — игры, которые включают в себя элементы кооперативных и некооперативных игр. В таких играх игроки могут образовывать группы, но игра может вестись в некооперативном стиле (к примеру kill stealing в League of Legends).

Скриншот из игры League of Legends

Каждый игрок в такой игре будет преследовать интересы своей группы, вместе с тем стараясь достичь личной выгоды. Подобное поведение носит название «Трагедия общин».

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

Вначале мы бы хотели обсудить, почему в некоторых ситуациях стоит идти к издателю. В нашей статье мы будем рассматривать только f2p-игры, поскольку именно эта модель монетизации приносит больше всего денег в магазинах мобильных приложений. В этом можно убедиться, посмотрев на AppStore Top Grossing US. Картинка ниже.



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

На Хабре уже есть очень много интересных статей про создание игры с нуля, но мало статей, описывающих что делать, чтобы своя любимая поделка не превратилась во Франкенштейна и дошла до вменяемого состояния. Автор оригинальной статьи рассказывает, как эволюционировал код игрового движка от кучи хлама в основном цикле к продуманной, расширяемой архитектуре, использующей Entity Component System. В статье много кода, который почти весь часто повторяется — но я не стал его выбрасывать, поскольку с ним будет понятнее, какие изменения вносит автор и как это отражается на всей структуре. Статья рассчитана на новичков, вроде меня, которые уже настрочили несколько «гениальных» прототипов, но теперь не знают, как разобраться в их коде.

Привет, Хабр!

Мы в РИКе немного ретрограды — до сих пор читаем книжки и советуем это делать нашим студентам. Пусть буржуи говорят про клиповое мышление, но мы верим, что Россия как была самой читающей страной в мире, так ею и останется :)

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

В свое время, в начале разработки двухмерной игры на Unity3d, мне пришлось перерыть кучу документации, сайтов, проштудировать answers.unity3d.com и forum.unity3d.com на тему: как сделать 2d-игру на этом 3d-движке. Самыми первыми вопросами были: как правильно настроить камеру, как сделать 2d-спрайт так, чтобы он отображал текстуру «пиксель в пиксель». На то время уже существовал SpriteManager (далее – SM) и даже SM2 с его мощной поддержкой редактора. Судьба сложилась так, что я не мог его тогда купить, да и пробной версии не было. В итоге, мне пришлось самому написать несколько полезных скриптов для реализации 2d на Unity3d. О том, как это сделать, пойдет речь в этой статье.

"

Так уж получилось, что даже на Хабре многие имеют очень смутное представление о семействе OS Linux.

Цель данной статьи – максимально популярным языком рассказать про особенности и отличия Linux от Windows для тех, кто вообще не имел с ним дела.

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

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

Часть первая


Неудачный тест физики

В этой части мы:
— оптимизируем код из предыдущей статьи;
— создадим объект «база» и научим её чиниться время от времени;
— добавим пушкам патроны и перезарядку;
— избавимся от «неудобной» переменной gv;

А в конце статьи вас ожидает маленький бонус :)

Всем заинтересовавшимся — добро пожаловать под долгожданный кат!

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

Часть вторая

Всем заинтересовавшимся — добро пожаловать под кат!

Предисловие

Хабралюди проявили некоторый интерес к Unity, поэтому открываю этим постом цикл туториалов, освещающих основные моменты работы с объектом (цикл неопределённой пока длительности — если кому окажется полезным продолжу).

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

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

Давно хотел написать на эту тему. Первым толчком послужила статья Miško Hevery "Static Methods are Death to Testability". Я написал ответную статью, но так и не опубликовал ее. А вот недавно увидел нечто, что можно назвать «Классо-Ориентированное Программирование». Это освежило мой интерес к теме и вот результат.

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

• это не дает никаких преимуществ по сравнению с процедурным программированием
• не стоит отказываться от объектов
• наличие статических членов класса != смерть тестам

Хотя эта статья про PHP, концепции применимы и к другим языкам.

Книги, которые должен прочитать Java программист: от новичка до профессионала

[Примечание переводчика: термины градации «профессионализма» оставлены англоязычные в связи с трудностью их адекватного перевода на русский и несовпадением с привычными Junior-Middle-Senior-Lead. Перевод достаточно вольный — если знаний языка хватает, то лучше читать оригинал, как и советует автор. Оба языка для меня не родные, так что про ошибки сообщайте в личку — исправим. Здесь и далее в квадратных скобках примечания переводчика]

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

Статья написана после прочтения статьи Копи деньги смолоду или пара утверждений, легко проверяемых в Excel.

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

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