Russian Qt Forum

Предположим, что я выбрал QGraphicsScene для того, что создать такую 2d игру (как на приставке Nes). Сюжет такой.
Появляется каратист на улице.
Сзади него не высокие дома поселочного типа.
Плывут облака.
На заднем плане виднеется лес.
В самом верху сцены есть панель с жизнями и кнопочка для выхода из игры.
Я клавиатурой двигаю нашего каратиста вправо и он бежит.
Стало быть дома ползут влево
Облака ползут, скажем, вправо с определенной скоростью.
Лес на заднем плане тоже передвигается, но медленней чем дома (как в автобусе едешь - стобы быстро, а в далеке все медленно перемещается)
Появляются враги - такие же каратисты
Предположим у меня осталось мало жизней и я бегу от врага куда-нибудь в начало уровня
Т.е. началось обратное движение домов и леса, облака двигаются естественно быстрее вправо
Отсиживаюсь в начале карты и через какое-то время меня враг настигает
Я отрегенерил жизни, вальнул врага и пришел в конец карты (уровня)
Конец

Вопросы следующие.
Чем должна быть карта, QGraphicsItem?
Это её надо целиком грузить в качестве картинки, а если она на час рассчитана?
Как осуществлять движение по такой карте? Скроллы QGraphicsView естественно не подходят, т.к. не должен игрок видеть заранее, что его ждет.
Ведь по сути для игрока персонаж остается в центре экрана, если это не начало и не конец карты.
Персонаж это дочерний QGraphicsItem карты?
Лес и облака тоже?
Выходит, чтобы сделать перемещение вперед или назад надо:
- сдвинуть дома
- сдвинуть лес
- замедлить или ускорить облака в зависимости от того куда движется персонаж
или достаточно просто сделать эти итемы дочерними для другого итема и двигать внутри него?
- не будет ли сильно лагать, если я буду перемещать всю карту туда-сюда вместо того, чтобы перемещать "камеру" (скроллить QGraphicsView)?
- если скроллить view, то возникает проблема со статической панелью с жизнями игрока и кнопочкой выхода в главное меню.
- это мне надо менять её позицию вслед за персонажем?
- а как тогда делают в 3d играх подобные меню, кнопочки остаются на месте, а позади 3d сцена как только не изголяется?

В общем хотелось бы узнать ваше мнение как это вообще реализуется, никогда играми не занимался.

Ответ не по теме, но всё же... Для чего это? Причуды заказчика? Или грёзы программиста?

Грёзы. Так то я наверно Ogre3d выбрал бы.

В принципе, объекты карты можно подгружать динамически, по мере появления.
А потом скроллить ее программно, при движении чувака (как вариант).
лагать в любом случае не должно, особенно если применить setUpdatesEnabled() :)

Желание не пропало? Могу помочь...
1. Самое простое хранить уровни в виде матриц. Эл. матриц есть идентификаторы рисуемых спрайтов.
    int map[10][32][128]; //10-уровней, 32 ячейки высота, 64 ячейки ширина уровня.
   
    далее ты должен получить итоговую картинку на экране с помощью таких шагов
   
    если на экране помещается 32х32 ячейки, то согласно глобальной позиции игрока найти индекс col массива map[curLevel][row][col]

но это не всё... самое интересное начнётся когда нужно будет просчитывать реакцию на столкновения игрок-противник,
игрок-уровень, и т.д.

далее следует анимация состояний игрока.. ну конечно если ты художник, то проблем нет..

я не думаю, что для задачи описанной тобой нужно использовать QGraphicsScene... хотя можно и попробовать.


   

Немного потыкался и наконец нашел как называется стиль этих игр: скроллер (scroller) или tile-based game. Нашел пару ссылок, где объясняется технология. К сожалению только на английском:

http://www.strille.net/tutorials/part1_scrolling.php
http://www.gamedev.net/reference/articles/article728.asp
На русском, на примере Flash, но смысл понятен: http://www.dionaholding.ru/news/articles/tbg_flash/tbg_0

Хех, попиарюсь чуток :-)
http://launchpad.net/openhomm попытка создать клон известной игрушки используя Qt 4.5 :)
Пока есть только рендер.

Интересный проект. Есть, кстати, аналогичный для HoMM II (правда, не на Qt). А какова цель? Сделать полноценную игру, улучшив HoMM III или просто академический интерес?

Ну да, полноценную игру, улучшив HoMM III :) Прикрутив новые фишки (к движку, геймплей будет оригинальный) и убив баги оригинала (наплодив свои  ;D ).
Ну и интерес конечно, не академический, а практический. Т.к. очень люблю эту игру и часто в нее играю.
Так же в курсе про клон HoMM 2, есть еще другой клон HoMM III, но...

На этом думаю оффтоп закончим, кому инетерсно пишем в эту группу: http://groups.google.ru/group/openhommdev

