Создание 2Д игр с условно бесконечным пространством

[IGR]

Под условно бесконечным подразумевается то что игровая карта будет большой, настолько большой что игрок в ходе игры не сможет осознать ее размеры !! Реалтаймовой или еще какой либо генерации пространства не будет !!
Вообще размеры карты это уже косвенный вопрос, а интересует в первую очередь слудующие:

1) Объекты на карте:
Я так думаю нужно вводить какуето игровую единицу растояния и в файлах даных записывать позиции объектов в етих единицах: объект1, 100, 20; объект2,5000,450; и т. д.

2) Отображение карты на экране и навигация игрока:
Ну а тут я вообще хз !! Вот допустим игрок види часть карты на экране по Х 100 - 200 игровых единиц, по У 250 - 300 игровых единиц !! Если у нас есть какие то игровые объекты то отображаем их !! При перемещении игрока все время пересчитываем !! Но как быть с ландшафтом ??
Вторая мысль типа создание какойто композитной картинки куда отрендерить кусок карты с ландшафтом объектами и прочим и двигать эту картинку по экране при перемещении !!
Вообщем хотелось бы услышать толковые решения знающих !! Спасибо !!

[IGR]

чо-чо ?? Никто не делал двухмерные игры ?? Или непонятны вопросы ??
Эх.. Ох.. Ах.. ((

[SBJoker]

в 2д обычно расстояния меряют клетками из которых это 2д и состоит.
В СтарКрафт-1 например самая большая карта это 256*256, и это реально огромная карта.

[IGR]

не ну я представляю что нужно какой то порог дискретности, но как определять что выводить на экран юзеру ?? Не всю же эту карту огромную карту держать в видеопамяти ??

[pax]

1. У тебя есть объекты (тайлы, юниты и остальное), есть координаты экрана, строишь квадтри уровня, делаешь запрос объектов, рисуешь необходимые.

2. Если поле - двухмерный массив, то исходя из координат экрана рассчитываешь область подмассива которую надо рисовать - рисуешь...

3. Еще что-то подобное... что давно не рисовалось можно выгружать. Либо что далеко от координат экрана.

[Reizel]

объекты имеют X,Y, RenderSize.
Так же нужно иметь OFFX,OFFY - смещения, как бы 2Д координаты камеры.
В цикле проверяешь (для каждого объекта), входит ли его XY координаты в прямоугольник экрана + RenderSize объекта. Усе!
А если тебе не понятна единица измерения - делай, к примеру, по 10 пикселей на единицу. и выводи - x*10,y*10 . Хотя я так бы не стал.

[baton4ik]

Всё правильно насоветовали!
Для Colominer'a делал тайловый движок - есть список зон, в каждой зоне 75*75 тайлов. У каждой зоны есть свои локальные координаты и у каждого тайла есть локальные координаты внутри зоны. Функции, которые конвертируют экранные координаты в локальные зоны (с учётом смещения камеры) и локальные тайла, возвращают сам тайл. И функции обратной конвертации для отрисовки тайла.

[IGR]

всем спасибо !!
2Д игры это просто !!

[HolyDel]

имхо

Реалтаймовой или еще какой либо генерации пространства не будет !!

не состыкуется с

Создание 2Д игр с условно бесконечным пространством

[IGR]

не ну чо имеется в виду что мир будет очень большой, для юзера будет казатся бесконечным, но тем не мение ввесь мир будет сразу описан в файлах даных и не будет генерироватся в ходе игры еще что то !!

[Phantom]

У меня вопрос не по теме, но тоже про создание пространства. Взгляните на пример во вложении. Структуру лабиринта из примера слева можно просто хранить в памяти, разбив на сектора, каждый сектор может иметь одно из двух значений: "стенка" или "пустота". Карту такого лабиринта можно хранить построчно в файле из 10 строк, по десять символов в каждой:

/*********
0000000000
0111011110
0001010010
0111010110
0100010100
0111110110
0010000000
0111011100
0101110110
0000000000
*********/ 


А как мне хранить карту лабиринта из второго примера?

[IGR]

ну можно по аналогии - есть стенка/нету, но тут тебе нужно уже описывать не ячейку а ее 4 стенки !! Но поскольку одна стенка принадлежит сразу двум ячейкам то зачем описывать эту стенку два раза в двух ячейках !! Можно просто описать стенки по горизонтали и по вертикали !! В этом случаее будет 9 значений в ряд, или 11 если учитывать еще ограничивающие стенки !!
Первая строка по горизонтали будет - 10010010011, а по вертикали - 11010110101 !!

[Phantom]

А если усложнить задачу и учитывать, что у стенки с разных сторон должна быть разная текстура или просто я введу какое-то свойство стенки, которое может отличаться у неё с обоих сторон?

[Dream]

а кто ограничивает каким числом описывать ячейку? можно же отвести 1,2,4,8,16 для типа пола, 32, 64, 128 - для типа стенок.
Это если важно чтобы поле было описано имеено так как ты написал. и кстати, если всётаки только один символ на ячейку, то можно использывать же char*он там до 256 кажется же,

[Phantom]

Метод хранения роли не играет. Мне интересно, как правильнее разбивать лабиринт на сектора. По пустым пространствам может перемещаться персонаж, там могут находиться какие-либо предметы или ещё что-то. Пустые пространства в любом случае надо как-то хранить в памяти, всё равно разбивая на сектора, как и на рисунке. Но и информацию о стенках как-то надо хранить. А они, в отличие от первого рисунка, не лежат в зоне секторов, а лежат между секторами, как по вертикали, так и по горизонтали. Вот я и не знаю, как лучше хранить это всё вместе. Если хранить по методу, который описал IGR, то отдельно придётся информацию о секторах хранить. А при перемещении персонажа по лабиринту придётся учитывать информацию из двух разных источников. Как-то бы разбить по уму всё на сектора, чтобы получилась единая структура, по которой было бы несложно перемещаться в циклах, как по двумерному массиву.