Индустрия вомгле...

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

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

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

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

Раздражают моменты, когда сотрудники не только беспричинно ходят по комнате, в которой развертывается разработка видеоигры или какого-то другого проекта, но и без всякой просьбы (или даже разрешения) заглядывают в твой экран, высматривая, что на нем происходит. Совсем выводят из себя последующие комментарии: «А я тоже так смогу». После таких слов охота на этом же месте разбить его голову клавиатурой или чем-нибудь потяжелее. Запустить Unity может и моя бабушка! Кстати, в крупных организациях сотрудники редко позволяют себе такую свободу, в небольших же компаниях подобное случается довольно часто.

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

Планирование и отчетность

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

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

GameDev в одиночку

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

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

Разработка игр в одиночку? Уже не кажется такой безумной идеей.

 Over the Rainbow - 2009

Юрий "yurembo" Язев

21 сентября 2009-го года, в понедельник в ДК им. Солдатова, что в г. Перми, состоялся потрясающий концерт группы Over the Rainbow. Следовательно, как, уважающий себя и свою любимую музыку металлист, я не мог пропустить это грандиозное событие, поэтому участвовал в этом мероприятии!

Вообще, группа Over the Rainbow была организована 21 июня 2008 года бывшими участниками группы Rainbow, игравшими когда-либо. Однако место соло-гитариста занимает новый участник – сын Ричи Блэкмора – Югдан Блэкмор. Напомню, Ричи организовал группу Rainbow в 1975-ом.

По поводу переименования группы я имею следующие размышления. Во-первых, без Ричи уже не Rainbow, поэтому участники не захотели идти против него, и возможно, против закона – авторских прав Блэкмора старшего, о которых он бы обязательно вспомнил. И вторая мысль имеет противоречие самой себе и заключается в следующем. Младший Блэкмор не хотел повторять лейбл группы своего отца. Это утверждение имеет такое противоречие: как же так, если новая группа играет хиты Rainbow. Отсюда следует, что первое утверждение, скорее всего, правильно.

У микрофонной стойки на месте вокалистом во вновь образованной группе в  настоящее время находится Джо Линн Тёрнер. И о концерте.

Как обычно бывает на подобных концертах, зал был полон. У меня было место в первом ряду амфитеатра, то есть, это получается приблизительно 11-ый ряд в общем числе. При этом билет далеко не самый дешевый. Ну, да ладно, всё равно под конец концерта все вылезли на сцену! И, как обычно на концертах таких групп, зрительский контингент состоял в основном из взрослых людей, то и лучше!

Я точно не помню на сколько задержалось начало концерта, было не до этого! Кроме того, перед началом концерта я купил две мега-футболки с символикой группы. Концерт начался с песни Tarot Woman, которая была на альбоме Rainbow Rising, вышедшем в 1976-ом. После этого было исполнено много великолепных вещей Rainbow, в числе которых: Death Alley Driver, Power, Stone Cold, Can’t Happen Here, Since You’ve Been Gone и даже чудесная Stargazer! Первую половину концерта люди - зрители спокойно сидели на своих местах, и похоже я один прыгал рядом со своим местом, всё это очень не нравилось людям, сидящим сзади меня, на что я ответил: «Да, чёрт возьми, это же рок – концерт!» После чего, ко мне уже никто не приставал! Вторую половину концерта, точнее, последнюю четверть, как я уже говорил, все вылезли на сцену! Ну, это образно говоря, так как охрана никого на сцену не пускала, к тому же около сцены всё было отгорожено, и попасть на нее можно было только по двум подмосткам, находящимся возле нее. И самые отчаянные фанаты, в числе которых был автор этой статьи, обступили их. Собственно, народ окончательно сошёл с ума во время исполнения «Long Live Rock’n’Roll», и все, подпевая «long live rock’n’roll» бросились на сцену! В этом безумстве мне удалось пожать руку Джо Тёрнеру (вокалисту) и получить медиатор от самого Блэкмора, пускай и младшего, но великолепно играющего на гитаре! Теперь, когда у меня есть медиатор, чтобы научиться играть на гитаре осталось то совсем ничего – купить саму гитару! Чтобы получить медиатор, надо было вынести страшную давку, массу народа, толпу людей, и после его получения, остаться в живых под человеческой массой! И мне повезло! Вот, я живой вернулся домой и печатаю этот текст!  В очередной раз, когда Джо подошёл к озверевшей публике, он опустил в нее микрофон, и, парень, стоящий возле меня поймал его и начал орать в микрофон: «Long Live Rock’n’Roll!».  Мне микрофон не достался, Джо поспешил забрать его обратно :) !

После Long Live Rock’n’Roll было исполнено ещё пара песен, но я уже не помню, что это были за песни, все вокруг что-то орали…! Опомнился я тогда, когда вместе со всеми орал: «I wanna touch you all night long, I wanna feel you all night long» - слова из песни «All Night Long».

Всё замечательное когда-нибудь заканчивается, и это была последняя песня этого великолепного концерта! Правильно сказал Ронни Дио в 1978 (когда был вокалистом Rainbow) в своей песне: “Long Live Rock’n’Roll!”

 Ассемблерная заметка №3

О разрядности процессоров

Процессор считается «N-битным», главным образом, по размеру его шины данных и значительной части его сущностей (внутренней архитектуры): регистров, аккумуляторов, арифметико-логических единиц (ALU), набора инструкций и т. д.

Например: Старый добрый процессор Motorola 6800 (или Intel 8050) - это 8-битный процессор. Он имеет 8-битную шину данных, 8-битную внутреннюю архитектуру и 16-разрядную адресную шину.

Ассемблерная заметка №2

Об инструкции CMP

Furthermore, with the CMP instruction, the destination operand doesn't change. Just the flags.

Let me illustrate. Let's say EAX = 00000005 and EBX = 00000005. If we do this arithmetic operation:

CMP EAX, EBX

What's happening, is in effect this:

EAX - EBX ----> 00000005 - 00000005

Since the result would be 0, but we don't change the destination operand in a CMP instruction, the zero flag is set to 1 (since it's true).

So, as we saw, depending on the result of the previous arithmetic operation, flags can be set accordingly:

Ассемблерная заметка №1

Об инструкции TEST

Some x86 instructions are designed to leave the content of the operands (registers) as they are and just set/unset specific internal CPU flags like the zero-flag (ZF). You can think at the ZF as a true/false boolean flag that resides inside the CPU.

in this particular case, TEST instruction performs a bitwise logical AND, discards the actual result and sets/unsets the ZF according to the result of the logical and: if the result is zero it sets ZF = 1, otherwise it sets ZF = 0.

Conditional jump instructions like JE are designed to look at the ZF for jumping/notjumping so using TEST and JE together is equivalent to perform a conditional jump based on the value of a specific register:

example:

TEST EAX,EAX

JE some_address

the CPU will jump to "some_address" if and only if ZF = 1, in other words if and only if AND(EAX,EAX) = 0 which in turn it can occur if and only if EAX == 0

the equivalent C code is:

if(eax == 0)

{

    goto some_address

}