Я вот такую штуку понять не могу со скроллированием тайлов. Если брать paintEvent, это мне надо сначала сгенерить картинку окна целиком, сдвинуть её на некоторое смещение и отрисовать чтоль? Или сразу рисовать по одному тайлу на окно, но опять же крайние тайлы должны рисоваться не целиком, а частями в зависимости от смещения. Во флеше вроде как тайлы рисуются целиком, но там их рамка обрезает и есть невидимые части как тут http://oos.moxiecode.com/tut_04/index.html

1) http://www.gamedev.ru/ --- сайт полный флуда но там есть пару специалистов, и есть какие-то статьи все на русском - может и по вашей игре найдется

2) Не уверен т.к. мало работал с QGraphicsView - но есть вероятность что не хватит произвродительности и прийдется делать в OpenGL с помощью готового 2D или 3D движка - кот. можно будет привязать к GLWidget - а там будет и камера настоящая и т.д. Но по идее если в QGraphicsView тоже используется OpenGL то может и норм. работать будет.

оффтоп:
  ------ соглашусь что жесть только из-за того что учится на банкира, если бы учился на программиста - нет проблем - ведь не говорится что все надо делать с 0 -- берется тот же ogre3D упомянутый выше, его examples или вообще открытый проект на его основе - которых хватает (движок то открытый, и этих открытых движков немало - просто они не особо круты но для летнего задания подойдет любой из них) -- а дальше в зав. от собственно желания разобраться или пишется свое на основе взятого или чуть меняется для представления преподу...

по поводу QGraphicsScene - не стоит.
медленно и чревато глюками.
намного лучше подойдет QGLWidget, вся отрисовка 2D через QPainter в paintEvent() аналогична обычному рисованию.

Тайлы на то и тайлы, чтобы генерировать с помощью них готовую картинку. Отрисовка крайних тайлов, будетзависеть от реализации, конечно можно их обрезать, но думаю при размерах тайла 32*32 пикселя, производительности это не добавит :) Либо сделать так, чтоб в окно влезали только целые, и сразу потом на один тайл скроллировать.

По поводу QGraphicsView. Для нашего проекта его производительности не совсем достаточно, т.к. тьма объектов с анимацией. Но надо будет попробовать на 4.5.1, там производительность этой подсистемы вроде улучшили. Только вот насколько много.

QGraphicsView хреновато работает с анимацией и прозрачностью - очень большие тормоза при выводе от 50 и более элементов, даже мелких (при этом на машине Crysis идет нормально, не кляча :).
Поэтому QGLWidget однозначно.
А тайлы рисовать можно только те, что на экран помещаются в данном кадре. С обрезанием проблемы не вижу. Ее вообще нет :) Если координаты части тайла выходят за экран, то нарисована будет только видимая часть.

Если кому интересен пример программы, во всю использующей QGraphicsView, то вот здесь http://www.aom-game.org/download/AoMMapEditorSetup.exe (http://www.aom-game.org/download/AoMMapEditorSetup.exe) можно скачать редактор карт для HoMM-подобной игры. Это, конечно, не сама игра, там нет динамики, но есть тайлы, есть вывод прозрачных картинок, вроде бы ничего не тормозит. Анимации там нет, потому что её пока нет в самой игре, но поддержка её в редакторе есть и когда я её тестировал, то тоже ничего не тормозило. Хотя, конечно, речь шла не о сотне тысяч объектов.

Вообще то в Qt Quaterly есть статья о том как ускорить работу своих виджетов, и суть такова чтон адо брать QGraphicsView стаить емук какой-то QGLPainter и все будет OK. Подробно не читал но предположу что если приложить ум то все будет бытсро работать...

QGLPainter - такого класса вообще не существует в Qt4.

Вот что говорит ассистент:
By default, QGraphicsView provides a regular QWidget for the viewport widget. You can access this widget by calling viewport(), or you can replace it by calling setViewport(). To render using OpenGL, simply call setViewport(new QGLWidget). QGraphicsView takes ownership of the viewport widget.

т.е. все через QGLWidget.

Да такого класса может и нет я имел ввиду вот это QPaintEngine::OpenGL (вспоминал по памяти и перепутал) Но если я правильно понял статью (хотя особо не вникал) - то можно не сильно меняя код своего виджета заставить его рисоваться через OpenGL - там использовался QGraphicsView, поэтому повторюсь что можно наверное его заставить работать быстро через OpenGL. А то что это будет еще и через QGLWidget - ничего плохого не вижу. Скорее всего кутешные механизмы сами заменяют стандартные команды отрисовки - на команды OpenGL - моэтому и ненадо сильно менять код

ссылка на статью
http://www.wiki.crossplatform.ru/index.php/Accelerate_your_Widgets_with_OpenGL (http://www.wiki.crossplatform.ru/index.php/Accelerate_your_Widgets_with_OpenGL)

Да, это делается довольно быстро, вчера ушло где-то 30 минут на то, чтобы перевести проект на QGraphicsView/QGLWidget. Описанный подход, конечно, похож больше на хак, чем на "правильный" способ. Но работает.

Мне это понадобилось для вывода обычных виджетов поверх вывода OpenGL (меню игры, настройки и т.д.).