Es posible que este post os parezca un poco coñazo, pero os agradecería que os lo leyeseis, igual al principio os aburre un poco pero me haríais un gran favor. Gracias por adelantado.


Como sabéis, el año pasado, junto a otros dos autores, sacamos un libro de introducción a Unity 2017, se que algunos foreros lo compraron (gracias). La idea era haberlo actualizado a la versión 2018 y ampliar sus contenidos, pero por distintos problemas que no vienen al caso, no se ha podido hacer (son cosas que pasan cuando algo pertenece a tres personas y cada uno va por un lado).
 
El caso es que la editorial me ha propuesto escribir uno nuevo y que sea un poco más amplio, unas 400 páginas frentes a las 300 que tenía el anterior. En principio la estructura del libro anterior me parecía bastante buena, que era la siguiente:
 

• 
     Capítulo 1. Introducción a Unity. En este se veían cosas como descargar e instalar Unity, activar la licencia, la estructura de carpetas, crear y abrir un proyecto o el manejo del editor de código.
  


• 
     Capítulo 2. Aspectos básicos. En este capítulo se ve todo lo que es la interfaz de Unity: paneles, ventanas, manejo de la escena, inspector, jerarquía, opciones de proyecto, importación de assets y la consola
  


• 
     Capítulo 3: Scripting. En este se tratan básicamente variables, bucle de juego, input de usuarios, transformaciones, manejos de objetos y depuración, pero no se ven cosas como la herencia.
  


• 
     Capítulo 4. Creación de niveles. Aquí se vé básicamente el editor de terrenos, la importación de modelos 3D, el LOD, la iluminación, en tiempo real, sin bakeados, las cámaras y el audio.
  


• 
     Capítulo 5. Físicas. En este se tratan el RigidBody, los materiales físicos, los colliders, los objetos dinámicos, cinemáticos y estáticos, el character controller, el raycast y los bucles de juego y la escala de tiempo, el tema del Fixed Update y el fixed Tima, el deltaTime y todo eso.
  


• 
     Capitulo 6. Interfaz de usuario. Poco que decir, paneles, canvas, objetos del UI y cosas de esas.
  

Desde la publicación del libro, tengo dos cosas que me están escociendo, son dos capítulos que no se llegaron a incluir por falta de tiempo de la persona que los revisaba, uno, que me parece absolutamente imprescindible es el tema de animaciones (este no llegó a escribirse) y otro fue un juego de ejemplo, utilizando todo lo aprendido que se quedó escrito y abandonado en una carpeta de mi disco duro.
 
Examinando el libro después de casi un año de su publicación y de dos de empezar a escribirlo, veo cosas que me gustaría cambiar, el tema es que las páginas son caras y me parece que es perfectamente posible prescindir de mucho contenido sin el que el lector podría de forma fácil, buscarse la vida el solito y dedicarlo a cosas mas interesantes, llegado a esta conclusión el capítulo 1 me lo cargaría al 75% y el 2 al 50 % lo que implicaría que se recuperarían una treintaytantas páginas sobre los contenidos actuales. Creo que todos los capítulos se pueden aligerar, al menos en un 10%, excepto el de UI, tienen demasiada prosa inútil, se podría ir a la chicha mas directamente y ahí recuperar otras 20 páginas, esto resultaría en 150 páginas reales de nuevos contenidos.
 
Supongo que a estas alturas estaréis preguntándoos: "¿y este tio, para que nos está dando semejante tabarra?", pues la respuesta es fácil, porque el nuevo libro, que empezaré a escribir la semana que viene, con la idea de que su publicación sea para enero o febrero, me gustaría escribirlo con lo que a la gente le gustaría ver o lo que considera importante y con un enfoque lo mas practico posible.
 
En principio, mi idea inicial es la siguiente:
 

• 
     Trabajar sobre un juego, no he decidido si pequeños juegecillos super simples para ver los escenarios, las físicas, etc o uno un poco mas complicado y grande que se amplie fase a fase.
  


• 
     Incluir ademas de los visto en el anterior libro: 
     
  
  
  • 
             Creación de animaciones
          
  
        
  • 
             El Mecanim
          
  
        
  • 
             El Animator 
          
  
        
  • 
             Uso del 2D
          
  
        
  • 
             Crear y desplegar los juegos en Android e iOS,.
          
  
     
  
  

