Как стать разработчиком игр

На случай, если ты хочешь научиться делать игры, и не знаешь с чего начать.
Или, если хочешь прокачаться в скиллах, и не знаешь, что читать :^)

Как стать разработчиком игр Игры, Разработка, Книги, Гайд, Мобильные игры, Gamedev, Программирование, Дизайн, Длиннопост

За картинку большущее спасибо Milo Yip
Взято отсюда – https://github.com/miloyip/game-programmer

Лига Разработчиков Видеоигр

6.5K пост22K подписчика

Добавить пост

Правила сообщества

ОБЩИЕ ПРАВИЛА:

- Уважайте чужой труд и используйте конструктивную критику

- Не занимайтесь саморекламой, пишите качественные и интересные посты

- Никакой политики


СТОИТ ПУБЛИКОВАТЬ:

- Посты о Вашей игре с историей её разработки и описанием полученного опыта

- Обучающие материалы, туториалы

- Интервью с опытными разработчиками

- Анонсы бесплатных мероприятий для разработчиков и истории их посещения;
- Ваши работы, если Вы художник/композитор и хотите поделиться ими на безвозмездной основе

НЕ СТОИТ ПУБЛИКОВАТЬ:

- Посты, содержащие только вопрос или просьбу помочь
- Посты, содержащие только идею игры

- Посты, единственная цель которых - набор команды для разработки игры

- Посты, не относящиеся к тематике сообщества

Подобные посты по решению администрации могут быть перемещены из сообщества в общую ленту.

ЗАПРЕЩЕНО:

- Публиковать бессодержательные посты с рекламой Вашего проекта (см. следующий пункт), а также все прочие посты, содержащие рекламу/рекламные интеграции

- Выдавать чужой труд за свой

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


О РАЗМЕЩЕНИИ ССЫЛОК:

Ссылка на сторонний ресурс, связанный с игрой, допускается только при следующих условиях:

- Пост должен быть содержательным и интересным для пользователей, нести пользу для сообщества

- Ссылка должна размещаться непосредственно в начале или конце поста и только один раз

- Cсылка размещается в формате: "Страница игры в Steam: URL"

Вы смотрите срез комментариев. Показать все
11
Автор поста оценил этот комментарий

На случай, если хочешь делать игры - делай.


Сейчас же не 20ый век. Любой недостаток теоретической базы гуглится на раз-два.

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


Да, в этом случае вы будете наступать на грабли, которые можно было бы с помощью знания теории обойти. Но вопрос целесообразности стоит остро - стоит ли учить столько теории, чтобы потом пользоваться 1% из этих знаний, или же попробовать начать разрабатывать сразу и затем обучаться на практике?

раскрыть ветку (42)
13
Автор поста оценил этот комментарий
Это называется Code Monkey
раскрыть ветку (38)
15
Автор поста оценил этот комментарий

Современное программирование похоже на какой-то нацизм.


Казалось бы - нравится тебе писать так как ты пишешь - пиши (особенно если тебе так удобно и твою команду всё устраивает). Но нет же... Делают правило на правило.  Потом из-за этих мнимых правил разводят срачи вроде: табы vs пробелы, camelCase vs under_score, фп vs ооп.

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


В итоге вместо процесса разработки происходит дрочево на код. И на выходе мы имеем мега-кодеров с идеальным кодом и прокаченной теорией, которые не способны сделать хоть что-то интересное.


Рефакторинг кода это бездушный (по большей части) процесс, который можно свести к автоматизму. Его всегда можно купить, наняв за копейки "мега-кодера". Идею же вы не купите. Есть даже такая теория, что избыточное чтение теории и зацикливание на качестве кода мешает формированию новых идей, т.к. постоянно вгоняет человека в рамки.

раскрыть ветку (31)
7
Автор поста оценил этот комментарий
Но нет же... Делают правило на правило.

Дык, если ты дом строить возьмёшься, то тоже будут "правила на правиле". Просто потому что эти шишки люди набивали, продумывали, рассчитывали и если делать "на глазок", то оно может выйти боком. И "душевные творческие люди" может и родили бы шедевры, но физика "к сожалению" мешает.


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


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


Кстати, идеи без реализации тоже мало чего стоят.

раскрыть ветку (8)
3
Автор поста оценил этот комментарий

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


Например, если один код пишет сразу команда разработчиков (что бывает не просто редко, а крайне редко) - естественно нужно придерживаться правил (или если предполагается, что в код кто-то будет изучать/править и т.д.). Если же, как это зачастую бывает, ядро пишет один разработчик, а остальные пишут библиотеки (классы, расширения) - смысл? Т.е. первостепенна задача, а код и его качество вторично.


