Diario de un intento de desarrollo.

Responder
Publico esto aquí ya que EOL es el foro que frecuento con mayor asiduidad y donde me siento más cómodo. Aunque soy consciente de que los hilos en este subforo no suelen tener mucha actividad, pero con un proyecto tan en pañales prefiero publicar cosillas aquí y en el futuro ya se verá.

Pues aprovechando el tiempo libre yo y una amiga hemos decidido aprender a hacer un juego, cada uno se dedicará a aprender una cosa (modelar, programar etc). Hemos estado mirando varios motores como Unreal, Unity y Godot, pero finalmente nos hemos decidido por Unity,.

En principio lo que queremos hacer es un juego de terror con vista isométrica con un estilo grafico low poly, creo que es algo sencillo para ir aprendiendo y siempre me a hecho ilusión hacer un survival horror por ser uno de mis géneros favoritos. Las mecánicas a implementar serán las típicas de este genero, gestión de inventario, recoger objetos, resolver puzzles y eso, no vamos a reinventar nada vamos, pero son las típicas cosas que siempre me han gustado de los juegos tipo Resident Evil.

En cuanto a la historia, la tenemos parcialmente pensada, aunque prefiero no profundizar demasiado en este tema por si surgen cambios (y porque me da vergüenza), tenemos pensado que transcurra en un hotel al que llegas siguiendo una pista de un caso de desaparición. Con los escasos conocimientos que tenemos intentaremos darle la mejor ambientación que podamos.

Imagen
Primer prototipo.

Imagen
Segundo prototipo.
Mucho ánimo y suerte con el proyecto, ya nos irás informando de cómo avanza 😉
@AzaToch

Pues ciertamente, este subforo no tiene apenas actividad, pero yo lo visito semanalmente por si hay alguna novedad.
Estará muy interesante ver vuestro progreso, tanto si es bueno como si encontráis dificultades, que las habrá por el camino.

Quizá os diría que, si es vuestro primer juego y sois absolutamente novatos, un sistema de inventario y su gestión es de lo más difícil que os podéis encontrar.
Si mantenéis el juego simple, las posibilidades de llevarlo a buen puerto aumentarán exponencialmente.

Estaré encantado de leer vuestros progresos.
@prizzio @gambapaketera

Gracias por vuestros ánimos, este mundillo es duro pero vamos tirando, y si, ya hemos tenido unos cuantos problemas y los que quedan [+risas], prácticamente con cada paso que das te encuentras con un muro pero ya sabiamos que esto no iba a ser fácil. En un futuro post detallaré lo que hemos ido haciendo con alguna screen.

Por cierto gambapaketera sigo el hilo de tu juego desde hace tiempo, antes de que empezases a hacer el juego de la escuela incluso, me parece muy interesante todo el trayecto que has ido tomando, espero que sigas con el juego y te vaya todo bien [beer].
@AzaToch Sí, todo bien, no lo he sacado por problemillas personales que me han tenido algo ocupado, pero el juego está prácticamente terminado a falta de toquecitos finales. Pasé una semana haciendo una última pasada de optimización y ahora queda traducción, integración de menús del DLSS y un par de opciones gráficas y la traducción.

Hasta un juego así de pequeño (un único nivel, mecánicas sencillas, sin historia etc. ) lleva meses de desarrollo.

Volviendo a lo vuestro. Todo lo que pongáis lo devoraré jejeje
Creo que habéis acertado con Unity por el estilo de juego que tenéis. Yo hice cositas con Unity allá por el 2009, hasta hice unos tutoriales para hacer un arkanoid :P

Dadle duro y mostrad cosas!!
Un abrazo!
Bueno, voy poniendo algunas cosillas que se han ido haciendo, a ver si se explicar las cosas con claridad [+risas].

Después de poner la típica capsula por ahí moviéndose para ir teniendo algo de movimiento tocaba ir preparando lo que será el sistema de combate, después de barajar varias ideas al final decidimos que será con un sistema de target automático, vamos que al pulsar un botón el personaje rote automáticamente hacia el enemigo mas cercano y se mantenga mirándolo mientras pulses, de ejemplos estuve mirando juegos como Silent Hill 3 y Parasite Eve 2.

Para lograr esto, que será de lo más sencillo del mundo pero a mi me costó lo suyo, tuve que darle mil vueltas para conseguir un resultado que me gustase, pero resumiendo, lo que hice fue crear un cono que representa el rango de visión del personaje, los enemigos que están dentro de ese rango son añadidos a una lista:

Imagen

Para así poder acceder al gameobject del enemigo y realizar lo que sea necesario, en este ejemplo será rotar hacia su posición:

Los cubos representan los enemigos y la bola el enemigo seleccionado.
Imagen

Después de eso, como me veía venir que seguramente pasarían cosas como seleccionar enemigos a través de las paredes y cosas del estilo, añadí un raycast que se ocupa de saber que enemigo es seleccionable, por lo que si el enemigo está detrás de un collider debe seleccionar otro enemigo que si esté a la vista:

Imagen

Seguramente habrán mejores formas de conseguir esto pero después de darle vueltas así es como me a funcionado, ahora falta seguir añadiendo funciones como el disparo y todo eso.

Y de momento poco más, a sido una semana de estar 24 horas haciendo esto prácticamente... [+risas].
Iré actualizando una vez a la semana siempre que tenga alguna cosilla que compartir, gracias a todos y feliz navidad!.
Poca actividad hay.
Y no sé, cuando hice Resident Evil Demake como no tuve problemas en otra sección, hace bastante tiempo.
Pero lo tengo reciente.

Fue hace casi 10 años,
siempre he usado Rpg Maker 2003 que va por eventos, llevaba años editando gráficos para rpgs tipo snes y quería ponerme con pixel art sencillo.
Al principio iba a ser un juego tipo Sweet home, con combates tipo Rpg.
Pero acabé haciendo por eventos
el tema de disparo-accion, hice los menús, (primero hice un croquis)
También una base de datos con cada objeto/cantidad. El baúl, los ordenadores del laboratorio, y el resto de puzles.

Yo no sé programar en ningún lenguaje, simplemente me paraba a pensar y lo diseñaba según la teoría conforme avanzaba.
Mis planes eran dibujar viendo los escenarios del juego original.

Vamos, entre lo que hice y los plugins que añadí como un pathfinder, que usa el algoritmo A+ si un enemigo quiere llegar hasta ti sin atascarse, quedaron pocas cosas propias del motor y creo que estuve con ese proyecto 6 años, a ratos.
También hice chiptune de la música.
Vaya locura 🤣

El de PSX lo miré a fondo, lógicamente.
También cosas de la memoria, no sabía lo de la aleatoriedad de la vida de los zombis.
Cada vez que entras a un cuarto, la vida del zombi es aleatoria en un rango.
Así que a veces, es más difícil.

No sé hasta qué punto se hizo que fuese aleatorio, si hay eventos que influyen o no.
Puede que esté todo bien documentado.
@AzaToch

Me gusta esa mecánica del raycast. ¿Podrías expandir un poco más su funcionamiento?

Entiendo que da igual que el enemigo esté muy escorado a izquierda o derecha, no?

¿Cómo evitas que no seleccione a un enemigo que esté en la misma habitación pero tenga delante a lo mejor una mesa y el raycast "falle?

¿Lanzas el raycast antes o después de intentar seleccionar al enemigo?

Me está gustando mucho cómo estás planteando el juego, desde la base. Sí señor.
@gambapaketera

Voy a intentar explicar algunas cosas, pero tened en cuenta que puedo estar equivocado porque me falta mucho recorrido aun, lo digo para que nadie se tire de los pelos si digo algo que esté mal [+risas].

En principio no debería de haber ningún problema con que el enemigo vaya inclinado, al raycast no debería afectarle ni la rotación ni la inclinación del objeto, el mayor problema que se me ocurre es que usando este sistema rotes el personaje para que mire hacia el centro del enemigo y este vaya de cintura para arriba inclinado (suponiendo que te refieras a esto), por lo que si usas un objeto para representar una bala que debe impactar en el enemigo para que reciba daño, la bala pueda pasar por su lado sin darle, para que esto ocurra debería tener el collider muy ajustado claro, aunque tampoco quedaría bonito que las balas dieran en el aire xD.

Sobre el tema de mesas, sillas y cosas que puedan obstaculizar al raycast es un tema delicado la verdad, al menos con lo que se ahora mismo. Hasta donde yo se, los personajes deben tener el pivote en el centro de sus pies, cuando tu disparas un raycast hacia el transform de ese personaje irá hacia el pivote, que está en el suelo, entonces si hay cosas por en medio el raycast puede colisionar en esos objetos y no dejarte targetear al enemigo, hay varias soluciones que se me ocurren:

- Disparas el raycast a nivel del suelo y ajustas los colliders para que no toquen el suelo, entonces el raycast pasará por debajo sin problemas.

- Disparas el raycast por encima de esos muebles y pones un hijo al enemigo que también esté por encima de los muebles, entonces apuntas a ese objeto en vez de al enemigo en si.

- Filtras con layers los muebles que no te interesen.

- Creas el escenario de tal manera que no puedan darse esas situaciones.

También dependerá mucho del juego de cada uno, en mi caso por ejemplo, tendremos enemigos pequeños como ratas y eso, por lo que poder targetear a una rata que está detrás de una silla dará lugar a que al disparar, la bala colisione contra la silla, aunque esto igual no queda mal del todo.

Al final es usar un poco la imaginación para conseguir que quede lo mejor posible, aunque seguramente alguien que sepa más del tema estará pensando en que vaya cacao acabo de montar [qmparto].

Sobre el ultimo tema, tal como lo tengo ahora montado, ya que voy haciendo cambios según se me ocurren, funciona así:

Al apuntar se activa el cono, los enemigos que estén o entren dentro del cono son añadidos a una lista, entonces se dispara un raycast por enemigo para detectar cual es el más próximo al personaje, el más próximo se añade como enemigo seleccionado y el personaje rota hacia su posición. Todo esto está sujeto a cambios según lo vaya viendo en movimiento, seguramente me dará problemas que ahora mismo no imagino xD.

@Gadesx

Sobre lo del rpgmaker, me acuerdo que hubo un tiempo que cuando visitaba tu web me quedaba leyendo las actualizaciones que ponías sobre el demake, la verdad es que tiene que ser difícil montar todo eso en un motor tan limitado para ciertas cosas.

Aun tengo pendiente pasarme el Wild Arms 2 y el Baten Kaitos Origins con tu traducción [tadoramo], a ver si me quito backlog de encima y me pongo a ello.
@AzaToch Me refería a qué pasaría si el enemigo estuviese escorado, por ejemplo como en esta imagen:

Imagen

La verdad, cuando yo tocaba Unity no hice nada de este estilo, por lo que no sé cómo funcionan los raycasts, pero te comento cómo va en Unreal, debe ser muy similar.

Hay canales de colisión. Por defecto los raycasts en Unreal (que se llaman en blueprints LineTrace y en C++ SweepSingleTrace) van a "preguntar" si se está chocando con el canal especificado. Por defecto, el canal es o bien de visibilidad o bien de cámara.
Todos los objetos en escena van a tener estos dos canales (se pueden desactivar), pero se pueden crear canales propios. Por ejemplo, crear un canal de colisión llamado "Enemy" y el raycast sólo "preguntará" por ese canal. Además, puedes hacer tu raycast ignore ciertos elementos (como mobiliario), traspasándolo.

Viendo la documentación de Unity, puedes hacer todo lo que comento, los layer masks para ignorar los muebles te solucionarían la papeleta. Y tal y como veo en tu imagen, ya estás lanzando el raycast desde el centro de tu cápsula recto al centro del enemigo, estaría perfecto.

Es apasionante cómo para una cosa tan simple empiezan a salir problemas a poco que te preguntas "y qué pasa si...?"
Siempre lo digo, la gente que no desarrolla piensa que implementar la mecánica de (por ejemplo) sprintar es cosa de dos minutos (que sí, que lo es).

Pero luego, qué sucede si te agachas y le das al botón de sprintar? vas a correr? se va a activar la animación mientras estás agachado?
Si no lo has tenido en cuenta, seguramente saldrán cosas raras, intentará mantenerse agachado corriendo, o correrá pero luego no podrás agacharte de nuevo etc.
Y ya si luego haces que recargue el arma, qué sucede si a mitad de animación sprintas? y te agachas y sprintas? y si a mitad de animación de recargar cambias de arma?

Es todo un cacao de pelotas y hay que organizarlo muy muy bien y estar muy atento a los detalles.

Lo dicho, te está quedando un hilo muy chulo :)
@gambapaketera

Si está donde has marcado simplemente rotará hacia esa posición, te dejo un gif aunque vaya a pedales para que lo veas:

Imagen

Piensa que la línea azul no es el raycast, igual debí especificar eso antes [+risas], esa línea la puse simplemente para ver que todo quedaba mas o menos alineado, los raycast son las líneas blancas.

Y yo también pienso que la mejor solución es usar layers, o canales como los llaman en el unreal, eso junto a hacer el mapa con un poco de cabeza creo que será suficiente.

Lo de las mecánicas la verdad es que implementar algo así normalito no es difícil, el problema como tu dices viene cuando se mezcla con otras mecánicas y todas deben responder bien entre si, ahí empieza lo gracioso xD.
@AzaToch Aaaah, vale vale, detectas al enemigo y lanzas el raycast a su posición para ver si hay algo por medio.

Entiendo que no eres nuevo en esto de programar, no? Alguien que parte desde cero no suele tener este pensamiento tan claro. Hablas de "escasos conocimientos", pero igual es prudencia (que nunca viene mal) por tu parte.
Pues igual no lo parece pero voy aprendiendo sobre la marcha, aunque la ventaja que tengo en comparación de alguien que empieza completamente desde 0 es que he leído y visto a mucha gente por youtube explicando como montan su juego, lo que me ayuda mucho a imaginarme como tengo que montar algo, así que por ejemplo si quiero montar esto del target pues conozco los raycast de algún video donde alguien lo usaría en su juego, pero luego tengo que ponerme a mirar la documentación y ver algún tutorial para ver como se usa de verdad [+risas].

La verdad es que es un tema que siempre me a dado curiosidad, pero poniéndome ahora a hacer un juego veo que voy a hechar mil horas para hacer algo que otros hacen en un momento, con esto del target llevo mas de una semana ya... Espero que llegue el día que escriba código como escribo normal aquí en el foro [qmparto].
Yo estoy con el pixelart ahora mismo en una situación que es similar,
porque reviso sprites de personajes para adaptarlos mejor de arcade a una resolución menor
y aunque no son de cero, un frame me puede llevar hasta 1 hora, o incluso más si es grande el
sprite. No me suelen creer, pero es así al menos mientras aprendo, [+risas]
Con mayor resolución la curva de tiempo para hacer algo se dispara.

Pero estoy aprendiendo con ello, por eso me puse, y porque me gusta el juego donde
luego se muestra y manejo a los personajes.
Claro que esto lleva a que empiecen a pedirme cosas otros, pero no puedo darme
ese lujo de ir echando un cable a todo el que me lo pide.
Los que controlan de verdad de esto, no lo hacen gratis.
Y si es por hobby debe haber alguna motivación, como gustarte el juego.
Bueno, en primer lugar, espero que estéis teniendo un buen inicio de año [beer].

Sobre el tema del desarrollo, hemos avanzando un poco, para empezar mi compañera ya tiene listo el personaje protagonista, tiene varios accesorios que se pueden poner y quitar, por ejemplo un chaleco antibalas (en el gif se puede ver) y las cartucheras para poder equiparlos cuando el jugador los encuentre. Sobre el rig me estuvo comentando que le costó bastante aprender a hacerlo pero cuando me lo explica no me entero de mucho porque no es mi tema y me suena todo a chino [+risas].

Imagen

Del sistema de disparo aun queda mucha faena pero mas o menos empieza a ser funcional, tengo que mejorar algunas cosas como el cambio de target que ahora mismo se hace pulsando un botón, pero por ahora no me da para hacerlo de otra forma, también tengo que añadir una bala que salga al disparar ya que ahora el daño se hace directamente al pulsar el botón de disparo.

Me he montado un pequeño "campo de tiro" para ir probando las cosas:

Imagen

También le estamos dando vueltas al tema de la cámara, ya que al estar mirando en diagonal no se pueden aprovechar muchas paredes y en principio no queremos rotar la cámara, así que seguramente la pongamos mirando de frente, en tener alguna toma pondré alguna fotillo para comparar.