Básicamente me gustaría que quien leyese el libro, fuese capaz de hacer un pequeño juego indie, casual, sencillito de principio a fin y ponerlo en los markets y a partir de ahí seguir avanzando con cosas mas complicadas como shaders, IA,, juegos en red y las cien mil posibilidades más que tiene Unity.
 
Así que lo que me gustaría, es que utilizaseis este hilo como una carta a los Reyes Magos, pidiendo como si no costase, que de momento no cuesta y para quitar siempre hay tiempo, ver coas en las que no he caído, etc. 
 
También para que la gente que ha comprado el libro ponga lo que echó en falta la otra vez y poder, en la medida de lo posible, mejorar esa parte, ya que el libro va a ser reescrito entero, puesto que cambia el enfoque y no soy el completo propietario de los contenidos (yo escribí cuatro de los 6 capítulos e hice los ejemplos, pero otro de los autores los revisó e hizo correcciones y mejoras), asi que aprovechando la reescritura, pretendo mejorarlo en lo posible.
 
Os agradezco que hayáis llegado hasta aquí, es un ladrillo considerable   y os agradezco también las opiniones y sugerencias que dejéis.
 
Mil gracias.

He recomendado tu libro a varios alumnos y a los usuarios de la Comunidad, así que es un placer ayudarte a mejorarlo. 
 
Cosas que creo que puedes repasar, por si te faltan:
 

• 
     Durante la Introducción y Conceptos Básicos sobre Unity3D, veo que, en general, se deja bastante de lado el explicar cómo está estructurado Unity3D y sobretodo el por qué, y cuál es la diferencia con otros motores de videojuegos (no sólo Unreal, sinó cualquiera de los clásicos de compilar código). Algunos alumnos me comentan que se les hace al principio muy raro entender el por qué no hay un Void Main, y ni un código principal como tal...
  


• 
     Omite/Elimina todo rastro de la sección de Terrenos. En unos meses van a implementar el nuevo sistema; es totalmente distinto del que existe, por lo que ese temario no va a servir. 
  


• 
     Ve preparando el setup del Scriptable Render Pipeline, para que los lectores sepan como crear proyectos con cada uno.
  


• 
     Si te cargas la sección de Terrenos, la puedes sustituir completamente por una de PRO-BUILDER. Viene al mismo caso, porque es para hacer "escenarios de juegos", y hay bastante contenido que conviene enseñar.
  


• 
     No sé si llegaste a tocar todo lo del AI/Navigation Mesh, pero por si acaso, amplía el temario con assets de Pathfinding, etc..
  


• 
     Joints y Effectors, mini-apartado dentro de Colliders. No veas la cantidad de gente que me pide hacer según qué cosas con ellos....
  


• 
     Las herramientas del portal online de Unity (Ads, CloudBuild, Metrics,etc). La gente va a tener que acostumbrarse a usarlas a partir de ahora, sí o sí.
  


• 
     Meter en el mismo saco Animator/Meccanim, Animation, importar modelos FBX animados con/sin huesos y animaciones, etc, Timeline y CineMachine. Todo en el mismo apartado. No es que falte en el temario, es que la mayoría de usuarios que vienen con problemas con alguno de estos temas siempre resultan ser Artistas, y lo encuentran todo separado aparte. Conviene que esté todo junto, para una comprensión más lógica. El Timeline no deja de ser un complemento al Animation, así que tiene sentido...
  


• 
     Dentro del Animation, incluir algo sobre los AnimationEvent. A día de hoy encuentro muy poca información sobre ellos en videotutoriales, y es algo súper útil.
  


• 
     Materiales y Shaders, explicados brevemente en la sección de importar modelos,etc, pero sin entrar en detalle. Lo correcto es dedicarles su propia sección aparte, porque la cosa se llega a extender hasta casi un libro propio.
  


• 
     Si te atreves con los Jobs y el ECS, adelante. Yo lo miré por encima, pero aún no me atrevo a dar el paso...
  

 

Cita de: FNP date=1535469407Así que lo que me gustaría, es que utilizaseis este hilo como una carta a los Reyes Magos, pidiendo como si no costase, que de momento no cuesta y para quitar siempre hay tiempo, ver coas en las que no he caído, etc. 
   

