Извините, ничего не найдено.

Dream · 01.05.2011, 05:23

Если хранить допустим в тойже xml, то можно держать описание сектора, а внутри его описания к его стенкам.
По типу такого( для первой ячейке твоего примера)

<sector location="1;1" type="1" >
    <wall side="upper" type="1" />
    <wall side="left" type="1" />
    <wall side="buttom" type="2"/>
</sector>

Ну а ячейка должна быть типом/структурой, которая содержит список(а лучше словарь, с ключом - сторона) структур/классов её стенок.

Phantom · 01.05.2011, 05:57

Полегче, у меня игра будет для мобилы, всё будет проще. =) По сути ты предлагаешь делить на сектора, как на рисунке, и у каждого сектора хранить информацию об окружающих его стенках. Я так и думал делать, но меня просто смущает некоторая избыточность, как и сказал IGR, потому что о каждой стенке информация так или иначе будет содержаться в двух соседних секторах. Но я сейчас подумал, наверно это будет хороший вариант. Я буду хранить не информацию о стенках, а информацию о полустенках, пофиг на исбыточность, зато можно будет прикольные вещи делать, например сделать стенку однопроходной, чтобы через неё в одну сторону можно было пройти, а в другую нет. Или порталы. В общем, вопрос решён. Спасибо. =)

Dream · 01.05.2011, 05:59

Сообщение от Phantom

Полегче, у меня игра будет для мобилы, всё будет проще. =)

Xml не так уж и тяжел, если конечно там не будет описано 100000 ячеек

Phantom · 01.05.2011, 06:13

Да не, зачем усложнять. Я даже в памяти поле лабиринта наверно буду просто как массив чисел хранить. Если вдруг станет мало 4 байт, увеличу тип до Long.

pax · 01.05.2011, 14:52

Хм... не вижу разницы

Нажмите на изображение для увеличения
Название: maze.png
Просмотров: 891
Размер: 11.4 Кб
ID: 13613

блоки на уровне расставлять можно анализируя матрицы 3х3:

Нажмите на изображение для увеличения
Название: maze1.png
Просмотров: 885
Размер: 12.2 Кб
ID: 13614

Phantom · 02.05.2011, 01:26

pax, у меня и такая идея тоже была, но в таком случае нужно ещё хранить и углы секторов, информация о которых в коде вообще нафиг не нужна. Всё таки буду делать так, как решил. =)

pax · 02.05.2011, 02:11

Эм... мне казалось во втором варианте лабиринт больше в 4 раза... нет? Я что-от не понял про углы секторов...

Phantom · 02.05.2011, 08:41

Нее, лабиринт не больше. Поле по сути такое же. Он только кажется больше засчёт того, что стенки в нём находятся между секторами, а не являются секторами, как в первом.

IGR · 02.05.2011, 11:41

не ну в первом случае стенки занимают (отнимают) место в лабиринте, а во втором нет так как стенки именно между ячейками !! По этому в первом лабиринте пространства меньше чем во втором !!

pax · 02.05.2011, 12:03

Во втором случае стенками являются все клетки, в отличии от первого, а ходить можно по ребрам. Это как раз увеличивает площадь лабиринта в 4 раза так как я расставил нолики и единички.

Собственно я хотел собрать первый лабиринт из блоков второго - у меня не получилось... наверное потому что принцип построения разный. Карту такую можно собрать из ~10 разновидностей блоков каждый поворачивая на 0/90/180/270 градусов, но сетка передвижения будет такой как я привел. Если хочешь, чтобы она была такого же разрешения, как и первый лабиринт, то второй надо инвертировать. Но опять же новый лабиринт будет больше, т.е. клеток, на которые можно наступить будет больше:

Нажмите на изображение для увеличения
Название: maze2.png
Просмотров: 918
Размер: 3.8 Кб
ID: 13616

Правда надо будет хранить информацию о гранях/углах для столкновений... Так что даже не знаю как ты собираешься с тем же разрешением сделать нормальную обработку... Потом поделись решением, если не секрет будет

Taugeshtu · 02.05.2011, 19:36

Всё можно сделать чуточку проще. Представьте себе, что вам нужно сделать кольчугу из квадратиков. Причём базовый элемент кольчуги должен быть одинаковый. Что мы сделаем? Правильно, сделаем элемент, который имеет соединения типа "папа" с, допустим, нижней и правой стороны, и "мама" с верхней и левой. И тогда можно строить какие угодно кольчуги.

Тот же принцип и здесь:
чтобы не было повторяющихся стенок, храним информацию только о 2х из 4х стенок - информацию о двух других стенках в любом случае содержат наши "соседи". С точки зрения хранения инфы это всего 2 бита инфы для ячейки, + если для хранения одной ячейки используется 1 байт, у тебя остаётся ещё 6 бит на описание того, что находится в ячейке.

Из потенциальной проблемы только границы уровня, но тут либо делать их всегда закрытыми, либо добавлять ещё по ряду "лишних" клеток с незаписываемых сторон лабиринта.

В аттаче помалевал поверх лабиринта его "схему" - зелёные линии получились там, где нижняя стенка, синие - где правая, белые уголки - где обе хранимые стенки. Думаю, понятно вышло...

UPD.
В принципе получается, что "стеночный" лабиринт вдвое больше по количеству информации, чем его "блочный" собрат.

Что касается формы хранения и обработки - 2 бита на стенки, 6 на содержимое должно хватить (2^6 = 64 разных состояния клетки, или 63 айтема + пустая клетка), во время перемещения персонажа я бы держал в памяти для удобства массивчик Surround 3х3, в котором хранил бы возможность перейти в соседнюю клетку из текущей. ЧТобы просчитать Surround-карту достаточно точечно (считай - без вложенного цикла) взять 8 позиций из карты лабиринта (не нужно брать нижнюю правую клетку, т.к. её данные ни на что не повлияют) если персонаж может гулять по диагонали, или вообще 3, если не может (левее, выше, и прямо где персонаж).

Phantom · 02.05.2011, 19:52

Правда надо будет хранить информацию о гранях/углах для столкновений... Так что даже не знаю как ты собираешься с тем же разрешением сделать нормальную обработку... Потом поделись решением, если не секрет будет

Игра вообще будет 3D

Taugeshtu, всё таки я думаю, что со способом, на котором я определился, будет проще работать в программе.

PassCall · 12.05.2011, 10:52

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

Эм... допустим у тебя 500 объектов (при такой большой карте вполне реальное число).

итак, надо ввести условие, попадает ли объект на область экрана, и если да, то прорисовываем. А теперь подумайте.

Допустим, тебя устравивает 10 фпс. Значит, нужно проводить 500*10*2 (сравнивается x и y)=10000 сравнений в секунду. Чисто для одного условия из кода. ИМХО, это не очень полезно для быстродействия.

Taugeshtu · 12.05.2011, 12:53

ИМХО, это не очень полезно для быстродействия.

ИМХО, ты не представляешь себе, на что способны современные процессоры. Квадратичная сложность - ничтожна, хоть там 10к вызовов средней тяжести функции, хоть 100к.
Для примера представь себе, как тяжело физиксу, когда у него в памяти сидит тримеш уровня о 100к вершин, и ещё 100 патиклов с физическим взаимодействием с миром на него сыпятся. Да-да, это 10М переборов, и ведь жуёт, зараза!

Ну а для телефонных игр условно бесконечное пространство - ооооочень сомнительная фича. Даже на 5" экране.

PassCall · 12.05.2011, 17:57

Я говорил про мобильный телефон =)

Простите, не читал тему полностью.
Вообще вполне реально создать такую карту, чтобы была ну очень большого размера.

Ведь по сути память занимает массив с индексами тайлов. И если взять размер тайла 30х30 пикс., а матрица будет 500х500, то это замет 25000*6 байт (вроде столько занимает интегер)=150Кб, а размер такого мира -15000 пикс (что примерно 50 мобильных экранов в ширину и около 38 экранов в высоту).

Думаю, только профессиональные мазохисты решат обследовать весь такой мир =)