Э-ге-гей! Кто хочет узнать, как делаются видеоигры? Ладно, я угораю. Уж где-где, а тут публика должна быть в курсе. Тем не менее, как насчёт увидеть процесс создания игры? Полностью. С первой до последней строчки. ВСЁ. Вообще ВСЁ. Не просто увидеть, даже поучаствовать, если очень сильно захочется. Эта волшебная лошадка на картинке приведёт вас к плей-листу на ютубе, показывающему, как сделать видеоигру.

Итак, я приглашаю всех на мой канал на ютубе, где я два-три раза в неделю сажусь и фигачу. Фигачу код. Фигачу ассеты. Фигачу JSON, в котором описана вся информация об этих ассетах. Вся моя работа в открытом доступе. Можно посмотреть, можно поиграть, можно присоединиться, если вдруг очень захочется. Уникальная возможность! По крайней мере, других идиотов, готовых таким заниматься я пока не видел. Там под катом, больше информации.

А следующий абзац, пожалуйста, прочитайте голосом Рэя Лиотты.

Если тут есть музыканты, которые имеют свой ютуб-канал или паблик вконтакте, ответьте мне на один вопрос: знаком ли вам такой способ набрать популярность, как каверы на музыку из старинных видеоигр? Способ убойный не только из-за ностальгии. Smooth McGroove в одном из своих интервью упоминал, что был удивлён, насколько крутые мелодии делались для старых игр. Дело не только в том, что над старыми играми работали профи, но и в том, какие ограничения им приходилось преодолевать. То, что звучит круто, будучи собранным из ассемблера, спичек и желудей, расцветает ещё больше, если это сыграть на настоящих музыкальных инструментах. Ну, или спеть акапельно.

В этой статье я расскажу о том, как в общих чертах работает звукогенерация в Ricoh 2A03/2A07, которые использовались в NES. Почему именно об этом? Ну, тут не столько я выбираю темы для своих статей, сколько мой pet-project выбирает их для меня.

Необходимое вступление

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

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

Столь малые гарантии поднимают вопросы о причинах, по которым статья пишется. Я считаю, что этим вещам должны учить везде, где учат программированию, вплоть до уроков информатики в школах с углублённым её изучением. Тем не менее, для меня стала пугающе нормальной ситуация, когда я узнаю, что собеседник мой коллега, причём работающий уже не первый год, но про инкапсуляцию «что-то там слышал». Необходимость собрать всё это в одном месте и давать ссылку при возникновении вопросов зрела давно. А тут ещё и мой «pet-project» дал мне изрядно пищи для размышлений.

Тут мне могут возразить, что учить эти вещи в школе рановато, и вообще на ООП свет клином не сошёлся. Во-первых, это смотря как учить. Во-вторых, 70% материала этой статьи применимо не только к ООП. Что я буду отмечать отдельно.

Пролог: internal is new public

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

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