Y de momento poco más, ahora seguramente me ponga a intentar hacer el inventario para variar un poco y no quemarme con lo mismo.

Muchas gracias por tomarte tu tiempo en leer hasta aquí!, voy a ver si me puedo dormir que son casi las 4 de la mañana y no dejo de darle vueltas a esto [qmparto].
Yo usé en resident evil demake un plugin
que hace uso de lo que es un pathfinder, buscador de caminos,
tras hablarlo con un amigo programador, me contó que usaba dicho plugin
el algoritmo A++

Lo puse en enemigos para que llegasen hasta el personaje, sin atascarse.
Los disparos en 2D son más sencillos, dos ejes a tener en cuenta.

Hice IDs de evento que eran enemigos, cálculo de distancia y dirección.
El sistema que usé de base no tenía definidas las propiedades.

Recuerdo disparar a un enemigo, (cuando venían 2 hacia mí) y el impacto le llegaba
al de atrás. Porque tenía una ID como evento menor y tomaba prioridad.
Quité eso, el más cercano por cálculo recibía daño ya,
no recuerdo si llegué a hacer algo de dispersión, cosas como
que una escopeta impacte a varios si es de cerca o haga más daño.

Todo lo de menús del Resident evil 1, y los puzles, los fui haciendo,
era la primera vez que me ponía con algo así,
empecé con un croquis y una base de datos antes de meter cosas.
Lista de objetos, categorías, si se puede combinar, etc.

Lo pillé con ganas [carcajad]
gadesx escribió:Recuerdo disparar a un enemigo, (cuando venían 2 hacia mí) y el impacto le llegaba
al de atrás. Porque tenía una ID como evento menor y tomaba prioridad.


Eso con un poco de imaginación lo cuelas como que el disparo atraviesa enemigos [carcajad]

Supongo que para hacer el inventario el rpg maker te da ciertas facilidades no?, yo es que estaba pensando ahora en como tendría que ser y por ejemplo para almacenar la munición es un follón, porque tienes que detectar si tienes stacks con espacio para guardar la munición ahí, y en caso contrario crear un stack nuevo, eso siempre que tengas espacio en el inventario claro, y también se puede dar la situación de que tengas el inventario lleno pero tengas un stack donde puede entrar una bala, asi que tendrás que coger una bala de la munición del escenario y dejar el resto para que el jugador lo pueda recoger después [mad], y aun no me he puesto ni a pensar como tiene que ser para combinar objetos, miedo me da xD.
Pues para hacer algo personalizado en rpg maker como hice yo, no pude usar nada
del menú interno, quizás por detrás podía haber puesto algo,
como ver en el menú un cargador con 15 balas y que detrás estuviese la base de datos del maker
que ya detecta que es único y la cantidad que puedes llevar, pero no usé nada.
Solo usé la vida del personaje, aunque los números no se muestran jugando,
con un % mostraba el estado en el menú a base de imágenes en un ciclo.

Hice todo a mano, y no facilita mucho las cosas.

Por ejemplo, yo tenía hecho el menú con valores, es decir
Cada posición era una ID como variable, que podía contener x cosa

0--1
2--3
4--5
6--7

Si en la posición del menú 0 tenía la pistola, y en 1 tenía un cargador, al darle a combinar,
se ejecutaba un proceso que calculaba
- El arma tiene menos de 15 balas = se puede recargar
- - El cargador tiene x balas =
---Iniciaba un loop de pasar balas 1 a 1, (ni hice cálculos mejores)
---- Se rompe el loop cuando el arma está cargada con 15 balas, o no quedan balas en el cargador.
Luego ejecutaba un proceso que limpiaba todo y reordenaba el menú.

El problema del maker, pues que si haces las cosas fuera de lo normal, te comes mil ralladas.
Tenía que poner,
Si la pistola está en 0 y el cargador en 1-2-3-4-5-6, independientes.

Es decir, cualquier cosa que combinase debía ponerla en todo orden posible y llamarlo.
Me ayudó un programa que hizo cherry, un programador alemán,
permitía pasar una selección de eventos enorme y cambiar valores, así iba
cambiando los valores de una variable por la de otra posición de golpe, y no una a una.

