- Сообщения
- 67
- Реакции
- 85
Автор статей: Дядя Миша, многим известный как разработчик движка Xash3D
Источник: csm.dev (ранее известный как cs-mapping.com.ua)
К созданию данного цикла статей (ну или по крайней мере первой статьи из цикла) меня подтолкнул тот простой факт, что даже спустя 16 лет подавляющее большинство крайне смутно себе представляет принцип работы Quake-движков. Статей по их внутреннему устройству практически нет, а то что есть - перевод надмозгов о принципе работы BSP. Причем перевод такого рода, что понять чем там вообще идет речь затруднительно, но признаваться в этом как-то стыдно.
Поэтому их мапперы их друг-другу советуют к прочтению, а потом с умным видом спрашивают: ну как, помогло? На сайте gamedev.ru, до сих пор проскакивают упоминания о чрезмерной брутальности кода кваки, а один товарищ два дня искал там класс камеры, но так и не смог найти.
В силу этого представление о том, как пишутся игровые движки у многих строятся исключительно на книжках для начинающих с названием "как самому сделать игру". Эти книжки неплохо помогают провести начальный ликбез, но все примеры в них не являются хоть сколько-нибудь конкурентноспособными. То есть, грубо говоря, в книжке приводится простой пример как можно сделать то-то и то-то, но всегда обходится стороной тот факт, что в реальных условиях этот пример выступит ключевым тормозом перестройки и для серьезной игры он попросту непригоден. При этом литературы о том, как писать серьезные движки по сути не существует в природе. Предполагается что грамотному программисту достаточно лишь обрисовать алгоритм, а он по нему уже сам всё зафигачит.
В результате имеем дефицит информации как раз для того слоя, который имеет о работе 3D движков уже довольно определенное представление, но о самих методах, причем не абстрактных, а тех, которые реально работают и дают приемлемые результаты. Иными словами из всех примеров NeHe полноценный движок не слепить.
Когда-то на gamedev.ru существовал неплохой обучающий проект GUNgine, преследующий аналогичные цели, но к сожалению после 12-го урока он был свернут, а сами уроки-примеры куда-то пропали. Собственно я перед собой цели написать такой движок-пример не ставлю, поскольку до меня с этой задачей справилась Id Software вообще и гражданин Кармак в частности. И да, я полагаю, что изучение внутреннего устройства движка, который был использован в доброй сотне игр и модов, практически без изменения ядра и архитектуры заслуживает того, чтобы посвятить ему цикл статей, где подробно рассмотреть основные механизмы и методы их реализации.
Первое, что хотелось бы осветить, это механизмы отсечения невидимых для игрока объектов и частей уровня, как на клиенте, так и на сервере, поскольку это один из основных механизмов, дающий движку приемлемую производительность даже на слабых машинах. Темы для остальных статей из цикла, я думаю определят наши форумчане, в виде пожеланий- предложений. Основные аспекты будут раскрываться применительно ко всей линейке движков Quake от первого до третьего, поскольку там много схожих механизмов, ну и иногда будет упоминаться Half-Life, если данный механизм там имеет некоторые отличия.
Кроме того будет отдельная статья, посвященная загрузке, отрисовке и колоизации студиомоделей, которые используются в Half-Life (потому что на эту тему тоже практически нет информации).
Итак, поехали:
1. Статья о методах отсечения невидимых объектов в Quake
2. Статья о реализации физики в Quake
3. Статья о реализации статического и динамического освещения в Quake
4. Статья о работе со строками в Quake и Half-Life
5. Статья об устройстве changelevel в Quake и Half-Life
6. Статья-экскурс о Stupid Quake Bug и о том, как с ним бороться
Источник: csm.dev (ранее известный как cs-mapping.com.ua)
К созданию данного цикла статей (ну или по крайней мере первой статьи из цикла) меня подтолкнул тот простой факт, что даже спустя 16 лет подавляющее большинство крайне смутно себе представляет принцип работы Quake-движков. Статей по их внутреннему устройству практически нет, а то что есть - перевод надмозгов о принципе работы BSP. Причем перевод такого рода, что понять чем там вообще идет речь затруднительно, но признаваться в этом как-то стыдно.
Поэтому их мапперы их друг-другу советуют к прочтению, а потом с умным видом спрашивают: ну как, помогло? На сайте gamedev.ru, до сих пор проскакивают упоминания о чрезмерной брутальности кода кваки, а один товарищ два дня искал там класс камеры, но так и не смог найти.
В силу этого представление о том, как пишутся игровые движки у многих строятся исключительно на книжках для начинающих с названием "как самому сделать игру". Эти книжки неплохо помогают провести начальный ликбез, но все примеры в них не являются хоть сколько-нибудь конкурентноспособными. То есть, грубо говоря, в книжке приводится простой пример как можно сделать то-то и то-то, но всегда обходится стороной тот факт, что в реальных условиях этот пример выступит ключевым тормозом перестройки и для серьезной игры он попросту непригоден. При этом литературы о том, как писать серьезные движки по сути не существует в природе. Предполагается что грамотному программисту достаточно лишь обрисовать алгоритм, а он по нему уже сам всё зафигачит.
В результате имеем дефицит информации как раз для того слоя, который имеет о работе 3D движков уже довольно определенное представление, но о самих методах, причем не абстрактных, а тех, которые реально работают и дают приемлемые результаты. Иными словами из всех примеров NeHe полноценный движок не слепить.
Когда-то на gamedev.ru существовал неплохой обучающий проект GUNgine, преследующий аналогичные цели, но к сожалению после 12-го урока он был свернут, а сами уроки-примеры куда-то пропали. Собственно я перед собой цели написать такой движок-пример не ставлю, поскольку до меня с этой задачей справилась Id Software вообще и гражданин Кармак в частности. И да, я полагаю, что изучение внутреннего устройства движка, который был использован в доброй сотне игр и модов, практически без изменения ядра и архитектуры заслуживает того, чтобы посвятить ему цикл статей, где подробно рассмотреть основные механизмы и методы их реализации.
Первое, что хотелось бы осветить, это механизмы отсечения невидимых для игрока объектов и частей уровня, как на клиенте, так и на сервере, поскольку это один из основных механизмов, дающий движку приемлемую производительность даже на слабых машинах. Темы для остальных статей из цикла, я думаю определят наши форумчане, в виде пожеланий- предложений. Основные аспекты будут раскрываться применительно ко всей линейке движков Quake от первого до третьего, поскольку там много схожих механизмов, ну и иногда будет упоминаться Half-Life, если данный механизм там имеет некоторые отличия.
Кроме того будет отдельная статья, посвященная загрузке, отрисовке и колоизации студиомоделей, которые используются в Half-Life (потому что на эту тему тоже практически нет информации).
Итак, поехали:
1. Статья о методах отсечения невидимых объектов в Quake
2. Статья о реализации физики в Quake
3. Статья о реализации статического и динамического освещения в Quake
4. Статья о работе со строками в Quake и Half-Life
5. Статья об устройстве changelevel в Quake и Half-Life
6. Статья-экскурс о Stupid Quake Bug и о том, как с ним бороться
Последнее редактирование: