Buenas, estoy intentando empezar un pequeño juego básico, el clásico de naves con scroll horizontal (tipo R-TYPE). Se llamará:
 
YOLIPAUN
 
El equipo lo formamos dos personas para todo, a ver qué tal 
 
Mi principal duda es...¿es "eficiente" usar la potencia de Unity3D para hacer un juego simple de naves en 2D? (Lo digo por no matar moscas a cañonazos...) 
 
La idea es algo parecido a la captura adjunta, que es un juego que empecé con Div Games Studio y estoy pensando retomarlo con Gemix Studio....o dar el salto a Unity3D.
 
Por lo tanto el estado del juego es Indefinido, en diseño....no sé.
 
Gracias.
 
Un saludo.
 

(tú eres el conductor, la excavadora es Unity y el perrito tu juego 2D)
 

 
 
 
tranquilo, aunque se llame Unity3D este engine está orientado tanto al desarrollo de juegos 3D como 2D, esto es, tiene un montón de clases específicas para trabajar en 2D. O sea que respondiendo a tu duda te diría que no temas, la herramienta también está pensada para lo que quieres hacer.

Cita de: musaranya date=1472033124(tú eres el conductor, la excavadora es Unity y el perrito tu juego 2D)
   
   
       tranquilo, aunque se llame Unity3D este engine está orientado tanto al desarrollo de juegos 3D como 2D, esto es, tiene un montón de clases específicas para trabajar en 2D. O sea que respondiendo a tu duda te diría que no temas, la herramienta también está pensada para lo que quieres hacer.
   

Justo has captado la idea que planteaba  Por eso digo, ¿no sería mejor hacer el perrito andando o en bicicleta (Gemix Studio por ejemplo o Game Maker) en lugar de usar la excavadora (que es más completa y permite hacer más cosas pero más complicada de manejar)?
 
Es que tampoco termino de entender cómo se hacen las cosas...veo que hay Escenas (que serán como los niveles, mapas, fases del juego), Assets (que aún no lo tengo claro, parece algo hecho aparte por cada programador) y en IDE parece más 3D Studio MAX que un programa para hacer videojuegos 
 
Decir que aparte de la experiencia (poca) programando videojuegos que comenté en mi presentación, llevo trabajando como programador (no de videojuegos) desde 2001, principalmente con PL/SQL pero también he tocado C/C++ y Java.
 
Gracias.
 
Un saludo.

Me parece bien lo que expones thurderon, pero ¿tu quieres jugar con el "perrito" toda la vida?. Si tu respuesta es SI, vale programa con algo más "simple" como planteas. Si la respuesta es NO, antes o después usarás Unity, pues mejor antes y ya vas aprendiendo. 


Unity (ya lo dirán mejor los expertos) tiene 2 partes (por decirlo de algún modo simple)


1) Diseño de escenas. Eso que ves como 3D Studio. 

2) Programación de script. Es C# o Js (mira lo que vienes haciendo hace años, programar)


- Las escenas las has definido muy bien, serían los niveles/mapas/fases. 

- Los Assets, serían objetos que pones en esas escenas, cubos, personajes, etc. Un cubo lo pones desde el mismo unity pero un personaje ya lo diseñan fuera en un programa de diseño (ya sea 3d o 2d).

- Los scripts es la parte de programación que haces en C#. 


Obviamente es un poco más complejo de lo que te digo y en 2D no hice nada por ahora.  Pero mirando tu pregunta yo si que entraría en Unity (para que programar en algo que no vas a usar más). Que además te sirve para aprender lo que creo que usarás en juegos más complejos. 
 
 
 
Saludos. 

 

Te recomiendo hacerlo en unity mejor que GameMaker o Gemix Studio, con unity puede que acabes encontrando trabajo en unos años si vas cogiendo nivel y te gusta este mundillo, el 90% de las ofertas de curro que veo son para Unity. Por otro lado también hay muchísima documentación y tutoriales. 
 
https://unity3d.com/es/learn/tutorials
 
Podéis hacer los 5 primeros (interface, scripting, graphics, audio y UI), y pasar luego directamente al space shooter. No creo que os lleve mas de dos semanas.
 
https://unity3d.com/es/learn/tutorials/projects/space-shooter-tutorial
 
 
 
saludos ^^

Yo te diría que utilices Unity. Te permite hacer bien lo que quieres y siempre podrás expandirlo o hacer cosas más complejas si te apetece. Además no olvides la ventaja de poder publicar en varias plataformas (PC, Android, iOS etc).
 
A modo de resumen muy muy muy resumido la cosa funciona así:
 
- el juego está compuesto de escenas, la acción se desarrolla todo el rato en 1 escena (sería como una fase o nivel del juego, o el propio menú inicial). 
 
- en una escena hay objetos, ya sean 2d o 3d. Son los que arrastras desde la biblioteca de assets (común a todas las escenas del proyecto) hasta la ventana de escena (lo del 3dmax que dices)
 
- cada objecto tiene vinculados componentes, los ves en la ventana Inspector cuando lo seleccionas. Hay unos básicos que "siempre" están (los necesarios para renderizar el objecto: en el caso de 3d la malla, el material, la "caja" para las colisiones ... cosa de esta). Y luego algo muy importante: scripts (siguiente punto)
 
