Comments 38
Даже не знаю что хуже, то что вы пишете гейм-логику на плюсах или то что запихали в проект MVC и половину содержимого gang of four в придачу. И почему не внесли в стаью время затраченное на штудирование книжки по паттернам?
UFO just landed and posted this here
Выбрал с++ для гейм-логики т.к. его лучше знаю чем javascript и lua(эти языки тоже используются при работе с cocos2dx). Использовал MVC потому что мне показалось естественно отделить логику от её представления на экране. Первый класс отвечает за внешний вид, второй за предметную область(игровая логика), и третий за связь между первыми двумя. Понимал ооп года два от первого знакомства с книжкой банды четырёх, и до сих пор не понял до конца.
Вредную литературу читаете потому что :)
Из-за использования MVC, у вас получается 50 файлов там где могло быть несколько строчек(условно). Лучше подумайте действительно ли вам в этом случае так необходимо отделять логику от представления?
Какой-нить lua осваивается в худшем случае за неделю(про js такое не могу сказать), зато потом экономит месяцы.
Из-за использования MVC, у вас получается 50 файлов там где могло быть несколько строчек(условно). Лучше подумайте действительно ли вам в этом случае так необходимо отделять логику от представления?
Какой-нить lua осваивается в худшем случае за неделю(про js такое не могу сказать), зато потом экономит месяцы.
Я бы ваши советы назвал вредными.
Аргументируйте
Вот это, например:
Плюс, если честно, не понимаю, в чём проблема с MVC? Количество файлов — не аргумент.
действительно ли вам так необходимо отделять логику от представления?
Плюс, если честно, не понимаю, в чём проблема с MVC? Количество файлов — не аргумент.
А вы считаете, что разделять данные, логику, и представление нужно обязательно всегда и везде?
C MVC проблема в том что в данном случае он скорее всего просто не нужен. Аргументы — разбухаение кода, усложнение логики, уменьшение понятности и читаемости на пустом месте.
Лучше скажите какие плюсы даст MVC в данном случае
C MVC проблема в том что в данном случае он скорее всего просто не нужен. Аргументы — разбухаение кода, усложнение логики, уменьшение понятности и читаемости на пустом месте.
Лучше скажите какие плюсы даст MVC в данном случае
Изначально я не задавался целью использовать какие-то шаблоны. Просто разделял программу на классы, каждый класс отвечает за что-то одно. Возможно было бы быстрее всё вместить в пару классов, но тогда бы мне было тяжелее изменять программу. Вот пример кода(Objective c), который я писал для самой первой моей игры, там смешано всё в одно, и мне сегодня сложно разобраться в этом классе.
А в чем проблема с гейм-логикой на плюсах?
Ну это не проблема, а скорее лишний гемор. Вместо реализации собственно гейм-логики, придется очень много задумываться над деталями реализации там, где в скриптовых языках думать не надо вовсе.
Вообщем плюсы банально сложнее. А зачем усложнять себе жизнь, если плюсы дают только выигрыш в производительности, который а гейм-логике не существенен, непонятно.
Где гемор? Давайте пример, мой опыт показывает противоположную ситуацию. Память в игровом цикле уже обычно вся выделена, с памятью работать не надо, на худой конец временное на стеке выделяется без напряга, думать не надо вообще. Дергай себе методы в машине состояний и не задумывайся не о чём. А вот во всяких скриптовых языках вы даже и не знаете когда будет выделяться память, вы не сможете в принципе создать пул объектов, чтобы память более не выделялась.
Да на каждом шагу. Веселье с инклудами, гардами и forward declarations, там где в скриптах есть import\require, разбиение кода на h\cpp с иногда неочевидными синтаксическими приколами, монструозные конструкции из шаблонов, std::function, auto и лямбд, там где в сприптах есть first class функции, бесконечные касты и шаблоны там где в скриптах есть динамическая типизация, огромный ворох указателей, ссылок, constссылок\указателей, shared\weak\unique\raw указателей там где в скриптах только ссылочные типы(не считая примитивных) и т.п. Это не проблема когда нужно написать например движок, но при написании гейм-логики я тратить на это время не хочу.
Ну так скриптовые языки и придуманы за тем чтобы ускорить процесс разработки, путем скрытия таких деталей реализации от программиста, а не для того чтобы думать сколько раз объект скопируется при возвращении его из метода. К тому же никто не запрещает использовать пул для плюсовых объектов в скриптах.
Ну так скриптовые языки и придуманы за тем чтобы ускорить процесс разработки, путем скрытия таких деталей реализации от программиста, а не для того чтобы думать сколько раз объект скопируется при возвращении его из метода. К тому же никто не запрещает использовать пул для плюсовых объектов в скриптах.
Хм… а не гемор ли в таком случае пробрасывать игровые функции из нативного кода в скрипты и обратно? И задумываться над деталями реализации это же ведь не плохо, если конечно целью не стоит собрать что-то разовое из «говна и палок». Плюс скриптовую часть игры распотрошить на порядок проще, что не совсем хорошо. А может даже совсем не хорошо.
Ради того чтобы экономить месяцы разработки, можно один раз забиндить скрипты. Да и всегда можно взять готовое решение(тот же cocos2d-x имеет готовые биндинги к lua и js). Нет, конечно, не плохо, вопрос в том сколько таких деталей реализации требуют внимния в плюсах и в сколько сприптах. Для скриптовых языков существуют компиляторы и обфускаторы.
Есть универсальное правило — писать быстрее всего на том языке, который знаешь.
Да, если стартует большой проект и заранее известно, что его трудоемкость будет в десятки человеко-лет, то надо сильно задуматься о выборе средств разработки и получении необходимой квалификации с целью минимизировать трудозатраты. Но для домашней поделки — выбор языка имеет совсем другие приоритеты.
Да, если стартует большой проект и заранее известно, что его трудоемкость будет в десятки человеко-лет, то надо сильно задуматься о выборе средств разработки и получении необходимой квалификации с целью минимизировать трудозатраты. Но для домашней поделки — выбор языка имеет совсем другие приоритеты.
Архитектурные астронавты
Как сделать что то странное и долго
>месяц на продумывание архитектуры и написание классов-моделей,
wat? Это можно ну за неделю сделать с головой
wat? Это можно ну за неделю сделать с головой
За неделю я только смог придумать основные классы моделей(интерфейсы классов), а уже потом писал их реализации. В ходе разработки придерживался следующей схемы: сделал класс модели, затем класс контроллера и потом, если необходимо, класс представления. Месяц был потрачен на написание всех реализаций классов моделей и их рефакторинг при необходимости.
Почти образцовый, очень аккуратный проект.
Удивляюсь, конечно, как он не падает при таком довольно старомодном подходе к программированию на C++.
Удивляюсь, конечно, как он не падает при таком довольно старомодном подходе к программированию на C++.
Спасибо. А что значит старомодный подход к программированию на C++.? В моём коде есть несколько проблем:
1) Не использовал умные указатели, т.к. поздно про них прочитал(когда уже половина кода была написана). Я попытался их внедрить но почему-то получал утечки памяти, возможно я плохо следил за слабыми ссылками.
2) Почти не ставил идентификатор const перед переменными.
3) Иногда передавал по значению, где можно передать по ссылке или указателю.
При этом я активно использовал лямбда-выражения, и один раз потоки из с++11.
1) Не использовал умные указатели, т.к. поздно про них прочитал(когда уже половина кода была написана). Я попытался их внедрить но почему-то получал утечки памяти, возможно я плохо следил за слабыми ссылками.
2) Почти не ставил идентификатор const перед переменными.
3) Иногда передавал по значению, где можно передать по ссылке или указателю.
При этом я активно использовал лямбда-выражения, и один раз потоки из с++11.
Проблем много, лень всё описывать тут, но главное, что они все решаемы. Перебор контейнеров, например.
вы правы). Было бы неплохо если вы предложите ресурсы(книги, ссылки) по их улучшению.
По смарт-поинтерам основы: www.boost.org/doc/libs/1_58_0/libs/smart_ptr/sp_techniques.html
по шаблонам основы: Александреску «Современное проектирование на с++»
а дальше по мере нужды: из списка: www.boost.org/doc/libs/1_59_0
по шаблонам основы: Александреску «Современное проектирование на с++»
а дальше по мере нужды: из списка: www.boost.org/doc/libs/1_59_0
Спасибо за статью. Приятно знать, что кто-то еще использует кокос))
Было бы интересно прочитать (хотя бы вкратце) про следующие аспекты и то как автор с ними борется:
-поддержка разных размеров экранов на разных платформах
-поддержка нативных штук (как вы обходитесь без JNI обвязок?) )
-были ли автотесты?
-был ли какой-то нестандартный ui, которого нет в кокосе?
-были ли какие-то нестандартные тразишины, которые не сделать (сложно сделать) штатными методами кокоса?
Было бы интересно прочитать (хотя бы вкратце) про следующие аспекты и то как автор с ними борется:
-поддержка разных размеров экранов на разных платформах
-поддержка нативных штук (как вы обходитесь без JNI обвязок?) )
-были ли автотесты?
-был ли какой-то нестандартный ui, которого нет в кокосе?
-были ли какие-то нестандартные тразишины, которые не сделать (сложно сделать) штатными методами кокоса?
Спасибо автору! Мы тоже писали игру на cocos2d-x (кратко о ней megamozg.ru/company/whisperarts/blog/18730)
Из трудностей/особенностей могу поделиться:
— GoogleAnalytics, AdMob и Facebook пришлось пробрасывать мостами и использовать нативные sdk под каждую платформу
— Для внутренних платежей использовали soomla (https://github.com/soomla/cocos2dx-store). Было много проблем с интеграцией, но в итоге всё завелось. Его нет под Win8, поэтому там в итоге запустили платную версию с демо-режимом
— WindowsPhone не поддерживал проигрывание mp3, поэтому специально для этой платформы для сборки мы использовали wav
— cocos2d-x неплохо поддерживает работу с сетью — в том числе веб-сокеты, которые мы использовали для создания сетевого режима игры
—
это оказалось серьезной проблемой и для нас при использовании внутреннего конфига. Поэтому конкретно для этой платформы мы сделали сохранение в файл
— для некоторых элементов меню, анимаций и мультиков мы использовали CocosStudio (http://www.cocos2d-x.org/wiki/Cocos_Studio)
Из трудностей/особенностей могу поделиться:
— GoogleAnalytics, AdMob и Facebook пришлось пробрасывать мостами и использовать нативные sdk под каждую платформу
— Для внутренних платежей использовали soomla (https://github.com/soomla/cocos2dx-store). Было много проблем с интеграцией, но в итоге всё завелось. Его нет под Win8, поэтому там в итоге запустили платную версию с демо-режимом
— WindowsPhone не поддерживал проигрывание mp3, поэтому специально для этой платформы для сборки мы использовали wav
— cocos2d-x неплохо поддерживает работу с сетью — в том числе веб-сокеты, которые мы использовали для создания сетевого режима игры
—
Движок не поддерживал пути с кириллицей. Если имя пользователя windows написано по русски, то игра вызовет ошибку и не запуститься.
это оказалось серьезной проблемой и для нас при использовании внутреннего конфига. Поэтому конкретно для этой платформы мы сделали сохранение в файл
— для некоторых элементов меню, анимаций и мультиков мы использовали CocosStudio (http://www.cocos2d-x.org/wiki/Cocos_Studio)
А можете пожалуйста рассказать подробнее как вы решили проблему с кириллицей?
Я чуть ошибся, не в файл — а в стандартные winrt-настройки. У нас был свой класс, упрощающий доступ к настройкам. И в нем был такой макрос:
Вот наши сеттинги для WINRT:
dl.dropboxusercontent.com/u/8086143/SettingsWinRT.h
#if (CC_TARGET_PLATFORM == CC_PLATFORM_WINRT)
#include «SettingsWinRT.h»
#define USER_DEFAULTS SettingsWinRT::getInstance()
#else
#define USER_DEFAULTS UserDefault::getInstance()
#endif
Вот наши сеттинги для WINRT:
dl.dropboxusercontent.com/u/8086143/SettingsWinRT.h
Спасибо.
-поддержка разных размеров экранов на разных платформах. Использовал разные ветки в гит для разных платформ. Для андроид использовал политики и дизаин-разрешение экрана ( setDesignResolutionSize(320, 480, kResolutionShowAll) ), а также для разных разрешений экрана разный арт вот Для winRT тоже политики, а для обычной win32 сделал один и тот же размер окна для всех экранов.
-поддержка нативных штук (как вы обходитесь без JNI обвязок?) ) Не использовал нативных штук, за исключением генерирования guid, и то взял готовую библиотеку, для андроид не понял как связываться с JNI, поэтому сделал один guid для всех. В итоге у меня в гугл аналитике по андроид новых пользователей 1.
-были ли автотесты? Нет.
-был ли какой-то нестандартный ui, которого нет в кокосе? В данном проекте нет. На одном проекте(cocos2d-iphone) понадобился контроллер магазина с табами, пришлось написать его самому с помощью CCScrollLayer.
-были ли какие-то нестандартные тразишины, которые не сделать (сложно сделать) штатными методами кокоса? Нет
-поддержка разных размеров экранов на разных платформах. Использовал разные ветки в гит для разных платформ. Для андроид использовал политики и дизаин-разрешение экрана ( setDesignResolutionSize(320, 480, kResolutionShowAll) ), а также для разных разрешений экрана разный арт вот Для winRT тоже политики, а для обычной win32 сделал один и тот же размер окна для всех экранов.
-поддержка нативных штук (как вы обходитесь без JNI обвязок?) ) Не использовал нативных штук, за исключением генерирования guid, и то взял готовую библиотеку, для андроид не понял как связываться с JNI, поэтому сделал один guid для всех. В итоге у меня в гугл аналитике по андроид новых пользователей 1.
-были ли автотесты? Нет.
-был ли какой-то нестандартный ui, которого нет в кокосе? В данном проекте нет. На одном проекте(cocos2d-iphone) понадобился контроллер магазина с табами, пришлось написать его самому с помощью CCScrollLayer.
-были ли какие-то нестандартные тразишины, которые не сделать (сложно сделать) штатными методами кокоса? Нет
Вот ссылка на игру в гугл плей
Sign up to leave a comment.
Как сделать тетрис за полгода на cocos2dx