Años después vi que tenía algún bug el menú, ya que las cantidades de los objetos las añadí
después de todos los tipos de armas, y el proceso que reordena los objetos no tiene en cuenta
el valor cantidad de una posición. Podías gastar una hierba al inicio del inventario y otra cosa podía tener
la cantidad de "un cargador" que reemplazase su lugar, digamos.
Seguramente se puede arreglar en un momento, si recuerdo las cosas [+risas]

Me puse a hacer otras cosas y lo dejé como una beta.

PD: Las cosas cambiaron bastante desde entonces,
antes yo usaba Rpg maker 2003 con dynrpg, es decir, el editor no original, y con parches.
Solo funcionaba en windows.

Tiempo después, Degica quería sacar Rpg Maker 2003 en steam, pero habían perdido el código
fuente, así que contrataron al que he mencionado, cherry, y añadió de todo. (Lo tengo original)
A la vez, avanzó a pasos de gigante Easyrpg player, que aunque no esté el editor hecho, si
puedes lanzar un juego, no es compatible con ciertas cosas de dynrpg, pero el juego se
puede cambiar un poco y el player funciona en muchos sistemas, está hasta en retroarch como core.
Y en steam hay varios juegos publicados que lo usan.
Pequeño update.

Se a terminado de implementar un laser para las armas, en el gif anterior podía verse pero aun le faltaban detalles, ahora reacciona a las colisiones para adaptar el tamaño según convenga, también se a añadido un decal en el punto de colisión para simular el punto del laser:

Imagen

Por la parte del apuntado, como vamos a tener enemigos de diferentes tamaños el personaje debe apuntar hacia arriba o abajo según la altura, para ello he usado el addon animation rigging de unity para añadir pesos a los huesos y poder inclinar el personaje, mientras buscaba información sobre el tema también vi que se podía hacer con un blend de animaciones pero como ya estaba liado con esto seguí adelante, más adelante según lo vaya viendo en funcionamiento ya veré si lo cambio o se queda así:

Imagen

Y de momento ya está, para próximas actualizaciones dejaré de sacar los gifs/fotos en el escenario de prueba y empezaré a enseñar algo de chicha, ya está bien de cubos xD.
@AzaToch
Ya echaba yo en falta nueva info de todo esto :)
Vas por el buen camino, sí señor.
Luego todo esto, cuando hagas otro proyecto, es camino ya andado y lo harás casi sin pensar, y lo que han sido semanas de investigar, en un par de tardes te lo has quitado.
Pero desde luego, para ser un primer proyecto, da la sensación de que tienes más bagaje del que comentas.
Enhorabuena
Lo de bueno de Unity es que hay tutoriales para casi cada cosa, así que voy tirando de eso y de algunos cursos que he pillado, mi intención este año es aprender a programar medianamente bien, o al menos llegar al punto de no tener que mirar un tutorial para cosas simples.

Me alegra que parezca que tengo ya tengo algo de experiencia la verdad, si me vieras haciendo las cosas y la cantidad de bugs que veo al día no pensarías lo mismo [+risas], pero bueno, como dije anteriormente si que conozco bastantes cosas del mundillo de haberlo visto de otros, antes de ponerme ya sabia lo que era un for, un switch, las variables etc pero nunca lo había puesto en practica, aunque ahora me facilita aprender más rápido, o como poco toda esa parte me la puedo saltar, aun así me frustro casi cada día por no acordarme de algo que ya había hecho.

Edit:

No me deja crear otro post así que edito este, finalmente me he puesto con el inventario, de momento no tengo gran cosa, ni siquiera una interfaz, pero al menos ya puedo coger algunos objetos y verlos en el inspector, parece una tontería pero me hace ilusión, para hacerlo he usado una lista y scriptable objects, con lo aprendido con las listas de enemigos no a sido muy difícil hacer algo parecido pero con objetos, y con el scriptable object almaceno toda la información que necesite sobre el objeto.

Imagen

Imagen

Aunque con el nombre de los objetos y la descripción tengo un problemilla, si escribo directamente en el campo solo puedo hacerlo en un idioma, y si el juego tiene 2 idiomas tengo que poder cambiar entre uno y otro.
AzaToch escribió:Aunque con el nombre de los objetos y la descripción tengo un problemilla, si escribo directamente en el campo solo puedo hacerlo en un idioma, y si el juego tiene 2 idiomas tengo que poder cambiar entre uno y otro.

