Форум программистов [Powered by Invision Power Board]

Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Программирование игр, графики и искусственного интеллекта > Начать с тетриса (классический совет ветеранов)

Автор: Gunslinger 19.4.2007, 15:40

Вот решился. Игрушка будет видоизменяться и наращивать способности по мере повышения моего экспириенса. Для начала: одноэлементные кубики, никаких вспышек, работа в канвас.
Выбрал "стакан" средой обработки столкновений кубиков с полом, стенами, друг с другом. То есть функции элементов "физической" части будут выполняться в "стакане" (main, я думаю).
Кубики будут представлять собой объекты, инкапсулирующие графические ресурсы (свое изображение в нормальном режиме и режиме уничтожения), звуковые ресурсы (звук падения на поверхность и звук уничтожения), геометрические размеры... Может быть еще какие механизмы (пока моя игровая логика слаба и пашет со скрежетом).
Кое-какие вопросы:
1. Как организовать движение? В кубике функциями приращения координат (падения) и перерисовки или в среде (среда сама следит за движением кубиков) и через таймер? (лучше выразиться пока не могу).
2. Вопрос к первому. Как обновлять изображение? В тетрисе хорошо то, что в каждый момент времени движется только один объект. А если несколько? Все привязывать к единому таймеру или можно реализовать перерисовку каждого объекта поотдельности (тогда можно получить эффект мерцания)?

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

Автор: Rickert 20.4.2007, 06:00

Ты просто должен каждый кадр рисовать с чистого листа и всё. Отчищая экран и опять рисуешь все элементы, по новым координатам. Функция отрисовки (в ней же, предварительно, очистка) срабатывает по таймеру, который ты задаёшь (25 раз в секунду - сам понимаешь - норма). Перед тем как отрисовать - просчитываешь всю аналитику игры: столкновения, падение кубика, появление нового и т.п.

Автор: Gunslinger 20.4.2007, 18:02

Rickert, это понимаю.
  void Приростил_координату(); (в случает тетриса - координату падения y)
  флаг=bool Просчитал_столкновение(); истина - столкновение
  if(флаг)
             {  Оставить объект; т.е. снять с объекта "фокус", чтобы игрок с ним уже не смог работать
                 Создать новый объект; пока невидимый
                 Перерисовать_канвас;
               }
     else Перерисовать_канвас;

Где-то так себе представляю. Но тут все с объектами. Короче говоря грубый набросок.
Переосмыслил вчерашний пост и переформулировал вопросы.
1. Понятно, что перерисовывается только канвас, поэтому в объекте "кубик" безсмысленно создавать метод перерисовки.
2. Кто следит за столкновениями: сама среда или в каждом объекте реализовывать метод ("сканирование" пространства перед собой, если столкновение - переключать на другие механизмы класса, которые будут обрабатывать поведение объекта соответственно столкновению?
3. Как определять, что перед объектом (как раз задача "сканера")? Со своей колокольни вижу только один способ - матрица. Тогда в метод кубика "сканер" передается информация о ячейках перед ним. Если в ячейке 1, то препятствие и остановиться. Именно это описал псевдокодом. То есть методы всех объектов работают с единой матрицей. Есть другие способы?

Автор: Rickert 21.4.2007, 07:18

Цитата(Gunslinger @ 20.4.2007, 18:02

)

2. Кто следит за столкновениями: сама среда или в каждом объекте реализовывать метод ("сканирование" пространства перед собой, если столкновение - переключать на другие механизмы класса, которые будут обрабатывать поведение объекта соответственно столкновению?

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

Цитата(Gunslinger @ 20.4.2007, 18:02

)

3. Как определять, что перед объектом (как раз задача "сканера")? Со своей колокольни вижу только один способ - матрица. Тогда в метод кубика "сканер" передается информация о ячейках перед ним. Если в ячейке 1, то препятствие и остановиться. Именно это описал псевдокодом. То есть методы всех объектов работают с единой матрицей. Есть другие способы?

Вот так и делай. smile

Автор: Gunslinger 21.4.2007, 10:00

Процесс "сканирования", как я себе его представляю. В классе "кубик" реализуем функцию обработки столкновений с аргументом, в который - на каждом шаге движения - среда записывает флага: есть впереди препятствие (другой кубик) или нет. Эту информацию среда, в свою очередь, берет из глобальной матрицы. Можно обработку столкновений реализовать в одной функции (столкновение со стеной, столкновение с другим объектом, определение, достиг ли кубик крыши "стакана"), а можно разнести по функциям, тогда одна будет получать от среды флаг, анализировать и направлять соответствующей функции - сейчас не суть важно.
Только вот друг говорит, что определять столкновения по матрице - изврат. Как неизвратно - я не уточнил, однако думаю что способ только один. Потому что сегодняшняя компьютерная техника умеет оперировать только битами, "сканирование" графиеской и семантической информации - удел компьютеров будущего. Или он все таки прав и есть другой способ?

Автор: Goganchic 23.4.2007, 14:43

А что если назначить задачу сканирования не кубику а среде, т.е. чтобы среда занималась сканированием и выставляла соответствующие флаги. Тогда получиться, что не надо каждому объекту давать доступ к глобальной матрице. Как такая идея?
P.s. извиняюсь за корявый язык, если что-то не понятно - спрашивайте

Автор: Gunslinger 23.4.2007, 16:16

Goganchic, я думал над этим вопросом. Сканирование может осуществляться двумя объектами: кубиком и средой. Если кубиком:
В классе "кубик" есть открытая функция с аргументом (или с аргументами: ячейка снизу, ячейка слева, ячейка справа, ячейка сверху). Программист в главной программе вызывает эту функцию объекта и передает ей значения из матрицы (пока не знаю, как этот механизм будет выглядеть). Все остальное происходит в обработчиках объекта.
Если средой.
Тут может быть я гоню, но в моем представлении при таком способе среда становится менеждером объектов и сама ими рулит. А если количество объектов неизвестно? То есть чтобы менеджер не распух, его придется ограничить.
Да и с точки зрения объектной ориентированности так мне кажется правильнее. В игрострое я не шарю, так что может и не правильнее - не объект сам себе хозяин, а среда, в которой этот объект находится.