Espero que estas divagaciones aclaren mi pregunta: sin embargo, entendería totalmente si no lo harían, así que avíseme si ese es el caso e intentaré aclararme.
Conoce a BoxPong , un juego muy simple que hice para familiarizarme con el desarrollo de juegos orientado a objetos. Arrastra el cuadro para controlar el balón y recoge las cosas amarillas.
Hacer BoxPong me ayudó a formular, entre otras cosas, una pregunta fundamental: ¿cómo puedo tener objetos que interactúen entre sí sin tener que "pertenecer" el uno al otro? En otras palabras, ¿hay alguna forma de que los objetos no sean jerárquicos, sino que coexistan? (Voy a entrar en más detalles a continuación).
Sospecho que el problema de los objetos que coexisten es común, así que espero que haya una forma establecida de resolverlo. No quiero reinventar la rueda cuadrada, así que supongo que la respuesta ideal que estoy buscando es "aquí hay un patrón de diseño que se usa comúnmente para resolver su tipo de problema".
Especialmente en juegos simples como BoxPong, está claro que hay, o debería haber, un puñado de objetos que coexisten en el mismo nivel. Hay una caja, hay una pelota, hay un coleccionable. Sin embargo, todo lo que puedo expresar en lenguajes orientados a objetos, o al menos eso parece, son relaciones estrictas HAS-A . Eso se hace a través de las variables miembro. No puedo comenzar ball
y dejar que haga lo suyo, necesito que pertenezca permanentemente a otro objeto. He configurarlo de manera que el objeto principal del juego tiene una caja, y la caja a su vez tiene una bola, y tiene un contador de puntuación. Cada objeto también tiene unupdate()
método, que calcula la posición, dirección, etc., y sigo un camino similar allí: llamo al método de actualización del objeto principal del juego, que llama a los métodos de actualización de todos sus hijos, y ellos a su vez llaman a los métodos de actualización de todos sus hijos. Esta es la única forma en que puedo ver para hacer un juego orientado a objetos, pero siento que no es la forma ideal. Después de todo, no pensaría exactamente que la pelota pertenece a la caja, sino que está en el mismo nivel e interactuando con ella. Supongo que eso se puede lograr convirtiendo todos los objetos del juego en variables miembro del objeto principal del juego, pero no veo que eso resuelva nada. Quiero decir ... dejando de lado el desorden obvio, ¿cómo habría una manera para que la pelota y la caja se conocieran , es decir, interactuaran?
También está el problema de los objetos que necesitan pasar información entre ellos. Tengo bastante experiencia escribiendo código para SNES, donde tienes acceso a prácticamente toda la RAM todo el tiempo. Digamos que está haciendo un enemigo personalizado para Super Mario World , y desea que elimine todas las monedas de Mario, luego simplemente almacene cero para abordar $ 0DBF, no hay problema. No hay limitaciones para decir que los enemigos no pueden acceder al estado del jugador. Supongo que esta libertad me ha echado a perder, porque con C ++ y similares a menudo me pregunto cómo hacer que un valor sea accesible para otros objetos (o incluso globales).
Usando el ejemplo de BoxPong, ¿y si quisiera que la pelota rebotara en los bordes de la pantalla? width
y height
son propiedades de la Game
clase,ball
tener acceso a ellos. Podría transmitir este tipo de valores (ya sea a través de los constructores o los métodos donde se necesitan), pero eso me grita una mala práctica.
Supongo que mi principal problema es que necesito que los objetos se conozcan, pero la única forma en que puedo hacerlo es mediante una jerarquía estricta, que es fea y poco práctica.
He oído hablar de "clases de amigos" en C ++ y sé cómo funcionan, pero si son la solución final, entonces, ¿cómo es que no veo friend
palabras clave vertidas en todos los proyectos de C ++ y cómo es que Qué concepto no existe en todos los lenguajes OOP? (Lo mismo ocurre con los punteros de función, de los que acabo de enterarme recientemente).
Gracias de antemano por las respuestas de cualquier tipo, y nuevamente, si hay una parte que no tiene sentido para usted, hágamelo saber.