Реклама:

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

Напоследок приведу одно важнейшее правило работы с любыми текстурами, в том числе и для спрайтов. О нем, увы, забывают порой даже профессиональные разработчики, что кончается серьезными графическими глюками. У любой текстуры должны быть стороны, кратные степеням двойки, т.е. из ряда 4, 8, 16, 32, 64, 128, 256, 512, 1024 и далее по списку. Это требование связано с особенностями организации видеопамяти. Самое малое, что вы можете получить, нарушив его, — темные полосы непонятного происхождения по краям полупрозрачных спрайтов. И если на каком-то этапе разработки у вас на каких-то текстурах вдруг появились непонятные артефакты, в первую очередь проверьте, какие у них размеры.

Программирование игры на основе движка ЄІ^сепе: иерархия классов и объектов

Прежде всего давайте выясним, зачем вообще нужна какая-то иерархия, система классов? Почему бы просто не писать движок, как пишется, и не заморачиваться какими-то иерархическими сложностями? Необходимо это для того, чтобы потом не было предельно сложно. В одном из педыдущих разделов я привел пример с домом и кирпичами. Мы выяснили, что игровые движки лучше разбивать на независимые модули. Можно продолжить эту аналогию. Допустим, вы строите крупнопанельный дом, и вашему начальству пришло в голову панели сделать ну очень крупными: размерами в несколько этажей, да еще и сложной формы. Соседний дом строится по старинке, из кирпичей. Вдруг высшее начальство решило, что дома должны расти не ввысь, а вширь. Какое здание будет проще переделать под новый стандарт? Ясно, что кирпичное, так как там элементы гораздо меньше, и они могут свободно сопрягаться друг с другом.

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

Результат таких преобразований всегда один: непонятный код, состоящий из плохо стыкующихся кусков, странные баги, которые приходится отлавливать неделями, и бессчетные чашки кофе, не способные более охладить кипящий разум всех программистов проекта. Но и это не самое страшное. Самое страшное — потеря времени, а значит, — вновь умчавшиеся вперед технологии, вновь поменявшаяся конъюнктура рынка, и работу опять приходится начинать сначала.


⇐ Предыдущая страница| |Следующая страница ⇒