Разработка игры под Windows Phone

[@Gorthauer87]

Как-то безрадостно всё.

[@Xlab]

Мне не понятно, а была ли причина в построении велосипеда для детекции столкновений или просто было интересно сделать «свой» алгоритм? Например, чем тут плох quadtree (я не знаю ответа, интересно).

Сочувствую по поводу XNA. ;(

[@impwx]

Если я правильно понял, Quadtree решает несколько иной вопрос, нежели алгоритм, приведенный в статье. Там из множества объектов отсекаются те, которые заведомо не могут столкнуться. Я же проверяю более точное столкновение у объектов, пересечение границ которых уже определено. К сожалению, мой алгоритм не позволяет проверять попиксельное столкновение с объектами, когда они повернуты или отмасштабированы — если кто-то осилит такое написать или даст ссылку на чужое творение, буду очень признателен :)

[@Razaz]

Не смотрели в сторону MonoGame? Они даже нэймспэйсы от XNA оставили… =)

[@impwx]

Как раз смотрел, на него вся надежда. Но MonoGame заменяет только XNA, и я не совсем представляю, как он будет работать вкупе с новым WinRT XAML. Там есть нечто, аналогичное UIElementRenderer?

[@Razaz]

Пока еще не смотрел. Для WP8 есть еще SharpDX, у которого есть сборка Toolkit, реализующая часть функционала XNA и у него в примерах было что-то по части связки XAML. Но даже MS уже на британском «Power Up» рекомендует MonoGame. Хотя обидно за XNA.

[@impwx]

SharpDX, насколько я знаю, является базой для MonoGame, т.е. еще более низкоуровневой оберткой. Хотя есть надежда, что раз используется «полноценный» DirectX, на WP8 наконец-то можно будет использовать кастомные шейдеры и другие удобные вещи.

[@shwars]

Мне кажется не надо так сильно переживать по поводу XNA. Майкрософт решила не поддерживать это направление (т.к. в случае нехватки ресурсов приходится чем-то жертвовать), при этом Mono подхватило флаг и выпускает почти тоже самое под названием MonoGame — конечно, уровень качества и SLA не совсем такие, как в Майкрософт, но для целевой аудитории пользователей XNA это не должно быть стоп-фактором! Я тоже раньше переживал по поводу XNA, но потом стал рассуждать описанным образом, и полегчало!

[@Razaz]

Я про вот это www.sharpdx.org/documentation/api/n-sharpdx-toolkit/. (Линк текстом, так как доспорился=)))

[@impwx]

Ссылка полезная, спасибо, с кармой помог чем смог :)
Только слэш в конце лишний: www.sharpdx.org/documentation/api/n-sharpdx-toolkit

[@Razaz]

Автор SharpDX кстати сейчас работает в Японии над Paradox .NET game engine.

ПС. Спасибо :)

[@iandreev]

MonoGame достаточно хорошо работает с Xaml. В стандартной поставке есть шаблон MonoGame+Xaml для Windows 8.

[@Mezomish]

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

Сэкономлю кому-нибудь время на гугление по запросу «omg aliens» (из тегов) и переход по первой же ссылке :)
www.wpcentral.com/play-omg-aliens-windows-phone-and-blast-8-bit-aliens-oblivion

Судя по скриншотам и видео, игрушка на твёрдую 5. Респект за то, что довели до конца несмотря ни на что!

[@Vladek]

Объясните мне простую вещь с идеями для игр — можно ли делать полные ремейки чужих игр, естественно со своей графикой, но с тем же сюжетом или правилами игры?

[@nile1]

спросите у Zynga :)

[@vyacheslav_ka]

Тоже интересен этот вопрос, может кто то таки подскажет?

[@Dimmerg]