Para mi si queres un libro "moderno" y resaltar frente a otros que he leido, un aspecto muy útil (y de la vida real) es NO presentar contenido técnico en el libro, sino enseñar a buscar en el lugar adecuado, realizando esto de forma guiada, basta con mirar este foro, 1 de cada 100 sabe buscar en un manual o en internet (a los 99 restantes , no offense) si el libro es de caracter introductorio no estaría mal decir "Bueno, este es un rigidbody y lo queremos mover, del manual se ve que se puede mover de 2 formas, de la documentación oficial de scripting se ve que existen X métodos que permiten moverlo, vamos a elegir AddForce, que admite tal y tal signature, como necesitamos pasar este parámetro vamos a usar esta signature, Ojo ver que abajo dice "CUIDaDO! nunca usar esto con X cuando Y y Z están presentes" ...  y así poco a poco vas entrenando al lector, no simplemente diciéndole que hacer (como lo hacen todos los libros). Incluso podrías tener un capítulo entero dedicado a esto, pero enseñar a buscar contenido técnico es algo clave que nadie cubre, logicamente por los cambios al acceso de información de los ultimos años, pero igual, ya es hora que esto se tenga en cuenta en todo rubro.
 
Con respecto a los temas que nombraste:
 

1. 
      Mecanim: Acá la verdad no se por donde arrancar, antes (Unity 4) mecanim estaba relacionado a un conjunto de animaciones prestablecidas, (recordaran las del negro de remera blanca corriendo, haciendo parkour) pero ahora llaman a mecanim como el proceso de animación de Animator (?) la verdad no se, Si esto = Animator sí, por supuesto debe estar en tu libro, es el nucleo de la animación (o los estados si te vas por esos lados).
   


2. 
      2D: infaltable, cada vez más cosas están usando 2D, aunque yo soy fan de hacer las cosas directamente en 3D (las 2D) pero están llegando nuevas herramientas cada vez más poderosas y buenas al 2D que resulta imposible no prestarle atención.
   


3. 
      build para Android (sobretodo)/ iOS: probablemente sea el target actual de Unity, todo el mundo quiere hacer apps o juegos para android/iOS, podrías presentar un capitulo practico de como adaptar un juego intencionalmente hecho con controles de teclado y mouse a un dispositivo móvil, y presentar algunas diferencias claves, algunos trucos de optimización, etc. Como introducción mas que nada.
   

Uno que podrías presentar es el pegamento de todo, los Managers en gral, un pequeño "Core" si querés, que se encargue de manejar escenas, guardar el juego, guardar opciones, cosas así estarían más que bien. Solamente dar un vistazo general, con algo de código, aunque quizás sean temas algo más avanzados (?) y requieran de mayor nivel de C#, quizas no.
 
 

Estoy de acuerdo contigo, tengo 400 páginas y como es logico ahí no entra todo, la idea es dar un enfoque practico y enseñar a buscarse la vida, una cosa que me fastidiaba bastante del otro libro era gastar paginas con cosas como «instalar Unity», las paginas son un bien escaso.
 
Las animaciones son esenciales y ese es otro resquemor que me quedo del otro libro, evidentemente tendran que estar, ya veremos en que medida.
 
Totalmente de acuerdo con el 2D, cada vez tiene mas auge.
 
Sobre los builds, tengo un poco de reparo en la publicacion en la Apple Store, porque Apple, aparte de que tienes unos criterios que no veas, cambia el procedimiento cuando quiere y es todo bastante engorroso, ademas de necesitar cuenta de pago, pero al menos si me gustaria incluir la construccion y el testeo con TestFligh, el problema que veo es que eso me puede comer medio libro. Habra que vero despacio.
 
Lo de los managers me parece bien. Eso en realidad es la forma de hacer las cosas en Unity y aunque algo se ve levemente en el otro libro, los demas autores no eran muy partidarios de incluir estos temas por la complejidad.
 
Yo veo el libro como una introducción a Unity, pero no como una introducción ni a la programacion, ni a C#, ni a la orientacion a objetos y entiendo que no es cuestion de estar explicando la diferencia entre clase e instancia, elemento dinámico o estático, interoperabilidad y cosas similares, para eso hay otros libros, igual que tampoco voy a enseñar tecnicas de mapeado con tilesets o algebra lineal para trabajar con vectores en un espacio 3D. Para eso hay otras cosas. No deberia ser un problema encontrarse con esas cosas, porque el lector deberia saber programar y conocer C#.

