Как стать автором
Обновить

Комментарии 36

Слушайте, а хорошая идея. Надо перечитать произведение, актуальности не потеряло

Т.е. это связано, что Мертвые души - оно из любых произведений и то что я в геймдеве? :(

Одно из любимых да, еще напомнило - на прошлой неделе embracer закрыли студию, которая "делала" Deus Ex новый (https://kotaku.com/embracer-group-deus-ex-cancelled-eidos-montreal-layoffs-1851205890). Но проблема в том что в студии на 100+ человек не было никого, кто делал прошлые игры серии, были набранные студенты, стафы и сыновья менеджеров. И было 5 (пять, Карл!) программистов. Студию закрыли, программистов перевели, мертвые души уволили.

А что скажете по поводу книги "Изучам питон", Эрика Мэтиза?

Как связаны между собой геймдев и питон?

Оох, С-С++ roadmap самый хардкорный. Как .NET-чик, посматриваю купленную на первом курсе книгу Роберта Лафоре по С++ (талмуд в почти 800 страниц), с мыслью "А не восстановить ли знания?", и как оказалось, книга покрывает только С++ 98 + STL. А помимо этого за много лет куча новых стандартов вышло и еще всякие cmake-и и прочий зоопарк водится...
PS: За roadmap-ы спасибо - прямо definitive, приятно, что самому собирать не приходится, чувствуется коллективный разум современной IT-индустрии.

Посоветуйте, что почитать про подход entity component system?

НЛО прилетело и опубликовало эту надпись здесь

Как игровой программист и, в прошлом, программист движков - не поддерживаю список. Очень много нишевой литературы, очень много того что вам не понадобится.
Как по мне - стоит исходить из задач, которые перед вами встанут.
Вы всё равно начнете как джун. Предположим вы решили быть AI программистом. Почитали как работает ИИ, много умных книжек - во первых без практики вы их просто не усвоите. Какая-то часть инфы уложится, но очень маленькая. Во-вторых, вы всё равно будете работать с реальными решениям принятыми не вами, никто не даст вам как джуну проектировать архитектуру. А значит вы столкнетесь с легаси от людей, которые, скорее всего не читали того что читали вы. Конечно, общая эрудированность поможет, но проще осваивать материал под задачу, а не просто весь подряд.
Вот если вы хотите с нуля свой проект делать, тогда ознакомиться с теорией это правильно. Но опять же, не лучше ли читать то, что нужно конкретно сейчас?

UPD:
Конечно, в списках много отличных книг. Например, Robert Nystrom "Game programming patters" - это просто золото. Я в издательстве себе её печать заказал, настолько хотелось иметь её в бумаге. Но то что в списке много хороших книг не отменяет того, что я выше написал.

UPD: Понял что не совсем правильно сформулировал мысль. Список отличный. Много хорошего. Но и спорного хватает. Используйте как справочник по принципу "что почитать когда мне будет нужно", не читайте всё подряд(это вообще реально, всё перечисленное прочитать джуну?)

Считаю что все приходит с опытом на практике, бред читать сотни книг в никуда, полностью согласен.

Ну почему же в никуда, не зная алгоритмов сортировки Джун напишет пузырьковую и будет ее использовать, а shell "изобретет" через пять лет. Не лучше ли осваивать теорию до, чем чинить грабли на проде после?

А зачем писать алгоритм сортировки вручную, если это уже все давно реализовано? Должны быть черткие причины и чёткая проблема, которая решается своей реализацией

НЛО прилетело и опубликовало эту надпись здесь

Да, но допускать код джуна до прода без проверки... ну такое себе. А на ревью такие вещи быстро попадают на глааза.

Но это не умаляет полезность теории)

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

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

А какие из этих книг вы бы посчитали более общими? Я больше интересуюсь инди разработкой, как хобби, и пишу на rust и углубляться в С++ не хочется, но все равно есть множество вещей, которые существуют одинаково вне зависимости от языка и движка

Архитектура, паттерны и математика
Game Engine Architecture - читаем не закапываясь в тех детали, если чтото непонятно можно пропускать, кмк
Robert Nystrom "Game programming patterns"
- читаем, непонятные моменты ищем в примерах первой книги
Eric Lengyel. Mathematics for 3D Game Programming - если совсем плохо с 3d, лучше пройти базовый курс лекций на курсере, и потом прочитать эту, непонятные места ищем в первых двух книгах и перечитываем

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

Патерны тем более. Изучение их раньше времени приводит к тому, что их начинают впихивать везде, тут нужно четкое понимание зачем они нужны

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

Это сумма не то чтобы большая, с успешного ларька с шаурмой можно кажется похоже заработать. И автор с дтф там не разрабатывает, он фрилансеров нанимает дешёвых (соответствующего качества, судя по расходам). Дальше окажется, что ларёк масштабировать проще -- продать 100 треш-проектов не получится также, как продать 8. И 100 таких нанятых треш-программистов не смогут сделать одну хотя бы среднего качества игру.

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

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

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

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

Добавлю 3 от себя, которые подошли бы в Recomended, а не Optional-path

Pattern-Oriented Software Architecture - если паттерны из GoF про design-for-change или language idioms, то тут ещё и паттерны архитектуры, некоторые из которых, как и у Кристофера Александера, очень даже timeless.

Agner Fog Optimization manuals - про стоимость абстракций C++, и объяснение архитектуры современных процессоров на уровне, ещё понятном для прикладных программистов (хотя уже ближе к разработчикам компиляторов и embedded). Объясняет нелюбовь геймдев-программистов к виртуальным функциям, лишним ветвлениям, исключениям, и любовь к cache-locality.

Development and Deployment of Multiplayer Online Games - архитектура сетевых игр, от fast-paced шутеров, для mmo rpg.

А где можно приобрести вредные советы в бумаге?

вам наверное лучше автор @Andrey2008ответит

Ответ в личке

Можно мне тоже?

Тоже же бы хотел услышать.

У вас эта книга опубликована на сайте.
Как вы отнесетесь к инициативе, если публично какое-то количество людей соберется и закажет персональную печать для себя этой книге?
Как, например, было с ГПиМРЦ?

У вас эта книга опубликована на сайте.

Нет. Печатная книга сильно переработана :)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории