Книга cocos2d, Глава 3: Основы
Глава 3 – Основы
Эта глава - ссылка о фундаментальных классах cocos2d и как использовать их. Узлы, Слои, Сцены, Лейблы, Эльфы, Переходы, Действия, Вы называете это. Также CCDirector, SimpleAudioEngine и другие часто используемые классы единичного предмета также. Более продвинутые понятия будут обсуждены в более поздней главе, Spritesheets например. Also CCDirector, SimpleAudioEngine and other often used singleton classes as well. More advanced concepts will be discussed in a later chapter, Spritesheets for example.
Подчинение первого проекта главы должно следующий пятница, 16-ого июля.
То, что делает Вы думаете, должно быть в Главе 3?
Вы знаете cocos2d класс или процесс, что Вы думаете, важно и должен быть обсужден в этой главе? Сообщите мне!
Резюме работы над Главой 2 – Начинание
Для одного я детализировал Привет Мировой типовой проект и сделал простую модификацию, используя вход прикосновения. В то же самое время, по крайней мере, некоторый базовый уровень понимания о cocos2d классах был введен, но суть этого сделана в Главе 3. Кроме того, было много теоретических аспектов, которые я хотел обсудить также, больше всего управление Памятью и доступная память так же как ожидания урегулирования при тестировании на Тренажере против устройства. И конечно устройства и их тонкие различия. Я действительно надеюсь, что подобные детали ценятся, даже если они не 100 %, связанных с cocos2d. Я регулярно вижу, что cocos2d разработчики борются с проблемами памяти с неожиданными различиями на устройстве против Тренажера, или сравнивают framerates Тренажера, и возможно даже Отладка строит. Это заставило меня хотеть отклониться в глуши на мгновение, чтобы, мы надеемся, спасти читателей некоторые неправильные представления и боль, связанная с ними. In addition, there were a lot of theoretical aspects I wanted to discuss as well, most of all Memory Management and available memory as well as setting expectations on testing on Simulator vs. a device. And of course the devices and their subtle differences. I do hope that those kind of details are appreciated even if they’re not 100% related to cocos2d. I regularly see cocos2d developers struggling with memory issues, with unexpected differences on the device vs the Simulator, or comparing framerates of the Simulator and possibly even Debug builds. That made me want to stray off the beaten path for a moment to hopefully save the readers some misconceptions and the pain associated with them.
Я также понял, сколько шагов новый разработчик должен пройти и насколько там должен учиться в случае, если Вы никогда не работали с iPhone SDK прежде. Это начинается с регистрации как разработчик iPhone и не заканчивается монтажом SDK, потому что Вы также нуждаетесь в обеспечивающих профилях, очень обсужденной и неприятной особенности. Для всего этого я отсылал к существующему (и превосходный) документацию Apple. Как правило изменение процессов с каждым новым iPhone, SDK или может даже находиться под NDA, таким образом обсуждая, как все это работает с iPhone SDK 4, не было бы хорошей идеей, так как вскоре после того, как книги отсутствует iPhone, SDK 5 может прибывать, вводя изменения Двери Разработчика и iTunes Соединяется с этим. Это действительно получало меня идея, и я знаю, что у других есть это также, что мы нуждаемся в некоторой Обучающей программе рук холдинга, которая берет один через шаги от регистрации как Разработчик iPhone к публикации первого Приложения, ссылаясь на правильную официальную документацию для каждого шага, не забывая о распространенных ошибках, которые не находятся в официальных докторах. For all of this I refered to existing (and excellent) Apple documentation. Typically the processes change with each new iPhone SDK or may even be under NDA, so discussing how all of this works with iPhone SDK 4 wouldn’t be a good idea since shortly after the book is out iPhone SDK 5 may be coming, introducing changes to the Developer Portal and iTunes Connect with it. It did get me the idea, and I know others have it too, that we need some holding-hands Tutorial which takes one through the steps from registering as iPhone Developer to publishing one’s first App, by referring to the correct official documentation for each step while not forgetting about common pitfalls that are not in the official docs.
Я также заметил, насколько легкий это может быть должно пропустить, как Вы внезапно вводите новое понятие, не объясняя это сначала. И затем Вы должны решить, сколько информации необходимо, чтобы ввести понятие, не отклоняясь слишком далеко от того, о чем Вы хотите говорить во-первых. Это особенно твердо для меня, потому что я склонен хотеть объяснить все подробно, но некоторые вещи должны быть оставлены для более позднего обсуждения. Я с нетерпением жду редакционной обратной связи теперь. Это помогло tremendeously для первой главы, и я учился много из редакции Apress, таким образом, я считаю это возбуждением, что эксперты указывают мне на недостатки и делают предложения, я вхожу, чтобы установить их и затем видеть, насколько лучше это. Это - то, как мне нравится изучать вещи, и это собирается быть одним из основного понятия книги. Покажите, как это сделано, как это не должно быть сделано (если это часто делало неправильно), и как это может быть сделано еще лучше, если Вы хотите избежать проблемы в конечном счете, объясняя почему. It’s especially hard for me because I tend to want to explain everything in detail but some things have to be left for a later discussion. I’m looking forward to editorial feedback now. It has helped tremendeously for the first chapter and I learned a lot from the Apress editorial staff, so I find it exciting that the experts point me to the flaws and make suggestions, I go in to fix them and then see how much better it is. That’s how I like to learn things and it’s going to be one of the core concepts of the book. Show how it’s done, how it shouldn’t be done (if it’s often done wrong) and how it can be done even better if you want to avoid trouble in the long run, while explaining why.
Действительно любите Вас книга о cocos2d, только задаваясь вопросом, можете ли Вы добавить больше информации о части акселерометра особенно о фильтре нижних частот и фильтре высоких частот.
Больше информации об этом в http://developer.apple.com/iphone/library/documentation/EventHandling/Conceptual/EventHandlingiPhoneOS/MotionEvents/MotionEvents.html
Думайте довольно полезно, чтобы изолировать компонент силы тяжести. Строя тип Raiden игры с cocos2d теперь и я считаю важным изолировать силу тяжести, чтобы получить X и движение Y. Сообщите мне то, что Вы думаете об этом? Let me know what you think about it ?
Гонконг Ченг
Спасибо, который является интересной темой действительно! И легко пропускаемый, что есть понятие, названное силой тяжести, затрагивающей данные об акселерометре. По крайней мере, я должен сделать коробку примечания и указать на связь для дополнительной информации. At least I should make a Note box and point to the link for further information.
Не упоминайте это
Одной областью, которая нуждается в намного большем количестве документации, являются пространственные особенности иерархии узла.
Отношения между границами, структурами, contentSize, измеряют и т.д. Чтобы измениться когда, и побочные эффекты и значения изменения каждого. Как они изменены (если вообще) родительскими узлами. Узлы "Запаковывают" свои границы вокруг их детей? Вопросы как этот. How they are modified (if at all) by parent nodes. Do nodes “shrinkwrap” their bounds around their children? Questions like that.
Немного методов отладки иерархии представления обсуждения было бы большим, также. Такой как, как определить, почему детские узлы не показываются в размере/положении, который Вы ожидаете.
Вы и все остальные, кажется, используете сцены экономно, твердое кодирование их в Ваших классах. Например, в Вашем исходном коде главы 3, когда Вы идете в сцену меню, у Вас есть кнопка, чтобы вернуться к сцене HelloWorld:
[[CCDirector sharedDirector] replaceScene: [Сцена HelloWorld]];
Но что, если я хочу иметь, говорят 10 сцен и перемещаются между ними с сильно ударением или навигационными стрелками? Я не хочу трудно кодировать передовые сцены и задние сцены в каждой сцене. Было бы лучше иметь некоторого менеджера сцены, вид подобных основная сцена с другой внутренней частью это. It would be better to have some kind of scene manager, sort of like a master scene with the other inside it.
Это возможный иметь где-нибудь за пределами сцен:
CCArray NextSceneArrayOfScenes = ”Scene00 ″, ”Scene01 ″, ”Scene02 ″;
chosenScene + = 1;//пользователь nagivates вперед
CCScene* nextScene = [NextSceneArrayOfScenes objectAtIndex:chosenScene];
[[CCDirector sharedDirector] replaceScene: [сцена nextScene]];
Или Вы использовали бы слои/узлы вместо этого, и только переместили бы их в сторону, моделируя изменение сцены?
Когда люди делают журнал или что-то, как каждая обработанная страница, как сцена или как слои/узлы?
Я нашел обучающую программу для sceneManager.
http://www.iphonegametutorials.com/2010/09/07/cocos2d-menu-tutorial-part-2/
Это довольно умно, создавая слой и обертывая это в сцену и возвращение этого, чтобы быть новой сценой.
Это могло быть изменено так, чтобы у sceneManager было множество всех возможных сцен, и сцена, которая называет sceneManager, могла послать число, основанное на настоящем положении (скажите, делаете ли Вы журнал или что-то, где сцены - эквивалент "страниц").
Однако, что-то с 50 страницами должно было бы, вероятно, быть обработано еще более эффективно, где страницы так или иначе произведены динамически, также загружая содержание динамически.