Обложка книги
Я всё ещё продолжаю разгребать завалы литературы, и мне попалась на глаза "Игровая разработка без боли и кранчей" Ричарда Лемаршана. И, как по мне, это довольно хорошая книга, несмотря на забавное название. Почему я нахожу его немного смешным? Ну, в разработку игр без кранчей, я с трудом, но могу поверить. Но без боли? Ха, и ещё три раза ха. Тут на некоторые движки взглянуть без боли нельзя, а если начать смотреть в их кишки, то единственная реакция на это может быть только изображение ниже.
После многочасовой отладочной сессии
Но опять же, книга написана с точки зрения геймдизайнера, причём довольно крупных студий - Naughty Dog язык не повернётся назвать маленькой. Так что речь в книге идёт с позиции этой профессии, а также её роли в процессе разработки.
Сразу же напишу о том, что в книге не понравилось, так как понравившегося всё же больше. Я сильно не люблю маркетинговый стиль написания книг, когда возникает ощущение, что человек продаёт свою важность и пытается её доказать нам. Как по мне, сам факт покупки книги уже достаточен и особо пиариться и пиарить профессию в тексте нет смысла. Но, к счастью, к середине книги это ощущение исчезает.
Ещё часть советов выглядят как "делайте хорошо, а плохо не делайте", т.е. довольно очевидны любому, кто хоть раз открывал литературу по управлению проектами. Ну да ладно, всё же для новичков такое будет полезно.
Это всё мелочи, но что мне понравилось - замечательное описание документов, оформляемых геймдизом - макродизайна и микродизайна. Отличные советы по оформлению плейтестов - пожалуй, к ним хочется вернуться. Ещё огромный интерес у меня вызвала связь порядка разработки игры с порядком следования элементов сюжета. Она здесь, оказывается, довольно неочевидна, но этому приведено внятное и хорошее обоснование. Я, например, полагал, что начать надо с условного первого уровня игры и так вперёд, а, оказывается, - нет, и даже не с последнего.
Из управления проектами страшно понравилась идея диаграммы "сгорания задач". В принципе, автопостроение такой диаграммы - классная тема, и, как по мне, полезная вещь. Она в книге не совсем такая, как в вики, и выглядит более удобной.
Но я не удержусь здесь от небольшой критики - вообще процессы, описанные в книге, выглядят немного тяжеловесными и будут хороши, когда на их поддержание есть ресурсы. Это заставляет задуматься о том, что же можно из всего процесса исключить при управлении маленькой командой? Есть ощущение, что после размышлений в итоге можно прийти к выводу, описанному в одном из ранних докладов о разработке ПО: "Какие планы? Какие диаграммы? Садимся работать и ***шим!"
Но книгу однозначно рекомендую. Это неплохое чтение, и я, пожалуй, в своей библиотеке оставлю.