- Cada objeto puede tener asociados de cero a varios scripts, programados en C# o JS. Estos scripts se suelen añadir al objeto en cuestión desde el propio IDE de Unity y él ya te crea una clase que hereda de MonoBehaviour, que es la clase base por excelencia de todo el tinglado. Estos scripts pueden contener lo que quieras (tienes "todo" lo de .NET a tu disposición) y también tienen todo lo heredado de MonoBehaviour. Lo más importante: el método Start() en donde inicializas las variables y el objeto en general; y el método Update(), que se ejecuta a cada frame. Es una descripción muy poco exacta y muy general, pero sólo es para que te hagas una idea. De MonoBehaviour heredas un montón de cosa...
 
- Un objeto que también tienes que tener en la escena es una Camara (es un tipo de objeto que se añade desde el menú). Puedes tener varias o ninguna pero a modo de resumen da igual. 
 
- Cuando le das al PLAY Unity pone en marcha la escena en la que te encuentras. Para cada cámara renderiza la escena. Renderizar consiste en pintar en pantalla todos los objectos que se ven (aquí entran las técnicas de culling para evitar no pintar lo que no se ve y un montón de cosas más, muy divertido de aprender). Además de pintar los objetos, también ejecuta el método Start() de todos los scripts presentes en la escena (y que tengan método Start), y a cada frame llama al método Update() de todos los scipts presentes. 
 
- Esto es una explicación muy básica, general, poco precisa y a la bestia, pero para que te hagas una idea de como va esta cosa creo que te puede servir.
 
- Visto esto ya te puedes imaginar tu juego de naves:
 

• 
     la cámara fija 
  


• 
     un plano de fondo que será un objeto de tipo Plane que pondrás en la escena y que tendrá un script asociado que a cada Update() "mueve el fondo" (no entro en detalle, hay 1000 maneras)
  


• 
     otro objeto entre la cámara y el fondo, que es la nave, y que tiene un script asociado que a cada Update() escucha los inputs (de teclado, mando, touch de la pantalla...) y mueve el objeto en consecuencia
  


• 
     y así ir tirando... (está el tema de instanciar proyectiles en runtime, las colisiones, etc... todo es ponerse)
  

En fin, que estoy en el trabajo y se nota que no tengo ganas de trabajar, menuda parrafada, perdón!
 
 
 
 
 
 
 
 

Gracias por las aclaraciones....me estáis animando a meterme en Unity jajaja. Eso sí, en Gemix ya tenía mucho aprendido y aquí sería aprenderlo todo de nuevo
 
Y las funciones "básicas" de videojuegos vienen ya implementadas imagino no? Mover objeto, escuchar teclado, reproducir sonidos/música, pintar una imagen...
 
 
 
De perdón nada, con la parrafada me has aclarado mucho

Cita de: thurderon date=1472040653Gracias por las aclaraciones....me estáis animando a meterme en Unity jajaja. Eso sí, en Gemix ya tenía mucho aprendido y aquí sería aprenderlo todo de nuevo
   
   
      Y las funciones "básicas" de videojuegos vienen ya implementadas imagino no? Mover objeto, escuchar teclado, reproducir sonidos/música, pintar una imagen...
   
   
       
   
   
      De perdón nada, con la parrafada me has aclarado mucho
   

Por supuesto, eso está todo hecho ya. La clase base MonoBehaviour ya te expone funciones al estilo OnCollisionEnter u OnMouseDown, y luego para detectar pulsaciones de teclas dentro de la función Update() de cualquier script metes algo así: if(Input.GetKeyDown(KeyCode.LeftControl)){...}
 
Otra cosa buena que tiene es el tema UnityAnswers. Es un foro muy activo dentro del portal de Unity donde allí la gente pregunta lo que quiere y te suelen responder bien y rápido. Ahí tienes un montón de conocimiento por si lo necesitas.
 
 
 
 

Cita de: musaranya date=1472044028Por supuesto, eso está todo hecho ya. La clase base MonoBehaviour ya te expone funciones al estilo OnCollisionEnter u OnMouseDown, y luego para detectar pulsaciones de teclas dentro de la función Update() de cualquier script metes algo así: if(Input.GetKeyDown(KeyCode.LeftControl)){...}
   
   
      Otra cosa buena que tiene es el tema UnityAnswers. Es un foro muy activo dentro del portal de Unity donde allí la gente pregunta lo que quiere y te suelen responder bien y rápido. Ahí tienes un montón de conocimiento por si lo necesitas.
   
   
       
   
   
       
   

Genial, a eso me refería, ese tipo de funciones habituales en la programación de videojuegos 
 
Veo que el foro que dices está en inglés...de momento no me manejo mucho, prefiero éste foro en español 

Cita de: thurderon date=1472040653en Gemix ya tenía mucho aprendido y aquí sería aprenderlo todo de nuevo
   

 
 
al final con unity se convierte en un ahorro xq no tienes que aprender nada mas, tienes todo para crear cualquier juego

Cita de: Braltor date=1472050811 
   
   
      al final con unity se convierte en un ahorro xq no tienes que aprender nada mas, tienes todo para crear cualquier juego
   

Poco a poco vamos viendo cómo se hacen las cosas, ayer ya conseguí poner un fondo en la escena y una nave encima que se mueve con los cursores 

Se ve muy interesante, me gustan los juegos de nave y ya espero la beta, estoy dispuesto en ayudar en lo que sea que nesesites amigo.