Під час розробки ігор у вас може виникнути необхідність якось переміщувати карту відповідно до дій персонажу. Особливо важливо правильно реалізувати скролінг у платформерах — я б дуже рекомендував прочитати ось цю статтю, просто для того, щоб зрозуміти всю глибину проблеми.

Для прикладу візьмемо анімацію чарівника та проведемо його по довгому-довгому рівню, схожому на замок.

У Cocos2d переміщення карти (точніше, переміщення по карті) легко реалізувати за допомогою класу Camera.

Camera, є нащадком Node тому для того, щоб змінити її позицию, можна використовувати звичайні акції (в даному випадку MoveTo). Але, на відміну від об'єктів, які ми використовували раніше, камера живе у тривимірному просторі, тому координати вказуються трохи інакше.

Ось так виглядає приведення камери до точки, на якій знаходиться маг:

cocos2d::Vec2 expectedMagePos; // поточна позиція мага
<....>
Camera* camera = getDefaultCamera();
const Vec3 currentCameraPos = camera->getPosition3D();
Vec3 newCameraPos = Vec3(expectedMagePos.x, expectedMagePos.y, currentCameraPos.z);
MoveTo* cameraMoveAction = MoveTo::create(1, newCameraPos);
camera->runAction(cameraMoveAction);

Просто задаєте нову позицію камери (висота така сама, як у старої, а координати на площині змінюються), створюєте акцію і все, скроллінг готовий. У демонстраційній програмі камера пересувається кожного разу, як маг завершує перехід у точку, що знаходиться занадто близько до краю вікна.

Результат виглядає так:

Зі скелетами у цій програмі пов'язана пара цікавих речей. По-перше, деякі з них ходять за межами екрану, тому ресурси на обчислення їх положення витрачаються даремно. Може виникнути бажання якось вимкнути виконання акцій для об'єктів, що знаходяться далеко від гравця. Проте така дія є передчасною оптимізацією, її краще уникати.

По-друге, об'єктів-скелетів багато, тому для управління ними краще створити окремий клас. В принципі, для мага теж треба було б зробити свій клас, але це ускладнило б код, тому у прикладі його координати зберігаються у класі сцени.

Можливі два варіанти:

• зробити клас скелету нащадком cocos2d::Sprite
• створити клас, що буде управляти об'єктом cocos2d::Sprite

Це дискусійне питання “наслідування проти композиції", у кожного вибору є свої переваги та недоліки. У своєму прикладі я використав наслідування, а поради щодо створення композиції можна знайти у цій статті.