Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 13
Предварительно я изучил вопрос о том, что нужно для создания движка на C, и, похоже, удобным для работы SDL будет Emscripten
странно, а почему автор cocos2d-x не попытается использовать?
Вобще, использовать монстров вроде unity/UE для 2d пиксельной прыгалки мне кажется не очень разумно… ровно как и ныть на поломанный там кем-то плагин, и не в состоянии его починить/написать, но заявлять что «щас я тут напишу вам правильный игровой движек»… или я не прав?
В частности, есть же box2d, opengl, да и тот же cocos как обертка вокруг всех этих вещей. Зачем заново что то изобретать? Получается какой-то критики пост.
Однако в языках наподобие Lua сборщик мусора похож на «чёрный ящик». Можно заглянуть в него, чтобы получить намёки о происходящем, но это неидеальный способ работы. Когда у вас происходит утечка в Lua, то она оказывается гораздо большей проблемой, чем в C.
Нет, не оказывается. Если знать, как это делать, окажется еще и куда проще, чем в C, потому что там происходят произвольные выделения памяти в разных местах, а в Lua это контролируемый процесс. Самый просто вариант — это просто посчитать количество объектов в дампе памяти, глянуть где вы их создаете и просто пофиксить то место. Как вы провернете такое в C?
Посмотрите в сторону Corona SDK, это ЛАВ на стероидах
Только об трейдоффе копипасты автор оригинального текста как-то забыл упомянуть. Что когда понадобится внести изменение в общее поведение А, его нужно будет скопипастить в три класса. А это x3 больше рутины и шанса возникновения багов.
Дело даже не только в том что контексты у одиночек и коллективов разные. Для коллектива — сложно структурированной и заумно-иерархизированный код — такое же зло как и для одиночек. Дело в том что роль наследования гипертрофирована в практически всех учебниках, и вытесняет композицию и копи-пасту. А нужно бы учить людей так: сначала копи-пастим, потом переиспользуем ф-цией или композицией, и только в крайнем, железобетонно-доказанном случае — используем иерархию.
Ещё могу сказать, что на самом деле и нет большой разницы между одиночкой и коллективом вот с какой точки зрения. И у одиночек есть участки кода, которые будут переиспользоваться много раз и будут вылизываться «как у взрослых» — всякие кор-компоненты. И у команд есть участки кода, которые нужно «просто написать» и не переусложнять — потому что завтра клиент может по этому ф-ционалу попросить что-то совсем другое. Просто соотношение одного и другого в разных проектах может отличаться.
Да, с Юнити грусть, выходит. Они уже создали золотую жилу, свой собственный рынок, с которого собирают свой бешеный процент. Ну и сосредоточились бы на этом — стабильный движок (а не с фичами). Т.е., имхо, это плохая практика — будучи хозяевами рынка — пытаться конкурировать с продавцами (создавать сервисы, включать ассеты в основной движок, добавлять фичи), вместо улучшения условий самого рынка (повышение стабильности движка, стимулирование продавцов/покупателей ассетов).
И добавили бы больше возможностей, собственно, для ассетов, разных лицензий, подписок — чтобы пользователи могли не только единоразово покупить, но и спонсировать, как на патреоне. Это я исхожу из своего опыта ещё. Вот я выпустил ассет, он нужен не всем, но для кого он нужен — он экономит сотни часов аниматора, или вообще является ключевым для игры. И, выходит, что продажи не покрывают мою работу над ассетом, а те для кого он важен — готовы платить за апдейты/помесячно, но не могут.
Про трейлеры. Я страдал до тех пор, пока не понял две вещи.
Первое — нужно найти удобный редактор. Т.е. поставили себе задачу — и пытаетесь решить в разных редакторах. Большинство выбешивает ещё на этапе загрузке, с двумя двумя-тремя в принципе что-то можно сделать, а в единственный — влюбляетесь, и, наконец, можете делать дело :) (я остановился на kdenlive).
Второе. Так же как у автора. Слушаю музыку и представляю что будет происходить на экране. А потом всё просто — нарезать под трек, под бит, под смену мелодии.
Кстати, в своём движке (на джаве) — сделал безлаговую запись звука и видео, чтобы получать плавные ролики. Это те самые редкие ролики, которые смотришь, и сразу видишь плавность и те саме 60 кадров. В Юнити такое получалось сделать только без звука и с не-реалтайм рендером.
Ещё могу сказать, что на самом деле и нет большой разницы между одиночкой и коллективом вот с какой точки зрения. И у одиночек есть участки кода, которые будут переиспользоваться много раз и будут вылизываться «как у взрослых» — всякие кор-компоненты. И у команд есть участки кода, которые нужно «просто написать» и не переусложнять — потому что завтра клиент может по этому ф-ционалу попросить что-то совсем другое. Просто соотношение одного и другого в разных проектах может отличаться.
Да, с Юнити грусть, выходит. Они уже создали золотую жилу, свой собственный рынок, с которого собирают свой бешеный процент. Ну и сосредоточились бы на этом — стабильный движок (а не с фичами). Т.е., имхо, это плохая практика — будучи хозяевами рынка — пытаться конкурировать с продавцами (создавать сервисы, включать ассеты в основной движок, добавлять фичи), вместо улучшения условий самого рынка (повышение стабильности движка, стимулирование продавцов/покупателей ассетов).
И добавили бы больше возможностей, собственно, для ассетов, разных лицензий, подписок — чтобы пользователи могли не только единоразово покупить, но и спонсировать, как на патреоне. Это я исхожу из своего опыта ещё. Вот я выпустил ассет, он нужен не всем, но для кого он нужен — он экономит сотни часов аниматора, или вообще является ключевым для игры. И, выходит, что продажи не покрывают мою работу над ассетом, а те для кого он важен — готовы платить за апдейты/помесячно, но не могут.
Про трейлеры. Я страдал до тех пор, пока не понял две вещи.
Первое — нужно найти удобный редактор. Т.е. поставили себе задачу — и пытаетесь решить в разных редакторах. Большинство выбешивает ещё на этапе загрузке, с двумя двумя-тремя в принципе что-то можно сделать, а в единственный — влюбляетесь, и, наконец, можете делать дело :) (я остановился на kdenlive).
Второе. Так же как у автора. Слушаю музыку и представляю что будет происходить на экране. А потом всё просто — нарезать под трек, под бит, под смену мелодии.
Кстати, в своём движке (на джаве) — сделал безлаговую запись звука и видео, чтобы получать плавные ролики. Это те самые редкие ролики, которые смотришь, и сразу видишь плавность и те саме 60 кадров. В Юнити такое получалось сделать только без звука и с не-реалтайм рендером.
Жёсткие уроки
Их контекст заключается в том, что я писал свою игру на Lua и с помощью LÖVE. Я написал 0 строк кода на C и C++, всё писалось на Lua. Поэтому многие из этих уроков связаны с самим Lua, хотя большинство из них применимы и к другим языкам.
nil
90% багов, получаемых от игроков, связаны с доступом к переменным nil.
Сишник не только не освобождает от вылетов из-за разыменования нулевого указателя, но и добавляет вылеты от разыменования указателя с любым неправильным значением (при условии если операционка не давала память с этим адресом, а если давала — то получаешь кота в мешке)…
Да, в современных версиях C++ есть полезные фичи на этот счёт, но вот так рассуждать, что использование C++ априори спасёт от подобных багов — это сильно переоценивать C++. Пока не придумали такой язык, где без самодисциплины со стороны программиста компилятор сам найдёт все баги.
люблю/ненавижу в LÖVE, Lua
Вместо того чтобы влепить кучу лого движков на картинку и потом ругать пару не очень удобных из них, попробовал бы уже Godot 3 :-)
Есть очень малое количество фреймворков/движков, на которых сами разработчики активно делают игры
King делает на своем Defold, который тоже на Lua
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Уроки, полученные при создании первой игры, и почему я хочу написать свой движок