В основном — да, можно. Вы должны заменить графику, музыку, звуки, тексты — все что может представлять собой объекты авторского права. Насчет например структуры уровней и задач (если это паззл) — сложнее. Автору изначальной игры надо будет доказать что его структура и содержание его уровней или загадок защищены авторским правом, но это мутно и я не могу вам точно сказать по этому поводу. Лучше конечно придумать свои уровни. Правда если вы сделаете свою графику, музыку, тексты, звуки, напишите код и сделаете для него свои уровни, то у игры есть шанс отклеиться от ярлыка «клон»)
Все вышесказанное не распространяется на ряд игр, где запатентована игровая механика (например, Тетрис или Пакман). Я не знаю, как ее запатентовали, но если вы сделаете прибыльный клон Тетриса, у вас точно будут проблемы с TTC. Не факт что они выиграют в суде, но они попробуют.

[@stepanp]

Пара технических вопросов:
1. Зачем делать проверку столкновений попиксельно? Это же мягко говоря, не очень быстро. Тем более что судя по видео геймплея, с головой хватит проверки только прямоугольников.
2. И про «отложенные действия». Разве нельзя просто обычным for'ом коллекцию обходить?

А игра красивая.

[@Dimmerg]

2. И про «отложенные действия». Разве нельзя просто обычным for'ом коллекцию обходить?

Если во время for изменить коллекцию, то счетчик может пропустить следующий элемент, или наоборот — пройти его дважды. Нужно писать доп. условия для корректировки счетчика.
Обычно либо делают как автор, либо проходят не по самой коллекции, а по ее копии, содержащей те же элементы — накладные расходы на создание такой копии не особо велики.

[@stepanp]

понятно, спасибо

[@iandreev]

Чтобы не было таких проблем просто пишется for reverse.

[@Dimmerg]

Для удаления сработает. А если при определенном условии нужно добавить новый элемент, а не удалить текущий? В конечном итоге это будет весьма запутывать.

[@impwx]

1. Попиксельная проверка нужна в любом случае. Например, если пришльцы еще с каким-то приближением вписываются в прямоугольник, то тачка игрока — совсем нет. Игроку было бы досадно и непонятно, почему пули разрываются в метре от капота, но его все же ранит. Кроме того, планировали делать боссов, форма которых тоже могла быть произвольной.
2. Комментатор выше все правильно описал, добавить нечего.

[@stepanp]

На тачку игрока можно пару прямоугольников взять

[@yorick_kiev_ua]

for-ом не надо, нужно что-то типа:

Bullets.RemoveAll(_ => _.LeavesPlayfield());

А «отложеные действия» — это какой-то аццкий велосипед с треугольным колесом.

[@impwx]

Такой вариант мне пришел в голову первым, однако он не подходит по некоторым причинам.

Во-первых, в реальной игре логика обработки более сложна. Для той же самой пули:

1. Если улетела вверх за экран — уничтожить.
2. Если столкнулась с пришельцем — уничтожить, пришельцу нанести bullet.Damage единиц урона, проиграть звук.
3. Если столкнулась со щитом — уничтожить, создать сноп искр.

Как вы понимаете, такими темпами наш список пуль будет обходиться три раза вместо одного, не говоря уже о том, что overhead на вызов функции в цикле в сравнении с простым циклом довольно существенный. LINQ-стиль удобен, но для приложения, в котором важна скорость, я посчитал нужным от него отказаться.

Во-вторых, древовидная структура графа объектов не дает нам полного представления о том, сколько foreach'ей сейчас выполняются и какие объекты трогать нельзя. Например, в моем случае структура такая:

Scene.Objects -> WaveManager.Waves -> Wave.Aliens.

Если я, обходя список пришельцев в Wave, решу добавить новый объект (взрыв? powerup?) в корень сцены, ее коллекция изменится и у меня снова будет ошибка.

С отложенными действиями получается действительно удобнее и быстрее, нужно только немного в них вкурить :)

[@yorick_kiev_ua]

Много шума из ничего. Сколько там у вас этих пуль на экране может быть? Десять? Двадцать? Целых тридцать? И вы на обходе такого огромного, коллосального списка серьёзно хотите сэкономить? Задание контуров коллижнов из двух-трёх ректанглов даст ИМХО на порядок больший выигрыш.