Ya lo he probado, ha mejorado bastante, en cuanto a control, pero creo que todavia le queda un poco, yo le pondria un sistema por turnos pero en tiempo real y algun tipo de control para que no se bloqueara.. es decir, si te descuidas, te echa al fondo, y de ahi no sales, pero puedes darle igual y ganas, imagino que luego al ser mas dificil, ya no ganaras tan facil.. Por eso digo lo de los turnos, es decir, que uno ataque, que se vea que este atacando y luego tenga que descansar o algo asi.. Y por otro lado, si detectas que alguno se queda en el fondo poner algo, para volver a los jugadores al centro...
Viewing post in no todo es lo que parece jam comments
No es Unity eso, esta mas unido a la programación y al control de estados. Yo lo hago casi todo con lo que se llama maquina de estados. Unity va con objetos, pues en cada objeto tengo una variable, que es el estado de ese objeto. Luego agrupo los objetos y tengo otro objeto, con otra maquina de estados, que controla ese grupo, y estos grupos, los agrupo, hasta tener un objeto que controla todo con estados. Lo de los estados es por ejemplo, al inicio, estadodeljuego=0, reinicio todas las variables pongo la imagen inicial y pasa a estado 1, que en espera del que jugador pulsa una tecla, y cuando pulsa la tecla pasa al estado 2, y pone el menu y pasa a estado 3, que es esperando a que el jugador elija una opcion del menu. Elige jugar, pasa a estado 10, por ejemplo, elige opciones, pasa a estado 20.. y asi con todo.. luego el propio juego tiene sus estados igual, estado 0, inicio juego, estado 1, jugando, estado 2, pausa, estado 3, game over, etc. eso es a tu gusto, puedes poner cada numero un estado y que haga ciertas cosas, teniendo en cuenta que hay estados que hacen cosas y otros de espera.. porque si los pones juntos se traba. Es decir, siempre despues de un cambio, un estado de espera que no haga nada.. Esto en codigo, es crear una variable estado, ponerlo a cero o al estado inicial en el start y el update hacer un switch con la variable estado y luego hacer lo que toque en cada valor.. Luego es llamar desde unos objetos a otros, cambiando esa variable estado.. Por ejemplo, el que lleva todo el juego, incluyendo menus, gameplay, sonido, todo.. ese debe tener acceso a cambiar los estados de los grupos generales.. Luego tendras una maquina de estados para los menus, otra para el sonido, etc.. Y el primero, el general, por ejemplo, si cambias al menu, le cambia el estado al que lleva los menus y el sonido.. y se queda a la espera.. con un estado que no haga nada.. En tu caso, que los muñecos tenga un estado ataque, otro estado defensa, otro estado pausa.. cuando el jugador toca una tecla de ataque le pones el estado a ataque.. y el jugador ataca... Y con esto puedes crear estados especiales.. aunque muy parecidos, pero diferentes, por ejemplo, si el jugador pulsa la tecla de ataque, pero los jugadores estaban en cierto estado, o el enemigo en un estado concreto, puede que cambies a un estado distinto a si tuvieran otro s valores.. O que uno general controle todo esto, por ejemplo, un o que controle las batallas por estado si detecta que el jugador esta encajonado en una esquina, le cambia el estado al jugador, y ya el jugador se quita de ahi...
Las animaciones en Unity funcionan un poco asi, cada animacion es un estado.. y cambian segun cierto valores de estado... Por resumirlo, y perdon por el ladrillo. Es crear una lista de acciones que hace ese objeto, o elemento y numerarlas, y pasar de una a otra desde otro objeto que controle a ese elemento y a otros. En lo que presente a la jam, el estado 0 era la frase del principio, el estado 1, el menu principal.. el 2 cuando pulsaba una tecla y pasaba al 3, el juego en si, y el 3 iniciaba todo, lo reseteaba y ponia los valores a los muñecos, las frases, etc.. y pasaba al 4 en espera.. el 4 esperaba a que los muñecos llegaran a su sition, y pasaba al estado 5 que ponia las frases y paraba los muñecos y ponia los menus para elegir, y pasaba al 6 a la espera que el jugador pulsara algo.. el 6 miraba si pulsaba izq y derecha y movia el rayo.. y si pulsaba el boton de destruir, pasaba al estado 7, que quemaba a un muñeco y el otro andaba a la salvacion, y pasaba al estado 8, a la espera que el jugador se queme y el otro salga, y entonces, pasaba al estado 9, en el nuevo comprobaba si ya habia acabado el juego, si no habia acabado, volvia al estado 3, si ya habian salido todos, pasaba al estado 10, donde ponia el final de juego...
Este es mas o menos sencillo, en mi juego del ahorcado, tengo el general, yo le llamo controljuego, pero normalmente le llaman gamemanager.. que es el general, que si lo use en la jam, pero en mi juego, tengo uno que maneja los menus por estados, otro para el sonido, otro para las plataformas que salen, otro para los muñecos animados, y luego cada uno de estos , manejan a su vez, los objetos que tienen asociados.. es decir, el controlador de menus, tiene control sobre todos los menus, que cada uno de ellos tiene una maquina de estados.. Porque en mi caso, los menus se mueven, entonces tengo un estado para que el menu salga, otro para que se quite, etc..
Bueno, no me enrollo mas, y perdona, por la charla, cualquier cosa me comentas :D
wow, es dificil de entender, si te entendi un poco pero pronto te voy a entender un poco mas, por eso tengo que aprender un poco mas los basicos en unity para entenderte, si te he entendido como estado o gamemanager y sí lo haré, lo usé estado para la IA, en realidad la IA o la CPU tenían una animación de bloqueo pero no entendía por qué mi proyecto no funciona aquí, mientra el proyecto del tutorial de como hacer un juego de pelea en unity (en inglés, donde lo aprendí ahi) si funcionaba el bloqueo.
El tema de los estados, es usarlo, y cambiar de forma de pensar.. Plantearte todo como elementos independiente y pensar que tiene que hacer ese elemento u objeto. Por cada cosa que haga, un estado o dos. El motivo porque hay estados de cambio y estados de espera. En los primeros asignas variables y haces los calculos de ese cambio, y en los segundos esperas a que pase algo, o esperas sin mas. En tu caso, el muñeco, en la ia, tambien viene bien lo de los estados. Por ejemplo, estado inicial, estado calculo de posición, otro estado para el ataque, otro para la defensa , otro para el bloqueo, etc.. Y el objeto que maneje ese muñeco, le vaya cambiando el estado, según convenga... Lo de las animaciones, comprueba los condicionales, el del bloqueo primero y luego el resto, seguramente sea un equal, es decir, que dos estados, se cumplen a la vez, porque pusiste algo distinto al tutorial..
Yo he seguido esos tutoriales, y lo de lo estados, no se si te lo explica. Si te explica el gamemanager, como otro concepto. En los juegos, como te comentaba, tienes que tener manager para cada grupo de objeto. Por diferenciarlo, el gamemanager seria el general, pero el del juego lo llamare gameplaymanager, para diferenciarlo. Entonces al diseñar el juego, tienes que ir creando o pensando cuantos managers necesitas. Lo habitual es el general, el gamemanager que controla todos, y luego casi siempre hay un menumanager, para los menus y otro soundmanager para el sonido. Luego el del gameplaymanager, tambien, o tambien le llaman CoreManager. Cada uno de estos puede tener otros manager, tiene sentido usarlos por cada grupo de objetos o cosas que uses que esten relacionados, como los menus, los sonidos, las mecanicas de juego, etc.. Y dependiendo del juego necesitaras mas o menos managers. Entre ellos se pueden comunicar, pero lo correcto es que no se comuniquen en el mismo nivel de rango. Es decir, el gamemanager se comunica con todos los que te he dicho, y estos a su vez a los que controla. Resumiendo, que al final te queda un diseño como un arbol o una piramide, donde arriba tienes el gamemanager el que lleva todo y llama el resto, y controla al de sonido, a los de menus, al del gameplay, etc.. Estos a su vez controlan u otros gamemanager, o directamente objetos. Por ejemplo, el de sonido, tendra todos los objetos de sonido a su disposicion, para hacerlos sonar, el de los menus, lo unes a los menus, y el de gameplay, pues al protagonista, al enemigo.. o incluso puedes crear otros game manager, uno para controlar la lucha de los proganistas, otro para controlar el movimiento, otro para controlar los esenarios, otro para controlar los marcadores.. etc.. E igual, el de marcadores, debe tener a su disposicion, todos los objetos de los marcadores.. Aunque por ejemplo, puedes incluir esos marcadores en el manager que maneja los menus y poner los marcadores ahi..
Pero esto que te cuento , tampoco tiene que ver con el gamemanager de unity, son conceptos generales de programacion.. sobre el de unity, te paso este video:
hola TioTizo, vine para decirte que hice una actualización de mi juego especial fiesta (Party Special) que algunos bugs se ha solucionado pero otro que no pude agrega como game manager todavía debido que algunos scripts que antes me funcionaba ahora se esta dejando de funciona.
solucionado o agregar a game manager para soluciona esos problemas es algo complejo de hacer que requiere mucho cuidado, pero lo intentaré irme despacio.
cuando lo solucione esos scripts o me compre un disco duro (para hacer copia de seguidad) lo agregaré game manager que seguro me serviría para algo y reemplazaré algunos scripts por game manager, seguirá en pausa slingshot fighter y aprendiendo basico de la programación y hacer juegos pequeño.