Aprenda & desarrollo de Juego de Maestro Cocos2D

Cuando la pregunta subió si a la subclase CCSprite o usan alguna clase modela para construir su jerarquía de entidad animosa en el foro cocos2d, subrayé que habría que tratar de no usar la herencia y guardar la jerarquía de herencia a como pocos niveles como sea posible. He trabajado con codebases con cientos de miles de líneas del código, y cientos de tipos diferentes de actores en el mundo. Aún la jerarquía de herencia era 2 clases (paternales) súper para casi todos los objetos, sólo muy pocos objetos animosos tenían 3 o 4 clases súper. ¿Cómo puede usted hacer juegos complejos este camino? Yet the inheritance hierarchy was 2 super (parent) classes for almost all objects, only very few game objects had 3 or 4 super classes. How can you make complex games this way?

La respuesta está en la composición, a menudo referida Componentes como Animosos por motores como TorqueX y el Motor de PushButton (un motor de juego de Destello de los reveladores de Torsión originales). Este vídeo de PushButton conduce el revelador Ben Garney lo explica muy bien y también ilustra el problema con el uso excesivo de herencia en motores animosos. Algo del cual la mayor parte de reveladores nuevos a la programación orientada al objeto y/o animosa realmente tienden de hecho a abusar – culpo esto de libros mal escritos y otras fuentes OOP introductorias que enfatizan la herencia sin hablar de sus desventajas. Something that most developers new to object-oriented and/or game programming do in fact tend to over-use – i blame that on poorly written books and other introductory OOP sources which emphasize inheritance without discussing its disadvantages.

Usted puede leer más sobre el sistema de Componentes de PushButton en su documentación. Como ellos pusieron en práctica Componentes en TorqueX y lo que las diferencias son a Componentes Animosos XNA adelante realza el entendimiento del concepto.

Ya que la lectura adicional y los argumentos leen el artículo Wikipedia sobre la ingeniería de software basada componente. ¡De hecho, la lengua Objetiva-C fue inventada para ser capaz de crear componentes de software reutilizables!

La conversación de 2002 GDC de Scott Bilas sobre Un Sistema de Objeto Animoso conducido por los Datos (PDF) como usado por el Sitio de Calabozo contiene más agujas en por qué la herencia falla para reveladores animosos y lo que las ventajas (sino también algunas advertencias) son con motores animosos basados en el componente. La conversación puede ser vieja pero todavía es tan válido hoy como esto estuvo de vuelta entonces. De hecho, en 2002 comencé a trabajar en SpellForce que ya hizo incorporar un sistema componente en su corazón, llamado Aspectos, Capacidades y Ortografía. Esto permitió que nosotros entráramos en todos los datos animosos en la base de datos y los programadores sólo tenían que escribir el código genérico que trató con los datos, así como poner ciertos límites y verificaciones de validez (eg. usted no podía usar una ortografía perjudicial en usted, pero si usted quisiera a usted podría apuntar a enemigos con su curar la ortografía, o tener edificios de brote de arqueros … errm). In fact, in 2002 i started working on SpellForce which already had a component system built into its core, called Aspects, Abilities and Spells. It allowed us to enter all the game data in the database and programmers only needed to write the generic code that dealt with the data, as well as setting certain limits and validity checks (eg. you couldn’t use a damaging spell on yourself but if you wanted to you could target enemies with your heal spell, or have archers shoot buildings … errm).

Durante 2009 GDC una presentación similar fue sostenida por Marcin Chady del Entretenimiento Radical. La conversación fue llamada Teoría y Práctica de la Arquitectura de Componente de Objeto Animosa (PPT).

Mick West escribió un artículo Refactoring Game Entities with Components que describe los desafíos y ventajas de cambiar a Tony Hawk codebase de un modelo de herencia a un sistema componente animoso.

Algo más avanzado leído en el uso componente es un papel de colaboración llamado el Sistema de Componente de Objeto Animoso Dinámico para Caracteres de Comportamiento Mudables que habla de componentes en el contexto de máquinas estatales finitas y comportamientos NPC con un sistema de activación basado en la regla.

El blog de Arquitecto Animoso lo llama una Anatomía de Desesperación y resume muy bien lo que las estafas del diseño de clase basado en la herencia es y como la composición los soluciona.