Если говорить о веб-разработке, то в начале нулевых был перекос в сторону излишней свободы, когда каждый говнокодил как хотел. А теперь перекос в другую сторону - в сторону излишней стилизации кода.


И я могу привести пример. Я занимаюсь RAD (концепция быстрой разработки приложений) и иногда снимаю видео по этой теме. В связи с этим частенько просматриваю аналогичные видео от коллег. Доходит просто до маразма. Человек пишет блог в течении 47 видео на протяжении около 20 (!!!) часов. И это не исключение, сегодня все так делают. Потому что сегодня так принято, что всё и вся нужно дробить на классы (даже если это противоречит здравому смыслу), подключать тучу совершенно не нужных проекту приблуд, компиляторов, менеджеров пакетов и т.д. В итоге задача, которую можно решить за 10 минут растягивается в 100 раз.


Ещё один свежий пример. Недавняя онлайн трансляция, в которой наш отечественный разработчик пишет простейший арканоид 6 часов. Почему? Потому что задачу, решаемую одной функцией за 10 минут раздробили на 50 классов и уделили время codestyle-у.


А по поводу идеи, согласитесь, что реализовать идею (особенно с помощью программирования) намного проще, чем придумать.

раскрыть ветку (7)
2
Автор поста оценил этот комментарий
Например, если один код пишет сразу команда разработчиков (что бывает не просто редко, а крайне редко)
Похоже, что у нас очень разный опыт. (:


Насчёт усложнения на ровном месте соглашусь, но с оговоркой. Да, весьма часто вся заложенная гибкость не нужна (или потребуется как раз не там, где её заложили) и городить 100500 классов бессмысленно. Но бывает, что оно всё-таки нужно. Скажем, если мы планируем наш арканоид всячески расширять. Какими мотивами руководствовался человек из видео я не знаю, это вполне может быть и непонимание и закостенелость. А может и нет.

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


А по поводу идеи, согласитесь, что реализовать идею (особенно с помощью программирования) намного проще, чем придумать.

Не знаю, не знаю... Раз уж тема про игры, то некоторые "клоны" весьма успешны и при этом нередко, в лучшем случае, комбинируют "чужие" идеи. Опять же, есть примеры шикарных/продуманных "инди" игр, которые очень заметно страдают именно от того, что "реализовать" не так просто (дешево). А ещё не очень понятно как заранее оценить (не)успешность идеи.

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

да, бывает и так, согласен

1
Автор поста оценил этот комментарий

Мне интересно, как написать арканоид за 6 часов. Бывают игровые движки, заранее заточенные под определенный жанр - там понятно. Но по вашей логике это значит "подключать кучу приблуд" и простейшая программа на таком движке будет содержать в себе мегабайты библиотек, из которых используются далеко не все.


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

раскрыть ветку (4)
Автор поста оценил этот комментарий
Мне интересно, как написать арканоид за 6 часов.
а в чем проблема? мой рекорд 3-4часа на LWJGL)
раскрыть ветку (2)
Автор поста оценил этот комментарий

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


Проблемы начинаются, когда надо прикрутить туториал, локализацию на разные языки, постепенно вводить фичи, соответственно включая\выключая элементы интерфейса. Для этого и делают максимально удобочитаемый и разбитый по функционалу код.

раскрыть ветку (1)
Автор поста оценил этот комментарий
несколько уровней, желательно хранимых отдельно, чтобы их можно было отредактировать.
Редактор не считаем, а меню, как и звук и хотя бы 3 уровня, можно вложить в это время - спокойно
Автор поста оценил этот комментарий

Понятно, что арканоиды разные бывают. Здесь речь шла о самом простом - внизу бегает за мышкой плашка и отражает летящий шарик, вверху блоки, которые нужно разрушать. Сами представьте себе сколько нужно такое писать - массив блоков и функция рисования (она же - перемещения шарика), запущенная по таймеру + обработка движения мыши. 5 минут? 10 минут? Но никак не 6 часов.


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

1
Автор поста оценил этот комментарий
Для этого и существует разделеление обязанностей. Олег идеально пишет код, Иван шикарный инженер проектировщик, Василий отличный сценарист, а у Юли прекрасное чувство вкуса и умение рисовать. Немного утрировано, но стремление уметь всё ведёт к провалу
раскрыть ветку (10)
4
Автор поста оценил этот комментарий
Иллюстрация к комментарию
раскрыть ветку (6)
3
Автор поста оценил этот комментарий
что за извращенный while true
Автор поста оценил этот комментарий

Аж передернуло от goto