Para la localización en Unity tienes este paquete. No sé si lo estás usando, pero puede serte útil.

https://docs.unity3d.com/Packages/com.unity.localization@1.5/manual/index.html

¡Ánimo!
@Sr.Esputos Que va, pensaba que me iba a tocar hacerlo por mi cuenta, pero si unity ya tiene un asset para esto mejor, me lo apunto para echarle un ojo cuando empiece a poner texto, gracias [tadoramo].

Más novedades, ya tenemos el primer enemigo, la pedazo de rata [carcajad]

Imagen

Te la podrás encontrar en sitios como el sótano y en escenarios de ese tipo, de momento la he colocado por las habitaciones para ver que tal quedaba.

Como comenté en post anteriores la cámara en diagonal no nos terminaba de convencer porque perdías una pared y el escenario se veía muy vacío, se podía solucionar dejando que el jugador rotase la cámara pero viéndolo ingame no me quedaba muy bien, así que fijándome en el Signalis hemos decidido probar el mismo enfoque y el resultado me gusta más.

Imagen
Una habitación nueva con assets nuevos que le dan más vidilla.

Con este resultado estoy muy contento la verdad, le hemos dado mil vueltas, incluso llegamos a plantear el poner cámaras estilo resident evil clásicos pero era una faena estar buscando ángulos donde quedase bien, los que lo hacen en sus juegos tienen todos mis respetos. Los modelos también se han mejorado, comparando con la primera foto que puse la verdad es que me gusta mucho como está quedando ahora.
@AzaToch

Pues aunque estos hilos se vean poco, aquí tienes a uno que lo acaba de descubrir y que estará encantado de leer tus adelantos.

En la época de confinamiento me dio por "jugar" un poco con Unity y estuve haciendo un pequeño proyecto de juego en scroll lateral 2D. Proyecto muy pequeño y que no terminé... [triston] Pero bueno, era más para pasar el tiempo que otra cosa. Lo estuve haciendo con 0 conocimientos de Unity y de programar, pero aun así, siguiendo algunos tutoriales se pueden conseguir cosas interesantes. Un chico al que recuerdo haber visto bastantes videos en youtube es Luis Canary. Tiene muchos tutoriales (Unity y otros motores) y me pareció que explicaba las cosas muy bien y de manera muy sencilla. Por lo que leo en tus comentarios tienes una base bastante buena, y quizás estos vídeos que te comento se te queden algo cortos, pero si no conocías a este muchacho te recomiendo que eches un vistazo a algunos de sus videos.

Lo dicho, encantado de leer tus futuros adelantos.
@joke747 Encantado de tenerte por aquí siguiendo los avances, estos días no he vuelto a poner nada porque estoy volcado con el inventario y hay mucha cosa nueva que no conocía aun.

La verdad es que si, siguiendo unos pocos tutoriales puedes ir empezando a hacer alguna cosilla, lo bueno que tiene C# y Unity es que es agradecido con los novatos y con pocos conocimientos puedes ir haciendo algún juego básico, a partir de ahí es ir ampliando conocimientos (cuidado con los Quaternions [mad]).

El youtuber no lo conocía, a ver si le echo un vistazo en tener un rato, aunque sean cosas básicas siempre va bien repasar, a veces descubro cosas que pasé por alto.
Mucho ánimo. Aquí hay poca actividad en estos hilos. Yo empecé hace "poco" también al desarrollo de juegos. Aunque yo godot. Que tal la curva de aprendizaje de Unity?
@Satoru Gojo De momento está siendo relativamente fácil, tampoco me he metido a hacer algo demasiado complejo. En tener Unity más o menos dominado me gustaría volver a probar Godot, estuve trasteando con el antes de empezar este proyecto, (o fue después, ya no me acuerdo xD), y no era capaz ni de sacar un cubo.

Para que no quede tanto post sin enseñar chicha pongo un pequeño video con el sistema de recoger objetos y la primera sala segura, de momento está sin terminar, faltaría añadir algún fundido o algo para que no aparezca de golpe y alguna cosilla más, pero como ya es funcional de momento se va a quedar así y ya iré añadiendo detalles más adelante.

26 respuestas
Responder
Volver a Desarrollo