Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Геймдев доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 19
Писать код проще, чем книгу о том, как писать код
Не знаю, как насчет книги, но написать статью о разработке кода своей программы – явно, тяжелее, чем написать саму программу.
Хотя, в моем случае, при написании обучающей (иностранным языкам) программы «L'école», я себе чуть мозги не сломал, пока не довел её до, более-менее, рабочего состояния. Но, только теперь, через полтора года публикации ее первой версии, я, наконец-то, дозрел до размышлений: «А как «правильно» ваять код подобной программы, особенно, если делать это в команде, а не самому?». До статьи на эту тему еще далеко, но некоторые мысли вполне уже можно сформулировать.
Например, пришел к выводу, что прототип программы должен разрабатывать архитектор программы. Это должен быть работающий минимальный код, в котором весь потенциальный функционал реализован в виде формальных классов – модулей. В данном случае я имею в виду оконные приложения на С++.
Все формальные классы представлены своими публичными функциями, которые ничего не возвращают (обмен данными происходит через их параметры), за исключением обработчиков сообщений. Те возвращают стандартные значения LRESULT (TRUE либо FALSE), но, как и все остальные публичные функции имеют пустые тела.
Приватные части автономных классов (на уровне файлов это *.h и *.cpp модули) находятся в компетенции членов команды.
Далее, архитектор программы фиксирует вызовы формальных публичных функций в «модуле управления» (для оконных интерфейсов это, как правило, обработчики класса типа CMainFrame либо CMainWindow). Но, поскольку, эти функции – пустые, то их использование никак не проявляется.
На примере моей обучающей программы, основными, независимыми друг от друга модулями, являются: класс для работы с чтением / записью текущего состояния приложения, класс логирования, классы для работы с графикой, текстом (отображение и редактирование), звуком и данными, классы вспомогательных окон («О программе», «Помощь», «Настройка» и прочее) и т.д. и т.п.
Для всех этих классов архитектор дает их формальную реализацию. Затем раздает копии своего проекта всем членам команды и говорит, кому, какой модуль реализовывать. Такой подход позволяет достаточно просто организовать коллективную работу без использования внешних систем контроля версий, вроде, гита.
Члены команды доводят до ума свои модули и передают их архитектору. Он замещает формальные модули – их полными версиями и тестирует общую реализацию. При необходимости вносит коррективы в работу команды.
При таком подходе члены команды могут работать удаленно и иметь минимальный конфликт интересов, о которых шла речь в статье.
Я даже не знаю, нужен ли, в таком случае, тимлид либо техлид. Наверное, да, для больших проектов. Но, для группы из нескольких программистов, думаю, без последних можно обойтись. В таком случае, архитектор «пишет» код прототипа либо ваяет его по принципу конструктора модулей.
Таким образом, используя модульное программирование либо итерационно-модульное (где предыдущие итерации, собственные для «своего» модуля каждого программиста, фактически являются просто бэкапами), можно, как мне кажется, упростить работу команды. Зато, основная нагрузка ложится на архитектора. А члены команды могут даже работать независимо друг от друга.
Однако, возможность «легко подключить модуль к проекту» (путем простой замены формальной реализации – полной) и «легко отключить модуль от проекта» (соответственно, наоборот, заменяя полную реализацию – формальной), позволяет, со временем, накаливать потенциальные модули для будущих проектов. Что дает возможность быстро создавать новые прототипы для новых проектов, аналогичного типа.
По сути, в идеале, мы получаем этакий конструктор для будущих программ.
Например, у меня есть неопубликованная программа «МедиаТекст».
http://scholium.webservis.ru/Pics/MediaText.png
Вместе, эти две программы, явно, могут иметь общие модули. При этом, в последней используются потоки и опенсорсный видеоплейер, для которых можно создать свою формальную реализацию.
Вот, приведение уже только этих двух программ к общему модульному типу (к ним можно добавить и мою третью программу – загрузчик «MiniDL» для любимых видосиков, которая опубликована здесь), позволит создать хорошую базу прототипов для будущих проектов данного типа задач. После чего можно будет уже спокойно предлагать себя в роли архитектора на похожую работу :) .
Но, даже если программировать только для себя на уровне пет-проектов, то данный подход кажется перспективным, по крайней мере, я перестану забывать программную логику своих давно написанных программ и смогу спокойно модернизировать их до новых версий. Чем и собираюсь заняться, в ближайшее время.
Как-то так.
Какие инструменты использовались для написание книги? В чем верстали?
Дополню небольшим инсайтом про работу над черновиком Game++ уже со своей колокольни. Да, будет практически дубль с моим комментом в анонсе от издательства, но молчать опять не могу :)
С Сергеем познакомился на Хабре и, когда я летом прошлого года в комментах оффтопнул с наивным вопросом: «а где прочитать разное структурированное про оптимизацию? чтобы не метаться по всему интернету и не тратить много лет, собирая в своей голове всё это воедино», он мне в личке предложил посмотреть черновик будущей книги и позадавать вопросы, если я чего-то не понял из материала. Вопросов я назадавал вдоволь, да и своими комментами буквально заспамил весь черновик.
Там поначалу была только половина (около 250 страниц) материала и ASCII-схемы из статей одноименного цикла (можете их увидеть на Хабре). В некоторые схемы я не врубился и вызвался их перевести в вектор (пришлось вспомнить университетские навыки работы с CorelDraw), чтобы было и красивее и понятнее (даже мне). Как результат: два или три месяца работы по вечерам/ночам и около 250 иллюстраций. Они с виду простенькие, но над некоторыми пришлось поработать дольше, почитать доп.литературу, статьи, собрать референсы, чтобы как можно локаничнее, точнее, нагляднее и грамотнее передать суть.
Теперь впечатления непосредственно про книгу — она вдохновляющая, когда я читал о некоторых аллокаторах (их не было, в статьях на Хабре, если что), у меня временами взрывался мозг — "а что так можно было? кто такое вообще придумал?". Вот игрушка на первый облыжный взгляд простенькая, ну не крузис же, чего сложного-то? — а под капотом тройной стековый аллокатор, еще и на асме, чтобы на железе тех лет она не то что летала, а вообще работала — вы представляете этот уровень мастерства и любви к искусству?
Далее порадовала часть про STL и вредные советы по алгоритмам (а-ля "Вредные советы для C++ программистов" Андрея Карпова — тоже классная книга), потому что там мне иллюстрации не надо было рисовать я познакомился с очень сильной аргументацией и дельными замечаниями от практикующего С++ разработчика, а не теоретика. Эта часть на меня сильное влияние оказала, что не надо выпендриваться и отказываться от возможностей языка и его библиотеки, когда некоторые «мэтры» считают иначе, ты код пишешь и в процессе важно его таки написать в разумный срок, чтобы работал и другие читать смогли, а не только самоутвердиться.
Про аудиторию. Game++ — это не учебник и не руководство для совсем уж начинающих, т.е. с одной только этой книгой вы движок не напишете, предполагается, что на плюсах писать вы можете и хотите. Более широкие знания / направления можно почерпнуть из GEA Грегори вкупе с Game Programming Patterns Найстрома, да и у них идет столько отсылок на источники, что лет за 50 всё не перечитать. Game++ эти книжки хорошо дополнит — можно (или лучше даже) читать их параллельно.
А еще у меня, как у начинающего, эта книга развеяла иллюзии про оптимизацию кода, в голове раньше была какая-то радужная картинка, мол, вот крестами/матаном/CS овладею, паттерны повторю, где-то алгоритм со SO подрежу и буду вторым Кармаком — авотфиг! — тонну кода пересмотри / сам напиши, инструментом овладей, матчасть прочитай, мозг включи, опыта / насмотренности наберись, вот тогда будет счастье (но не долго, т.к. эта музыка будет вечной, и придется повторять процедуру раз за разом).
Ну и еще много чего полезного я вынес из Game++, и про архитектуру и обзоры движков (юнити, анрил, дагор, край энжин и т.д.), как, кем, для чего они писались, что авторы хотели, на что обращали внимание, и про аллокаторы и контейнеры: какие бывают, где их применять, как их разогнать, какие нюансы и подводные камни бывают. И еще вагон с тележкой про многопоточность и паттерны разработки.
Сергея и причастных еще раз благодарю и поздравляю с выходом книги. Рад, что удалось внести свою лепту в ее создание.
Хм, была же уже в пятницу или четверг эта статья? Я правда прочитать не успел, открыл на работе, но руки не дошли. Но начало вроде то же самое.
Круто! Спасибо вам за проделанную работу, обязательно куплю, как минимум для общего развития)
Большое уважение за проделанную работу! Всегда открываю ваши статьи на Хабре, хотя на C++ не пишу уже довольно давно - обычно есть что почерпнуть и без языковой специфики.
P.S. Книжку купить не обещаю, но интересно было бы полистать, покрутить в руках. Это можно сделать где-то?
Писать код проще, чем книгу...
С этим не поспоришь. А написать плохую книгу, куда проще чем хорошую.
Книгу можно взять тут (с)
"Взять" можно за 1980 руб и в бумажном экземпляре.
...Что б писать хорошие книги, автору следует научиться точности слов. Руский язык богат, в нём есть более точное слово "купить", нежели "взять".
"Причастный" и знающий человек (с) пишет:
Game++ — это не учебник и не руководство для совсем уж начинающих, т.е. с одной только этой книгой вы движок не напишете
Сергея и причастных еще раз благодарю и поздравляю с выходом книги. Рад, что удалось внести свою лепту в ее создание.
https://habr.com/ru/articles/1002546/#comment_29569994
Количество страниц 592
Ключевые темы:
Архитектура игровых движков
Работа с памятью в компьютерных играх AAA-класса и других приложениях с высокими требованиями к производительности
Структуры данных языка С++
Работа со стандартной библиотекой шаблонов C++ (STL)
Обработка исключений
Неопределённое поведение и способы его предотвращения
Память и аллокаторы
Оптимизация в C++
Многопоточность
Классические паттерны проектирования применительно к разработке игр
По описанию вялые и невнятные темы.
Книга представляет собой сборник размышлений о языке... это не академическое исследование и не руководство к действию — это личный перечень наблюдений, пожеланий и претензий к C++. В книге описаны подходы к разработке игр, выработанные автором на основе собственного опыта.
(с) аннотация на сайте издателя
Может, всё-таки не стоило писать книгу?
А главное о игровых функциях в ключевых темах ни слова. Ни лодов, ни текстур, ни анимаций, ни звука, ни управдение, состояния, ии, модульность... Да даже про gameloop нет отдельной темы и про скриптовые языки
Определенно стоило, думаю опыт разработки и оптимизации AoE2, Sims, WarThunder, Metro, Deathloop, Stellaris и еще пары крупных проектов интересен многим. Не всем надо писать с нуля игровой движок. Заглянуть стоит в оглавление, там темы не такие вялые ;)
Заглянуть стоит в оглавление, там темы не такие вялые
Не успел тебе написать, но на сайте издательства действительно нет доступа к оглавлению. Считаю надо добавить обязательно.
Добавил ссылку на ozon, там есть оглавление.
>Q: Где купить в Европе?
>Q: Будет ли электронная версия или только бумага?
>A: Будет, позже.
Посмотрел оглавление, очень жду! (лучше раньше, чем позже :D)
А какая ситуация с современным С++, за 10 лет которые писалась книга она не успела устареть?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Писать код проще, чем книгу о том, как писать код