раскрыть ветку (4)
1
Автор поста оценил этот комментарий

Поясни за goto. Я, конечно, знаю почему на него гонят и где его можно использовать, но мне интересно, почему именно ты гонишь на него?

раскрыть ветку (3)
Автор поста оценил этот комментарий

Да просто ничто так не снижает читабельность кода, как goto, особенно если сам оператор и метка расположены не в пределах одной страницы. И я пока не не видел реальной задачи (повторю - реальной), где нельзя было бы заменить goto с помощью break, continue, switch etc. Хотя, если ваш код никто в дальнейшем не будет поддерживать, в том числе и вы через пару месяцев-год, то можно и все циклы через goto писать)

раскрыть ветку (2)
1
Автор поста оценил этот комментарий

6 циклов и в последнем цикле по условию цикл может случиться так, что надо брейкнуть два цикла разом. То есть break  не подходит, флаги - неудобно, а goto как раз

for (sq1_i = 0; sq1_i < sq1_h; sq1_i++)
__for (sq1_j = 0; sq1_j < sq1_w; sq1_j++)
____for (sq2_i = 0; sq2_i < sq2_h; sq2_i++)
______for (sq2_j = 0; sq2_j < sq2_w; sq2_j++)
m1:_____for (sq3_i = 0; sq3_i < sq3_h; sq3_i++)
__________for (sq3_j = 0; sq3_j < sq3_w; sq3_j++)
____________if (b_some) {
______________sq2_j++;
______________goto m1;
____________}

Эта задача, конечно, реальна лишь наполовину (в недавней олимпиаде по программированию пришлось написать такое), но всё равно для прерывания нескольких циклов goto подходит нормально. Тем более в js есть подобное (break label)

раскрыть ветку (1)
2
Автор поста оценил этот комментарий

Это пример, в котором действительно лучше использовать goto, а не вводить дополнительные флаги или выносить в функцию часть алгоритма и использовать return. Но я больше чем уверен, что в реальной задаче можно было обойтись без такой вложенности (взгляд в сторону big O)

Автор поста оценил этот комментарий

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

Игорь хочет сделать свой дом каким-то особенным, но ему говорят: всё, на что ты способен - идеально укладывать кирпичики. Это твоё клеймо.


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

раскрыть ветку (2)
2
Автор поста оценил этот комментарий
Я и не говорю, что не нужно расширять кругозор. Просто для прожекта будет лучше, если каждую его часть будет делать профессионал своего дела. В конце концов, Игорь не просто укладывает кирпичики, а знает как их укладывать быстро, красиво и ещё чтоб дом не рухнул. Разделение обязанностей - очень мощный механизм
Автор поста оценил этот комментарий

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

1
Автор поста оценил этот комментарий

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

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

раскрыть ветку (6)
Автор поста оценил этот комментарий

Если ты не нагружаешь мыслями о коде себя, ты нагружаешь ими других.

У меня был в команде такой гений, который в джаве именовал переменные по настроению то с большой то с маленькой буквы. В итоге встречаешь SomeDoer.doSmth() и думаешь "чё за класс такой SomeDoer, у которого вызывается статический метод?". Ну ок, мне не сложно, я перейду к объявлению и обнаружу, что это локальная переменная. А потом ещё что-то в этом духе и я начинаю беситься от того, что какие-то мелочи не дают сосредоточиться на основной идее. Другой фигачит код в один длинный метод с циклами в циклах, мешая бизнес-логику с реализацией, в итоге ты садишься это читать и понимаешь, глядя на этот ужас, что небольшая модификация займёт час твоего времени и в этом будет тяжело не запутаться (но оно без багов!). Или то же именование методов. Нужно вот тебе заюзать интерфейс, который что-то берёт, а у него есть методы getSmth(), getSmth(Object obj) loadSmth(int i) и вот чё тебе делать?

раскрыть ветку (5)
Автор поста оценил этот комментарий

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

По интерфейсам, я например, называю все паблик методы, ради которых создан класс с префикса I_, например, I_ProcessPathfinding(Tile _target).
Кому-то это непривычно, ок, но это не делает код нечитабельным и сложным для понимания. Это вкусовщина, как var переменные в c#.Ну не люблю я этот стиль, но много людей его обожает.

раскрыть ветку (4)
Автор поста оценил этот комментарий

а, ты про это. Мне повезло, с таким не сталкивался. А что значит "паблик методы, ради которых создан класс"? Какие в нём могут быть другие паблик методы?

раскрыть ветку (3)
Автор поста оценил этот комментарий

Ивенты например, проверки состояния и т п.
Допустим, у тебя класс, где есть паблик методы:

