«Те из вас, кто следил за деятельностью renderDragon’а, знают, что мы объединили силы с Endless Fluff Games для создания и выпуска нашей первой игры для iOS: Derfwood. Но вы могли и не знать, что Derfwood – это уже второй наш совместный проект. В первый раз мы помогали Endless Fluff разместить их игру «Legend of Fae» в Steam’е (игра недоступна в России – прим. переводчика).
При создании «Legend of Fae» Endless Fluff использовали Game Maker. Я знаю, что пользователи Game Maker’а (а в еще большей степени хейтеры – прим. переводчика) очень сомневаются в том, что игры, сделанные с его использованием, могут работать (и самое главное – продаваться – прим. переводчика) со Steam’ом. Даю 100% гарантию, что Steam-версия «Legend of Fae» сделана на Game Maker’е. Интеграцию со Steam’ом, как эксперты по части Game Maker могли догадаться, нам обеспечила самописная библиотека, которую мы создали и связали с Game Maker’ом при помощи Game Maker’s Extension Maker’а. Библиотека была написана в Visual Studio C++ и связана с библиотеками Steam’а. Эта DLL – своеобразный промежуточный слой между Steam’ом и игрой, сделанной на Game Maker’е. Как и предполагалось, она дала доступ ко всем возможностям, которые может предложить Steam (Cloud, Достижения и т.д.). К сожалению, мы не можем предоставить больше деталей, так как Steam API находится в закрытом доступе.
Если смотреть с технической точки зрения, то больших проблем всё это не доставило. Steam API предоставляет множество функций, и выбор за вами: использовать их или нет. Всё зависит от того, насколько сильно вы хотите интегрировать вашу игру со Steam’ом. Также для проверки корректности работы игры со Steam’ом предоставляется замечательнейшая платформа для тестов, что очень удобно и просто.
Поработав со Steam API мы убедились, что Steam был разработан настолько удобным, насколько это возможно, так что единственное препятствие для размещения вашей игры – это долгое время ожидания одобрения игры для продажи (а также качество самой игры, конечно – прим. переводчика). Так что независимо от того, программируете вы, работая в Scratch (визуальная объектно-ориентированная среда программирования для обучения школьников младших и средних классов – прим. Википедия), или используете 3д-движки, будьте уверены в себе и продолжайте делать веселые и захватывающие игры. Мы, как игроки, ждем не дождемся как бы поиграть в них!
Также если вы считаете, что данный материал мог быть интересен и полезен кому-то из ваших друзей, то вы бы могли посоветовать его, отправив сообщение на e-mail друга:
Игровые объявления и предложения:
Если вас заинтересовал материал «Game Maker и Steam на примере Legend of Fae», и вы бы хотели прочесть что-то на эту же тему, то вы можете воспользоваться списком схожих материалов ниже. Данный список сформирован автоматически по тематическим меткам раздела.
Предлагаются такие схожие материалы:
Если вы ведёте свой блог, микроблог, либо участвуете в какой-то популярной социальной сети, то вы можете быстро поделиться данной заметкой со своими друзьями и посетителями.
А что не верить то, к гм легко подключаются длл-ки, а значит вполне вероятно, что запечатав функции Steam в библиотеку, тем самым развязываете гм руки =)
Хех. Игру явно не лохи делали, думаю они бы смогли сделать её и на флеше, и на ксане, и на юнити, или вообще написать свой движок игры с нуля на С++. Подавляющее же большинство "игроделов на гамаке" вряд ли сможет сообразить свою собственную дллку для стима (учитывая еще и то шо стим АПИ кагбэ закрыт, значит люди не с улицы), а если и сообразит, то в принципе париться не будет, а запилит свою игрулину на той же XNA или вообще самостоятельно движок напишут. Скорее всего игра была выпущена в рекламных целях ГМ студио, и небось участие гамака свелось к рендерингу.
Маркетологи, такие маркетологи. Гамк существует уже стопицот лет, а толковых игр на нем можно по пальцам пересчитать. Как среда для прототипирования дизайнеров - может и сгодится. Но ни один нормальный программист под ней писать не будет, а если и будет, то обплюются. Сам по-началу проявил интерес, в итоге понял шо ветка то мертвая. Причины таковы: - фееричная производительность, особено радует то шо скрипты, вынесенные за пределы объекта отдельно выполняются медленнее. То шо львиная доля программы - это куча функций, которые потом уже используются в мейн лупе, для Овермарса видимо тайна, ну или он считает пользователей гамака настолько тупыми, шо они никогда не выйдут за пределы стандартных функций. - концепция ООП реализована по-инвалидски, полиморфизмом даже и не пахнет. Да и вообще нету нормальных инструментов для работы с объектами. - все что сложнее платформера из стандартного примера, превращается в трудноуправляемую мешанину скриптов и пиктограмок. По дефолту создавать свои действия и функции низя, только через отдельную утилиту, которая ничего не гарантирует или вообще, стиснув зубы, писать свои дллки. В итоге куча радостных часов, потраченных на то, что бы выяснить какое событие и в каком объекте вызывает такой-то метод в другом объекте. - синдром левого окна. Могу даже скриншот выложить, где всего два объекта - один высчитывает расстояние до другого в 130 пикселей, второй до первого в 128 пикселей ))) Видимо это уже особенность движка - скорее всего прежде чем перейти к следующему объекту, движок сначала должен полностью обработать предыдущий объект - все события и методы, про другие способы организации Марк видимо тоже не знает, та же коллизия будет обрабатываться в процессе перемещения текущего объекта, до того, как будут перемещены все остальные, идущие за ним, объекты. А движок, ох и ах, уже не перепилишь - мягко говоря не самый удобный интерфейс, который дополняют свистелками и перделками, вместо того, чтобы сделать сквозную и прозрачную IDE. Ей богу, блокнот кажеться по сравнению с ним верхом изобретательности.