Всем привет! Как сделать такие изометрические платформы, чтобы герой мог двигаться вглубь, запрыгивать на более высокий уровень и диагонально вверх подниматься и спускаться? NO MATTER WHAT YOUR JOURNEY IS, KEEP WALKING!
проще всего через обычную переменку yy в которой записывать текущее положение перса по y, а при прыжке учитывать yy как точку 0, стены обычной маской можно сделать... в общем задача простейшая=) Более мощный компьютер глючит быстрее и точнее.
проще всего через обычную переменку yy в которой записывать текущее положение перса по y, а при прыжке учитывать yy как точку 0, стены обычной маской можно сделать... в общем задача простейшая=)
Добрый человек) сделай мне пожалуйста пример хотя бы малюсенький,чтобы я понял суть. Оч прошу) NO MATTER WHAT YOUR JOURNEY IS, KEEP WALKING!
Сообщение отредактировал funkypanky - Пятница, 29 Марта 2013, 19:31
Тогда уж, чтобы совсем было верно" Аксонометрическая косоугольная фронтальная диметрия" диметиря
Мне для реализации идеи нужно сделать так, чтобы главный герой мог двигаться вот на таком рельефе. Но я к сожалению пока не могу понять как это сделать правильно... NO MATTER WHAT YOUR JOURNEY IS, KEEP WALKING!
Сообщение отредактировал funkypanky - Пятница, 29 Марта 2013, 19:58
Мне для реализации идеи нужно сделать так, чтобы главный герой мог двигаться вот на таком рельефе.
самый вопрос в том, как ты будешь хранить такой рельеф.
и, да- обычными стенами-объектами гамака с атрибутом проходимости здесь не отделаешься. вывод придётся прописывать самому и отслеживание столкновений со стенами- тоже придётся прописывать самому. все правила форумной игры Дуэль Программистов
самый вопрос в том, как ты будешь хранить такой рельеф.
и, да- обычными стенами-объектами гамака с атрибутом проходимости здесь не отделаешься. вывод придётся прописывать самому и отслеживание столкновений со стенами- тоже придётся прописывать самому.
В этом-то у меня основная и проблема - я не понимаю как прописать столкновение с глубиной стены и прыжок на углублённую платформу , а также и с углублённой платформы на другую. Я сделал прыгающий шарик с возможностью прыгать в глубину- а далее у меня ступор. Хоть на блендер переходи.. но я хочу сделать на гамаке. NO MATTER WHAT YOUR JOURNEY IS, KEEP WALKING!
Читать остальное не стал. Есть грубая идея. Перемещение персонажа идет в 2-х плоскостях: Стандартный профильный вид, для которого думаю ты сможешь написать поведение для персонажа (X и Y) и третья ось условно стандартная Z, для которой проводятся дополнительные вычисления параллельно с первичными по X и Y. И лишь рендер будет проблемой.
Просто не думаю, что ты делаешь именно так.
Для упрощения понимания можно представить рельеф в виде кубов. Глупо, правда?
Добавлено (29.03.2013, 22:55) --------------------------------------------- Подумал подкрепить слова примерчиком, но не могу. Студия ничтожна, мягко говоря.
Читать остальное не стал. Есть грубая идея. Перемещение персонажа идет в 2-х плоскостях: Стандартный профильный вид, для которого думаю ты сможешь написать поведение для персонажа (X и Y) и третья ось условно стандартная Z, для которой проводятся дополнительные вычисления параллельно с первичными по X и Y. И лишь рендер будет проблемой.
Просто не думаю, что ты делаешь именно так.
Для упрощения понимания можно представить рельеф в виде кубов. Глупо, правда? Добавлено (29.03.2013, 22:55) --------------------------------------------- Подумал подкрепить слова примерчиком, но не могу. Студия ничтожна, мягко говоря.
Стандартный вид это не проблема. Сейчас прикреплю шарик свой- там я третью координату завожу, но может ты не то имеешь ввиду. ШАРИК Ещё я пробовал создавать второй объект линкованный к первому и придавал ему смещение на 45 градусов при нажатии вверх и вниз - но опять же это всё не правильно, глубины как таковой не получается задать. Если не сложно можешь показать что ты имешь ввиду? NO MATTER WHAT YOUR JOURNEY IS, KEEP WALKING!
Сообщение отредактировал funkypanky - Пятница, 29 Марта 2013, 23:02
Я сделал прыгающий шарик с возможностью прыгать в глубину
перемещения как раз- не проблема. по X движешься как обычно, по Y- смещаясь по x и y, по Z- смещаясь по y. то есть, трёхмерные координаты переводятся в двумерные довольно просто. отсюда получается и ходьба и прыжки во всех направлениях.
Цитата (funkypanky)
я не понимаю как прописать столкновение с глубиной стены и прыжок на углублённую платформу , а также и с углублённой платформы на другую.
это всё одна и та же проблема отслеживания столкновений. прыгаем и летим до столкновения со стеной. если стена сбоку- она не даёт нам пролететь в эту сторону в бок, если стена снизу- она не даёт нам упасть вниз. приехали. отдельной какой-то сложности с углублёнными платформами нет- это всё одна и та же проблема отслеживания столкновений.
а решение начинается с того, чтобы продумать, как хранить твой сложный рельеф. но тут мы выходим на тропу написания сложной игры. ты готов?
я бы предложил трёхмерный массив, в котором будут храниться коды стен. и рельеф складывается из стен как из каких-нибудь кубиков. и при правильном порядке отрисовки мы затираем передними кубиками те части, которые они заслоняют, НО я вот посмотрел на твою левую верхнюю платформу, на которой стоит первый красный шарик.. тут потребуется движок по круче, чем для простой изомерии. дело в том, что если ГГ, будучи в глубине примерно по центру платформы, станет слева от неё, то он может перекрыть её левую часть. а если станет справа- то он перекроет её правую часть. то есть, правильным порядком отрисовки тут не отделаешься. можно, правда, отрисовывать вначале весь пейзаж, а поверх отрисовывать персонажей, но в твоём случае и это не годится- посмотри на следующую удалённую платформу- куб. она может перекрывать персонажа, стоящего справа от неё.
короче- загадал ты задачку..
я не знаю, какой твой уровень, но думаю, что правильный ответ будет такой: сделай для начала что-нибудь попроще.
например, что-нибудь в духе принца персии 1989-го года, Flash Back или Black Thorne. у них тоже интересный стиль с углублением в экран, но гораздо проще, чем у тебя. хотя с отрисовкой там замучаешься(но спрайты ГГ из принца и black thorne можно найти в нете- я когда-то находил).
ну, или, да- можно продолжать думать над твоей задачкой.
Что касается хранения. Если нет этажа над этажом (типа как в Snake Rattle N Roll), подойдет карта высот, как это было реализовано когда-то в DOOM.
Вся карта рельефов хранится: в двухмерном массиве с данными по высотам. либо (Более простой вариант): в спрайте за пределами игровой зоны, при этом каждый цвет означает следующую ступень высоты. Вообще лучше остановиться на ступенчатой карте высот, не делать сложного рельефа. Пусть уровней будет конечное количество и не очень много для начала.
Вариант со спрайтом более прост, т.к. на нем как на миникарте проще реализовать контроль движения, поместив поверх точку - "аватар" ГГ. Однако это можно сделать только в том случае, если у ГГ дискретный шаг (как в тех же "змейках"). В противном случае лучше пользоваться массивом. 1. Adventure Mouse - мини-аркада про мыш и его друга сыр 2. Герои Реконструкции и Страйкбола - тематическая пошаговая стратегия 3. Dangerous Dave 5: Fansequel - трибьют на Dangerous Dave Всё здесь http://zvizdez.ru/download.php?list.1
Сообщение отредактировал Randall - Суббота, 30 Марта 2013, 00:13
Что касается хранения. Если нет этажа над этажом, подойдет карта высот
хорошая идея. только как потом из этого отрисовывать? хранить раздельно карту для столкновении и карту для отрисовки- плохо, так как будет сложно отслеживать ошибки построения уровня.
Цитата (Randall)
Вообще лучше остановиться на ступенчатой карте высот, не делать сложного рельефа.
ну да, ну да. для начала лучше делать что-нить попроще. я тоже думаю, что так будет лучше.
Цитата (Randall)
либо (Более простой вариант): в спрайте за пределами игровой зоны, при этом каждый цвет означает следующую ступень высоты.
в спрайте- не проще. к тому же из него дольше вытаскивать нужную высоту и скорость пострадает.
вообще мысль хорошая. действительно- можно хранить карту высот, а чтобы учесть всяческие диагонали во все стороны(см #5), можно хранить, кроме массива высот кубиков ещё и массив форм кубиков. типа: у нас вертикальные стопки из стандартных кубиков, на которых стоят всякие извращённые кубики.
НО вот ещё какая фигня: смотрим пропасть посреди #5. там, как ни крути, получается, что хотя бы c одной из сторон надо отрисовывать нестандартные кубики на каждом уровне высоты.
на самом деле, с нормальным трёхмерным массивом работать ничуть не сложнее, чем с картой высот. но зато он позволит нормально отрисовать обе стороны пропасти. а те части стен, которые могут перекрывать персонажей, можно выводить после всей отрисовки пейзажа, во время отрисовки персонажей.. как-то так.
вообще, рассматривая рисунок #5 можно договориться до того, что такую игрушку проще сделать в 3d.
причём в гамаке есть какие-то средства для отрисовки 3d вперемешку со спрайтами. может быть, это действительно самый лёгкий путь, в данном случае?
да, в таком варианте всё гораздо проще. но устроит ли это funkypanky?
Цитата (LetsOffBrains)
Из-за ограниченности ГМ это 3 двумерных массива.
то есть N двумерных массивов, где N- глубина.
такой вариант имеет тот недостаток, что некоторых интересных фич картинки из #5 он сделать не позволяет, НО, пожалуй, он имеет много весомых преймуществ: - он сравнительно прост в реализации - он позволяет легко устроить этажи над этажами причём легко делается и отрисовка и столкновения.
пожалуй, это самая годная идея на текущий момент. и самая очевидная с самого начала: это же классическая изометрия)))
для обычного 2d мира можно было бы взять двумерный или даже одномерный массив. с N двумерных массивов мы получаем возможность делать уровни любой сложности: с углублёнными платформами и прочими любыми наворотами НО эта идея проста в реализации за счёт одного ограничения: весь уровень сложен из кубиков одной формы, расположенными строго по ячейкам. все правила форумной игры Дуэль Программистов
Цитата (Randall) Что касается хранения. Если нет этажа над этажом, подойдет карта высот
хорошая идея. только как потом из этого отрисовывать? хранить раздельно карту для столкновении и карту для отрисовки- плохо, так как будет сложно отслеживать ошибки построения уровня.
Цитата (Randall) Вообще лучше остановиться на ступенчатой карте высот, не делать сложного рельефа.
ну да, ну да. для начала лучше делать что-нить попроще. я тоже думаю, что так будет лучше.
Цитата (Randall) либо (Более простой вариант): в спрайте за пределами игровой зоны, при этом каждый цвет означает следующую ступень высоты.
в спрайте- не проще. к тому же из него дольше вытаскивать нужную высоту и скорость пострадает.
вообще мысль хорошая. действительно- можно хранить карту высот, а чтобы учесть всяческие диагонали во все стороны(см #5), можно хранить, кроме массива высот кубиков ещё и массив форм кубиков. типа: у нас вертикальные стопки из стандартных кубиков, на которых стоят всякие извращённые кубики.
НО вот ещё какая фигня: смотрим пропасть посреди #5. там, как ни крути, получается, что хотя бы c одной из сторон надо отрисовывать нестандартные кубики на каждом уровне высоты.
на самом деле, с нормальным трёхмерным массивом работать ничуть не сложнее, чем с картой высот. но зато он позволит нормально отрисовать обе стороны пропасти. а те части стен, которые могут перекрывать персонажей, можно выводить после всей отрисовки пейзажа, во время отрисовки персонажей.. как-то так.
вообще, рассматривая рисунок #5 можно договориться до того, что такую игрушку проще сделать в 3d.
причём в гамаке есть какие-то средства для отрисовки 3d вперемешку со спрайтами. может быть, это действительно самый лёгкий путь, в данном случае? Добавлено (30.03.2013, 01:05) --------------------------------------------- --------------------------------------------------------------------------------------- Цитата (LetsOffBrains) В стандартном виде я имел ввиду обычный 2Д ми
да, в таком варианте всё гораздо проще. но устроит ли это funkypanky?
Цитата (LetsOffBrains) Из-за ограниченности ГМ это 3 двумерных массива.
то есть N двумерных массивов, где N- глубина.
такой вариант имеет тот недостаток, что некоторых интересных фич картинки из #5 он сделать не позволяет, НО, пожалуй, он имеет много весомых преймуществ: - он сравнительно прост в реализации - он позволяет легко устроить этажи над этажами причём легко делается и отрисовка и столкновения.
пожалуй, это самая годная идея на текущий момент. и самая очевидная с самого начала: это же классическая изометрия))) Добавлено (30.03.2013, 01:11) --------------------------------------------- Цитата (LetsOffBrains) В стандартном виде я имел ввиду обычный 2Д мир.
для обычного 2d мира можно было бы взять двумерный или даже одномерный массив. с N двумерных массивов мы получаем возможность делать уровни любой сложности: с углублёнными платформами и прочими любыми наворотами НО эта идея проста в реализации за счёт одного ограничения: весь уровень сложен из кубиков одной формы, расположенными строго по ячейкам.
noname, пожалуйста научи меня как задать такой массив для столкновений и высот. Я пока что применял массив в небольших лишь потребностях- типа хождения по неровной поверхности. Я просто не знаю как в GM задать эти три двухмерных массива с проверкой высот и столкновений. Не спорю-задача из небанальных и всё не просто. У меня не было до этого опыта работа с изометрией, поэтому хочется наверстать и понять что к чему. NO MATTER WHAT YOUR JOURNEY IS, KEEP WALKING!
нет-нет, отрисовка как раз несложна. Сложнее прописать алгоритм столкновений. Хотя тут тоже может помочь проверка прямо по массиву.
Пример: массив x,y, в этом массиве хранятся высоты z Y у нас начинается от экрана и уходит вглубь него, Чем больше Y, тем больше глубина плоскостей в ряду. И еще в каждом ряду каждая левая стенка на слой глубже, чем правая, а каждая правая, в свою очередь, на слой глубже, чем плоскость.
И тут уже не имеет значения, как и что отрисовывать. Плоскости встанут на свои места.
Что касается столкновений. При создании объекта-плоскости в create сразу откладывается текущая глубина wall.y. Маска столкновений - это вертикальная линия по центру стен и горизонтальная по центру "полов". При столкновении с объектом проверяется совпадение player.y=wall.y по глубине и исходя из этого игра решает - отрабатывать это столкновение или нет.
Примерно так. Этот алгоритм действенен только при дискретном движении персонажа в глубину (все те же змейки как пример). Если у нас свободное движение по координате Z, то проще сразу переходить на 3D, подобный расчет будет нецелесообразен. 1. Adventure Mouse - мини-аркада про мыш и его друга сыр 2. Герои Реконструкции и Страйкбола - тематическая пошаговая стратегия 3. Dangerous Dave 5: Fansequel - трибьют на Dangerous Dave Всё здесь http://zvizdez.ru/download.php?list.1
нет-нет, отрисовка как раз несложна. Сложнее прописать алгоритм столкновений. Хотя тут тоже может помочь проверка прямо по массиву.
Пример: массив x,y, в этом массиве хранятся высоты z Y у нас начинается от экрана и уходит вглубь него, Чем больше Y, тем больше глубина плоскостей в ряду. И еще в каждом ряду каждая левая стенка на слой глубже, чем правая, а каждая правая, в свою очередь, на слой глубже, чем плоскость.
И тут уже не имеет значения, как и что отрисовывать. Плоскости встанут на свои места.
Что касается столкновений. При создании объекта-плоскости в create сразу откладывается текущая глубина wall.y. Маска столкновений - это вертикальная линия по центру стен и горизонтальная по центру "полов". При столкновении с объектом проверяется совпадение player.y=wall.y по глубине и исходя из этого игра решает - отрабатывать это столкновение или нет.
Примерно так. Этот алгоритм действенен только при дискретном движении персонажа в глубину (все те же змейки как пример). Если у нас свободное движение по координате Z, то проще сразу переходить на 3D, подобный расчет будет нецелесообразен.
Randall, извиняюсь за необразованность в вопросах массивов, я просто не понимаю как ты задал циферные столбики для карты высот, как вообще получились все эти цифры. Чувствую что что-то прошло мимо меня, что-то важное)) NO MATTER WHAT YOUR JOURNEY IS, KEEP WALKING!
1 квадратик в высоту = +1 к z-координате 1. Adventure Mouse - мини-аркада про мыш и его друга сыр 2. Герои Реконструкции и Страйкбола - тематическая пошаговая стратегия 3. Dangerous Dave 5: Fansequel - трибьют на Dangerous Dave Всё здесь http://zvizdez.ru/download.php?list.1
noname, пожалуйста научи меня как задать такой массив для столкновений и высот.
позже. я сейчас- спать и у меня на выходные есть работа, но постараюсь зайти.
проще и лучше всего работать с одним трёхмерным массивом. и этот массив использовать и для отрисовки и для столкновений.
карта высот ничуть не добавляет простоты, но ограничивает невозможностью строить этажи над этажами и потолки на разной высоте.
Цитата (Randall)
Возьмем пример из поста №12.
да. я тоже склоняюсь к тому, чтобы делать обычную изометрию. и только после создания такой игры уже замахиваться на что-то более сложное.
Цитата (Randall)
Этот алгоритм действенен только при дискретном движении персонажа в глубину (все те же змейки как пример). Если у нас свободное движение по координате Z, то проще сразу переходить на 3D, подобный расчет будет нецелесообразен.
к обычному дискретному миру, как в #12 вполне можно прикрутить плавное движение и столкновение персонажей. подобным образом, собственно, обычно в 2d играх и поступают: хранят дискретный двумерный массив со всем, что происходит в мире, НО персонажи при этом, во многих играх, могут двигаться не дискретно. но, да- дискретное перемещение попроще будет.
с плавным перемещением, действительно, возникают небольшие сложности при отслеживании столкновений с противниками. со стенами то ещё ладно, а вот противники разной формы.. при столкновении их придётся учитывать как какие-то более простые фигуры. кубы? шары? цилиндры? думать надо..
обычно в 2d играх могут доходить до попиксельного сравнения при коллизиях, но в изометрии такое не прокатит.
извиняюсь за необразованность в вопросах массивов, я просто не понимаю как ты задал циферные столбики для карты высот, как вообще получились все эти цифры.
смотри: площадка какого-то двора вымощена квадратными плитами. пришёл Randall и написал на плитах свои числа. потом пришли рабочие и поставили на плиты кубы с размером стороны куба как раз как плита. причём, на каждую плиту поставили столько кубов, сколько на ней написал Randall.
в этом примере Randall создал карту высот(ту самую, которую он предлагает хранить в массиве), а рабочие построили по карте высот уровень.
в "карты глубин" для плоскостей/стенок лучше и не пытаться вникать. достаточно знать, что мы можем просчитать, что куда отображать.
И тут уже не имеет значения, как и что отрисовывать. Плоскости встанут на свои места.
не совсем. иногда часть плоскости может перекрываться. важно, чтобы те плоскости, которые перекрывают, отрисовывались бы позже чем те, которые перекрываются: если мы выводим кубы, то куб 1 должен быть нарисован позже куба 2, чтобы затереть его верхнюю плоскость(не говоря уж о том, что он затирает весь верх того куба, на котором стоит). если же мы выводим только стороны кубов, то всё равно квадрат куба 1 должен быть выведен позже чем верхняя плоскость куба 2, которую он частично затирает.
если же предлагается рисовать такие уровни, в которых ни одна плоскость не перекрывает другую, то получатся уровни, в которых дальний левый угол всегда является самой высокой точкой, а от него уровень расходится либо вниз либо прямо. невозможны ни канавы ни выступы. для таких уровней можно придумать быстрый способ отрисовки, но.. ведь это слишком сильные ограничения.
обычно в 2d играх и поступают: хранят дискретный двумерный массив со всем, что происходит в мире,
ну.. на самом деле, похоже, что во многих играх это не так. но и так тоже делают. суть в том, что это возможно, и при этом не слишком сложно(было и в синклеровских игрушках): можно хранить мир в двумерном массиве и при этом все персонажи могут перемещаться плавно и могут останавливаться или менять направление движения, не доходя до конца клеточки.
как на самом деле это делается, я не знаю. но могу предположить, что в массиве такой 2d игры хранятся не только стены, но и всё, включая персонажей, занесено в массив. при этом, естественно, отдельно хранится список(массив) подвижных персонажей. и каждый персонаж занесён в ту ячейку, к которой относится его (допустим), левая нижняя точка. если размер персонажей не менее ячейки(а так в тех играх и было), то два персонажа одновременно не смогут всунуть свою левую нижнюю точку в одну и ту же ячейку. при движении приходится проверять столкновения максимум с четырьмя спрайтами: спрайтом того, что находится в нашей ячейке, что находится выше, что находится правее и того, что находится и выше и правее. хотя, на самом деле, поскольку столкновения проверяются после каждого движения, то достаточно проверять только столкновение с той стороной, куда двигался только что передвинутый объект.
в гамаке всё это обычно прописывать не надо, потому что конструктор всё делает за вас, НО если мы делаем что-то нестандартное, как изометрия, то придётся обо всём думать и всё прописывать самим.
Добавлено (30.03.2013, 17:25) --------------------------------------------- --------------------------------------------------------------- теперь ближе к делу: хранить всё в 3d массиве(в гамаке это, как я понял, будет несколько 2d массивов) и отрисовывать в правильном порядке- идеально подошло бы для такой игрушки, как синклеровская Knight Lore. это совсем не сложно, но.. в Knight Lore почти весь этот 3d массив прогонялся впустую и лишь иногда там попадались предметы для отрисовки, кроме того, не только стены, но и все собираемые предметы в игре были подогнаны под размер блока и все подвижные персонажи были достаточно объёмны и могли поворачиваться на все четыре стороны(те у кого стороны различались)).
если же мы попробуем таким способом отрисовывать полоску-дорогу battletoads, то большая часть кубов будет прописываться впустую и затираться более близкими к экрану блоками. то есть- многие места бы будем отрисовывать по несколько раз почти на одном и том же месте. кроме того, я глянул battletoads, и увидел примерно такую же штуку с персонажами, как и в Golden Axe: персонажи могут поворачиваться только в две стороны- влево и вправо. и работа с ними, фактически, идёт как с плоскими картинками! ну, или почти так.
в battletoads мы имеем путь, по большей части слева-направо, но он может вдруг становиться ниже или выше и ещё из дальней стены могут быть выступы, причём видны обе стороны выступов(!), то есть, там изометрия как-то в обе стороны идёт. и с провалами/подъёмами уровня аналогично. этот приём двусторонней изометрии, очевидно, сделан для того, чтобы пейзаж никак не мог перекрывать персонажа. что упрощает отрисовку- сначала рисуем весь пейзаж, затем, поверх него, рисуем персонажей. причём, поскольку картинки персонажей плоские, то порядок отрисовки тоже понятен: отрисовываем сначала дальний слой, потом ближе и ближе. коллизии тоже не слишком сложные: мы проверяем столкновение полосочки на которой стоит движущийся персонаж с другими полосочками. для создания впечатления объёма это могут быть не полосочки, а прямоугольнички. ну, чтобы невозможно было пройти слишком близко сзади от нашего персонажа. в battletoads скорее всего проверяется столкновение не прямоугольников, а эллипсов, но нам, для первой попытки написать такую игру, приближение до прямоугольников подойдёт. если наносится удар, то проверяется б0льшее поле, чем при движении, чтобы было легче попадать(зависит ещё и от вида удара).
осталось разгадать самое последнее- как хранить и отрисовывать такой пейзаж, как в battletoads и как проверять столкновения с ним. короче- с чего начали, к тому и пришли))) но на этот раз мы имеем всё же б0льшее представление о том, что мы хотим сделать.
на самом деле есть ещё один вопрос.. дело в том, что рисунки и запросы funkypanky таковы, что не совсем ясно, нужен ли ему движок именно как в battletoads, или же вместо плоских картинок у него будет прыгать объёмный шар по таким уровням, как в синклеровской игре H.A.T.E.(рис.1 и рис.2).
в-общем, я пошёл отдыхать и заниматься своими делами, а funkypanky пусть почитает, посмотрит и подумает, что ему надо.
хотелось бы получить хоть какой-то отклик не обязательно от него, а хоть от кого-нибудь вообще. чтобы я понял, что не зря тут время теряю, и что кому-то это интересно. все правила форумной игры Дуэль Программистов
Сообщение отредактировал noname - Суббота, 30 Марта 2013, 17:41
Цитата (funkypanky) noname, пожалуйста научи меня как задать такой массив для столкновений и высот.
позже. я сейчас- спать и у меня на выходные есть работа, но постараюсь зайти.
проще и лучше всего работать с одним трёхмерным массивом. и этот массив использовать и для отрисовки и для столкновений.
карта высот ничуть не добавляет простоты, но ограничивает невозможностью строить этажи над этажами и потолки на разной высоте.
Цитата (Randall) Возьмем пример из поста №12.
да. я тоже склоняюсь к тому, чтобы делать обычную изометрию. и только после создания такой игры уже замахиваться на что-то более сложное.
Цитата (Randall) Этот алгоритм действенен только при дискретном движении персонажа в глубину (все те же змейки как пример). Если у нас свободное движение по координате Z, то проще сразу переходить на 3D, подобный расчет будет нецелесообразен.
к обычному дискретному миру, как в #12 вполне можно прикрутить плавное движение и столкновение персонажей. подобным образом, собственно, обычно в 2d играх и поступают: хранят дискретный двумерный массив со всем, что происходит в мире, НО персонажи при этом, во многих играх, могут двигаться не дискретно. но, да- дискретное перемещение попроще будет.
с плавным перемещением, действительно, возникают небольшие сложности при отслеживании столкновений с противниками. со стенами то ещё ладно, а вот противники разной формы.. при столкновении их придётся учитывать как какие-то более простые фигуры. кубы? шары? цилиндры? думать надо..
обычно в 2d играх могут доходить до попиксельного сравнения при коллизиях, но в изометрии такое не прокатит.
Добавлено (30.03.2013, 16:05) --------------------------------------------- --------------------------------------------------------------- --------------------------------------------------------------- Цитата (funkypanky) извиняюсь за необразованность в вопросах массивов, я просто не понимаю как ты задал циферные столбики для карты высот, как вообще получились все эти цифры.
смотри: площадка какого-то двора вымощена квадратными плитами. пришёл Randall и написал на плитах свои числа. потом пришли рабочие и поставили на плиты кубы с размером стороны куба как раз как плита. причём, на каждую плиту поставили столько кубов, сколько на ней написал Randall.
в этом примере Randall создал карту высот(ту самую, которую он предлагает хранить в массиве), а рабочие построили по карте высот уровень.
в "карты глубин" для плоскостей/стенок лучше и не пытаться вникать. достаточно знать, что мы можем просчитать, что куда отображать.
Добавлено (30.03.2013, 16:34) --------------------------------------------- Цитата (Randall) И тут уже не имеет значения, как и что отрисовывать. Плоскости встанут на свои места.
не совсем. иногда часть плоскости может перекрываться. важно, чтобы те плоскости, которые перекрывают, отрисовывались бы позже чем те, которые перекрываются: если мы выводим кубы, то куб 1 должен быть нарисован позже куба 2, чтобы затереть его верхнюю плоскость(не говоря уж о том, что он затирает весь верх того куба, на котором стоит). если же мы выводим только стороны кубов, то всё равно квадрат куба 1 должен быть выведен позже чем верхняя плоскость куба 2, которую он частично затирает.
если же предлагается рисовать такие уровни, в которых ни одна плоскость не перекрывает другую, то получатся уровни, в которых дальний левый угол всегда является самой высокой точкой, а от него уровень расходится либо вниз либо прямо. невозможны ни канавы ни выступы. для таких уровней можно придумать быстрый способ отрисовки, но.. ведь это слишком сильные ограничения.
Добавлено (30.03.2013, 16:52) --------------------------------------------- Цитата (noname) обычно в 2d играх и поступают: хранят дискретный двумерный массив со всем, что происходит в мире,
ну.. на самом деле, похоже, что во многих играх это не так. но и так тоже делают. суть в том, что это возможно, и при этом не слишком сложно(было и в синклеровских игрушках): можно хранить мир в двумерном массиве и при этом все персонажи могут перемещаться плавно и могут останавливаться или менять направление движения, не доходя до конца клеточки.
как на самом деле это делается, я не знаю. но могу предположить, что в массиве такой 2d игры хранятся не только стены, но и всё, включая персонажей, занесено в массив. при этом, естественно, отдельно хранится список(массив) подвижных персонажей. и каждый персонаж занесён в ту ячейку, к которой относится его (допустим), левая нижняя точка. если размер персонажей не менее ячейки(а так в тех играх и было), то два персонажа одновременно не смогут всунуть свою левую нижнюю точку в одну и ту же ячейку. при движении приходится проверять столкновения максимум с четырьмя спрайтами: спрайтом того, что находится в нашей ячейке, что находится выше, что находится правее и того, что находится и выше и правее. хотя, на самом деле, поскольку столкновения проверяются после каждого движения, то достаточно проверять только столкновение с той стороной, куда двигался только что передвинутый объект.
в гамаке всё это обычно прописывать не надо, потому что конструктор всё делает за вас, НО если мы делаем что-то нестандартное, как изометрия, то придётся обо всём думать и всё прописывать самим.
Добавлено (30.03.2013, 17:25) --------------------------------------------- --------------------------------------------------------------- теперь ближе к делу: хранить всё в 3d массиве(в гамаке это, как я понял, будет несколько 2d массивов) и отрисовывать в правильном порядке- идеально подошло бы для такой игрушки, как синклеровская Knight Lore. это совсем не сложно, но.. в Knight Lore почти весь этот 3d массив прогонялся впустую и лишь иногда там попадались предметы для отрисовки, кроме того, не только стены, но и все собираемые предметы в игре были подогнаны под размер блока и все подвижные персонажи были достаточно объёмны и могли поворачиваться на все четыре стороны(те у кого стороны различались)).
если же мы попробуем таким способом отрисовывать полоску-дорогу battletoads, то большая часть кубов будет прописываться впустую и затираться более близкими к экрану блоками. то есть- многие места бы будем отрисовывать по несколько раз почти на одном и том же месте. кроме того, я глянул battletoads, и увидел примерно такую же штуку с персонажами, как и в Golden Axe: персонажи могут поворачиваться только в две стороны- влево и вправо. и работа с ними, фактически, идёт как с плоскими картинками! ну, или почти так.
в battletoads мы имеем путь, по большей части слева-направо, но он может вдруг становиться ниже или выше и ещё из дальней стены могут быть выступы, причём видны обе стороны выступов(!), то есть, там изометрия как-то в обе стороны идёт. и с провалами/подъёмами уровня аналогично. этот приём двусторонней изометрии, очевидно, сделан для того, чтобы пейзаж никак не мог перекрывать персонажа. что упрощает отрисовку- сначала рисуем весь пейзаж, затем, поверх него, рисуем персонажей. причём, поскольку картинки персонажей плоские, то порядок отрисовки тоже понятен: отрисовываем сначала дальний слой, потом ближе и ближе. коллизии тоже не слишком сложные: мы проверяем столкновение полосочки на которой стоит движущийся персонаж с другими полосочками. для создания впечатления объёма это могут быть не полосочки, а прямоугольнички. ну, чтобы невозможно было пройти слишком близко сзади от нашего персонажа. в battletoads скорее всего проверяется столкновение не прямоугольников, а эллипсов, но нам, для первой попытки написать такую игру, приближение до прямоугольников подойдёт. если наносится удар, то проверяется б0льшее поле, чем при движении, чтобы было легче попадать(зависит ещё и от вида удара).
осталось разгадать самое последнее- как хранить и отрисовывать такой пейзаж, как в battletoads и как проверять столкновения с ним. короче- с чего начали, к тому и пришли))) но на этот раз мы имеем всё же б0льшее представление о том, что мы хотим сделать.
Добавлено (30.03.2013, 17:40) --------------------------------------------- Цитата (noname) осталось разгадать самое последнее
на самом деле есть ещё один вопрос.. дело в том, что рисунки и запросы funkypanky таковы, что не совсем ясно, нужен ли ему движок именно как в battletoads, или же вместо плоских картинок у него будет прыгать объёмный шар по таким уровням, как в синклеровской игре H.A.T.E.(рис.1 и рис.2).
в-общем, я пошёл отдыхать и заниматься своими делами, а funkypanky пусть почитает, посмотрит и подумает, что ему надо.
хотелось бы получить хоть какой-то отклик не обязательно от него, а хоть от кого-нибудь вообще. чтобы я понял, что не зря тут время теряю, и что кому-то это интересно.
noname, твоя помощь мне очень была бы кстати. Я поэтому и задал вопрос как это можно реализовать, потому что у меня одного пока не хватает умений сделать такой ландшафт. Смотрел и на ютубе и других форумах-никто пока не подсказал как можно сделать такую изометрию. Даже на забугорную ЁЁ писал) Я не программист, поэтому мне вдвойне тяжелее, я художник. Простой платформер вид сбоку я сделать в силах. Танчики сделал недавно, правда не до конца, но там задачи для меня посильные были. Да, я хочу реализовать движок как в battletoads, интересно очень как там изометрия устроена и научиться её реализовывать. Хотя бы для начала с одним видом кубов. В идеале конечно хочется чтобы была свобода для творчества, чтобы я мог сделать ландшафт под свои нужды, тот что я нарисовал в самом начале. NO MATTER WHAT YOUR JOURNEY IS, KEEP WALKING!
Сообщение отредактировал funkypanky - Воскресенье, 31 Марта 2013, 03:10
Смотрел и на ютубе и других форумах-никто пока не подсказал как можно сделать такую изометрию. Даже на забугорную ЁЁ писал)
а я сейчас возьму и расскажу, как устроен их движок, да? судя по тому, что на sinсlair 48k, изометрических игр было до фига и больше, обычная изометрия должна быть заметно проще чем движок battletoads.
Цитата (funkypanky)
Хотя бы для начала с одним видом кубов.
в battletoads, фактически, и есть один вид платформ- такие, у которых прекрасно видны обе боковые стороны. обычных изометрических кубов в battletoads нет.
я выше давал ссылки на картинки Knight Lore и H.A.T.E.- в них обычная изометрия.
вся фишка обычной изометрии в том, что из трёхмерного массива отрисовывается сначала самый глубинный слой, потом ближе и ближе. в каждом слое отрисовывается сначала нижняя строка, затем- выше и выше. порядок отрисовки кубов в каждой строке- слева-направо. можно и не только кубы. разницы нет. проверка столкновений по-сути такая же, как в обычной 2d игре(какая именно- я описал выше). осталось только понять, как отрисовывать предметы и персонажей, с учётом того, что они могут быть не ровно в клеточке, а сдвинуты на пол-клетки или меньше. в Knight Lore можно было толкать предметы по чуть-чуть. ну, надо ещё столкновения подумать- вдруг там не всё так просто.
Цитата (funkypanky)
battletoads, интересно очень как там изометрия устроена
как там устроена изометрия, мне самому интересно. впрочем, полагаю, их способ отрисовки основан не на простой хитрости, а на сложном алгоритме. то есть- реализация тупо в лоб. как именно.. лучше я пока про обычную изометрию подумаю.
и, да- у меня опять остаётся мало свободного времени и это надолго.
вся фишка обычной изометрии в том, что из трёхмерного массива отрисовывается сначала самый
описанный порядок отрисовки годится в случае, если у нас кубы развёрнуты как на рисунках в #12 и в #18.
если изометрия развёрнута иначе, то и порядок отрисовки нужен другой. то есть, в пределах одной игры у нас будет всегда один и тот же порядок отрисовки, в другой игре он может быть другим. все правила форумной игры Дуэль Программистов
Сообщение отредактировал noname - Воскресенье, 31 Марта 2013, 21:31
сделай мне пожалуйста пример хотя бы малюсенький,чтобы я понял суть. Оч прошу)
Чувствую что что-то прошло мимо меня, что-то важное))