LevelController

// interface

I_LoadLevelAdditive()

I_UnloadAdditiveLevel()

// events

OnGameReady()

OnGameReadyMP()


// bool operations

SetBoolFoo()

SetBoolBar()


// check operations
CheckIfLevelIsBeignLoaded()


Из всего этого, чтобы заюзать загрузчик левелов, тебе, по сути, нужны

I_LoadLevelAdditive()

I_UnloadAdditiveLevel()

Т е , методы, которые являются входной точкой в блок.

раскрыть ветку (2)
Автор поста оценил этот комментарий

Т.е. я правильно понимаю, что в терминах интерфейсов у вас тут

interface ILevelController {

I_LoadLevelAdditive()

I_UnloadAdditiveLevel()

}

и interface IExtendedLevelController : ILevelController {/*всё остальное*/} ?

и вы можете вполне нормально вместо класса LevelController : IExtendedLevelController использовать интерфейс ILevelController, и при этом метод CheckIfLevelIsBeignLoaded()  совсем не обязателен?

раскрыть ветку (1)
Автор поста оценил этот комментарий

//этом метод CheckIfLevelIsBeignLoaded() совсем не обязателен?
Но... почему "вместо"... "на ряду с".
Не очень понял зачем IExtendedLevelController : ILevelController... они, вроде как, параллельны по замыслу...

По сути, выходит как-то так:
IClassDefaultInterface {все паблик методы} // "скрытый" интерфейс класса по дефолту
ILevelController { I_LoadLevelAdditive(), I_UnloadAdditiveLevel() } // подразумеваемый префиксом I_ интерфейс


Но вообще, твой вопрос наводит меня на мысль, что лучше бы явно объявлять отдельные интерфейсы для групп методов { LoadLevelAdditive(), I_UnloadAdditiveLevel() }, ивентов и проверок соотв, чтобы код был понятнее.

1
Автор поста оценил этот комментарий

Полностью поддерживаю, мир катится в ад

1
Автор поста оценил этот комментарий
Если все вокруг неправы, то м.б. задуматься о себе? Если не осиливаешь "мнимых правил", то может быть стоит просто принять их на веру, пока не подрастёшь?
раскрыть ветку (2)
2
Автор поста оценил этот комментарий

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


Вот вы пишите, что стоит принять на веру правила. А вы знаете, что стандартов много и они все разные? Какой же стоит принимать на веру и что в этом случае стоит отвечать фанатам других стандартов? Есть приверженцы разных ЯП, разных технологий (ООП или ФП), разных codestyle и т.д. Всем вы не угодите, по этому единственный правильный вариант - поступать так, как считаешь целесообразней в каждой конкретной ситуации.

раскрыть ветку (1)
1
Автор поста оценил этот комментарий
Ок, да, неправильно понял вас. Просто дохрена людей. которые "мнимыми правилами" считают само существование понятия codestyle, паттернов и других не очевидно критичных вещей. И это очень плохо сказывается на всей индустрии прямо сейчас.
2
Автор поста оценил этот комментарий

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

Скилл писать понятный и простой код без излишеств приобретается только с опытом, к сожалению :/

раскрыть ветку (4)
2
Автор поста оценил этот комментарий
Т.е. тупо искать шаблонное решение в интернетах и пихать его в свой код только потому-что не можешь и не знаешь, как это написать самому, это нормально?
раскрыть ветку (3)
2
Автор поста оценил этот комментарий

Почему сразу "не можешь" и "не знаешь", при чем тут это?
Даже если не знаешь - загуглил, подумал, подходит ли это для проекта? Если да - запилил, если нет - доработал/нашел другое/спросил коллегу.
Если человек не может перестроить свой мозг под программирование, тогда он будет коуд манке, это другой случай.

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

https://m.habrahabr.ru/post/104231/
раскрыть ветку (1)
1
Автор поста оценил этот комментарий

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

Автор поста оценил этот комментарий

Это называется Stack Overflow Driven Developement.

5
DELETED
Автор поста оценил этот комментарий
Я попробую объяснить чем обернётся такое изучение.

Например тебе надо проехать на трамвае и выйти на остановке.

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

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

раскрыть ветку (2)
2
Автор поста оценил этот комментарий

вы оба из крайностей в крайность прыгайте.

У Одно к правильному решению нельзя прийти - у другого, всегда приходишь к правильном решению

1
Автор поста оценил этот комментарий

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


В другой ветке я написал, что качество кода и теоретическая база должна соответствовать задаче. В данной ситуации, если человек хочет написать игру - его ничего не может и не должно останавливать.

Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку