Простое обнаружение столкновений выполняется путем проверки, перекрывают ли ограничивающие рамки (или иногда ограничивающие круги). То есть, если для данного объекта A и объекта B их ограничивающие рамки перекрываются, то произошло столкновение.
Если вы хотите получить фантазию, вы создаете полигоны для своих объектов и определяете, перекрывают ли ограничивающие полигоны. Это сложнее и сложнее понять, а также требует значительно больше обработки.
Это не сильно отличается от использования тайлакарты. Используя карту тайлов, вы обнаруживаете столкновения с плитками. Без карты тайлов вы обнаруживаете столкновения с ограничивающими рамками отдельных объектов. Логика почти идентична.
Дополнительная информация:
Я думаю, что проблема, с которой вы боретесь, заключается в том, что вы думаете с точки зрения экранов. При написании игры важно отделить концепцию игрового мира (модель) от презентации (экран).
Например, простая игра с боковым скроллером может состоять из множества «экранов», полных информации. В то время как экран может иметь ширину 1000 единиц, игровой мир может иметь ширину 10 000 или 100 000 единиц. Обратите внимание, что я говорю «единицы», а не «пиксели». Единица измерения игры может быть дюймами, сантиметрами, милями или чем-то еще. Вся ваша игровая логика должна работать с точки зрения мировых координат. То, как вы проецируете это на вид (экран), не имеет отношения к тому, что происходит в мире.
Каждому объекту в мире назначается позиция в мировых координатах . Это включает в себя спрайт игрока, который перемещается по миру. Все обнаружение столкновений и других взаимодействий объектов в мире осуществляется в терминах мировых координат.
Чтобы упростить вещи, предположим, что существует взаимно-однозначное сопоставление между мировыми единицами и единицами экрана. То есть ваш мир имеет ширину 10000 пикселей, а экран - 1000 пикселей. Тогда мир размером «десять экранов». Вернее, экран может просматривать 1/10 мира. Если это так, то ваш вид может быть определен самой левой мировой координатой, которая видна. Таким образом, если мировая координата 2000 находится слева от вашего экрана, самый правый столбец пикселей на вашем экране будет иметь мировую координату 2999.
Это означает, что вам нужны функции преобразования из мира в экран и из экрана в мир. Для этого случая эти функции очень просты. Если предположить, что вертикальной прокрутки нет, то нужно преобразовать только координату x, вычитая координату x мира из координаты x вида. То есть world.x - viewOrigin.x. Таким образом, в приведенном выше случае экранная координата объекта, находящегося в мировой координате х 2,315, будет (2,315–2000) или 315. Это координата x положения объекта на экране. В текущем представлении.
Экран к миру противоположен: добавьте экранную координату объекта к источнику представления: 315 + 2000 = 2 315.
Не могу не подчеркнуть, насколько важно поддерживать это разделение между координатами мира и вида. Вся ваша игровая логика должна работать с точки зрения мировых координат. Вы обновляете представление, чтобы показать вам, что происходит в мире. В боковом скроллере вы обычно перемещаете вид влево и вправо в зависимости от действий игрока. Если игрок перемещается влево, вы перемещаете начало координат влево. Если игрок двигается вправо, вы перемещаете начало координат вправо.
Как только вы усвоите эту идею, все станет намного проще. Все, что делается в игровом мире, происходит в мире . Вы проверяете, что состояние мира согласованно, а затем вы беспокоитесь о том, чтобы отобразить представление о мире.
Нет более простого (насколько мне известно) способа создать игру, которая больше экрана. Независимо от того, как вы его построите, у вас должна быть какая-то концепция, показывающая только часть мира на виде. Формализуя его, вы отделяете презентацию от логики игры, и все становится намного проще.