Podcast – Chromaticity Engine.
Decidí hacer un podcast sobre mi nuevo engine. Es un podcast de 32 minutos donde hablo sobre el diseño del engine nuevo y las diferencias con el anterior. Como es el primer podcast en la pagina es una prueba pero si hay interés voy a seguir haciendo podcast porque para mi es muy fácil de grabar y me es mucho mas fácil que escribir.
Pueden bajar el podcast de http://www.pablo-zurita.com.ar/podcasts/ChromaPodcast.mp3
Buenas,
Podrías usar alguno de los tantos “chiches” que hay por allí para escuchar el mp3 directamente desde la web
Esta web tiene muchas cosas: http://www.stratos-ad.com/forums3/search.php?search_id=newposts
Comentario por Josepzin — Junio 29, 2006 @ 6:56 am
Gracias por el comentario. Aunque yo personalmente prefiero bajar los mp3 porque los escucho en el WinAmp/Xmms o en mi mp3 player, pero reconozco que hay gente que prefiere escucharlo directamente en la página así que ahí lo agregue. Y si, soy miembro del foro de Stratos.
Comentario por Pablo Zurita — Junio 29, 2006 @ 3:24 pm
No he terminado de escuchar el podcast. Me parece bastante interesante, sin embargo hay cosas que mejoraría:
- Tendría claro el guión. Lo digo porque al comienzo explicas un poco el porqué, pero te lías a dar vueltas a lo mismo y además hablas de tu antiguo motor sin hacer una introducción del mismo previa.
- Marcaría claramente las diferentes partes. Cuando estás en una conferencia siempre está el apoyo de un ppt o transparencias, si embargo aquí si no estás muy centrado te despistas.
Por otro lado espero que pongas en tu weblog un esquema y hables en detalle del kernel que comentas. Cuando termine de escucharte te haré alguna sugerencia más.
Espero que sigas haciendo podcast y que los hagas de temas más concretos
.
Comentario por javi — Junio 29, 2006 @ 4:39 pm
1) Es verdad, pero igual la idea de hacer un podcast es que mientras lo grabo puedo seguir trabajando. No creo que vaya a hacer un podcast estructurado como si fuera un programa de radio, pero espero no dar tantas vueltas. Igual la mayoría va a mejorar según vaya grabando más podcasts.
2) El tema es que hacer eso toma mas tiempo y por eso después me veo haciendo actualizaciones una vez cada dos meses. Haciendo así puedo grabar cuando quiero sin perder tiempo, seguro que esto va a mejorar con el tiempo pero lo voy a tener en cuenta al momento de grabar.
3) En esta semana voy a grabar dos podcasts más y después voy a escribir la definición básica del kernel. El tema es que llevo solamente dos semanas de trabajo, todo puede evolucionar de una manera diferente. Pero cuando vea que esta todo un poco mas estable voy a escribir sobre el tema.
Muchas gracias por los comentarios.
Comentario por Pablo Zurita — Junio 29, 2006 @ 5:01 pm
Tampoco me refiero a hacer un programa de radio, pero sí a tener delante un papel con 4 ó 5 puntos bien diferenciados. Eso no lleva más que medio minuto y permite expresar las cosas con más claridad.
Espero esos podcast
Comentario por javi — Junio 29, 2006 @ 6:33 pm
Realmente interesante. El diseño de nodos genéricos parece una buena idea; si no recuerdo mal el motor ogre también lo implemente y es bastante efectivo.
Tengo curiosidad por la parte de la lógica del juego… ¿le has dado vueltas a cómo implementar los estados de los nodos?, ¿delegar a los nodos que gestionen su propia lógica o un sistema más general que los lleve a todos pasándoles mensajes de unos a otros?, ¿quizá la posibilidad de scriptear cosas desde fuera?
¡Enhorabuena por el podcast!
Comentario por cobo — Julio 1, 2006 @ 8:19 am
El motor no esta pensado para ningún tipo de aplicación especifica. Por lo tanto no hay nada en específico en el motor que tenga que ver con juegos (o cualquier otro tipo de aplicación). Mi idea es que si en algún momento decido hacer un juego todo la lógica y demás cosas especificas al juego estén en la aplicación cliente del motor, o a lo sumo como una librería del motor que no sea requerida sino que sea una extensión a la que podes linkear si así se desea. Por eso la idea es que el cliente mantenga su propio sistema de lógica y lo único que hace el motor es renderizar a audio/video lo que esta pasando internamente. Con respecto al scripting no estoy seguro que lenguaje elegir. AngelScript es muy bueno en general sobretodo porque la sintaxis es similar a C++, que es muy bueno para el desarrollador usando el engine ya que el engine en si usa C++. Pero por otra parte he escuchado muy buenos comentarios de Python sobretodo en el tema del debugging. Pero cuando llegue el momento de implementar el scripting voy a mirar de nuevo las opciones disponibles y buscar lo que sea mejor.
Comentario por Pablo Zurita — Julio 1, 2006 @ 3:52 pm
Hola Pablo,
Otro lenguaje que empieza a llamar la atención por ahí, con sintaxis de C++, pero tirando más por el lado de lo dinámico (en la línea de Python, Ruby, pero Lua sobre todo), es http://squirrel-lang.org/
No tuve oportunidad de probarlo todavía, pero ganas no me faltan, y algunos ‘desarrolladores amigos’ lo recomiendan fervientemente.
Saludos!
Comentario por Hernán Moraldo — Septiembre 21, 2006 @ 1:53 pm