а почему не на wp8 ориентируешься? это дало бы гибкость в выборе платформ.
+планшеты, PC и если приложить немного усилий, то дроид с иосью. в monogame например.
[dtimofeev.blogspot.com]
1. Девайс старый, только поддерживает WP7.5. Собственно у меня нет возможности тестировать приложение созданное для WP8. Покупать новый телефон не хочется, мой старый htc titan меня полностью устраивает.
2. За полтора года накопилось довольно много наработок, и просто вот так вот взять и отказаться от них немного жалко. И как-то сложно принять мысль, что все это было в пустую.
У меня следующий план. Эту игру выпустить в рамках XNA фреймоворка. Посмотреть гемплей игры, отрегулировать баланс. Попытаться заработать. И в конце жизненного цикла программы заморозить код.
Следующий шаг это портировать игру на С++ с упором на кросплатформенность.
Либо, начну новый проект уже на DirectX C++
Monogame мне не нравится, если майкрософт похоронит xna то так тому и быть. Иначе чувствую себя как будто я скачу на мертвой лошади.
Yozka, вы недооцениваете 'Monogame', он развивается бешеными темпами, и все наработки для 'xna', будут работать на Monogame! Даже ничего переделывать не придется. Плюс (для кого-то точно), 'Monogame' стал поддерживать Playstation 4 XD.
PS: Программировать на C#, это же одно удовольствие! :3
MonoGameSite//LWJGL//OGRE
Я в Google+,Twitter Сайт нашей команды.[Обновлен]
general спасибо за ссылку.
Это что получается, придется свой интернет магазин скалачивать для внутригровых покупок?
Логику вижу такой:
Запускаем игру, игра имея ID пользователя скачивает из магазина все уже ранне купленные игровые штуки.
Если пользователь, хочет прикупить игровых вещей. То он в игре регестрируется. Придумывает себе ник и пароль. либо игра генерирует "токен"
Дальше идет на сайт, вводит имя/пароль либо "токен".
Ложим в корзину игровые вещи, производитм оплату палкой или робокассой, или другой платежной системой.
купленные игровые вещи, привязываются к ID пользователю.
Запилил второе видео (выложил на первую страницу), снимал на эмуляторе 720P. Видны по бокам черные полосы, так как я сделал гардиент по краям карты, эти полосы некретичны.
Уже прорисовывается интерфейс. Через пару недель закончу с интерфейсом, далее займусь частицами, или инвентарем. или системой со сменой уровней.
Работы еще полно.
Изменил(а) Yozka, 26.10.2013 23:51:24
Мдяяяяя, ненашел вменяемого редактора 2D костной анимации, чтобы можно было точки и матрицы поворотов костей экспортировать в XML.
Придется свою тулзу писать.
А мне это делать неохота, старею я.
Сделал редактор 2Д анимации. Получилось трешово, но пользоваться можно. Самый главный момент в том, что редактор анимацию экспортирует в и гровой проект ввиде кода. Да редактор создает порятнку - код. который отрисовывает и анимирует юниты.
Пока получается несусветная хрень. Если в течении недели несмогу закончить анимацию. то демка/игра будет без анимации. жаль. Иначе проект затяну на долгое время. Хочется к новому году выпустить играбельную демку.
У тебя анимация построена на соотношении Время - Матрица деформация? И редактор дает файл с этими соотношениями, а в проге ты просто парсишь этот файл в класс который в последующем обрабатывает анимацию?
да, анимация построена по соотношению времени. время задаю в милисекундах. В программе время представляется от 0 до 1. Этакая временная линия анимации. На эту линию вешаю узлы.
Узел это смещение спрайта относительно нуля по X,Y,ПОВОРОТ .
По этим узлам строится матрица трансофрмации. для отрисовки спрайтов.
Далее редактор, создает код C# ввиде класса, где статическйи сформирован массив узлов. по которым этот класс и рисует анимацию.
Получаются такие адские портянки
Например отрисовка робота, сформированно автоматический.
где
joint_* - текущие узлы, в котором хронятся анимационные смещения
m_robot_* - спрайты ввиде классов, которые могут отрисовыватся и хранятся внутри точки соеденения узлов между собой
щас отлаживаю. уже рисуется робот. даже дрыгает своими оглоблями. (руками ногами)
Что-то тут не так) Если у тебя будет много объектов со скелетной анимацией, то это же сколько кода будет... А так редактор бы записывал в файл, например:
GeSHi: C#
[Bone:Head]
[Time0][Matrix[]]
[Time1][Matrix[]]
[Bone:Leg]
[Time0][Matrix[]]
/*И т.д.*/
Добавлено за 0.004 секунд, используя GeSHi 1.0.8.2
А в игрушке просто парсишь его в класс, который воспроизводит анимацию.
от файлов отказался по двум причинам:
1. слишком муторно, сейчас гружу уровни через content pipeline xml. и мне этот механизм немного раздражает.
2. скорость, если еще к анимации прикрутить парсенг файла, то будет неэффективно.
Да, с моим подходом для генерации кода анимации - не оптимален, и генерируемый листинг доходит до 15 тыщь строк . Но слава майкрософт, и компилятор хорошо оптимизирует код, что основной размер исполняемого файла увеличивается всеголишь на 20кб. При выполнении программы, используемая память увеличилась чтото меньше мегабайта. Считаю что это хорошим результатом.
По количеству объектов, неее их будет немного.
4 скелета роботов:
а) антропоморфное чудовище
б) робот ввиде ведра R2D2
с) робот на гусенечной и колесной тяге, всякие машины
д) летающие шняги
к каждому скелету по 5-6 анимаций
причем, анимация сделана по принципу "один ко многим"
В итоге, всего анимаций выйдет неболее 30. И из за этих 30 анимаций городить огород с парсингом анимационного файла - думаю излишним.
Пускай редактор сразу, код генерит. так проще.
Вот, видео сделал. анимация пока на зачаточном уровне. YouTube Video
Изменил(а) Yozka, 18.11.2013 21:59:47
Ага. усложню задачу.
Внешний вид персонажа, может менятся. там српайты рисуются разные. зависимости от характеристики персонажа. И собственно модель которая отрисовывает эти спратйты тоже динамический меняется. не так часто. но всеже это происходит. Соответственно в зависимости от модели создается соответствующая анимация.
Ну и главный для меня аргумент, это "таблица чисел для анимации" хранить непосредственно у персонажа - немного не оптимально. эти данные будут находится у каждого персонажа. и чем больше персонажей. то тем больше придется хранить анимации. Причем анимация то будет у всех одинаковая. такое вот получается неоптимальное расходования памяти. Можно конечно эти таблицы анимации вынести в отдельный менеджер. который будет грузить необходимые данные. и собсвтенно через этот менеджер ренедрить на карте персонажей с учетом анимации. Но это приведет опять же к усложнению кода.
Yozka написал:
Можно конечно эти таблицы анимации вынести в отдельный менеджер. который будет грузить необходимые данные. и собсвтенно через этот менеджер ренедрить на карте персонажей с учетом анимации. Но это приведет опять же к усложнению кода.
Ну на счет усложнения не знаю. У меня к примеру есть AtlasStorage, где я храню атласы текстур(AtlasTexture).
GeSHi: C#
publicstruct AtlasTexture
{
publicstring AtlasName;//Атлас-родитель
publicstring Name;//Имя текстуры или frm#. frm# - разрешает использовать атлас в качестве источника кадров для анимации.
public Rectangle Rectangle;
publicint Width { get {return Rectangle.Width;}}
publicint Height { get {return Rectangle.Height;}}
public AtlasTexture(string aname, string tname, Rectangle rect)
{
AtlasName = aname;
Name = tname;
Rectangle = rect;
}
}
Добавлено за 0.006 секунд, используя GeSHi 1.0.8.2
Так же есть AtlasDrawer(в конструкторе передается ссылка на атлас) и AnimatedSprite(в конструкторе: ссылка на атлас, кадры в секунду). Последний в свою очередь рисуется с помощью первого. И код вроде не совсем сложный выходит.