Cita de: FNP date=1535490983Yo veo el libro como una introducción a Unity, pero no como una introducción ni a la programacion, ni a C#, ni a la orientacion a objetos y entiendo que no es cuestion de estar explicando la diferencia entre clase e instancia, elemento dinámico o estático, interoperabilidad y cosas similares, para eso hay otros libros, igual que tampoco voy a enseñar tecnicas de mapeado con tilesets o algebra lineal para trabajar con vectores en un espacio 3D. Para eso hay otras cosas. No deberia ser un problema encontrarse con esas cosas, porque el lector deberia saber programar y conocer C#.
   

Claro exacto, yo veo a un libro introductorio no necesariamente como "introducción" o "primeros pasos" sino como la puerta principal a varios temas, es obvio que por una parte o capitulo no te vas a hacer experto en algo, pero a veces se valora mucho más alguien que te tire "las puntas" del tema que un libro entero explicando que hace tal cosa en profundidad. Un ejemplo que se me ocurre es "Game Engine Architecture" (https://www.gameenginebook.com/) el libro asume un montón de cosas pero te da un incentivo impresionante para seguir investigando de cada capítulo, quizás esto resulte más valioso para una "introducción". Con el tema de los manager coincido que pasa más por un tema de diseño de código, o patrones de diseño en general, te lo menciono simplemente porque a mi me gustaría ver un libro que no solo meta al lector en la SceneView de Unity sino que lo haga pensar en un juego completo y terminado, y un Core de fondo con managers es indispensable. Tenés pensado meter alguna sección enfocada a publicidad? Admob? etc.

A todo ésto, cuando quieras promocionar el libro, puedes mandarme un banner y lo subo a la web, @FNP...

Gracias @pioj, lo haré. a ver si de momento logro crear un indice aproximado y cerrar los contenidos.
 
Ahora tengo que leer unos artículos que tengo por ahí y ver unos vídeos sobre lo que van a hacer estos de Unity en el futuro, porque barajando fechas, el libro no estará antes de febrero / marzo del año que viene y para esa fecha Unity 2019 estará o en beta, u oyéndose que va a salir y he leído/oído de pasada cosas que me han puesto un poco los pelos como escarpias, como que Unity tiene intención de abandonar Mono y eso puede tener implicaciones muy grandes y no me gustaría que me pillase con el libro escrito y saliese obsoleto o que tuviese que cambiar la mitad, 
 
De todas formas, no he querido tomarme nada de eso al pie de la letra hasta no verlo bien, demasiadas cosas y poco tiempo, ahora que me quedo un poco desahogado me ten go que poner las pilas con mucha documentación que tengo atrasada.
 
No da uno de si

Cita de: FNP date=1535549565y he leído/oído de pasada cosas que me han puesto un poco los pelos como escarpias, como que Unity tiene intención de abandonar Mono y eso puede tener implicaciones muy grandes y no me gustaría que me pillase con el libro escrito y saliese obsoleto o que tuviese que cambiar la mitad, 
   

Te referís a mono develop no? Yo la verdad pensé que Unity ya lo había abandonado, de todas formas, si buscas un excelente reemplazo multiplataforma, digo, para enseñarlo o para uso personal(si es que estás usando monodev) te recomendaría Visual Studio Code. Igual esta parte no va a tener grandes complicaciones para el lector (supongo), es muy fácil de configurar (3 clicks, literalmente) y de ultima se puede consultar en cualquier momento en la web. Puede que quede mejor para el libro pasarse a algo con más "futuro" si se quiere, pero ni te preocupes que no cambia mucho (a fines prácticos).

No, juraría que leí Mono, lo ponía muy genéricamente, pero lo entendí mas como que se refería a la implementación de código abierto de .net, el mono develop al fin y al cabo es una herramienta para editar y depurar y puedes usar cualquier otra cosa, hasta el bloc de notas y la consola  
 
De todas formas, sobre esto ya empezó a hacer cosas con la 2018: https://blogs.unity3d.com/es/2018/01/05/discontinuing-support-for-monodevelop-unity-starting-in-unity-2018-1/ asi que no le veo demasiado futuro al Mono Develop, aparte de que en Mac funciona fatal.
 
De todas formas, ya te digo no se si lo lei de pasada o lo vi en un vio, rápidamente, en inglés y lo mismo (seguramente) ni me enteré como es debido, lo tengo que ver con calma. mientras tanto lo tengo como rumor.

Cita de: FNP date=1535565930No, juraría que leí Mono,
   

Keep calm 

Hola Fernando (FNP). Justamente tengo aquí al lado tu libro. Este verano me he puesto con él y estoy casi acabando. 
 
Soy totalmente nuevo en Unity aunque muy viejo en programación e informática. 
 
Te comento como novato de Unity. 
 
El libro está muy bien. Lo más destacable que veo es que hay mucha prosa y pocos ejemplos. 
 
Explicas los temas muy bien. Entendemos qué se puede hacer con Unity pero para rematarlo lo ideal sería añadir ejemplos para poner en práctica lo aprendido.
 
También echo de menos la explicación paso a paso de un juego de ejemplo. Paso a paso. Para saber exactamente el porqué de muchas cosas explicadas. 
 
 
 
Añadiría también (por pedir...) más información relacionada con el 2D. Justamente son los juegos que me gustan!!!! En 2D y bien pixelados  
 
 
 
Por último puntualizar mi percepción del libro. Yo lo encuentro un libro muy recomendable para un novato como yo. Me has explicado muchos conceptos y características de Unity que desconocía (normal, es mi primer contacto con este software). 
 
Lo veo más como un libro de consulta que como un curso o guía (quizás esa fue vuestra intención, claro). 
 
Ahora, sabiendo lo que puedo hacer, cuando tenga alguna duda miraré el libro incluso antes de buscar en Internet. 
 
Quizás un libro en formato de curso o guía paso a paso creo (yo, personalmente) que sería más práctico. 
 
Ahora tengo mucha teoría y muy poca práctica. 
 
Lo dicho, como libro de iniciación y consulta lo veo fantástico.
 
Evidentemente abarcar todos los temas de Unity es imposible para un libro. Son muchos temas, muy extensos y con muchísimas ramificaciones. 

Hola, tengo aquí tu libro (me lo regaló mi novia, junto a uno de blender) y, por no repetirme mucho respecto a anteriores y a ti mismo, estoy de acuerdo en general en que les falta un poco de "literatura", no se, mas metáforas del tipo "Imagínate dos bolas de billar en una mesa, cuando una golpea la otra..." o " Piensa en los coches teledirigidos, imagina que la z la empujas con la palanquita de la izquierda..." y cosas así, si necesitas un cable, estoy en el punto intermedio perfecto entre escritor y diseñador de videojuegos

Cita de: Capa date=1535748524También echo de menos la explicación paso a paso de un juego de ejemplo. Paso a paso. Para saber exactamente el porqué de muchas cosas explicadas. 
   

Ese fue uno de mis grandes cabreos cuando se publicó, junto al de las animaciones, porque ese capítulo esta escrito y abandonado en mi PC, pero por  tamaño y falta de tiempo para su revisión (pues habría podido incluirse como contenido descargable), finalmente no se incluyó.
 
Estoy totalmete de acuerdo con el 2D que irá en el nuevo.
 

Cita de: CastGames date=1535765194estoy de acuerdo en general en que les falta un poco de "literatura", no se, mas metáforas del tipo "Imagínate dos bolas de billar en una mesa, cuando una golpea la otra..." o " Piensa en los coches teledirigidos, imagina que la z la empujas con la palanquita de la izquierda..." y cosas así, 
   

Precisamente yo creo que le sobra literatura y que debería ir mas a la chicha y mas que utilizar la metáfora, que si examinas el libro con detenimiento, la usa mucho, debería más trabajar sobre e ejemplo práctico y centrarse más en aspectos de construcción, como explicaba @lightbug en su post, no tanto explicar la vida, historia y circunstancias de un RigidBody, sino que es, para que se usa, cuando y como usarlo, y como buscarse la vida para cuando lo necesites usar. Todo esto con un ejemplo comentado donde se vaya viendo como montar todas las estructuras de un juego utiliza internamente.

Cita de: FNP date=1535972239Precisamente yo creo que le sobra literatura y que debería ir mas a la chicha y mas que utilizar la metáfora, que si examinas el libro con detenimiento, la usa mucho, debería más trabajar sobre e ejemplo práctico y centrarse más en aspectos de construcción, como explicaba @lightbug en su post, no tanto explicar la vida, historia y circunstancias de un RigidBody, sino que es, para que se usa, cuando y como usarlo, y como buscarse la vida para cuando lo necesites usar. Todo esto con un ejemplo comentado donde se vaya viendo como montar todas las estructuras de un juego utiliza internamente.
   

Si al final hablamos de lo mismo: De que sea mas viable ver el funcionamiento de todo con ejemplos, bien sean reales o figurados. De paso añadiré que hay algunas foticos en las que no se lee un carajo.